Föreläsning 9: Hashning, Bloomfilter

Föreläsning 9: Hashning, Bloomfilter • • • • • • • • •

Idén med hashning Komplexiteten för sökning Dimensionering av hashtabellen Hashfunktionen Krockhantering Javaklassen Hashtable Om stavningskontroll Boolesk hashtabell Bloomfilter

Idén med hashning Binärsökning i en ordnad vektor går visserligen snabbt, men sökning i en hashtabell är oöverträffat snabbt. Och ändå är tabellen helt oordnad (hash betyder ju hackmat, röra). Låt oss säga att vi söker efter Kalas i en hashtabell av längd 10000. Då räknar vi först fram hashfunktionen för söknyckeln Kalas och det ger detta resultat. "Kalas".hashCode() -> 72260712

Hashvärdets rest vid division med 10000 beräknas nu 72260712 % 10000 -> 712

och när vi kollar hashtabellens index 712 hittar vi Kalas just där! Hur kan detta vara möjligt? Ja, det är inte så konstigt egentligen. När Kalas skulle läggas in i hashtabellen gjordes samma beräkning och det är därför ordet lagts in just på 712. Hur hashfunktionen räknar fram sitt stora tal spelar just ingen roll. Huvudsaken är att det går fort, så att inte den tid man vinner på inbesparade jämförelser äts upp av beräkningstiden för hashfunktionen.

Komplexiteten för sökning Linjär sökning i en oordnad vektor av längd N tar i genomsnitt N/2 jämförelser, binär sökning i en ordnad vektor log N men hashning går direkt på målet och kräver bara drygt en jämförelse. Varför drygt? Det beror på att man aldrig helt kan undvika krockar, där två olika namn hamnar på samma index.

Dimensionering av hashtabellen Ju större hashtabell man har, desto mindre blir risken för krockar. En tumregel är att man bör ha femtio procents luft i vektorn. Då kommer krockarna att bli få. En annan regel är att tabellstorleken bör vara ett primtal. Då minskar också krockrisken, som vi ska se nedan.

Hashfunktionen Egentligen skulle man vilja ha en perfekt hashfunktion, dvs en funktion som ger olika värden för olika söknycklar. I regel är dock detta inte praktiskt möjligt, eftersom det kräver 1. en hashtabell som har minst lika många platser som det finns söknycklar, 2. en perfekt hashfunktion som inte är för tidskrävande att beräkna, 3. att man lyckas hitta en perfekt hashfunktion (dom är sällsynta). I vissa specialfall (t ex när man vill skapa en tabell över reserverade ord) kan det finnas anledning att försöka hitta en perfekt hashfunktion och det finns algoritmer för detta, t.ex. Cichelli's metod och FHCD-algoritmen i Drozdeks bok. Men vi begränsar oss här till enklare metoder. Ofta gäller det först att räkna om en String till ett stort tal. I Java gör man ingen skillnad på en bokstav och dess nummer i UNICODE-alfabetet, därför kan ABC uppfattas som 656667. Det man då gör är att multiplicera den första bokstaven med 10000, den andra med 100, den tredje med 1 och slutligen addera talen. På liknande sätt gör metoden hashCode() men den använder 31 i stället för 100. Ur javadoc för String.hashcode(): public int hashCode() Returns a hashcode for this string. The hashcode for a String object is computed as s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation (…)

Om man vill söka på datum eller personnummer kan man använda det som stort heltal utan särskild hashfunktion. Exempel: sexsiffriga datum kan hashas in i hashvektorn med 990323 % size. En olämplig storlek är 10000, ty 990323 % 10000 --> 323

och vi ser att endast 366 av de 10 000 platserna kommer att utnyttjas. Det säkraste sättet att undvika sådan snedfördelning är att byta 10000 mot ett närliggande primtal, till exempel 10007. Det visar sej nämligen att primtalsstorlek ger bäst spridning. Alla objekt i Java får automatiskt en hashCode()-metod (ärvd från klassen Object). Men i regel returnerar metoden bara objektets minnesadress omvandlat till ett heltal, vilket vi inte har någon större nytta av.

Krockhantering Det naturliga är att lägga alla namn som hashar till ett visst index som en länkad krocklista. Om man har femtio procents luft i sin vektor blir krocklistorna i regel mycket korta. Krocklistorna bör behandlas som stackarna, och hashtabellen innehåller då bara toppekarna top till stackarna. Den andra idén är att vid krock lägga posten på första lediga plats (linear probing). En fördel är att man slipper alla pekare. En nackdel blir att man sedan inte enkelt kan ta

