1 Repetition av viktiga begrepp inom objektorienterad programmering

Transkript

1 Repetition av viktiga begrepp inom objektorienterad programmering 1 1 Repetition av viktiga begrepp inom objektorienterad programmering U 1. U 2. U 3. U 4. U 5. En referensvariabel har en viss deklarerad typ (klass). Den får då referera till objekt av denna klass eller till subklasser till denna. Därför är satserna 1, 2, 4, och 6 korrekta. Resten är felaktiga. info får i tur och ordning följande värden: "Lisa Svensson", "Lisa Svensson, D", "Kalle Karlsson, C" och "Per Holm, Computer Science". Förklaring till den andra tilldelningen: p har deklarerad typ Person, men refererar här under exekvering till ett objekt av typen Student. Det blir därför metoden tostring() i klassen Student som exekveras. Förklaring till fjärde tilldelningen: p refererar här till ett objekt av typen FacultyMember. Det beror på vilken typ av objekt ref refererar till under exekveringen. Om ref refererar till ett objekt av subklassen, så blir det metoden p där som exekveras, annars blir det p i klassen C. Alternativ 1 och 4 är korrekta. Korrekt antal parametrar skickas med till konstruktorn i bägge fallen. Eftersom Shape är superklass till Square får s referera till Square-objekt. I alternativ 2 stämmer inte antal parametrar. Alternativ 3 är fel eftersom man inte kan skapa objekt av abstrakta klasser. Vektorelementet theshapes[i] har den deklarerade typen Shape. Vid kompileringen söks därför efter en metod draw() i klassen Shape. Men någon sådan metod finns inte. Lösningen är att deklarera draw som en abstrakt metod i klassen Shape: public abstract void draw(); U 6. U 7. U 8. a) Statiska attribut och metoder är knutna till en klass, inte till ett objekt. De finns bara i en upplaga per klass. I detta fall har man valt att deklarera attributet static eftersom (vi antar att) alla personer har samma lagstadgade pensionsålder. I statiska metoder kan man inte komma åt icke-statiska attribut eller metoder. I vanliga (icke-statiska) metoder kan man komma åt både vanliga attribut och metoder och statiska attribut och metoder. Metoderna setseniorage och getseniorage kan alltså implementeras som antingen vanliga metoder eller (som här) statiska metoder. Man föredrar dock att deklarera metoder som statiska när så är möjligt. Detta beror på att vanliga attribut och metoder har en (implicit) referens till det objekt de är knutna till. Detta är onödigt i de fall vi bara hanterar statiska attribut (eller inga attribut alls). b) I det första fallet använder man sig av klassnamnet (Person) för att referera till det statiska attributet. I det andra fallet använder man sig av ett objekt av klassen för att komma åt samma attribut. Båda är korrekta men man brukar föredra att använda klassnamnet. c) Det statiska attributet ändrar värde till 65 genom satsen p.setseniorage(65). Ett statiskt attribut är gemensamt för alla objekt av klassen Person. Därför skrivs 65 ut. 2 skrivs ut. Förklaring: När en parameter förs över till en metod kopieras den. Inuti metoden incr är det kopian som ökas med 1. "Lisa" skrivs ut. Förklaringen är densamma som i föregående uppgift. Metoden har en referensvariabel som parameter. När referensen p förs över som parameter, kopieras den. Vi kan kalla kopian pcopy. Eftersom den är en kopia på p så refererar den först till samma

2 2 Repetition av viktiga begrepp inom objektorienterad programmering objekt som p (Lisa). Inuti metoden får sedan referensen pcopy ett nytt värde. Den refererar nu till ett annat objekt. Men p ändras inte. U 9. Som ovan, p kopieras och vi kan igen kalla kopian pcopy. pcopy refererar till personobjektet som har namnet "Lisa". I metoden anropas sedan metoden setname för den person som pcopy refererar till. Det resulterar i att denna person får nytt namn, "Kalle". Därför kommer "Kalle" att skrivas ut. U skrivs ut. I Java är vektorer objekt. Vi kan alltså uppfatta a som en referens till det objekt som representerar vektorn. Förklaringen är sedan densamma som i föregående uppgift: När vi anropar metoden är det egentligen en kopia av referensen som används i metoden. Men den refererar till samma vektorobjekt. U 11. Vektorn nbrs1 innehåller 10, 20, 30, 40, 50 och nbrs2 innehåller 50, 40, 30, 20, 10. I bägge metoderna avser man att vända på elementen i vektorn a så att de kommer i omvänd ordning. Men metoden r1 innehåller ett fel så att vektorn förblir oförändrad. När referensen nbrs1 vid anropet av r1 förs över som parameter, kopieras den till a. a refererar alltså först till samma vektor som nbrs1. Inuti metoden får sedan a ett nytt värde och refererar nu till temp-vektorn. Men innehållet i nbrs1 ändras inte. När r2 anropas kopieras referensen till vektorn nbrs2 till a. När vi inuti metoden ändrar i vektorn a är det i själva verket vektorn nbrs2 som ändras.

3 Polymorfism, skuggning och överlagring av metoder 3 2 Polymorfism, skuggning och överlagring av metoder U 12. Klassdiagram: A <<interface>> I B <<interface>> J C B är subtyp till A och I. J är subtyp till I. C är subtyp till J och B och därför även till A och I. U 13. Klassdiagram: <<interface>> IA <<interface>> IB C 1 är korrekt ty C implementerar IA. 2 är fel, C implementerar inte IB. 3 är korrekt ty IB är subtyp till IA. 4 är inte korrekt ty IA är inte subtyp till IB. 5 är korrekt, deklarerad typ för c är C och högerledet är ett objekt av typ C. 6 år inte korrekt, högerledet är av typ IA som inte är subtyp till C. 7 är fel ty högerledet är inte subtyp till C. U 14. Metodanrop 1 och 4 är korrekta. Här råder tilldelningskompatibilitet mellan respektive aktuella och formella parametrar. 2 är fel ty den andra parametern uppfyller inte kravet på tilldelningskompatibilitet. 3 är fel av samma skäl. 5 är också fel. p1 har deklarerad typ Person och den andra aktuella parametern uppfyller därför inte kravet på tilldelningskompatibilitet. U 15. Metodens signatur är dess namn tillsammans med antalet parametrar och deras typer. U 16. Med skuggning (eng: override) menas att det finns metoder med samma signatur i en klass och i någon av dess superklasser eller subklasser. Exempel: metoden tostring i exemplet med klasserna Person och dess subklasser från övningsuppgifter 1. U 17. Metoder som har samma namn men olika signatur (t. ex olika antal parametrar eller olika typer på sina parametrar) sägs överlagra (eng: overload) varandra. Exempel: metoden append i klassen StringBuilder. Ett annat exempel på överlagring är när klasser har flera olika konstruktorer. Se till exempel dokumentationen för klassen ArrayList.

