Fra forrige gang 1
Lineær sortering Radix sort 2
Sorter hvert siffer for seg Bruk en stabil sortering (f.eks. CS) for å bevare arbeidet så langt Vi må begynne med minst signifikante siffer Konstant antall siffer: Lineær kjøretid 3
4
5
Hva om tallene har ulikt antall siffer? Hva om det er veldig stor forskjell? Kan vi få til O(m), der m er det totale antall siffer brukt? (Det ville kunne brukes på vilkårlige strenger også.) Bryter vi i så fall den nedre grensen vår? Korrekthet kan vises ved induksjon på antall pass Kjøretid Θ(n + k) (evt. Θ((n + k)d) Hvordan bryter radix sort reglene for sammenligningssortering? Vi kan få informasjon ut over bare å sammenligne to nøkler. Vi bruker nøkler som tabellindekser! 6 Det kan vi gjøre fordi vi kjenner verdiområdet.
Sorter heltall Eller lignende Verdier O(n k ) Sorter siffer Stabilt Lineær Ganske strenge krav O(kn) Radikssortering 7 Evt. gruntallssortering :-)
Lineær sortering Bucket sort 8
Anta uniformt fordelte verdier i [0,1) Del [0,1) i n like store bøtter Fordél verdiene i bøttene Gå igjennom bøttene i rekkefølge Skriv ut verdiene sortert 9
Bøttene sorteres (med en enkel algoritme) Hver bøtte har O(1) forventet størrelse Totalt O(n) kjøretid 10
Sortering Uniformt [0,1) Ordnet hashing Lineær Krav O(n) Bøttesortering 11
Select 12
Seleksjon: Finn i-ende ordens statistic Eksempler: minimum, maksimum, median min/maks: enkle spesialtilfeller Vi ønsker ikke å sortere 13
I stedet for å sortere begge halvdeler fortsetter vi bare i den som inneholder posisjon i, som er den vi leter etter. Randomized-Select Eksempel på tavla. ½ QuicksortVerste tilfelle blir som for Quicksort. Beste tilfelle blir Theta(n). Forventet kjøretid, forenklet: T(n) = T(n/2) + n 14 Regnes på tavla.
Select Hårete og søt 15
Denne algoritmen er fra 1973. Høsten 2014 viste Chen og Dumitrescu at den også fungerer om man deler i grupper på 3 eller 4. http://arxiv.org/abs/1409.3600 Del i grupper på 5, og finn medianen i hver Finn «medianen til medianene», rekursivt Bruk denne som pivot i Partition Select rekursivt på «halvparten» Median-av-5: Konstant tid (insertion sort, f.eks.) for hver; O(n) totalt. Median-av-medianer: T(n/5). Merk: Etter utført algoritme vil dataene allerede være partisjonerte rundt elementet vi leter etter. Så ved å kjøre select etter element k så finner vi automatisk de k minste elementene i tabellen. 16 Partition: O(n). Rekursivt kall T(7n/10 + 6), hvis T(n) er monotont stigende. Mao: Vi får en «prosent-deling» i rekursjonen.
Finn median Og lignende Halv Quicksort Kjapp O(n 2 ) WC O(n) Avg. Randomized Select 17
Finn median Og lignende Pivot = m. av m. finnes rekursivt Kjapp O(n) Select 18
Fra A til B Syvende forelesning 19
Microsofts MapPoint (tidlig 2005) gir forslag til korteste vei fra Haugesund til Trondheim. Via bl.a. London. 1685.9 miles. En annen variant involverer å ta ferge fra Haugesund til Newcastle Upon Tyne, og så ta ferge fra Newcastle Upon Tyne til Bergen. Senere løste MS problemet ved å forby deg å beregne en sti mellom disse byene. Det ser ut til at MapPoint nå fungerer bedre Korteste vei fra s til v: Den stien som har lavest vekt-sum over kantene. Korteste vei 20
21
Bare bruk én-til-alle i stedet for én-til-én. Man kjenner ingen algoritme som har bedre asymtotisk worst-case (selv om det finnes «tweaks»). Varianter Bare snu kantene, så får du én-tilalle. Én-til-én Alle-til-én I dag Én-til-alle Senere Alle-til-alle 22
Optimal substruktur s x y z s x y z 23
Hvis vi tillater negative sykler kan vi bruke korteste vei til å løse lengste vei-problemet, som er NP-komplett. Ingen kjente løsninger. (Problemet er at vi da ikke lenger har optimal substruktur; evt. figur på tavla.) Sykler NPC whatevs < 0 0 24
Representasjon [v] Forgjenger i den korteste stien Forgjengergraf: V = {v V : [v] = nil} {s} E = {( [v], v) E : v V {s}} 25
s π[s] = nil x π[x] = s y π[z] y = x z π[z] = y 26
Relax u v u v 5 2 9 5 2 6 u v u v 5 2 7 5 2 6 27
Se slutten av intro til kap. 24 og avsnitt 24.5. Om dere ikke henger med på alt, tenk at dette kan være forskjellige perspektiver eller innsikter som kan hjelpe dere til å forstå forklaringene som kommer etterpå. Korteste vei-egenskaper 28
Fra starten Initialize- Single- Source π[v] = nil for enhver node v d[s] = 0 d[v] = for enhver annen node v 29
Trekantulikheten s u δ(s, v) δ(s, u) + w(u, v) v 30
Overestimat s v d[v] δ(s, v) 31
Ingen sti s v d[v] = 32
Konvergens s s u Relax d[v] = δ(s, v) v v 33
Sti-oppdatering s s s x y y Path relaxation property. v v 34 v Helt essensiell for forståelse av algoritmene i dag! Kjøres relax i rekkefølge på den korteste stien, vil endenoden få riktig estimat. Om vi kjører ekstra relax-er spiller ingen rolle.
Forgjenger-delgraf Forg jengerpekerne utgjør «korteste veitrær» s x y v 35
Hvis alle kanter relaxes «i hytt og vær», igjen og igjen, så vil alt bli riktig til slutt, på grunn av egenskapvene vi har sett. De riktige estimatene «sprer» seg, for hver kant i en korteste vei som blir relaxet «i riktig rekkefølge». (Spørsmålet blir om vi kan finne en lur rekkefølge å kjøre Relax i, så vi slipper å jobbe så mye. Det er der de mer spesifikke algoritmene slår til.) Generell metode 36
Tenk parallellitet Path relaxation er kjernen: Hvis vi sørger for alle kanter i korteste vei-treet blir relaxet i riktig rekkefølge fra rota (*minst*) så blir svaret riktig. Alle nodene kan få nye «tilbud» De som får nye tilbud kan gi nye tilbud videre Til slutt vil vi (hvis alle kantene besøkes om hverandre) få et riktig svar 37
Relax *alle* kantene én gang. Mengden noder med korrekt estimat har da vokst «ett skritt utover» fordi vi har kjørt relax på alle de riktige kantene i riktig rekkefølge. Litt mye ekstra-arbeid, dog Bellman-Ford 38
Tillater negative kanter Kan oppdage negative sykler som kan nås Beregner d[v] og π[v] for alle v i V 39
Initialiser grafen Hvorfor V 1 iterasjoner? Hvordan virker den siste sjekken? Kjør Relax på alle kantene Gjenta forrige punkt V 2 ganger Sjekk om ytterligere forbedringer er mulig Ja: Negativ sykel Nei: Alt i orden 40
Anta en kortest sti (v 0,, vk) Første iterasjon vil relaxe (v 0, v1) Iterasjon k vil relaxe (v k 1, vk) Vi vet da at d[vk] = δ(v0, k) Det siste er pga. sti-oppdateringsegenskapen (path relaxation). 41
Hvorfor blir dette kjøretiden? Kjøretid: Θ(VE) 42
Korteste vei Én til alle Ingen neg. sykler Relax alle kanter V 1 ganger Neg. vekter Sykelvarsel O(VE) Bellman Ford 43
Dynamisk programmering. Her vet vi riktig rekkefølge fra starten av (en topologisk sortering). Verdt å merke seg: All dynamisk programmering (som vi kommer til senere) er egentlig DAG-SP. Det er bare ikke alltid så lett å se DAG-en :-) «DAG-Shortest-Path» 44
Tillater (naturligvis) ikke sykler Tillater negative kanter Beregner også d og π 45
Kan gjøre det omvendt også og relaxe innkommende kanter. Sorter nodene topologisk Initialiser grafen For hver node u, i rekkefølge: For hver etterfølger v: Relax (u, v) 46
Enhver kortest vei vil gå fra venstre mot høyre Alle får relaxet kantene sine i riktig rekkefølge 47
Kjøretid: Θ(V + E) 48
Evt. lengste! Korteste vei Én til alle Ingen sykler Top-sort + Relax inn eller ut Effektiv men kravstor O(V + E) DAG-Shortest-Path 49
Motivasjon En slags intuisjon bak Dijkstras algoritme. Vil være korrekt (om enn ikke nødvendigvis effektiv) for heltallsvekter. Heltallsvekter i BFS 50
BFS skiller ikke på kanter med ulik vekt. Vil ikke nødvendigvis finne riktige avstander eller riktige stier. (Kan du finne et enkelt moteksempel?) For heltall kan vi omforme grafen så BFS fortsatt finner korteste veier 2 51
Det er bare å splitte opp kantene. Vekt 2 blir til to kanter (med en ny «dummy-node»). Merk: Dette er ikke noe som brukes i praksis bare intuitiv motivasjon. BFS vil nå fungere akkurat som før det bør være opplagt at vi får riktig svar. Hvordan oppfører algoritmen seg, hvis vi ser på den opprinnelige grafen? 52
Vi lar dummy-nodene være «usynlige» hvordan vil algoritmen «se ut» da? Algoritmen «sprer» fortsatt nodebesøkene ut fra start-noden i nivåer men høye kantvekter forsinker den (med usynlige «mellomstasjoner». Tiden det tar før vi besøker en node er proporsjonalt med den korteste veien dit (litt som bølger som sprer seg i et kanal-nettverk eller dominoer som faller). Kan vi kanskje simulere dette direkte, uten å bruke dummynoder? Hvordan kan vi besøke noder i avstandsrekkefølge når vi ikke kjenner avstanden? Samme prinsipp som før: Vedlikehold estimater når kan vi nå en node hvis vi følger de veiene vi har funnet så langt? Hoved-innsikt: Vi vil aldri kunne finne snarveier til den som alt ser ut til å være nærmest, så det er trygt å besøke den. 53
Her finnes det også (minst) en riktig rekkefølge for Relax, men den må vi oppdage litt etter hvert. Tenk vann som sprer seg i rør: Vi behandler krysningspunktene i den rekkefølgen de fylles. Det må gi oss riktige svar. Altså litt som DAG-SP, men ikke topologisk sortert vi ordner (på magisk vis) etter faktisk avstand. (Hvis vi bare tar med kanter i de korteste stiene så er grafen topologisk sortert ) Dijkstras algoritme 54
I stedet for topologisk rekkefølge: Etter stigende avstand fra s Som BFS men prioritetskø (med d[v]) i stedet for FIFO-kø Takler ikke negative kanter! 55
For spinkle grafer: Bruker binær haug som prioritetskø Må kunne endre nøkler (dvs. d[v]) underveis Må ha kobling mellom mellom noder og haug-innslag Kan evt. legge inn noder flere ganger i stedet 56
Initialiser grafen Så lenge det finnes uferdige noder: Velg u med lavest d[u] For alle kanter (u, v): Relax(u, v) 57
Hvis nodene besøkes etter stigende avstand: Kantene i korteste veier bli relaxet i riktig rekkefølge Topologisk sortering av kantene som «teller» Men Hvordan vet vi at lavest d[v] faktisk er nærmest? 58
Bokas variant av korrekthetsbeviset. Merk: Det er snakk om nok et bevis ved kontradiksjon. Vi antar at d[u] ikke er korrekt i det en node u legges til, og viser at vi får en selvmotsigelse. Den neste er kanskje forelesningens vanskeligste slide. 59
Anta at u er den første som ikke har riktig d- verdi når den legges til. Da må x ha hatt riktig d- verdi, og siden (x, y) er relaxet, så må y også ha riktig d-verdi i det u legges til. d[y] = (s, y) (s, u) d[u] Vi vet her at y forekommer før u på den korteste stien (Merk at x og y godt kan sammenfalle med s her.) Husk også at d er et overestimat av δ. Dette virker bare hvis vi ikke har negative kanter; ellers kan vi ta «snarveier» og vi vet ikke lenger hvilken node som er nærmest. 60 d[u] Men Siden u ble valgt før y så vet vi at d[u] d[y]. d[y] d[y] = (s, y) = (s, u) = d[u] Sandwitch!
Underliggende antagelse: u er den første med galt men minimalt avstandsestimat (blant de hittil ubesøkte). Vi har y med korrekt d d[y] = δ(s, y) Dette viste vi ved å se at det må finnes en y med en forgjenger x rett innenfor og som altså har fått kjørt relax på sin forgjengerkant i den korteste stien, og dermed har korrekt d. u ligger senere på korteste vei δ(s, y) δ(s, u) d[u] men besøkes likevel (feilaktig) Det er denne ulikheten som ikke gjelder hvis vi har negative kanter. Da kan en node tidligere på den korteste stien likevel ligge lenger unna startnoden. d[u] d[y] 61 Vi får altså både d[y] d[u] og d[u] d[y], dvs. d[y] = d[u], med de faktiske avstandene klemt imellom. Med andre ord: Begge avstandene er korrekte likevel og vi har en selvmotsigelse.
(Min egen variant av korrekthetsbeviset litt enklere (IMO) enn det i boka.) Hypotetisk: Vi ordner noder etter faktisk avstand. Vi har positive kanter, så bakoverkantene vil være irrelevante (selv om vi jo ikke vet hvilke de er). Med andre ord har vi en (skjult, ukjent) DAG. Vi ønsker å besøke nodene i avstandsrekkefølge *uten å kjenne til* denne rekkefølgen (eller DAG-en). Induksjon to the rescue Dette beviset antar unike/ forskjellige vekter! 0 3 7??? Vi har besøkt de k 1 første nodene, og relaxet kantene ut. Disse nodene har nå riktig avstandsestimat og det har også den neste i rekka (selv om vi ikke vet hvilken det er ennå). Det er akkurat som i DAG-shortest-path. 62 Betrakt den neste i sortert rekkefølge. Den har korrekt estimat. Alle de gjenværende har større avstand, og minst like store estimater. Dermed må den med lavest estimat være den neste, og vi har løst problemet for k.
Kjøretid avhengig av prioritetskøen. Hver Relax (det vil si, hver kant) kan måtte bruke Decrease-Key som koster O(lg V). Hver Extract-Min (dvs. for hver node) koster også O(lg V). Vi har altså: O(E lg V) + O(V lg V). Hvis alle kan nås fra starten vil E dominere, og vi får O((E+V) lg V) = O(E lg V). Kjøretid: O(E lg V) * * Hvis alle noder kan nås fra s 63
Korteste vei Én til alle Ingen neg. kanter Besøk nærmeste Relax til alle naboer Effektiv Spes. på spinkle G Kravstor O(E lg V) Dette er jo en gjenganger. Jo sterkere krav vi stiller, jo mer effektive er algoritmene. Dijkstras algoritme 64