http://www.idi.ntnu.no/~algdat algdat@idi.ntnu.no Pensum: 3. utg av Cormen et al. Øvingstime: I morgen, 14:15
b c g a f d e h
The pitch drop experiment. Foreløpig kjørt fra 1927 til nå. Åtte dråper har falt så langt.
bogo sort: test tilfeldige permutasjoner Ideer til andre hacks som ikke er like brutale? 5 3 6 0 1 2 4 0 4 3 2 1 6 5 1 2 5 4 6 0 3 2 3 5 1 4 6 0 Det første man ofte prøver seg på (som et hack ) er en brute force -løsning. Bare prøv alle mulige løsninger, f.eks. Som et alternativ til bogo sort kan vi systematisk generere alle permutasjoner (så vi ikke risikerer å sjekke noen av dem flere ganger), s.k. permutation sort. Noen ideer til forbedringer? 6 2 3 0 1 4 5 Hva med å ta vare på biter som er riktige? Og kanskje være litt mer systematisk med å sette på plass tall som er på feil plass?
Hvorfor har vi ikke løst problemet?
Hvorfor har vi ikke løst problemet? Fordi 100! = 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
Altså 93326215443944152681699238856266 70049071596826438162146859296389 52175999932299156089414639761565 18286253697920827223758251185210 916864000000000000000000000000 permutasjoner må sjekkes
cn 2 T (n) n 0
http://boingboing.net/2008/06/19 O-notasjonen representerer en øvre grense. Det er en grunn til det
Klasse Merk: Det spiller ingen rolle hvilken logaritme vi bruker. (Hvorfor?) O( ) konstant 1 logaritmisk lg n lineær n «enn-log-enn» n lg n kvadratisk n 2 kubisk n 3 polynomisk n k eksponentiell k n Det finnes også problemer som ikke kan løses polynomisk, problemer vi tror ikke kan løses polynomisk, og problemer som ikke kan løses i det hele tatt. Dette er funksjonsklasser som vi beskriver kjøretider med. Kjøretider som oppstår i krysningen algoritme+problem (dvs. type instanser). Permutation sort er altså enda verre n!
Påstand: Etter hvert som datamaskiner blir mer effektive, og raskt kan behandle større datamengder, så blir algoritmekonstruksjon mindre viktig. Vi har effektiv hardware Mulig motargument: Vi vil utnytte hardwaren bedre. Dobbelt så effektiv: 8 ganger så varm. Men det er ikke hovedargumentet hva skal vi med effektive algoritmer?
Sorter ti mill 20m 5.5h Freq Alg Impl 10 7 n lg n 50 Insertion sort er det vi ender opp med i dag. Merge sort lærer dere siden. 10 10 n 2 2 Frekvens: Instruksjoner per sekund. Algoritme: F.eks. merge sort kontra insertion sort. Implementasjon: F.eks. inkompetent, høynivåsimplementasjon kontra ninjalavnivås-implementasjon.
Sorter hundre mill 4h 23d Freq Alg Impl 10 7 n lg n 50 10 10 n 2 2
n 10 100 1.000 Hvis vi kan håndtere større problemer blir effektive algoritmer *viktigere*. n 2 100 10.000 1.000.000 2 n 1024 >10 30 >10 300 Bogo sort (og brute force) er *mye* verre enn dette, faktisk, med forventet kjøretid proporsjonal med n! ( n fakultet ).
n 1
h = lgn n = 2 h
IN DUKSJON RE KURSJON
A? A? B? B? B! B! A! A! A? A!
Assume Delegate 1 n 1 n n n 1 1 Deduce Extend
Litt tilfeldig valgte forenklinger (De fleste forenklinger vil kunne gi oss ideer.) Kan dere komme på andre forenklinger/ spesialtilfeller? Gir det dere noen ideer? Hva om sekvensen har lengde 2? Hva om alle utenom ett element er sortert? Hva om vi bare skal få på plass det minste? Hva om alle elementene er enten 0 eller 1?
Hva om sekvensen har lengde 2? 5 3 3 5 Hmm. Bytter plass på to elementer ved siden av hverandre samtidig med at vi sammeligner dem. Kanskje nyttig grunnoperasjon?
Hva om alle utenom ett element er sortert? 0 1 3 4 5 2 6 0 1 2 3 4 5 6 Hmm. Det må flyttes forbi elementer, som må forskyves, én og én. Kanskje vi bare kan dytte det gjennom med sammenligning/ombytting av naboer?
Hva om vi bare skal få på plass det minste? 6 2 3 0 1 4 5 0 6 2 3 1 4 5 Lignende situasjon, men må må vi *finne* den minste. Det hadde vært bra om vi kunne bake det inn i sammenligninger/ombyttinger. (Dette kan vi også ta videre for å komme frem til selection sort og bubble sort.)
Hva om alle elementene er enten 0 eller 1? 0 0 0 1 0 1 0 0 0 0 0 1 1 0 Hmm. Nullene til venstre trenger vi ikke flytte på. Hvis vi finner en ny null så må den presses gjennom evt. enere, inn i null-gruppen, med sammenlign-og-bytt - taktikken.
Mens dere tenker
Vær oppmerksom på at tabeller i læreboka indekseres fra 1 til n så indekseres de i Java og Python fra 0 til n-1 x > x x i j i j x x > x Insertion-Sort(A) 1 for j = 2 to A.length 2 x = A[j] 3 // Sett x inn i A[1.. j 1]: 4 i = j 1 5 while i > 0 and A[i] > x 6 A[i + 1] = A[i] 7 i = i 1 8 A[i + 1] = x Nå har vi jo allerede smugtittet på kjøretiden, da vi sammenlignet med merge sort men hvordan kommer vi frem til den?
For de nysgjerrige: Her er alle de viktigste algoritmene dere skal lære. Bellman-Ford BFS/DFS Binære søketrær Binærsøk Bubblesort Bucket sort Counting sort Dijkstra DAGshortest-path Edmonds- Karp Floyd- Warshall Hashing Heapsort Huffmankoding Insertion sort Kruskal Merge sort Prim Quicksort Radix sort Randomized Select Select Selection sort Sterke komponenter Topologisk sortering
Bellman-Ford BFS/DFS Binære søketrær Binærsøk Bubblesort Bucket sort Counting sort Dijkstra DAGshortest-path Edmonds- Karp Floyd- Warshall Hashing Heapsort Huffmankoding Insertion sort Og denne skal vi ta i dag. Kruskal Merge sort Prim Quicksort Radix sort Randomized Select Select Selection sort Sterke komponenter Topologisk sortering