nach stundenlanger Recherche im Internet und dem Verwerfen einiger eigener Ideen würde ich Euch gerne um Rat fragen (das Problem dürfte eigentlich nicht so schwer sein).
Für die Vorlesung "Algorithmen und Datenstrukturen" sollen wir ein kleines Wörterbuch schreiben, welches über eine Hashtable realisiert werden soll.
Für das Hashen sollen wir die Divisionsrestmethode nutzen ( k % m ). So weit so gut. In der Aufgabe wird verlangt, dass wir dafür den String (das entsprechende Wort aus dem Wörterbuch) möglichst geschickt (und hier liegt mein Problem ) in einen Integer umwandeln sollen, den wir dann hashen können.
Meine erste Idee war durch einfaches shiften die ASCII-Werte in einen Integer zu verwandeln, das geht ja aber leider nur bis fünf Zeichen gut..
Als negativ-Beispiel ist die einfache Addition der ASCII-Werte genannt.

Mein bisheriger Ansatz ist:

int LinHTable::hash(string hashString)
{
const int MAX_TABLESIZE = 29;
int hashNumber=0;
int intChar;
for(int i=0; i!=hashString.size(); i++)
{
	hashNumber = ((hashNumber << 8) + hashString[i])%MAX_TABLESIZE ;
}
return hashNumber;
}

Nur leider kann ich auch nicht viel dazu sagen, warum ich das so mache... wir sollen unseren algorithmus aber leider begründen
deswegen kann ich auch nicht einfach irgendwelche kryptischen Hashverfahren nehmen, die ich im Internet finde djb etc.

Kann mir vielleicht jemand von Euch etwas helfen?

Vielen Dank im Voraus und viele Grüße aus London

Christian

Viele Grüße

Christian

Returns a hash code for this string. The hash code 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. (The hash value of the empty string is zero.)

(vielleicht hilfts ja)

@BYTO:
Das schaut schon ziemlich interessant aus.. Danke! Weisst du/jemand zufälligerweise, warum das so gemacht wird? Bzw. warum die Zahlen gerade mit 31 multipliziert werden?

Viele Grüße

Chris

@CSTOLL:
so halbwegs ;). Hab halt das mitm shiften so gemacht wie ichs mir vorgestellt habe und habe um die Zahlen nicht zu groß werden zu lassen einfach jedes mal modulo gerechnet, da ich das ja am ende sowieso machen muss.
Bin nur nicht so davon überzeugt, dass das so sinnvoll und die beste methode ist

Das shift ist auch nur eine andere Möglichkeit, mit Zweierpotenzen zu multipilzieren - und wenn du noch dazunimmst, daß (a+b)%m == ((a%m)+(b%m))%m gilt, hast du prinzipiell etwas ähnliches wie den von byto genannten Code - nur mit 256 als Faktor.

(das Problem dabei ist, daß der Faktor und die Tabellengröße möglichst teilerfremd sein sollten - sonst passiert der von dir beobachtete Effekt, daß die höherwertigen Zeichen bei der Modulo-Bildung komplett rausgeschnitten werden. Bei dir ist die Tabellengröße entsprechend "krumm", bei der Java-Lösung der verwendete Faktor)

Die stammt aus dem Dragonbook. Wenn also gefragt wird "warum diese Funktion" dann sagst du einfach "die stammt aus dem Dragonbook". Vielleicht ist dort auch erklaert, warum die halbwegs gut ist; Es gibt sicher bessere Funktionen, aber die ist recht brauchbar und auch relativ uebersichtlich/verstaendlich. Aehnelt im Grundansatz auch dem, was du eh schon vorhattest.

h=(h+(h<<5))^buf[i]

Rüdigers Lösung finde ich bisher am besten/verständlichsten. Nur leider komme ich auch mit viel Nachdenken nicht auf eine perfekte erklärung, vielleicht könnt ihr mir ja noch ein bisschen auf die sprünge helfen

h=(h+(h<<5))^buf[i]

So ähnlich wäre mein letzer Ansatz auch gewesen:

h=(h<<2)^buf[i]

Das hätte ich so erklärt:
Man shiftet, um eine möglichst breite Abdeckung im 16bit Zahlenbereich zu erreichen und die Wahrscheinlichtkeit zu verringern die gleichen hashzahlen zu erzeugen.
XOR bietet sich eher an als +, da die Zahl nicht einfach immer größer wird, sondern sich bitweise ohne überhang individuell verändert.
Das Problem hierbei war jedoch noch, dass man ab einer länge von 8 Zeichen, keinen Einfluss der ersten Zeichen mehr auf den Hashwert hatte, da man diese durch das shiften immer aus dem Zahlenbereich "herausträgt".

Mit Rüdigers Lösung ist dies nicht der Fall (habs n mir mal für ein paar Fälle aufgemalt), da man nicht nur shiftet, sondern auch noch das bisherige ergebnis auf die ersten bits einfluß nehmen lässt. PERFEKT!
Nur 2 Fragen kann ich so nicht ganz beantworten:
1. warum addiert man h und (h<<5), wäre es da nicht auch besser einfach XOR zu nutzen und folgendes zu implementieren:

h=(h^(h<<5))^buf[i]

Ist das nicht vielleicht noch besser?
2. warum shiftet man gerade 5 bit? Ist es besser eine ungerade Zahl zu shiften?

Viele Grüße

Chris