O(1) søking? Søking i sortert array og i søketrær: Optimalt søk som er O(1):

Transkript

1 Hashing

2 O(1) søking? Søking i sortert array og i søketrær: Er basert på sammenligninger med verdier som allerede finnes i datastrukturen Effektiviteten er log n, avhenger av n (antall verdier i datastrukturen) Søket går saktere jo flere data som er lagret Optimalt søk som er O(1): Finn den søkte verdien med bare ett direkte oppslag i datastrukturen, uavhengig av n Er praktisk mulig bare hvis antall elementer er lite og vi har en gitt nummerering av alle elementer som kan lagres i datastrukturen (f.eks. 11 spillere på et fotballag)

3 Hashing: Et forsøk på å lage en O(1) datastruktur Alle dataene lagres i en array med «nok plass», en hashtabell (aka «buckets») Hvert element som lagres har en nøkkelverdi Ut i fra nøkkelverdien beregnes hvilken indeks i hashtabellen som et element skal ligge på Indeksen beregnes med en hashfunksjon Indeksen som beregnes kalles en hashverdi Hvis alle hashverdier som beregnes er ulike, har alle elementer en unik indeks søking (og innsetting og fjerning) i hashtabellen blir da O(1)!

4

5 Hashing: Eksempel Skal lage et register for maksimalt 1000 objekter Hvert objekt indentifieres med en nøkkelverdi som er et unikt syvsifret tall, f.eks Kan bruke array med 10 mill. elementer, men... Bruker en array med lengde 1000 (hashlengden) Bruker en enkel hashfunksjon: De tre siste sifrene av nøkkelverdien brukes som hashverdi hash(key) = key % 1000 hash( ) = 996 (objektet lagres på indeks 996) Og da er alt i orden og vi har en O(1) struktur?

6 Problem: Kollisjoner (hash-clash) Kollisjon: To dataobjekter får samme indeks i hash-tabellen Eksempel: hash(key) = key % 1000 hash( ) = 331 hash( ) = 331 Hashing kan bli O(n) hvis mange kollisjoner

7 Og kollisjoner skjer «hele tiden» «En ulykke skjer sjelden alene» «Alt her i verden» (data) har en tendens til å ville skje samtidig og/eller opptre i klynger/clustere: Byer, bilkøer, industriklynger, sosiale samlinger Fornavn Maurtuer, fiskestimer, gresshoppesvermer Skogholt, oaser Galakser, stjernehoper, Hvorfor det alltid er slik vet vi egentlig ikke, men: Det skal «veldig lite til» før ting begynner å kollidere Klassisk eksempel: Fødselsdagsparadokset

8 Hashing, kollisjoner og effektivitet Ved bruk av hashing vil det alltid være mange kollisjoner i store datamengder For at hashing skal være effektivt, må: Hashfunksjonen som brukes gi et lite/minimalt antall kollisjoner og spre dataene godt i hashtabellen Kollisjoner håndteres så effektivt som mulig Hvis disse to kravene tilfredsstilles, kan hashing være mer effektivt enn både søketrær og B-trær for svært store datamengder

9 Vanlige anvendelser av hashing I store databasesystemer Internt i operativsystemer: Memoryhåndtering Filsystemer I kompilatorer Symboltabeller (funksjons- og variabelnavn) Spillprogrammer Lagring av «alle muligheter videre» i strategispill som f.eks. sjakk Rask gjenfinning av f.eks. grafikkelementer i 3D-spill Stavekontroll Rask tilgang til riktig stavede ord krever ikke alfabetisk sortering MS Word, emacs...

10 Hashfunksjoner Hash: «Kutte opp i biter og blande sammen» Perfekt hashfunksjon: Lager aldri kollisjoner, alle elementer får unik indeks Finnes bare for kontrollerte tilfeller der alle data er kjent Krav til en god/effektiv hashfunksjon: Beregning av hashverdien må være rask og O(1) Sprer hashverdiene jevnt i hashtabellen Minimerer antall kollisjoner Konstruksjon av gode hashfunksjoner er ingen «eksakt vitenskap»: Avhengig av datasettet og av lengden(!) på tabellen Baserer seg i stor grad på heuristikk og empiri

11 Noen (mer eller mindre) ulike og vanlige typer hashfunksjoner Trunkering Sammenslåing («folding») Midten-av-kvadratet Bytte av tallsystem Utplukk og ombytting Basert på lengde av nøkkelverdi

