Ich bin gerade dabei eine Hashtable zu programmieren.
Die Hashtable wird anhand 2 Klassentemplates (key, value) erstellt.
So nun das Problem:

Ich habe meine Hashfunktion so geschrieben, dass sie davon ausgeht das der "key" ein numerischer Datentyp ist. Jedoch "koennte" es auch was anderes sein.

Daher meine Frage:
Kann ich aus dem Key irgendeinen Code regenerieren, denn ich dann als "int" in die Hashfunktion uebergeben kann? Natürlich muss der Code je nachdem wie der key ist anders sein. Jeder Key muss natürlich beim generieren in der Int Zahl immer gleich bleiben.

Mfg Marcel

Kann ich aus dem Key irgendeinen Code regenerieren, denn ich dann als "int" in die Hashfunktion uebergeben kann? Natürlich muss der Code je nachdem wie der key ist anders sein. Jeder Key muss natürlich beim generieren in der Int Zahl immer gleich bleiben.

Nennt sich Hash. Was sind das für Keys? Strings?

Du willst also quasi eine Hashfunktion um die Hashfunktion zu füttern?

Jaein. Ich habe vorher die Bucksanzahl der Tabelle festgelegt und diese Hashfunktion entscheided dann nur lediglich anahnd des ints worein die Keys kommen. Klär koennte ich den Key in der Hashfunktion uebergeben und dort etwas generieren, bzw. dann entscheiden in welchen Buck es rein kommt.

Arcoth schrieb:

Nennt sich Hash. Was sind das für Keys? Strings?

Das soll ja vielfältig bleiben darum kann das alles mogliche sein. Zahlen, strings , andere Klassen etc.

Hallihallo!

Ich bin gerade dabei eine Hashtable zu programmieren.
Die Hashtable wird anhand 2 Klassentemplates (key, value) erstellt.
So nun das Problem:

Ich habe meine Hashfunktion so geschrieben, dass sie davon ausgeht das der "key" ein numerischer Datentyp ist. Jedoch "koennte" es auch was anderes sein.

Daher meine Frage:
Kann ich aus dem Key irgendeinen Code regenerieren, denn ich dann als "int" in die Hashfunktion uebergeben kann? Natürlich muss der Code je nachdem wie der key ist anders sein. Jeder Key muss natürlich beim generieren in der Int Zahl immer gleich bleiben.

Mfg Marcel

???

Also der Anwender gibt Dir einen int.

Es ist nicht unüblich, den erst *17 (oder so) zu rechnen, damit er noch noch gleicher verteilt. Du machst ja dann eh %size. Das *17 ist in Wirklichkeit Hasenpfeffer mit Schlangenöl.

Hashtables leben davon, daß der Anwender *gut* haschen kann. Kack auf die minderguten. Kannste nicht wirklich gut als Anwender hashen(mit Begründung), dann nimm einen Sortierbaum wie std::set. Ich bin ein Freund, sogar ein Fan von Hashtables. Aber echt *sehr selten* war mein Schatz spürbar schneller, tutmirleid.

Du wirst es dem Benutzer überlassen müssen, eine Hashfunktion für seinen Key-Typ bereitzustellen.

Daran habe ich auch zuerst gedacht, jedoch dachte ich mir es gibt halt eine bestimmte möglichkeit aus referencen einen Int Wert zugenerieren.

Lassen wir mal die Hashtable aus dem Spiel.

Gibt es echt keinerlei "Zahlencode" den man aus Refernzen erzeugen kann? Ich habe es schon mit den Adressen versucht, jedoch hat es nicht so geklappt, wie ich das haben wollte.

Daran habe ich auch zuerst gedacht, jedoch dachte ich mir es gibt halt eine bestimmte möglichkeit aus referencen einen Int Wert zugenerieren.

Man holt sich die Adresse und hat seine Zahl.

Daran habe ich auch zuerst gedacht, jedoch dachte ich mir es gibt halt eine bestimmte möglichkeit aus referencen einen Int Wert zugenerieren.

Man holt sich die Adresse und hat seine Zahl.

Was fuer hashes aber eine furchtbar schlechte idee ist.

Der User muss eine hash Funktion implementieren. Entweder per std::hash oder als functor im Template.

PS:
generische Hashfunktionen sind soweit schrott. Lohnt sich also garnicht erst eine zu erfinden.

Man holt sich die Adresse und hat seine Zahl.

Was fuer hashes aber eine furchtbar schlechte idee ist.

Hatten wir in der Firma. Alle Adressen waren vom Heap und durch 8 teilbar, initial gab es 8 Buckets, die Hashfunktion war einfach modulo 8, vom Feinsten.

Was fuer hashes aber eine furchtbar schlechte idee ist

Anwendungsbedingt. Habe das mal fuer Kollisionsereignisse zwischen Objekten genutzt.

Alle Adressen waren vom Heap und durch 8 teilbar, initial gab es 8 Buckets, die Hashfunktion war einfach modulo 8, vom Feinsten.

Moment, die Hashfunktion war "Adresse modulo 8"?

Alle Adressen waren vom Heap und durch 8 teilbar, initial gab es 8 Buckets, die Hashfunktion war einfach modulo 8, vom Feinsten.

Man nimmt also den pointer, generierst daraus das hash und um wieder an den pointer zu kommen, siehst man später in der hashtable nach, die auch noch furchtbar schnell ist, weil dank Alignment alle Werte den gleichen hash bekommen. Hat deine Firma noch weitere großartige Vorschläge, wie man noch mehr Geschwindigkit herausholen kann?

Man nimmt also den pointer, generierst daraus das hash und um wieder an den pointer zu kommen,

Soweit noch kein Problem, habe ich auch schon gemacht. Musste zu den Objekten noch ein wenig Zusatzinfo speichern, ohne die Objekte zu verändern. Wäre zum Beispiel denkbar für einen Debug-Heap.

Marthog schrieb:

siehst man später in der hashtable nach, die auch noch furchtbar schnell ist, weil dank Alignment alle Werte den gleichen hash bekommen.

Tja, mein *17 von der ersten Seite hätte es schon gelöst, vermutlich hätte sie dann sogar eine ganz besonders gute gleichverteilung auf die Buckets bekommen.

Marthog schrieb:

siehst man später in der hashtable nach, die auch noch furchtbar schnell ist, weil dank Alignment alle Werte den gleichen hash bekommen.

Tja, mein *17 von der ersten Seite hätte es schon gelöst,

durchachtteilbar*17 ist aber wieder durch acht teilbar.

Darum ist es zu empfehlen, dass die Anzahl Buckets eine Primzahl ist. Ganz einfach weil so Effekte kaum zu vermeiden sind.

volkard schrieb:

Marthog schrieb:

siehst man später in der hashtable nach, die auch noch furchtbar schnell ist, weil dank Alignment alle Werte den gleichen hash bekommen.

Tja, mein *17 von der ersten Seite hätte es schon gelöst,

durchachtteilbar*17 ist aber wieder durch acht teilbar.

Stimmt auffallend, ihh, ist das böse.

iknowmath schrieb:

Darum ist es zu empfehlen, dass die Anzahl Buckets eine Primzahl ist. Ganz einfach weil so Effekte kaum zu vermeiden sind.

Ungern eine Division bezahle. Naja, wenn die Größe compilezeitkonstant ist, geht's ja.