4 4 Interface, exceptions, generik, iteratorer 3 Interface, exceptions, generik, iteratorer U 18. Ett interface innehåller bara metodrubriker utan implementeringar (publika, abstrakta metoder). Man får också ha konstanter (attribut deklarerade static final). Ett interface utgör ett kontrakt mellan klasser som implementerar det och dess användare. En klass som implementerar ett interface måste implementera alla de abstrakta metoderna i interfacet. U 19. Både abstrakta klasser och interface innehåller (oftast) abstrakta metoder. Man kan inte skapa objekt av interface eller av abstrakta klasser. Ett interface innehåller bara metodrubriker, dvs. abstrakta metoder och ev. konstanter. En abstrakt klass kan (precis som en vanlig klass) innehålla attribut, konstruktorer och andra metoder. U 20. a) Lägg till implements Resizable i klassrubriken och implementera metoden downsize. public class Rectangle implements Resizable { private double height; private double width; public Rectangle(double h, double w) { height = h; width = w; public void downsize(int scalefactor) { height = height / scalefactor; width = width / scalefactor;... b) 1 och 3 är korrekta. Alternativ 2 är fel eftersom man inte kan skapa objekt av interface. U 21. a) /** * Scales down the object with scalefactor. scalefactor the scale factor which is used to reduce the * size of the object IllegalArgumentException if the specified scale factor is <= 0 */ public void downsize(int scalefactor) { if (scalefactor <= 0) { throw new IllegalArgumentException("The scale factor has the wrong value: " + scalefactor); height = height / scalefactor; width = width / scalefactor; b) try { r.downsize(n); catch (IllegalArgumentException e) { System.out.println(e.getMessage());

5 Interface, exceptions, generik, iteratorer 5 U 22. /** Returns true if this collection contains the specified element. */ public boolean contains(object x) { for (int i = 0; i < size; i++) { if (thecollection[i].equals(x)) { return true; return false; /* Creates an new array that is twice the size of the current array and copies the content of the current array into the new one. */ private void doublearray() { E[] tmp = (E[]) new Object[2 * thecollection.length]; for (int i = 0; i < size; i++) { tmp[i] = thecollection[i]; thecollection = tmp; Alternativ implementering av doublearray: private void doublearray() { E[] tmp = (E[]) new Object[2 * thecollection.length]; System.arraycopy(theCollection, 0, tmp, 0, size); thecollection = tmp; U 23. Inuti metodencontains anropas metodn equals för att jämföra två objekt. I contains har den formella parametern x den deklarerade typ Object. För anropet thecollection[i].equals(x) kommer därför kompilatorn att bestämma signaturen för metoden att vara equals(object x). När vi exekverar metoden refererar thecollection[i] till ett objekt av typen Person. Då börjar sökandet efter en metod med korrekt signatur i denna klass. Det finns ingen sådan. Då fortsätter letandet i superklassen, som i detta fall är Object. Där finns en metod med rätt signatur, som exekveras. Metoden equals i Object är emellertid implementerad så att den returnerar true om och endast om de båda jämförda objekten är identiska, vilket inte är fallet här. Problemet är alltså att metoden equals i klassen Person överlagrar metoden equals i klassen Object men inte skuggar den. För att hitta Lisa skall vi i stället skugga metoden equals(object) i klassen Person. Det gör vi genom att ge den samma signatur som equals i klassen Object: public class Person { String name;... public boolean equals(object p) { return name.equals(((person) p).name);... Kompilatorn kommer att göra samma beslut som beskrivits ovan. Skillnaden är nu att under exekvering hittas en metod med rätt signatur i klassen Person och det blir därför denna som exekveras.

6 6 Interface, exceptions, generik, iteratorer Anm. Det kontrakt som finns för metoden equals i Java innebär bl. a: Om x inte är null ska x.equals(null) returnera false. Om x och y är av olika klasser ska x.equals(y) returnera false. Metoden equals i klassen Person kan därför se ut så här: public boolean equals(object p) { if (p instanceof Person) { return name.equals(((person) p).name); else { return false; Uttrycket p instanceof Person returnerar true om p:s typ är Person eller någon subklass till Person. Uttrycket returnerar false om p har värdet null. Lösningen tillåter alltså att subklasser ärver equals-metoden. Man kan använda equals i en arvshieariki och jämföra subklassobjekt och superklassobjekt. Denna lösning kan dock leda till fall där equals inte uppfyller kraven i specifikationen. Detta undviks om man bara tillåter jämförelser mellan objekt av samma typ: public boolean equals(object p) { if (p == this) { return true; if (p == null) { return false; if (this.getclass()!= p.getclass()) { return false; return name.equals(((person) p).name); U 24. Interfacet Iterable<E> har en enda metod: Iterator<E> iterator(). Klasser som implementerar detta interface måste alltså ha en operation som returnerar ett objekt av en klass som implementerar interfacet Iterator<E>. Klasser som implementerar Iterable<E> representerar olika slags samlingar av element och operationen iterator() ger användare av klassen tillgång till en iterator för elementen, d.v.s. användaren får möjlighet att traversera samtliga element i samlingen. Det objekt som returneras måste vara av en klass som implementerar interfacet Iterator<E> som innehåller operationerna hasnext() och next(). Det är genom anrop av dessa operationer som traverseringen kan genomföras. U 25. a) Iterator<Person> itr = coll.iterator(); while (itr.hasnext()) { System.out.println(itr.next()); b) for (Person p : coll) { System.out.println(p);

7 Interface, exceptions, generik, iteratorer 7 U 26. Lägg till metoden iterator som ska skapa och returnera ett iterator-objekt. Iteratorklassen (en klass som implementerar interfacet iterator måste också skrivas. Den placeras lämpligen som en inre klass inuti samlingsklassen. public Iterator<E> iterator() { return new ArrayIterator(); private class ArrayIterator implements Iterator<E> { private int pos; private ArrayIterator() { pos = 0; public boolean hasnext() { return pos < size; public E next() { if (hasnext()) { E item = thecollection[pos]; pos++; return item; else { throw new NoSuchElementException(); public void remove() { throw new UnsupportedOperationException(); U 27. Då skulle man bara kunna iterera över elementen en enda gång (det finns ingen operation för att sätta tillbaks positionen). Även om vi införde ytterligare en metod first() för att sätta tillbaks positionen skulle det vara en dålig lösning. Man kan bara ha en position i taget i samlingen. Det finns många algoritmer som behöver mer än en position för att t.ex jämföra element med varandra. Om vi i stället har en iteratorklass och en metod som returnerar ett objekt av denna klass löses båda problemen. Vill man göra en ny iteration skapar man ytterligare ett objekt av iteratorklassen genom att anropa operationen iterator. Olika instanser av klassen kan ha olika positioner.

8 8 Listor 4 Listor U 28. I implementeringen av dessa klasser används metoden public boolean equals(object x) för jämförelser. Denna metod finns i klassen Object. Där är den implementerad så att ett anrop x.equals(y) ger true om och endast om x och y är identiska (samma) objekt. Man vill oftast definiera likhet mellan element som man sätter in i samlingar på annat sätt. T.ex. jämföra ISBN-nummer för böcker. Det åstadkommer man genom att i sina egna klasser överskugga metoden equals. U 29. Inuti de metoder i listklassen som innehåller någon slags sökning används metoden equals för att jämföra om två element är lika. Därför måste man i Book skugga metoden equals: public class Book {... public boolean equals(object rhs) { if (rhs instanceof Book) { return isbn.equals(((book) rhs).isbn); else { return false; U 30. if (list.contains(new Book(" ", null, null))) { System.out.println("Boken finns"); Anm. Om man vill använda det sökta Book-objektet kan man istället anropa indexof. U 31. SingleLinkedList<Integer> list = new SingleLinkedList<Integer>(); list.addfirst(3); list.addfirst(2); list.addfirst(1); U 32. a) /** Returns the first element in this list. Throws NoSuchElementException if this list is empty. */ public E getfirst() { if (first == null) { throw new NoSuchElementException(); return first.element; b) /** Returns the last element from this list. Throws NoSuchElementException if this list is empty. */ public E getlast() { if (first == null) { throw new NoSuchElementException(); ListNode<E> n = first; while (n.next!= null) { n = n.next; return n.element;

9 Listor 9 U 33. /** Returns true if this collection contains the specified element. */ public boolean contains(object x) { ListNode<E> n = first; while (n!= null) { if (n.element.equals(x)) { return true; n = n.next; return false; U 34. /** Removes the first occurrence of the specified element from this list, if it is present. If this list does not contain the element, it is unchanged. Returns true if this list contained the specified element (or equivalently, if this list changed as a result of the call). */ public boolean remove(object e) { if (first == null) { return false; if (first.element.equals(e)) { first = first.next; return true; ListNode<E> pre = first; ListNode<E> n = first.next; while (n!= null) { if (n.element.equals(e)) { pre.next = n.next; return true; pre = n; n = n.next; return false; U 35. Om man låter OrderedList ärva LinkedList så får användare tillgång till alla publika metoder i LinkedList. Använder man vissa av dessa kan man förstöra ordningen i listan. Exempel på en sådan metod är add(int index, E obj). U 36. /** Removes the first occurrence of the specified element from this list, if it is present. If this list does not contain the element, it is unchanged. Returns true if this list contained the specified element (or equivalently, if this list changed as a result of the call). */ public boolean remove(e obj) { ListIterator<E> itr = thelist.listiterator(); while (itr.hasnext()) { E e = itr.next(); if (e.compareto(obj) == 0) { itr.remove(); return true; if (e.compareto(obj) > 0) { return false; return false;

10 10 Listor U 37. Om det hade funnits en operation som returnerar en ListIterator så skulle en användare kunna förstöra ordningen i listan. I interfacet ListIterator finns ju en operation add som sätter in ett element i den position man befinner sig. U 38. Genom att skriva <E extends Comparable<E>> istället för <E> kräver man att de element som ska lagras i listan kan jämföras med metoden compareto. Dvs elementens typ måste vara en klass som implementerar interfacet Comparable. U 39. public class Patient implements Comparable<Patient> { private String firstname; private String lastname; private int prio; public Patient(String firstname, String lastname, int prio) { this.firstname = firstname; this.lastname = lastname; this.prio = prio; public int compareto(patient rhs) { if (prio == rhs.prio) { return 0; else if (prio < rhs.prio) { return -1; else { return 1; public boolean equals(object rhs) { if (rhs instanceof Patient) { return compareto((patient) rhs) == 0; else { return false;... Anm. Om man vet att prioriteterna alltid är positiva heltal (dvs. ingen risk för overflow) kan compareto implementeras på följande sätt: public int compareto(patient rhs) { return prio - rhs.prio; U 40. public int compareto(patient rhs) { int comp = lastname.compareto(rhs.lastname); if (comp!= 0) { return comp; else { return firstname.compareto(rhs.firstname);

11 Stackar och köer 11 5 Stackar och köer U 41. En samling element där det element som satts in först är det element som först tas bort ( first-in-first-out ). De viktigaste operationerna på en kö är: sätta in ett element sist i kön ta bort och returnera första elementet i kön undersöka om kön är tom U 42. En samling element där insättning och borttagning sker överst på stacken. D.v.s. det element som satts in senast är det element som först tas bort ( last-in-first-out ). De viktigaste operationerna på en stack är: lägga ett element överst på stacken push ta bort och returnera översta elementet pop returnera översta elementet peek undersöka om stacken är tom U 43. Att delegera till LinkedList innebär att man gör så här: public class Stack<E> { private LinkedList<E> thestack;... och sedan implementerar alla operationer i stack-klassen genom att anropa motsvarande operationer i listan. Att använda en enkellänkad lista innebär att vi gör som i SingleLinkedList, d.v.s. vi inför en (nästlad) klass som representerar noder i listan och implementerar sedan stackoperationerna p.s.s. som operationerna addfirst() och removefirst(). Att använda en vektor innebär att vi gör så här: public class Stack<E> { privatee[] thestack; private int size;... och sedan implementerar stackoperatiorna genom att lägga till resp. ta bort element i vektorn. U 44. Fördelen är att klassen LinkedList är färdig och testad. Nackdelen är att vi får tillgång till alldeles för många operationer som inte hör hemma i en stackklass. Råkar vi av misstag använda fel metod kan vi förstöra vår stack. U 45. Vi tömmer kön, och lägger elementen på en stack. Sedan tömmer vi stacken och lägger elementen i kön. Stack<E> s = new MyStack<E>(); while (!q.isempty()) { s.push(q.poll()); while (!s.isempty()) { q.offer(s.pop());

12 12 Stackar och köer U 46. public class Dequeue<E> { private Node<E> first; private Node<E> last; // refererence to the first element // refererence to the last element /** Creates an empty dequeue. */ public Dequeue() { first = last = null; /** Inserts the specified element at the beginning of this dequeue. */ public void addfirst(e x) { Node<E> n = new Node<E>(x); if (first == null) { first = last = n; else { n.next = first; first = n; /** Inserts the specified element at the end of this dequeue. */ public void addlast(e x) { Node<E> n = new Node<E>(x); if (first == null) { first = last = n; else { last.next = n; last = n; /** Removes and returns the first element in this dequeue. Returns null if this dequeue is empty. */ public E removefirst() { if (first == null) { return null; else { E temp = first.element; first = first.next; if (first == null) { last = null; return temp; /** Removes and returns the last element in this dequeue. Returns null if this dequeue is empty. */ public E removelast() { if (first == null) { return null; else { E temp = last.element; if (first == last) { first = last = null; else { Node<E> p = first; while (p.next!= last) { p = p.next; last = p; p.next = null;

13 Stackar och köer 13 return temp; private static class Node<E> {... given i uppgiftsformuleringen... U 47. a) En statisk klass deklarerad i en klass C har inte tillgång till typparametern i den omgivande klassen. Den har inte heller direkt tillgång till icke-statiska attribut eller icke-statiska metoder i C. Däremot kan den, komma åt statiska attribut och statiska metoder i C. En inre klass har tillgång till allt i den omgivande klassen (även det som deklarerats private). Nodklassen har i detta fall deklarerats statisk eftersom den inte behöver tillgång till någonting i den omgivande klassen. När det är lämpligt att deklarera en klass inuti en annan finns det alltså två fall: Man har ett behov av att använda attribut eller metoder eller modifiera attribut i den omgivande klassen. Då kan den nästlade klassen inte vara static Man behöver inte accessa någonting i den omgivande klassen. Då kan den nästlade klassen deklareras static. Det är inte fel att även i dessa fall deklarera den icke-statisk. En icke-statisk nästlad klass (inre klass) har emellertid alltid en implicit referens till det objekt av den omgivande klassen som den hör ihop med. Dessa referenser är onödiga om man inte tänker använda något från omgivningen. Därför brukar man deklarera nästlade klasser som statiska när det är möjligt. b) Ja det går bra. Se dock punkt 2 i föregående deluppgift. Om vi låter nodklassen bli en inre klass behöver den inte längre vara generisk. Vi kan i så fall deklarera den på följande sätt: private class Node { E element;... Det E som används i deklarationen av attributet element binds nu till typparametern E i den omgivande klassen Dequeue. U 48. Det skall finnas test av alla operationer. Alla operationer skall testas både för specialfall och normala fall. Vad som är specialfall beror på vad det är vi implementerar. För samlingar är en god regel att testa alla operationer för storlek 0,1,2,många. För vår kö kan det tolkas som att vi testar operationerna på en tom kö och på köer med ett element, två element med ett lite större antal element. Mot denna bakgrund kan vi definiera en rad fall som bör testas utgående från en från början tom dequeue: Två test som anropar removefirst respektive removelast. I dessa kontrollerar man att null returneras (eller att ett undantag genereras, beroende på hur man specificerat beteendet för dessa operationerna när de anropas på tom kö). Två test som gör ett anrop addfirst. Det ena kontrollerar sedan att removefirst returnerar det insatta elementet. Det andra testet kontrollerar att removelast returnerar det insatta elementet. Två test som gör ett anrop addlast. Det ena kontollerar sedan att att removefirst returnerar det insatta elementet. Det andra testet kontrollerar att removelast retur-

14 14 Stackar och köer nerar det insatta elementet. Test som sätter in två element och konrollerar att de hamnar i rätt ordning. Här bör man kolla alla kombinationer av att sätta in två element genom addfirst och addlast och att ta ut dem med removefirst och removelast. Test som gör flera insättningar och flera borttagningar och genom borttagningarna kollar att elementen hamnade i kön i avsedd ordning. Här kan man naturligtvis inte prova alla kombinationer, men ett par fall bör vara med. Ex på ett sådant test: q.addfirst(e1); q.addfirst(e2); q.addlast(e3); q.addlast(e4); kontrollera att q.removefirst returnerar e2 kontrollera att q.removelast returnerar e4 kontrollera att q.removelast returnerar e3 kontrollera att q.removelast returnerar e1

15 Algoritmers effektivitet, tidskomplexitet 15 6 Algoritmers effektivitet, tidskomplexitet U 49. Med tidskomplexitet menar vi ett mått på hur tidsåtgången växer som en funktion av problemets storlek. Vi är inte intresserade av tid mätt i millisekunder e.d. eftersom detta ändå blir olika på olika datorer. I stället mäter vi komplexiteten genom att reda ut hur många basala operationer en algoritm utför. På detta sätt får vi möjlighet att jämföra algoritmers effektivitet med varandra. Vi får också möjlighet att avgöra om algoritmen kan användas på stora probleminstanser eller om det kommer att ta orimligt lång tid (t.ex. om tidskomplexiteten är exponentiell). U 50. a) Den yttre loopen genomlöps n gånger. För varje gång exekveras den inre loopen två gånger. SimpleStatement kommer att exekveras 2n gånger. Komplexiteten är O(n). b) Den yttre loopen genpmlöps n gånger. För varje gång exekveras den inre loopen n/2 gånger. Det blir totalt n n/2 gånger som SimpleStatement exekveras. Tidskomplexiteten är O(n 2 ). c) Den yttre loopen exekveras för i = 1, 2,..., n. När i = k i den yttre loopen exekveras den inre loopen för j = n, n 1,...k d.v.s. (n k + 1) gånger. Satsen i den inre loopen kommer alltså att exekveras n + (n 1) + (n 2) = n(n + 1)/2. Algoritmen har tidskomplexitet O(n 2 ). d) Den innersta if-satsen kommer att exekveras n 2 gånger. Satsen SimpleStatement kommer bara att exekveras när i i den yttre loopen är lika med j i den inre loopen d.v.s. när i = j = 1, 2,..., n. Den exekveras alltså totalt n gånger. Men algoritmens tidskomplexitet är O(n 2 ) ty if-satsen utförs n 2 gånger. U 51. Vi antar att det finns n element i kön. a) addfirst och removefirst blir O(1). addlast blir O(n), man måste ju leta upp sista elementet. removelast blir O(n) av samma skäl. b) Nu blir addfirst, removefirst och addlast O(1). removelast blir O(n) ty vi måste leta upp näst sista elementet i listan, dels för att ta bort det sista elementet, dels för att uppdatera referensen till sista elementet. c) Om en dequeue representeras av en referens till första noden och en referens till sista noden i en dubbellänkad lista blir alla operationerna O(1). U 52. Därför att tiden för samma algoritm kommer att bli olika på olika datorer. Om den teoretiska tidskomplexiteten är T(n) så är den verkliga tidsåtgången t(n) c T(n) där c är tidsåtgången för de operationer som utförs T(n) gånger. U 53. Eftersom tidskomplexiteten är O(n) så gäller det att t(n) = c n för någon konstant c. Vi kan bestämma värdet på c för den dator där algoritmen exekverats ur sambandet c 100 = 1 vilket ger c = 1/100. Eftersom t(n) = c n kommer ett problem av storleken 1000 att ta c 1000 ms. Om vi nu sätter in vårt värde på c blir detta 10 ms. Alternativt kan vi i detta fall resonera så här: Vi har linjär tidskomplexitet. Problemstorleken 1000 är 10 gånger större än problemstorleken 100. Alltså krävs det 10 gånger så lång tid, d.v.s. 10 ms. U 54. På samma sätt som i föregående uppgift kan vi bestämma konstanten c för exekveringstiden t(n) = c 2 n genom att vi vet att det tog 1 ms för n = 10. Detta ger ju att c 2 10 = 1 eller c = En sekund är 1000 ms. Storleken (n) för det problem som kan lösas på denna tid får vi ur sambandet c 2 n = Om vi sätter in värdet på c ger detta 2 n = 1000/2 10

16 16 Algoritmers effektivitet, tidskomplexitet eller 2 n = , vilket ger 2 n 10 = 1000 eller n 10 = 2 log1000 = Det största heltalsvärde för n för vilket exekveringstiden inte överstiger 1 sekund blir därför = 19. U 55. a) För ArrayList är denna operation O(1). För LinkedList är den O(n) eftersom man måste leta sig fram till rätt position. b) För båda blir det O(n). Man måste ju leta upp elementet. c) Den blir O(n) för båda. I en ArrayList kan man visserligen få access till plats index på konstant tid. Men före insättningen måste man först flytta alla element till höger om denna plats ett steg högerut. Detts kostar O(n) i värsta fall. d) Den blir O(n) för båda. Motviering: samma som i föregående deluppgift. e) Om listan är av typ ArrayList kostar varje get-operation O(1). Den utförs n gånger vilket ger en total kostand på O(n). För en lista av typ LinkedList kostar get(i) i, man måste ju flytta sig i steg framåt i listan. Operationen utförs för i = 0, 1, 2,...n 1, vilket ger kostnad n 1 = O(n 2 ). f) Genom att använda en iterator blir kostnaden O(n) i båda fallen: Iterator<Integer> itr = list.iterator(); int sum = 0; while (itr.hasnext()) { sum = sum + itr.next(); Alternativt (och ekvivalent) kan man använda en foreach-sats: int sum = 0; for (int i: list) { sum = sum + i; U Om det finns n + k studenter i salen måste läraren leta på sin lista n + k gånger. Eftersom den är osorterad letar läraren då antagligen genom att läsa namn successivt tills ett namn hittas eller tills listan är slut. I värsta fall genomletas hela listan utan att namnet hittas. Då måste läraren läsa totalt (n + k) n namn på listan vilket kostar O(n 2 ). I k av fallen kommer läraren att också skriva till ett namn på listan. Detta kostar O(k). Totalt blir det O(n 2 ). Om alla de n personerna som finns på listan också finns i lokalen behöver läraren bara läsa i medeltal halva listan med namn för att hitta studenten. Kostnaden sjunker då till hälften, men är fortfarande O(n 2 ). 2. Läraren läser listan rakt igenom vilket kostar O(n). Därefter skall k studenter skrivas till vilket är O(k). Eftersom k är mycket mindre än n blir det hela O(n).

17 Algoritmers effektivitet, tidskomplexitet 17 U 57. a) Antag att det finns två kändisar p och q i en mängd. p är kändis och känner därför ingen av de andra personerna i mängden. Men då kan q inte vara kändis eftersom en kändis skall vara känd av alla andra i mängden. Alltså har vi en motsägelse. Därav följer att två eller flera kändisar i samma mängd är en omöjlighet. b) Det kostar O(n 2 ) att fråga alla personer och fylla i alla element i matrisen. Att undersöka om alla n elementen i en rad är false kostar i värsta fall O(n). I värsta fall måste man undersöka alla rader och då blir det totalt O(n 2 ). Eventuellt stöter man på en rad där alla element är false. Då avbryter man och undersöker om motsvarande kolumn har alla sina element true. O(n 2 ) är alltså ett värsta fall för algoritmens senare del. Den första delen, matrisifyllandet, görs alltid så kostnaden för algoritmen blir O(n 2 ). c) Varje gång man ställer en fråga kan man reducera mängden av möjliga kandidater med en. Efter n-1 frågor (d.v.s. kostnad O(n)) har man en kandidat x kvar. Att till sist fråga x om alla de andra n och fråga de andra om x kostar O(n). Totalt därmed O(n). U 58. Eftersom man kommit fram till att tidskomplexiteten är kvadratiskt växande med problemets storlek n så skall exekveringstiden bli ungefär fyra gånger så lång vid dubblering av problemstorleken. Man kan därför köra algoritmen för en serie fördubblade värden t.ex. n = 10, 20, 40, 80, 160,...och mäta tiderna t 1, t 2,... för dessa. Då bör det visa sig att t i 4 t i 1 för alla i. Alternativt kan vi genom en serie körningar för olika värden på n försöka visa att exekveringstiden blir c n 2. För varje värde på n mäter man då exekveringstiden t(n) och skriver ut kvoten mellan denna och n 2. Om denna kvot visar sig vara ungefär densamma (= konstanten c) för olika värden på n är det troligt att analysen var korrekt.

18 18 Rekursion 7 Rekursion U 59. a) public static double power(double x, int n) { if (n == 0) { return 1; else { return x * power(x, n - 1); b) public static double power(double x, int n) { if (n == 0) { return 1; else { double r = power(x, n / 2); if (n % 2 == 0) { return r * r; else { return x * r * r; Anm. Se till att power(x, n / 2) bara anropas en gång och att resultatet sparas i en lokal variabel som sedan används i multiplikationen. Gör man samma anrop flera gånger har man inte vunnit något. c) Ändra namnet på metoden från deluppgift b till recpower och lägg till följande metod: public static double power(double x, int n) { if (n < 0 ) { return 1.0/recPower(x, -n); else { return recpower(x, n); U U 61. Ett basfall är ett enkelt fall av problemet som man kan lösa direkt utan att göra något rekursivt anrop. Om basfall saknas kommer det att göras rekursiva anrop i all oändlighet (eller i praktiken tills minnet tar slut). U 62. /** Returnerar true om strängen s är en palindrom. */ public static boolean ispalindrome(string s) { return recpalindrome(s, 0, s.length() - 1); private static boolean recpalindrome(string s, int first, int last) { if (last <= first) { return true; else if (s.charat(first)!= s.charat(last)) { return false; else {

19 Rekursion 19 return recpalindrome(s, first + 1, last - 1); U 63. /** Beräknar hur mycket kapitalet capital vuxit efter years år om räntesatsen är interestrate. */ public static double computecapital(double capital, int years, double interestrate) { if (years == 0) { return capital; else { return computecapital(capital + (capital * interestrate / 100), years - 1, interestrate); U 64. a) /** Beräkna nollstället för funktionen f i intervallet [low,high] med precisionen eps. Förutsätter att det finns ett nollställe i intervallet. */ public static double getzero(double low, double high, double eps, Function f) { double mid = (low + high)/2; if (Math.abs((high - low)) < eps) { return mid; else { if (f.evaluate(mid) * f.evaluate(low) > 0) { // samma tecken return getzero(mid, high, eps, f); else { return getzero(low, mid, eps, f); b) public class MyFunction implements Function { public double evaluate(double x) { return Math.exp(-x) Math.cos(x); c) double zero = Bisection.getZero(0, 1.6, , new MyFunction()); U 65. Felet är att vi i rekursionen går ända fram till null. Det sista anropet av den rekursiva metoden har node = null. Inuti metoden får node ett nytt värde (en nod med innehållet x). Men i den anropande metoden (vars node.next == null) blir det ingen förändring. Den nya noden länkas alltså aldrig in i listan, som förblir tom. Ett sätt att korrigera felet är att i rekursionen stanna ett steg tidigare enligt följande: public void add(e x) { if (first == null) { first = new ListNode<E>(x); else { add(first, x); private void add(listnode<e> node, E x) { if (node.next == null) { node.next = new ListNode<E>(x); else { add(node.next, x);

20 20 Rekursion U 66. a) Denna metod är korrekt och väl utformad. Har ett basfall. b) Metoden är korrekt, men har ett onödigt basfall (n==1). c) Metoden är inte korrekt. Basfallet är fel. Funktionen kommer att hamna i evig loop om den anropas för n=0, då svaret borde bli 1. d) Helt fel. Saknar basfall. Hamnar i evig loop vilket värde vi än anropar med. U 67. Förslaget a) är korrekt. Förslaget b) klarar ej tom lista. Dessutom saknar b) fallet att man inte hittar elementet. Om b) anropas för ett fall där elementet ej finns i listan kommer det att ge ett exekveringsfel. Det kommer då att göras rekursiva anrop tills den lista som undersöks är tom, varvid exekveringsfelet kommer. U 68. Värsta fall inträffar om vektorn är sorterad i avtagande ordning. Då kommer jämförelsen v[n-1] > findmax(v, n-1) att bli false i varje rekursiv upplaga och därför kommer det rekursiva anropet findmax(v, n-1) i den sista else-grenen alltid att utföras. Vi får då två rekursiva anrop, ett i jämförelsen och ett i den sista else-grenen. findmax(v, n) kommer alltså att göra två anrop av findmax(v, n-1). Var och en av findmax(v, n-1) kommer att göra två anrop av findmax(v, n-2), d.v.s. totalt fyra anrop av denna. Det blir totalt i n rekursiva anrop d.v.s. O(2 n ). Man gör lösningen mycket effektivare genom att undvika två rekursiva anrop: public static int findmax(int[] v, int n) { if (n==1) { return v[0]; else { int temp = findmax(v, n-1); if (v[n-1] > temp) { return v[n-1]; else { return temp; Nu blir det bara ett rekursivt anrop i varje upplaga. Antalet upplagor är n och varje upplaga gör, förutom det rekursiva anropet, ett konstant arbete. Totalt blir det O(n). U 69. Dynamisk programmering innebär att man i en tabell håller reda på vilka instanser av problemet man redan löst. När man behöver lösningen till en viss instans kontrollerar man först i tabellen om den redan beräknats. I så fall hämtas lösningen där, dvs man gör inget rekursivt anrop. U 70. Den andra är både enklare att läsa och effektivare. Den första lösningen får tidskomplexitet O(n 2 ) och den andra O(n).

21 Träd, binära träd 21 8 Träd, binära träd U 71. Båda är korrekta. Den första har dock onödiga basfall. U 72. a) private void printinorder(node<e> n) { if (n!= null) { printinorder(n.left); System.out.println(n.element); printinorder(n.right); b) Utskriftssatsen placeras före respektive efter de två rekursiva anropen. U 73. a) Följande metoder läggs till i trädklassen: public int nbrleaves() { return nbrleaves(root); private int nbrleaves(node<e> n) { if (n == null) { return 0; else if (n.left == null && n.right == null) { return 1; else { return nbrleaves(n.left) + nbrleaves(n.right); b) Den publika metoden läggs till i trädklassen och den rekursiva hjälpmetoden i nodklassen: public int nbrleaves() { if (root == null) { return 0; else { return root.nbrleaves(); private int nbrleaves() { if (left == null && right == null) { return 1; else { int nbr = 0; if (left!= null) { nbr += left.nbrleaves(); if (right!= null) { nbr += right.nbrleaves(); return nbr;

22 22 Träd, binära träd U 74. /** * Returnerar en teckensträng som representerar uttrycket. Teckensträngen * innehåller parenteser runt alla deluttryck, utom runt talen. */ public String fullparen() { if (root == null) { return ""; else { StringBuilder sb = new StringBuilder(); recfullparen(root, sb); return sb.tostring(); /* * Lägger i sb till de tecken som representerar uttrycket i det träd där n är * rot. Tecknen innehåller parenteser runt alla deluttryck, utom runt talen. */ private void recfullparen(exprnode n, StringBuilder sb) { if (n.left == null && n.right == null) { sb.append(n.element); else { sb.append( ( ); // Trädet är strikt binärt, bägge subträden icke-tomma recfullparen(n.left, sb); sb.append(n.element); recfullparen(n.right, sb); sb.append( ) ); U 75. /** * Returnerar en lista med alla vanliga filer som är större än size bytes. */ public static List<File> biggerthan(file file, int size) { List<File> list = new ArrayList<File>(); recbiggerthan(file, size, list); return list; private static void recbiggerthan(file file, int size, List<File> list) { if (file.isfile()) { if (file.length() > size) { list.add(file); else if (file.isdirectory() { File[] files = file.listfiles(); for (File f: files) { recbiggerthan(f, size, list); U 76. Man börjar med att sätta in roten i kön. Därefter gör man så här: så länge inte kön är tom tag ut den första noden i kön (och behandla den) om noden har vänster barn sätt in vänster barn i kön om noden har höger barn sätt in höger barn i kön

23 Binära sökträd 23 9 Binära sökträd U 77. Binärt sökträd efter insättning av element med nycklarna: 2, 5, 1, 7, 9, 6, 3, 0, 8, U 78. Preorder: 2, 1, 0, 5, 3, 4, 7, 6, 9, 8 Inorder: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 Postorder: 0, 1, 4, 3, 6, 8, 9, 7, 5, 2 En traversering i inorder ger elementen i nyckelordning. U 79. Minsta möjliga höjden för ett binärt träd log n och största möjliga höjden = n. U 80. I ett binärt sökträd tillåts inte dubbletter. Därför kan man bara använda ett sådant för att sortera om indata inte innehåller dubbletter. I så fall sätter man in alla element som ska sorteras i trädet. En inordertraversering av trädet ger elementen i växande ordning. U 81. public String tostring() { StringBuilder sb = new StringBuilder(); buildstring(root, sb); return sb.tostring(); public void buildstring(node<e> n, StringBuilder sb) { if (n!= null) { buildstring(n.left, sb); sb.append(n.element.tostring()); sb.append( \n ); buildstring(n.right, sb); U 82. /** Skriver ut innehållet i de noder som är större än eller lika med min och mindre än eller lika med max i växande ordning. */ public void printpart(e min, E max) { printpart(root, min, max); private void printpart(node<e> n, E min, E max) { if (n!= null) { if (n.element.compareto(min) > 0) { // vänster subträd kan ha // element i rätt intervall printpart(n.left, min, max); if (n.element.compareto(min) >= 0 && n.element.compareto(max) <= 0) { // min<=n.element<=max, skriv ut System.out.println(n.element); if (n.element.compareto(max) < 0) { // höger subträd kan ha

24 24 Binära sökträd printpart(n.right, min, max); // element i rätt intervall U 83. Ett binärt träd är balanserat om det för varje nod i trädet gäller att höjdskillnaden mellan dess båda subräd är högst ett. Orsaken till att man vill balansera träd är att höjden är proportionell mot log n och därmed blir tidskomplexiteten för sökning, insättning och borttagning O(log n). U 84. a) Programmet går inte att kompilera eftersom klassen Book inte implementerar Comparable<Book>. b) public class Book implements Comparable<Book> {... public int compareto(book rhs) { return isbn.compareto(rhs.isbn); public boolean equals(object rhs) { if (rhs instanceof Book) { return compareto((book) rhs) == 0; else { return false;

25 Hashtabeller Hashtabeller U 85. a) Linjär teknik vid kollision: b) Kvadratisk teknik vid kollision: c) Öppen hashtabell: U 86. Hashfunktionen sprider inte ut elementen över hela vektorn. Det blir förmodligen många kollisioner. Låt hela personnumret (eller födelsenumret) påverka hashkoden.

26 26 Mängder och mappar 11 Mängder och mappar U 87. En mängd är en samling element där dubbletter är förbjudna. Man kan t.ex. använda ett binärt sökträd eller en hashtabell för att implementera en mängd. U 88. En map är en samling av element, där varje element har en en nyckel och ett värde (jfr. lexikon). De viktigaste operationerna är att sätta in respektive ta bort nyckelvärdepar, samt söka efter en nyckels värde. Man kan t.ex. använda ett binärt sökträd eller en hashtabell för att implementera en map. U 89. Det betyder helt enkelt att man förutsätter att elementen implementerar interfacet Comparable så att man kan jämföra dem genom att använda operationen compareto. U 90. a) HashMap<String, Book> map = new HashMap<String, Book>(); map.put (" ", new Book(" ", "De två tornen", "Tolkien")); map.put (" ", new Book(" ", "Hobbiten", "Tolkien")); Inga förändringar behövs i klassen Book. Nyckeln utgöra av ISBN-numret som har typen String. Metoderna hashcode och equals är omdefinierade i klassen String. b) HashSet<Book> set = new HashSet<Book>(); set.add(new Book(" ", "De två tornen", "Tolkien")); set.add(new Book(" ", "Hobbiten", "Tolkien")); Skugga följande metoder i klassen Book: public boolean equals(object rhs) { if (rhs instanceof Book) { return isbn.equals(((book) rhs).isbn); else { return false; public int hashcode() { return isbn.hashcode(); U 91. Metoden hashcode använd för att hitta rätt vektorelement, dvs rätt lista. Därefter söks denna lista igenom efter rätt element. Vid denna sökning används equals vid jämförelserna. U 92. a) Nycklarna i en TreeMap måste vara av en typ som implementerar interfacet Comparable. Nyckeln isbn är av typen String och klassen String implementerar Comparable. Därför behövs det inga förändringar i klassen Book. (Om vi istället byter ut HashSet mot TreeSet i uppgift U 90 b måste vi se till att klassen Book implementerar Comparable eller använda ett Comparator-objekt.) b) Det går snabbare ett söka i en hashtabell än i ett binärt sökträd. (I alla fall om hashfunktionen är vettigt vald och hashtabellen har en rimlig fyllnadsgrad.) Därför är HashMap att föredra om antal böcker är stort och det är viktigt att det går snabbt att söka.

27 Mängder och mappar 27 U 93. Man kan använda en hashtabell med ordet som nyckel och listan med sidnummer som värde. För varje ord i filen söker man i hashtabellen. Om ordet inte finns sätter man in det tillsammans med sidnumret. Om ordet redan finns ska aktuellt sidnummer sättas in sidnummerlistan om det inte redan finns med där. För att undvika dubbletter räcker det att jämföra aktuellt sidnummer med sista sidnumret i listan. Det är lämpligt att det finns en referens till sista elementet i listan så att man snabbt når detta. Innan man skriver ut orden och dess sidnummerlista måste orden sorteras. Som hashtabell kan man använda klassen HashMap och för sidnummerlistorna klassen LinkedList. Istället för att lagra orden i en hashtabell kan de lagras i en ett balanserat binärt sökträd (t.ex. TreeMap). För att skriva ut korsreferenslistan går man igenom trädet i inorder. Istället för att använda en lista för sidnumren skulle man kunna använda en sorterad mängd (t.ex. TreeSet). U 94. a) public class Anagram { private Map<String, Set<String>> anagrams; /** Skapar ett objekt som hanterar anagram. */ public Anagram() { anagrams = new HashMap<String, Set<String>>(); /** Lägger till ordet word */ public void add(string word) { String sorted = alphabetize(word); Set<String> anagramset = anagrams.get(sorted); if (anagramset == null) { anagramset = new HashSet<String>(); anagrams.put(sorted, anagramset); anagramset.add(word); /** * Returnerar en mängd med alla ord som är anagram till ett visst ord. * word ska inte ingå i den mängd som returneras. Om word inte har * några insatta anagram ska en tom mängd returneras. */ public Set<String> getanagramsof(string word) { Set<String> s = anagrams.get(alphabetize(word)); if (s!= null) { s = new HashSet<String>(s); // make a copy s.remove(word); // remove word, if present else { s = new HashSet<String>(); return s; /** * Returnerar en sträng med bokstäverna i word sorterade i * bokstavsordning. */ private String alphabetize(string word) { // Färdig att använda.

28 28 Mängder och mappar b) Vi antar att mappen innehåller n ord och att antal anagram till ett ord är litet Ett anrop av metoder på en ords mängd med anagram anser vi därför ta konstant tid. I add anropas get och ev. put på mappen. Eftersom vi använder en HashMap (hashtabell) får dessa metoder konstant tidskomplexitet och den totala tidskomplexiteten blir alltså O(1). Hade vi istället använt en TreeMap kostar metoderna get och ev. put O(log n) och den totala tidskomplexiteten blir O(log n).

29 Prioritetsköer, heapar Prioritetsköer, heapar U 95. En prioritetskö är en samling element där varje element har en prioritet (som används för att jämföra elementen med). Elementen plockas ut i prioritetsordning till skillnad mot en vanlig kö där elementen plockas ut i den ordning de satts in i kön. De operationer man ska kunna göra på en prioritetskö är sätta in element ta reda på det högst prioriterade elementet (minsta elementet) ta bort det högst prioriterade elementet (minsta elementet) U 96. Heap efter insättning av element med nycklarna: 2, 5, 1, 7, 9, 6, 3, 0, 8, U 97. En heap kan lagras i en vektor. Roten lagras på plats 0. Barnen till noden på plats i finns på platserna 2i + 1 och 2i + 2 i vektorn. Nod på plats i har alltså sin förälder på plats (i-1)/2). Heapen från uppgift U 96: U 98. Tag bort noden på plats 0 i vektorn. Ersätt med den som finns på sista plats. Detta ger rätt form, men roten har nu troligtvis fel storleksförhållande till sina barn. Byt med minsta av barnen tills ordningen ok ( percolate down ). U 99. a) Antag t ex att vi sätter in tre lika element e 1, e 2 och e 3 (i den ordningen) i en heap. Heapens utseende efter dessa insättningar visas till vänster i figuren nedan. Antag nu att vi gör en borttagning. Det blir då e 1 som tas ut. Efter borttagningen har heapen det utseende som visas till höger i figuren nedan. Nästa borttagning kommer därför att ta ut e 3. Detta element är yngre än e 2. Alltså är heapen inte stabil. e 1 e 3 e 2 e 3 e 2 b) Man kan sätta in element som består av prioritet plus ett nummer. Man numrerar sina element 1,2,... efterhand som man sätter in dem. Vidare definierar man comparetometoden så att den jämför på prioritet i första hand och nummer i andra hand. Av två element med lika prioritet kommer ett som är senare insatt då att anses vara större än det tidigare insatta. Då kommer element med lika prioritet att komma ut ur heapen i den ordning de sattes in.

30 30 Prioritetsköer, heapar U 100. I en heap kan man snabbt hitta minsta elementet. Sökning av ett godtyckligt element blir däremot dyrare. Vi kan inte söka oss ner på en gren som i ett sökträd, en heap är ju inte ordnad på samma sätt. Vi måste söka i både vänster och höger underträd tills vi eventuellt hittar elementet. I värsta fall behöver vi söka igenom hela heapen, vilket kostar O(n). U 101. a) Om trädet är skevt t.ex. om alla noder bara har höger barn så kommer noderna att hamna på platserna 0, 2, 6,..., 2 i 2,..., 2 n 2 i vektorn. I det andra fallet inträffar värsta fallet när noden på nivå k + 1 är höger barn till noden längst till höger på nivå k. Noden på nivå 1 finns på plats 0 i vektorn. Noderna på nivå 2 finns på platserna 1 och 2, noderna på nivå 3 på platserna 3, 4, 5 och 6 etc. Noderna på nivå i finns alltså på platserna 2 i i 2. Alla noder på nivåerna 1..k kommer därför att fylla platserna 1..2 k 2. Lägger vi till ett höger barn till den sista noden hamnar det på plats 2 k+1 2 d.v.s. vi behöver ungefär dubbelt så stor vektor trots att vi bara lägger till en enda nod på sista nivån. b) Om trädet är tomt ska det nya elementet placeras i roten. Om trädet har en nod ska det nya elementet placeras som vänster barn till roten, och om trädet har två noder ska det nya elementet placeras som höger barn till roten. Låt en båge från en nod till dess vänstra barn representera en nolla och en båge från en nod till dess högra barn representera en etta. Vägen för den andra noden beskrivs då av en nolla och vägen för den tredje noden av en etta. Om vi går vidare och utgår från ett träd med tre noder så ska den fjärde noden placeras som vänster barnbarn till roten. Denna väg motsvarar sekvensen 00. Nästa nods väg beskrivs av 01 och nästa av 10 och den sjunde nodens väg är 11. Om vi låter vägen till roten beskrivas av en etta får vi i stället sekvensenra 100, 101, 110 och 111 d.v.s. den binära representationen av 4, 5, 6 och 7. Varje nods plats beskrivs alltså på detta sätt av den binära representationen av antalet noder efter insättningen. U 102. I stället för en heap kan man använda t.ex. ett balanserat binärt sökträd för att representera en prioritetskö. Trädet sorteras då efter prioriteter. Man måste modifiera trädimplementeringen så att dubbletter kan sättas in. Detta kan man göra genom att man vid likhet mellan element alltid väljer att göra insättning i t.ex. höger underträd. Vi vet sedan tidigare att insättning kostar O( 2 logn) i ett balanserat binärt sökträd. Om vi ska använda trädet som en prioritetskö behöver vi också en metod för att ta bort minsta elementet ur trädet. Detta element finns längst ner till vänster i trädet, d.v.s. man hittar det genom att utgående från roten flytta sig nedåt med hjälp av referenserna till vänster barn. Borttagning kan inte kosta mer än O( 2 logn) i ett balanserat träd. Man kan också använda listor, sorterade eller osorterade. Har man en osorterad lista blir operationerna för att söka minsta och ta bort minsta långsamma (O(n)) men insättning blir O(1). För en sorterad lista är det tvärtom. U 103. Man kan införa en vektor av listor. Vektorns storlek = antalet olika prioriteter. Ett elements prioritet avgör i vilken lista det placeras. Insättning blir O(1). Tag bort minsta och sök minsta blir också O(1). Man måste visserligen söka upp första icke-tomma listan i vektorn, men vektorns storlek är en konstant. Man åstadkommer stabilitet genom att sätta in ett nytt element sist i den lista där det hör hemma. Det kräver då att man har en listimplementation där insättning sist kostar O(1).