Norges Informasjonsteknologiske Høgskole

Oppgavesettet består av 13 (mange) sider. Norges Informasjonsteknologiske Høgskole PG4200 Algoritmer og datastrukturer Side 1 av 13 Tillatte hjelpemidler: Ingen Varighet: 3 timer Dato: 4. juni 2014 Fagansvarlig: Lars Sydnes lars.sydnes@nith.no 93 03 56 85 Oppgavesettet består av 5 oppgaver. Husk å lese oppgavene nøye. En god begrunnelse av et dårlig svar er ikke å forakte. Alle punktene vektes likt. Løsningsforslag Obs: Dette er et utbygd løsningsforslag. D.v.s at det kan forekomme feil, og at løsningene er mer omfattende enn det som kreves av studentene på eksamen. Oppgave 1 a) Bruk O-notasjon til å angi ordenen til de følgende vekstfunksjonene uten å begrunne svaret. (i) f(n) = 31.4 + 15n 9 + 2 n (ii) g(n) = (n + 1) log n + 4n (i) f(n) har orden O(2 n ). (ii) g(n) har orden O(n log n). b) Estimer hvordan kjøretiden til funksjonene f og g i kodesnutten nedenfor avhenger av n. Svaret skal begrunnes og uttrykkes med O-notasjon. 1 void f(int n){ 2 for(int i = 0; i < n; i+=3) 3 dosomething(i); 4 5 6 void g(int n){ 7 int i = 1; 8 while(i < n){ 9 f(i); 10 i*=2; 11 12 13 14 void dosomething(int n){ 15 // Something O(1) 16

Side 2 av 13 Behandling av funksjonen f: Metoden dosomething oppgis å ha kjøretid O(1). Dermed har instruksjonen i linje 3 konstant kjøretid. Løkken definert i linje 2 går gjennom inntil n/3 iterasjoner. f(n) har følgelig kjøretid av orden O(n). Grov behandling av funksjonen g: Siden i < n, vet vi fra forrige oppgave at instruksjonen i linje 9 har kjøretid av orden O(n). I løpet av while-løkkas iterasjoner er i innom verdiene 1, 2, 4,..., 2 k, der k er største tallet slik at 2 k < n, altså det største tallet mindre enn log 2 n. Løkka går følgelig gjennom inntil log 2 n iterasjoner. Siden hver iterasjon har kjøretid av orden O(n), vil hele løkka ha kjøretid av orden O(n log n) Kommentar: Dette svaret er et gyldig worst-case estimat; vi er helt sikre på at worst-case-kjøretiden ikke vokser raskere enn n log n. Svakheten er at det er unødvendig grovt. I neste løsningsvariant kan du se et sterkere estimat. Dette svaret gir derfor kun halv uttelling. Bedre behandling av funksjonen g: Ettersom f(i) har kjøretid O(i), vet vi at det finnes en konstant K slik at kjøretiden i linje 9 er mindre enn K i. I løkka gjennomløper i verdiene 1, 2,... 2 k < n. Den totale kjøretiden blir dermed mindre enn K 1+ +K 2 k = K(1+2+ +2 k ) = K(2 k+1 1) < 2K 2 k < 2K n. Utifra dette konkluderer vi med at g(n) har kjøretid av orden O(n)

Side 3 av 13 Oppgave 2 a) Forestill deg et binært søketre uten balanseringsmekanisme som kun aksepterer ett eksemplar av hvert objekt. Lag en skisse av treet etter innsetting av følgende sekvens: 3, 1, 4, 1, 5, 9, 2, 6. 3 1 4 2 5 9 6 b) Hva er fordelen med balanserte trær? De fleste tre-operasjonene har kjøretid som avhenger av høyden i treet. Ett eksempel på dette er søk, som har kjøretid av orden O(h) der h er treets høyde. Lav høyde gir derfor raske operasjoner. Høyden til treet avhenger av balansen. Balanserte trær har lav høyde. I veldig ubalanserte trær kan høyden være omtrent like stor som antallet elementer i treet, f.eks hvis alle noder (unntatt roten) er venstrebarn. c) Forklar hva Red-Black-trær er. Red-Black-trær (RB-trær) har en mekanisme for å opprettholde en rimelig balanse: Hver gang treet forandres undersøkes det om treet forstatt er rimelig balansert. Dersom dette ikke er tilfelle utføres det venstre- og høyre-rotasjoner om strategisk valgte noder, med sikte på å gjenopprette en rimelig balanse.

Side 4 av 13 I RB-trær overvåkes balansen ved at nodene tildeles farge, enten rød eller svart. Denne fargeleggingen brukes til å overvåke balansen i treet. Et viktig poeng er at overvåkingen og balansering har kjøretid av orden O(h), så selv om dette blir en ekstra-kostnad i forbindelse med modifikasjon av treet, så blir ikke ordenen til kjøretiden forverret. På den annen side vil balanseringen medføre at høyden blir lavere. Dermed vil, i alle fall for de fleste store trær som ellers ville ha blitt veldig ubalanserte, balanseringen forbedre kjøretiden. Med RB-balansering av binære trær er kjøretiden for de viktigste treoperasjonen av orden O(log(n)), der n er antall elementer i treet. Kommentar: Her har vi først og fremst drøftet nytten av RB-trær. Vi har ikke drøftet i detalj hvordan RB-trær overvåker høyden, nemlig ved å følge med på at alle veier mellom roten og bladene inneholder nøyaktig like mange svarte noder samtidig som ingen røde noder får ha røde barn. Dette medfører at den lengste veien ut fra roten er inntil dobbelt så lang som den korteste. En konsekvens av dette er at høyden aldri er mer enn det dobbelte av den minimale høyden. Dette medfører at den maksimale høyden er av orden O(log n), der n er antallet elementer i treet. d) Når bruker vi køer i forbindelse med traversering av trær og grafer? Når bruker vi stakker til det samme? Nodene i trær og grafer har i utgangpunktet ingen naturlig rekkefølge. Traversering innebærer at vi besøker nodene i en bestemt rekkefølge. Når vi besøker en node med mange barn, kan vi umiddelbart gå videre til høyst ett av disse barna. De barna vi ikke besøker umiddelbart må registreres i en huskeliste, slik at vi kan komme tilbake til dem senere. Hvordan vi bruker denne huskelisten vil avgjøre traverseringsrekkefølgen. Dersom vi ønsker bredde først-traversering (i trær også kalt level order), må vi bruke listen som en kø, altså etter first in, first out-prinsippet. Dersom vi ønsker dybde først-traversering, må vi bruke listen som en stakk, d.v.s etter first in, first out-prinsippet. (Når vi har diskutert binære trær, har vi diskutert tre ulike varianter av dybde førsttraversering, nemlig preorder, postorder, inorder. Vi kan få frem alle disse variantene ved å bruke en stakk. Spørsmålet er i hvilken rekkefølge vi besøker noden og dens to barn. )