12 Hashfunksjon: Trunkering og/eller bruk av resten ved heltallsdivisjon «Klipper» bare ut en del av nøkkelverdien Eksempler: Nøkkelverdi er en streng: Bruk de tre første bokstavene, tolket som siffer Nøkkelverdi er et heltall: Bruk de k siste sifferne, finnes med heltallsdivisjon (nøkkelverdi % 10 k ) Fordel: Rask beregning av hashverdi Ulempe: Fordeler ujevnt, gir oftest mye kollisjoner i tabellen

13 Hashing med heltallsdivisjon Eksempel hashlengde = 8 hash(key) = key % hashlengde hash(36) = 36 % 8 = 4 hash(18) = 18 % 8 = 2 hash(72) = 72 % 8 = 0 hash(43) = 43 % 8 = 3 hash(6) = 6 % 8 =

14 Hashfunksjon: Sammenslåing («folding») Del opp nøkkelverdien i flere «småbiter» Så sammen/kombinér «småbitene», med f.eks. aritmetiske operasjoner, til en hashverdi Eksempel: Nøkkelverdi: Lengde av hashtabell (hashlengde) 1000 Hashverdi: ( ) % 1000 = 100 Sammenslåing sprer oftest bedre enn trunkering, spesielt hvis hashlengden er et primtall! (997 og 1009 er bedre som hashlengder enn 1000)

15 Sammenslåing: Eksempel hashlengde = 1009 nøkkelverdi: en tekststreng int hash(string s) { int h = 0; for (int i = 0; i < s.length(); i++) h += (int)(s.charat(i)) return h % 1009; } hash("vw Karmann Ghia") = 317 hash("porsche 356A") = 979 hash("alfa Romeo Spider") = 556 hash("renault Floride") = 463

16 Hashfunksjon: Midten-av-kvadratet Anta nøkkelverdien er et heltall Beregn kvadratet av nøkkelverdien Hashverdi: Siffere i midten av kvadratet Eksempel: Bruker hashverdier med tre sifre ( ) Nøkkelverdi: = hash(18562) = 547 Kan også brukes på ikke-numeriske nøkkelverdier, ved å tolke bitsekvensene som tallverdier

17 Hashfunksjon: Bytte av tallsystem Antar nøkkelverdi er et desimalt heltall, skrevet i det vanlige 10-tallsystemet Grunntallet er 10, sifferne er 0, 1, 2, 3,..., 8, = = Skriver om nøkkelverdien til f.eks. 8-tallsystemet: Grunntallet er 8, sifferne er 0, 1, 2, 3, 4, 5, 6, = = Hvis hashlengden er 1009: hash(1369) = 2531 % 1009 = 513 Bytte av tallsystemer i Java: Se f.eks. Integer.toOctalString

18 Hashfunksjon: Utplukk og ombytting Tar ut enkelte siffer (eller tegn) fra nøkkelverdien og bytter om på disse Sprer relativt godt i de fleste tilfeller Eksempel: Vil ha fire-sifrede hashverdier Nøkkelverdier med tolv siffer: Tar ut siffer nummer tre, seks, ni og tolv: 3851 Hashverdi: En eller annen omstokking av sifferne: Reversering: 1583 Høyreskift: 1385 Venstreskift: 8513 Parvis bytting: 8315

19 Hashfunksjon: Basert på lengde av nøkkelverdi Beregner en hashverdi basert på en nøkkelverdi og nøkkelverdiens lengde Eksempel: Nøkkelverdier med åtte siffer: Ganger de tre første sifrene med lengden av nøkkelverdiene: = 3696 Deler på det siste sifferet: 3696 / 7 = 528 hashverdi = 528 % hashlengde

20 Innsetting av dataelement i hashtabell 1. Bruk en hashfunksjon til å beregne elementets hashverdi h ut i fra elementets nøkkelverdi 2. Sett inn dataelementet i hashtabellen Innsetting er O(1) hvis problemet med kollisjoner kan løses med en O(1) operasjon Innsetting blir langsommere enn O(1) når hashtabellen blir «for full» av data load factor: Måler hvor full en hashtabell er load factor = antall elementer / hashlengde load factor = 0.5 : halvfull hashtabell

