Opgaven Hash Tabellen Datastructuren, 15 juni 2018, Werkgroep.

Transcriptie

1 Opgaven Hash Tabellen Datastructuren, 15 juni 2018, Werkgroep. Gebruik deze opgaven, naast die uit het boek, om de stof te oefenen op het werkcollege. Cijfer: Op een toets krijg je meestal zes tot acht opgaven. 1. Maximum in Direct Address: Zie boek, Cormen Bekijk alle plekken van de array van achter af. Als het maximum B is, bekijk je zo m B posities. Dat kan oplopen tot Θ(m) wanneer B klein is. 2. Aantal Collisions: Zie boek, Cormen ( ) n Voor elk paar (k, l), waar er oftwel 1 n(n 1) van zijn, is de kans op 2 2 ( ) een botsing 1. Het verwachte aantal is daarom n 1 n(n 1), wat gelijk is aan m 2. m 2m 3. Hashen uitproberen: Zie boek, Cormen Hashen naar gesorteerde lijst: Zie boek, Cormen Voor succesvol zoeken maakt het niet uit, zolang je elke key evenvaak vraagt. Succesloos zoeken wordt iets sneller omdat je gemiddeld halverwege de lijst kunt stoppen. Invoegen wordt duurder omdat je de lijst moet doorploegen in plaats van voor- of achteraan zetten in constante tijd. Voor Delete geldt het zelfde als voor succesvol zoeken. De besparing is marginaal omdat het idee van hashing is, dat de lijsten zeer kort zijn dus hun performance nauwelijks van belang. 5. Hashen Worst Case: Zie boek, Cormen Bij een gegeven hash functie H kun je per locatie i kijken naar het aantal elementen van U dat naar i hasht, noem dit s i. Omdat de #U elementen naar m locaties hashen, is het gemiddelde aantal keys per locatie #U/m, en volgens het gegeven is dit groter dan n. Voor elke verzameling getallen is het maximum minstens zo groot als het gemiddelde (pigeon hole principle), dus de grootste s i is zeker groter dan n. 6. Samplen uit Hashtabel: Zie boek, Cormen

2 7. Hashes in linked list: Zie boek, Cormen Om te zoeken in een gelinkte lijst, moet je de aanwezige elementen een voor een vergelijken met je query-key. Hier zijn de keys lange strings, en het vergelijken van zo n key kost daarom meer tijd (evenredig met de lengte van de strings in het slechtste geval). Bereken eerst de hash waarde van de query-key. Vergelijk voor elk element in de lijst eerst de hash-waarde, en alleen bij gelijkheid de hele string. De opgave noemt geen gegevens waarmee je het effect kunt uitrekenen. Stel dat de lijst n elementen bevat en dat de strings elk uit l tekens bestaan; bij string vergelijken heb je pech wanneer de strings in het begin overeen komen. Stel dat de hash m waarden kan hebben en uniform is. Een onsuccesvolle zoekactie zonder gebruik van hash kost n keer een string vergelijken, dus Θ(nl) tijd. De nieuwe methode vergelijkt n hashes, en een hele string in 1 per m gevallen, dus kost Θ(n + nl/m). Aangezien m meestal vrij groot is, zal dit in de praktijk een factor l schelen. 8. Ruimte-efficient hashen: Zie boek, Cormen Noem de r karakters c 0 t/m c r 1. De numerieke waarde van de string als radix-128 getal is i 128i c i. Je kunt dit snel modulo m uitrekenen met Horner s Rule, waarbij je na elke stap reduceert modulo m: h = c[r-1] for (int i = r-2; i >= 0 ; i--) h = (h * c[i]) % m; return h; 9. Letterwissel: Zie boek, Cormen De vraag is in feite een abstracte versie van de negenproef; om de rest mod 9 van een getal te bepalen, hoef je alleen maar de cijfers bij elkaar te tellen. Verwisseling van cijfers geeft uiteraard nog steeds hetzelfde resultaat. De radix R is hier R = 2 p en m = 2 p 1, en die combinatie is heel slecht. Er geldt immers dat R = 1 (mod m) en daarmee heeft ook elke macht van R, rest 1: R i %m = 1. De hashfunctie kent aan de string met karakters c 0 t/m c l 1 de hash h = ( i Ri c i )%m toe, maar vanwege de keuze van R en m is dit gelijk aan i c i (deze waarde zal meestal kleiner dan m zijn). Aan deze formule zie ten eerste dat de volgorde van de letters niet uitmaakt. Een tweede, misschien wel groter bezwaar, is dat de waarden heel klein zijn. Met strings van l tekens uit een alfabet van R is de waarde kleiner dan l R. Je krijgt dus veel collisions onderin je hashtabel. 10. Fibonacci-hash: Zie boek, Cormen Ik kom op 700, 318, 936, 554, 172, dus er lijkt wel enige spreiding te zijn.