Side 5 av 13 e) Skriv en ikke-rekursiv metode for sekvensielt søk i en lenket liste der nodene tilhører klassen Node: class Node<T> { T data; Node<T> next; boolean contains(t elem) { Node<T> current = head; while (current!= null) { if (elem.equals(current.data)) return true; else current = current.next; return false; f) Skriv en rekursiv metode for sekvensielt søk i en lenket liste der nodene tilhører klassen Node definert i forrige punkt. boolean containsrecursive(t elem){ return containsrecursive(elem,head); boolean containsrecursive(t elem, Node<T> node) { if (node == null) // Stoppbetingelse I return false; else if (elem.equals(node.data)) // Stoppbetingelse II

Side 6 av 13 return true; else // Rekursivt steg return containsrecursive(elem, node.next); g) Forklar hva det betyr at java.util.hashset benytter strategien chaining? I hvilken situasjon forekommer rehashing av hash-tabeller? I hash-tabeller forekommer det at to ulike objekter konkurrerer om samme indeks. Dette kan løses ved å legge ulike elementer som hører til på samme indeks i lenkede lister, en liste for hver indeks. Denne strategien kalles chaining. Når en hash-tabell er i ferd med å bli for full må den flyttes til et nytt minneområde med større plass. Denne prosessen kalles rehashing. Hva det vil si at en hash-tabell er i ferd med å bli for fullt varierer fra implementasjon til implementasjon. Det er ønskelig med mange ledige plasser i hash-tabeller, siden det gir færre konflikter og dermed raskere lagring og søk. Derfor er det vanlig å utføre rehashing når antallet elementer overstiger en viss andel av antallet indekser i tabellen, f.eks 75%. (Dette tallet er hentet fra java.util.hashmap).

Side 7 av 13 Oppgave 3 Tabell 1 nedenfor illustrerer to ulike sorteringsalgoritmer. De to sorteringsalgoritmene som er brukt befinner seg i denne oversikten: (i) Quick sort (ii) Insertion sort (iii) Bubble sort (iv) Selection sort (v) Merge sort 3 1 4 1 5 9 2 6 1 3 4 1 5 9 2 6 1 1 4 3 5 9 2 6 1 1 2 3 5 9 4 6 1 1 2 3 5 9 4 6 1 1 2 3 4 9 5 6 1 1 2 3 4 5 9 6 1 1 2 3 4 5 6 9 3 1 4 1 5 9 2 6 1 3 1 4 5 9 2 6 1 1 3 4 2 5 6 9 1 1 2 3 4 5 6 9 (b) (a) Tabell 1: Illustrasjon av to ulike sorteringsmetoder. a) Hvilken av sorteringsalgoritmene (i-v) er illustrert i tabell 1a? Hvilken av sorteringsalgoritmene (i-v) er illustrert i tabell 1b? Du behøver ikke å begrunne svaret. Tabell 1a viser algoritme (iv), selection sort. Tabell 1b viser algoritme (v), merge sort. På neste side ser du grafiske fremstillinger av måling av kjøretiden til tre sorteringsalgoritmer anvendt på sorterte og usorterte lister. De tre algoritmene er: (i) Insertion sort.

Side 8 av 13 (ii) Selection sort. (iii) En algoritme hentet fra java.util.arrays som hovedsaklig bygger på Quick sort. kjøretid (millisekunder) 1200 1000 800 600 400 200 Metode A 0 0 2000 4000 6000 8000 10000 Antall elementer Tilfeldige data Sorterte data Metode B kjøretid (millisekunder) 14000 12000 10000 8000 6000 4000 2000 0 0 2000 4000 6000 8000 10000 Antall elementer Tilfeldige data Sorterte data Metode C kjøretid (millisekunder) 14000 12000 10000 8000 6000 4000 2000 0 0 2000 4000 6000 8000 10000 Antall elementer Tilfeldige data Sorterte data b) Angi hvilken algoritme (i, ii, iii) som er brukt i hver av figurene (A, B, C). Begrunn svaret i to av tilfellene.

Side 9 av 13 Oppgave 4 Metode A er Quick sort. Metode B er Selection sort. Metode C er Insertion sort. Metodene B og C er opplag mye tregere enn metode A på usorterte data. På øyemål ser det ut til at kjøretiden for metode A vokser omtrent som n log n (Det virker i alle fall opplagt at vi befinner oss mellom n og n 2.) Utifra dette kan man være rimelig sikker på at metode A er Quick sort. Metode C er langt raskere når dataene er forhåndssortert. Kjøretiden til Insertion sort vokser lineært når dataene er forhåndssortert. Dermed kan vi være rimelig sikre på at Metode C er Insertion sort. Det virker som om kjøretiden til metode C er uavhengig av om dataene er sortert eller ei. Det rimer godt med Selection sort, som i hvert steg utfører sekvensielt søk etter det gjenværende minste elementet. Algoritmen drar altså ikke nytte av at dataene allerede er sortert. Kommentar: Et artig poeng vi ser her er at Selection sort har veldig forutsigbar kjøretid, mens kjøretiden til Insertion sort er ganske uforutsigbar, og til tider mye raskere enn selection sort. På den annen side later det til at worst case-kjøretid for Insertion sort er i nærheten av det dobbelte av Selection sort i denne testen. import java.util.priorityqueue; /*...*/ public static <T extends Comparable<T>> void metode(t[] data){ int n = data.length; PriorityQueue<T> pq = new PriorityQueue<T>(); for (int i = 0; i < n; i++) pq.offer(data[i]); for (int i = 0; i < n; i++) data[i] = pq.poll(); Hva kan vi bruke metoden metode ovenfor til? Estimer hvordan kjøretiden (T ) til metoden metode avhenger av antall elementer (n). Begrunnelsen skal være forankret i koden ovenfor samt det du vet om egenskapene til PriorityQueue.

Side 10 av 13 Metoden metode kan brukes til å sortere lister. En prioritetskø leverer til enhver tid ut det minste elementet tilgjengeliig i køen. Den andre for-løkken tar altså elementene ut av køen i sortert rekkefølge. PriorityQueue er implementert som en heap. Metodene offer og poll for modifisering av heapen har derfor kjøretid av orden O(log n). Tidsbruken i metode er dominert av de to for-løkkene, som medfører til sammen 2n slike modifiseringsoperasjoner. Den totale kjøretiden er dermed av orden O(n log n). Kommentar: Det er ikke helt feil å kalle denne sorteringsmetoden Heap sort. Et argument mot dette er at Heap sort gjerne foregår in place. Oppgave 5 Studentene i et studieprogram ved NITH skal arrangere semesteravslutningsfest. Studentene vil gjerne sitte rundt ett langbord, men dessverre ligger mange studentene i fiendskap med hverandre, og arrangørene har derfor kartlagt hvem som er fiender med hvem. Resultatet er fremstilt i denne tabellen: Person Eva Ove Ulf Are Ada Ole Liv Fiender Ole, Are Ada, Liv Are, Ada, Ole, Liv Eva, Ulf, Ada Ove, Liv, Ulf, Are Eva, Ulf Ove, Ulf, Ada Vi skal her se på hvordan dataene i denne tabellen kan presenteres som en graf der nodene representerer personer og kantene representerer fiendskap mellom personer. La oss kalle dette fiendskapsgrafen. Vi kan også definere en vennskapsgraf, der kantene representerer ikke-fiendtlige relasjoner. a) Skisser fiendskapsgrafen og vennskapsgrafen til denne studentgruppen.

Side 11 av 13 Fiender: Eva Ove Ulf Liv Are Ole Ada Venner: Eva Ove Ulf Liv Are Ole Ada Eva og Are ønsker å slutte fred, men ønsker kun å kommunisere gjennom venner, venners venner og så videre. b) Hjelp Eva og Are ved å beskrive en algoritme de kan bruke til å finne en kortest mulig kjede av venner de kan kommunisere gjennom. Problemet til Eva og Are kan formuleres innenfor graf-språket: Finn den korteste veien fra Eva til Are i vennskapsgrafen. En slik vei kan vi finne ved å bruke et bredde først-søk i grafen. Metoden kan betraktes som en forenkling av Dijkstras algoritme. Vi kan gjøre denne forenklingen siden det er en uvektet graf. Fremgangsmåten er som følger: Bygg alle mulige veier i grafen som starter hos Eva. Pass på at du hele tiden arbeider videre med de veiene som er kortest. Når du kommer over en vei som ender hos Are, vil denne veien være en løsning av problemet. Siden alle kantene er like lange, kan vi organisere veiene i en kø; de korteste veiene vil da alltid ligge først i køen. Dersom man vil gi en middels formell beskrivelse av algoritmen, kan man gjerne gjøre det slik.

Side 12 av 13 //Input: A, B //Data: QUEUE QUEUE.offer(newPathOfZeroLength(A)); while (QUEUE.size() > 0) { currentpath = QUEUE.poll(); currentnode = currentpath.target; for (Edge edge : currentnode.edges){ newpath = concat(currentpath,edge) if (newpath.target.equals(b)) return newpath; else QUEUE.offer(newPath) Her er metodene concat og newpathofzerolength udefinert. Det er også uklart hvordan de ulike objektene her er implementert, men denne kodesnutten kan i alle fall gi et bilde av hvordan vi kan håndtere dette. c) Hjelp Eva og Are ved å gå gjennom den algoritmen du beskrev i forrige punkt. Få fram de viktigste stegene samt sluttresultatet. Steg 1 Bygg veien med lengde 0 som starter og slutter i Eva. Køen ser nå slik ut: [Eva] Steg 2 Aktuell vei er nå Eva. Vi bygger ut denen veien ved å legge til kantene som går ut fra Eva. Køen ser nå slik ut: [Eva Ove, Eva Ulf, Eva Ada, Eva Liv] Steg 3 Aktuell vei er nå Eva Ove. Vi bygger ut denne veien ved å legge til kanter som går ut fra Ove. Først titter vi på Ove Ulf, som gir en ny vei i køen. Deretter kommer vi til Ove Are. Dette gir oss en vei fra Eva til Are, nemlig Eva Ove Are. Køen ser nå slik ut: [Eva Ulf, Eva Ada, Eva Liv, Eva Ove Ulf]

Side 13 av 13 Vi ser altså at Eva og Are kun behøver 1 mellom-mann, og at Ove kan gjøre den nytten. Det finnes én annen vei som er like kort, nemlig den som går via Liv. Ada redder studentfesten ved å lage en algoritme som raskt finner frem til en bordplassering der ingen fiender sitter ved siden av hverandre. Året etter planlegges det en fest der hele NITH skal sitte rundt ett stort langbord i gallerigaten. Ada tilbyr å hindre en fullstendig katastrofe ved å bruke algoritmen sin til å finne fram til en levelig bordplassering. d) Bedøm muligheten for at Ada lykkes også denne gangen. Vi kan se på bordplasseringsproblemet som nok et problem knyttet til vennskapsgrafen: Finn en rundreise i grafen som er innom hver node eksakt én gang, d.v.s en Hamiltonsk rundreise i grafen. Dette viser at Bordplassringsproblemet er NP-hardt (NP-hard), så vi har god grunn til å tro at Adas algoritme ikke har polynomisk kjøretid. Den praktiske konsekvensen av dette er at vi bør forvente at kjøretiden til Adas algoritme antagelig vokser meget raskt. Derfor bør vi ikke regne med at Adas algoritme har praktisk nytte i store grupper. Her kan man gjerne nevne noen flere momenter: Det at bordplasseringsproblemet er NP-hardt medfører at worst casekjøretiden vokser meget raskt. Det kan likevel tenkes at worst case-kjøretid for problemstørrelsen i det store tilfellet er praktisk akseptabel til tross for at kjøretiden vokser raskt (d.v.s. at vi møter veggen først ved enda større problemer), eller at inndataene i det store tilfellet er gunstige, slik at kjøretiden blir akseptabel til tross for at worst-case kjøretid er uakseptabel. Dette kan for eksempel inntreffe dersom det er få uvenner i gruppen. Dersom Ada mot formodning har kommet opp med en polynomisk løsning av bordplasseringsproblemet, så vil det være en stor oppdagelse. En konsekvens av dette ville være at alle problemer i klassen NP kan løses innenfor polynomisk kjøretid. Slutt på oppgavesettet