21 Håndtering av kollisjoner To standard metoder for å håndtere kollisjoner: Åpen adressering (open adressing): Hvis en indeks i hash-tabellen er opptatt, legges elementet et annet sted i tabellen på en eller annen systematisk måte (f.eks. neste ledige) Kjeding (chaining): Hvert element i hash-tabellen er en lenket liste (eller et søketre?) som inneholder alle elementer med samme hashverdi Load factor: Åpen adressering: Maks. 1.0 Kjeding: Kan være større enn 1.0

22 Åpen adressering Hvis hashindeksen som beregnes er opptatt, gjør vi en «probing» (søk) etter en annen indeks i hashtabellen der vi kan legge elementet Probingen må være systematisk/deterministisk, slik at vi kan finne igjen elementet ved søking Må håndtere muligheten for at vi ikke finner noen ledig plass i tabellen (kommer tilbake til startindeksen) Fire strategier/metoder for åpen adressering: Lineær probing Kvadratisk probing Dataavhengig probing/rehashing Probing med en (pseudo) randomgenerator

23 Enkleste variant av åpen adressering: Lineær probing Beregn dataelementets hashverdi h Hvis indeks h i hashtabellen er opptatt: Sett inn nytt dataelement på første ledige indeks etter indeks h Hvis indeks h + 1 er opptatt, prøv å sette inn på indeks h + 2, h + 3, h + 4, osv., inntil en ledig plass er funnet Gjør en «wrap-around» (fortsett med indeks 0) hvis vi kommer til slutten av tabellen

24 Lineær probing: Eksempel

25 Fordeler med lineær probing Enkelt å programmere Svært rask beregning av probes (kun én addisjon) Det kan bevises matematisk at: Hvis dataene som settes inn er «rimelig» tilfeldige og load factor er 0.5 (maks. halvfull hashtabell), vil lineær probing (nesten) alltid gi hashtabeller med O(1) effektivitet

26 Problemer med lineær probing Forsterker tendenser til clustering/klumping: Sprer ikke data som begynner å lage clustere Alle elementer som hashes til samme indeks («primary clustering») vil fortsatt bli liggende i en «klump» i tabellen Innsetting og søking vil begynne å ta lang tid når tabellen er full (load factor > 0.7) Det blir (for) lange sekvenser i tabellen som må gås gjennom for å finne en ledig plass Bedre med en probingstrategi som bidrar til å løse opp «primary clustering»

27 Kvadratisk probing Beregn dataelementets hashverdi h Hvis indeks h i hashtabellen er opptatt: Forsøk å sette inn på indeks h + 1 Hvis indeks h + 1 er opptatt, prøv å sette inn på indeksene: h + 4, h + 9, h + 16, h + 25, h + 36, osv., inntil en ledig plass finnes Gjør en «wrap-around» (fortsett med indeks 0) hvis vi kommer til slutten av/havner utenfor tabellen

28 Kvadratisk probing: Eksempel

29 Fordeler med kvadratisk probing Relativt enkelt å programmere Sprer elementene bedre enn lineær probing Løser opp «primary clustering» ved å flytte elementer med lik hashverdi langt fra hverandre Det kan bevises matematisk at: Hvis load factor er 0.5 og hashlengden er et primtall, vil kvadratisk probing alltid gi hashtabeller med O(1) effektivitet

30 Problemer med kvadratisk probing Beregning av «probes» med kvadrering er mer kostbart Løser ikke opp «secondary clusters»: «Klumper» av elementer, som har hashverdier som ligger nære hverandre i hashtabellen, vil bare flyttes rundt og i liten grad spres Matematisk analyse av kvadratisk probing er vanskeligere enn for lineær probing, og ikke komplett de mest bruke løsningene er i stor grad basert på «best practice»

31 Lineær og kvadratisk probing: Sammenligning av effektivitet av søking Konstant load factor lik 0.9, varierende hashlengder Søk der element ble funnet Søk der element ikke ble funnet

32 Lineær og kvadratisk probing: Sammenligning av effektivitet av søking Konstant hashlengde lik 1000, varierende load factor Søk der element ble funnet Søk der element ikke ble funnet