3 11. Invoegen in Open Adressering: Boek, Cormen Verwijderen bij Open Adressering: Boek, Cormen Zoektijd bij Open Adressering: Boek, Cormen Bij een onsuccesvolle zoekactie ga je door tot een leeg slot, wat je steeds met kans (1 α) tegenkomt. Volgens Stelling 11.6 is de verwachte zoektijd 1, dus 1 α respectievelijk 4 en 8. Bij succesvol zoeken loop je de sequence alleen af tot je de key vindt, en volgens Stelling 11.8 is het aantal verwacht hoogstens 1 ln 1. Voor α = 3/4 α (1 α) is dit 1,85 en voor α = 7/8 is dit 2, HashCode voor string: Zoek uit hoe C# een hashcode bepaalt voor type String. Kun je twee strings bedenken die dezelfde HashCode hebben?

4 15. ContainsValue: Christa slaat records op die een (spelers) naam en een score bevatten. Zij wil kunnen invoegen/verwijderen/zoeken op naam, en zij heeft een efficiente ZoekSc(s) nodig die de naam oplevert van een speler met score s. (a) Christa overweegt opslag in een hashtabel met de naam als key. Hoe kan zij een ZoekSc(s) uitvoeren? (b) Hoeveel tijd kost de ZoekSc bij deze opslag (noem de lengte van de hashtabel m en het aantal records n)? (c) Kan Christa haar ZoekSc(s) sneller krijgen door de records in een zoekboom op te slaan? Leg uit. (a) Christa moet alle records enumereren en checken of s erin zit (en kan misschien eerder termineren als ze s vindt). (b) Voor een hashtabel met m plaatsen en n keys kost dit O(n + m) tijd, dus zeg lineair. (c) Een zoekboom is voor Christa niet beter. Je kunt wel meer met de keys waarop de boom geordend is, maar zoeken op een andere waarde kan niet efficienter dan lineair. Christa zal haar boom moeten ordenen op naam en dan kost zoeken op score lineaire tijd. (Christa kan het beste bij haar verzameling records, twee hashtabellen maken: eentje waarin gehasht wordt op de key en eentje waarin gehasht wordt op value. Alle vier de operaties kunnen dan in O(1) tijd. Tot 3pt, 1 per deelvraag. Voor de beoordeling moet wel duidelijk zijn dat je het centrale probleem snapt: dat Christa wil zoeken op een veld dat niet de key van de datastructuur is. B = Een Boom is altijd trager dan een hashtabel omdat (door de aanpassing van m aan n) de α doorgaans begrensd blijft. C = Ze moet een ContainsValue doen, ja, ok, maar hoe moet dat dan? 0pt. E = Boom Enumereert sneller omdat je de lege velden niet hebt geeft maar 1/2pt. Bij normale load factor enumereren hashtabel en boom in lineaire tijd, en Θ(n) is nog steeds heel veel. H = Uitlag hoe Hashen normaal werkt (key afbeelden op getal en in array opzoeken) Werd niet gevraagd. L = Bij begrensde Load factor α zijn n en m asymptotisch gelijk en kun je Θ(n) of Θ(m) schrijven. N = Itereren over alle Namen kan niet zomaar in een hashtabel. S = Een zoekboom (of hashtabel) met Score als key is niet goed voor Christa omdat ze daarmee geen toegang meer heeft met een naam, 0pt.

5 16. Hashen van Strings: Nico bouwt een hashtabel om gegevens van ongeveer een miljoen studenten op te slaan. Hij wil snel kunnen toevoegen, zoeken en verwijderen op naam. Om deze opgave niet te moeilijk te maken, nemen we aan dat elke naam een rijtje is van hoogstens 12 letters (a t/m z). (a) Welke twee manieren zijn er om keys met gelijke hashwaarde af te handelen, en welke raad je aan voor Nico en waarom? (b) Nico geeft elke letter een getal (namelijk a=1, b=2, tot z=26) en berekent de HashCode als de lettersom (dus bv Tel heeft HashCode 37). Waarom werkt Nico s tabel erg traag? (c) Geef een functie die wel geschikt is als hash-functie. (a) Hashen kan met chaining (waarbij je elke key met hashwaarde i opslaat in een lijst A[i]) of met open addressing (waarbij je keys laat uitwijken naar andere posities wanneer hun positie al bezet is). Dat Nico wil verwijderen is een goede reden om Chaining te gebruiken. (b) Er zijn veel te veel botsingen. Omdat er hoogstens 12 letters zijn is de maximale HC 312. Alle miljoen studenten komen dus in de eerste 312 lijsten terecht, met een gemiddelde van 3000 per lijst. (c) Om ook de hogergenummerde lijsten te gebruiken, en de keys beter te spreiden, kun je de letterwaarden vermenigvuldigen met een waarde die afhangt van hun positie, bv. tel de i-de letter maal 26 i. Je kunt dan heel grote getallen krijgen, maar voor de positie in de hashtabel neem je toch weer HC modulo lengte. Tot 3pt, een per deelvraag. Codes: B = Er komen teveel Botsingen is niet genoeg, moet uitleg bij, 1/2pt. M = Het noemen of beschrijven van de Methodes is al genoeg bij (a) om een halve te verdienen. V = Je hashfunctie is invariant onder permutatie van letters (bijvoorbeeld: product, ook inv onder toevoeging van as), 1/2pt. 17. Range in Hashtabel: Gegeven is een hashtabel, waarin collisions zijn opgelost met chaining, en de keys zijn integers. (a) Geef een methode RQ(int a, int b) die alle keys tussen a en b afdrukt. (b) Wat is de looptijd van je query, uitgedrukt in n en m (aantal keys en lijsten). Waarom? (a) Dit kan alleen door alle keys te enumereren en conditioneel af te drukken: RQ(int a, int b) { for (int j=0; j < m; j++) foreach (int k in HT[j]) // HT[j] is een List if (a <= k && k < b) Console.WriteLine(k) (b) Enumeratie van een lijst is lineair in het aantal elementen, en je moet de lijsten aflopen, totaal O(n + m). Tot 2pt. Codes: B = Brute-Forcen over keys: kijk voor elke i in de range of i voorkomt. Dit kan, maar omdat keys vrij groot kunnen zijn is dit heel kostbaar. Het kost O(b a) tijd, dus niet begrensd door een functie van de tabelgrootte. L = Lijsten HT[a] t/m HT[b] bevatten heel andere keys dan die worden gevraagd.

6 18. Zoeken in Hashtabel: In een hashtabel (met chaining) heeft succesvol zoeken een andere analyse dan succesloos zoeken. Ga uit van een hashtabel met n keys en m lijsten, en load factor α = n/m. (a) Bij welk van deze twee gevallen druk je de zoektijd uit in de gemiddelde lijstlengte? Geef een uitdrukking voor de zoektijd. (b) Bij welk van de twee gevallen hangt de zoektijd af van het gemiddelde kwadraat van de lijstlengte? Leg uit waarom. (a) Bij de succesloze zoekactie. Je moet daar een van de lijsten, een willekeurige, doorlopen (om te constateren dat je key niet voorkomt). De tijd is O(1 + α). (b) Bij de succesvolle zoekactie wordt elke voorkomende key met gelijke kans gevraagd. Je zoekt dus in een lijst van gemiddelde lengte, waarbij je echter niet direct middelt over de lijsten, maar over de keys. Dat betekent dat bij een lijst met l elementen, deze lengte l ook l keer meeweegt in het gemiddelde. Het relevante gemiddelde is dus 1 m i (l2 i ). Ruwweg een punt per deelvraag, maar in combinatie beoordeeld. Beoordelingscodes: A = Je hebt Alleen de match goed (van de twee gemiddelden op de twee gevallen). Verder geen zinvolle en correcte uitleg: 1/2pt. α = De 1 hoort er echt bij in O(1 + α). Je kunt de zoektijd niet willekeurig klein maken door α te verlagen, omdat de hash ook berekend moet worden. De uitdrukking O(α) voor de succesloze zoektijd is daarom strikt genomen niet juist. Omdat zeer kleine waarden van α meestal vermeden worden, is O(α) toch als F meegerekend. D = Succesvol Duurt langer is niet persé juist, omdat je (gemiddeld) halverwege de lijst stopt. F = De match is goed en de Formule voor de tijd bij (a): 1pt. G = Geen Goeie match gemaakt: 0pt. L = Bij succesloos Loop je alle lijsten af : Gelukkig niet zeg! T = ZoekTijd O(n) of O(n + m): zo traag is een hashtabel gelukkig niet! U = Uitleg te vaag, incompleet, onjuist of ontbrekend.