bort poster utan att förstöra hela systemet, vilket man kan lösa genom att markera poster som borttagna istället för att ta bort dom. Ett annat problem man brukar råka ut för här är klustring, man får stora klumpar med poster, vilket gör att det kan ta lång tid att hitta nästa lediga plats. Om man vid en krock på plats n istället väljer att titta på plats n+12, n+22, n+32 osv (quadratic probing) får man bättre fördelning av posterna.

Javaklassen Hashtable Hashtable är en utmärkt och lättskött klass med två anrop, put och get. Första parametern till put är söknyckeln, till exempel personens namn. Andra parametern är ett objekt med alla tänkbara data om personen. Metoden get har söknyckeln som indata och returnerar dataobjektet om nyckeln finns i hashvektorn, annars returneras null. Här är ett exempel från Hashtables dokumentation där söknyckeln är talets namn ("one") och data är ett Integer-objekt som representerar talet. Hashtable table = new Hashtable(); table.put("one", new Integer(1)); table.put("two", new Integer(2)); table.put("three", new Integer(3));

För att få tillbaka talet skriver man så här: Integer n = (Integer)table.get("two"); if (n != null) { System.out.println("two = " + n); } Eftersom det som kommer ut är av typen Object, måste man oftast typa om det till aktuell klass. Om det har skapats med new Elefant() ser omtypningen ut så här: data=(Elefant)table.get(key);

Hashtabell eller Binära sökträd Sökning sker med O(1) respektive O(log n). Det är viss skillnad men inte jättestor. Binära träd är känsligt för sorterad indata. Binära sökträd har ett par fördelar, t.ex. att man kan skriva ut alla element i ordning. Man kan dessutom skriva ut flera element i ett visst intervall. Detta går inte med en hashtabell.

Stavningskontroll Ett stavningskontrollprogram ska läsa en text och markera alla ord som är felstavade. Om man har tillgång till en ordlista som innehåller alla riktiga svenska ord kan man använda följande enkla algoritm för att stavningskontrollera en text. • • •

Läs in ordlistan i en lämplig datastruktur. Öppna textfilen. Så länge filslut inte nåtts: o Läs in nästa ord från filen. o Slå upp ordet i ordlistan och skriv ut det på skärmen om det inte finns med.

Enda problemet är hur man ska välja datastruktur för lagring av ordlistan. Svenska akademiens ordlista innehåller ungefär 200000 ord. Förutom dessa ord finns en hel del böjningsformer och oändligt många tänkbara sammansättningar. Låt oss bortse från detta och anta att vi har köpt en ordlista med dom 200000 vanligaste orden i svenskan. Om vi snabbt ska kunna stavningskontrollera en stor text med en normal persondator måste följande krav på datastrukturen vara uppfyllda. • • • •

Uppslagning måste gå jättesnabbt. Datastrukturen får inte ta så mycket minne. Orden måste vara kodade (eftersom ordlistan är köpt och inte får spridas). Vi kan tillåta att uppslagningen gör fel någon gång ibland.

Den sista punkten är inte ett krav utan en egenskap hos vårt problem som vi kan utnyttja. Det är nämligen inte hela världen om programmet missar något enstaka felstavat ord i en jättestor text. Vanliga datastrukturer (sorterad array, sökträd, hashtabell) faller alla på något av kraven ovan. Försök med datastruktur: boolesk hashtabell Låt oss först försöka med hashning där vi inte lagrar själva orden och inte tar hand om eventuella krockar. Vi har en hashfunktion f(ord)=index som för varje ord anger en position i en boolesk hashtabell tab. Den booleska variabeln tab[f(ord)] låter vi vara sann (1) då ord ingår i ordlistan. Detta ger en snabb, minnessnål och kodad datastruktur, men den har en stor brist: Om det råkar bli så att hashfunktionen antar samma värde för ett ord i ordlistan som för ett felstavat ord så kommer det felstavade ordet att godkännas. Om hashtabellen exempelvis är fylld till häften med ettor så är sannolikheten för att ett felstavat ord ska godkännas ungefär 50% vilket är alldeles för mycket. Bloomfilter Lösningen är att använda många hashfunktioner som alla ger index i samma hashtabell tab. I Viggos stavningskontrollprogram Stava används till exempel 14 olika hashfunktioner f0(ord),f1(ord), f2(ord),...,f13(ord). Ett ord godkänns bara om alla dessa 14 hashfunktioner samtidigt ger index till platser i tab som innehåller sant (det vill säga 1). Uppslagning av ett ord kan då ske på följande sätt: for(int i=0; i