33 Andre metoder for åpen adressering For å få enda bedre spredning og fjerne også sekundære clustere: Dataavhengig probing/rehashing Bruk en ny og anderledes hashingfunksjon for å finne neste indeks/probe ved kollisjoner Hvis neste indeks også er opptatt, prøv med f.eks. 2 ganger ny hashverdi, deretter 3 ganger ny verdi etc. Probing med en (pseudo) randomgenerator Hvis kollisjon, bruk hashverdien som seed i en randomgenerator og beregn nye indekser som en sekvens av «tilfeldige» tall (% hashlengde) inntil ledig plass funnet Fungerer fordi alle randomgeneratorer er deterministiske (pseudo random)

34 Når hashtabellen blir «full» Ved bruk av åpen adressering bør hashlengden økes, for å sikre ~O(1) effektivitet, når: load factor blir > 0.8, eller vi ikke finner noen ledig indeks ved kollisjoner Vanlig å øke lengden av hashtabellen til det «dobbelte» Vet at effektiviteten er garantert for load factor < 0.5 Velger oftest hashlengde lik nærmeste primtall Økning av hashlengden er en O(n) operasjon: Alle elementer må hashes på nytt for at de skal kunne finnes igjen med ny hashlengde

35 Fjerning av elementer fra en hashtabell med åpen adressering Er vanskelig, fordi vi risikerer å «bryte kjeden» ved å fjerne et element som ligger i en liste av probes som er resultatet av flere kollisjoner Vanlig løsning: Ikke fjern elementer, men bruk i stedet en ekstra boolsk array til å merke at elementer skal slettes Ved kollisjoner kan vi stoppe kjeden av probes når vi kommer til et element som er merket som fjernet, og bare overskrive dette elementet Alle elementer som er merket som fjernet, blir tatt vekk hver gang vi må gjøre en fullstendig rehashing i forbindelse med økning av lengden på hastabellen

36 Hashing med kjeding Hashtabellen er en array av lister (buckets): Vanlig å bruke en usortert lenket liste Alternativt kan den lenkete listen «simuleres» ved å legge elementer som kolliderer i et ekstra «overflow» område i hashtabellen, for å spare noe overhead/ lagerplass til pekere (se figur 14.3 i læreboken) Kollisjoner løses enkelt: Alle elementer som får samme hashverdi legges inn i listen som ligger på denne indeksen i hashtabellen Hashing med kjeding partisjonerer dataene opp i små delmengder som kan behandles effektivt

37 Kjeding: Eksempel

38 Effektivitet av hashing med kjeding Innsetting og søking krever: Beregning av hashverdi/indeks i hashtabellen Sekvensielt søk i den usorterte listen som ligger lagret på denne indeksen Hashing med kjeding er O(1) hvis: Hashfunksjonen sprer jevnt, slik at ingen lister blir veldig lange Load factor ikke er for stor, slik at listene ikke blir for lange selv om hashfunksjonen er god

39 Load factor, hashlengde og kjeding Kjeding fungerer også for load factor større enn 1.0, hvis hashfunksjonen sprer jevnt: Fra Wikipedia: Chained hash tables remain effective even when the number of table entries n is much higher than the number of slots. Their performance degrades more gracefully (linearly) with the load factor. For example, a chained hash table with 1000 slots and 10,000 stored keys (load factor 10) is five to ten times slower than a 10,000-slot table (load factor 1); but still 1000 times faster than a plain sequential list, and possibly even faster than a balanced search tree.

40 Effektivitet av kjeding: Test av søking Load factor = 1.0 Varierende hashlengde Fast hashlengde Varierende load factor

41 Kjeding: Fordeler og ulemper Fordeler: Raskere(?) søking enn for åpen adressering, fordi vi alltid bare sammenligner med elementer som har samme hashverdi Tåler load factor >> 1.0, mindre behov for økning av hashlengde og full rehashing Fjerning av elementer er enkelt (lenket liste) Ulemper: Krever O(n) ekstra plass til referanser/pekere Økning av hashlengde med full rehashing er mer komplisert/tidkrevende enn for åpen adressering, fordi vi må håndtere dynamisk hukommelse/pekere

42 Sammenligning: Søkealgoritmer og datastrukturer Sortert? Innsetting Søking Fjerning Sekvensiell Liste/array Nei O(1) O(n) O(n) Binærsøk Array Ja O(n) O(log n) O(n) Søketre* Binært tre Ja O(log n) O(log n) O(log n) Hashing** Nja... O(1) O(1) O(1) Søkealgoritme Datastruktur Hashtabell Interpol.- søk Array Ja O(n) O(log(log n)) O(n) *: Garantert oppførsel (AVL) **: Ikke garantert