Ich bin mir sogar ziemlich sicher, dass das undefiniert ist. Habe das in einem C++-Buch gelesen, finde ich bloß gerade nicht. -- Wer früher stirbt ist länger tot.
Naja es wird halt nicht jede Zahl sondern nur die gleiche Repräsentation einer Zahl gleich abgebildet... Da ist ja noch nichts "verwerfliches dran"...
Na ja, wenn eine Zahl wie 0.5 verschiedene Hashes liefert, je nach dem, ob sie normalisiert ist (1.0 * 2^-1) oder nicht normalisiert (z.B. 0.25 * 2^1), dann ist schon fraglich, wozu der Hash brauchbar sein soll.
Danke für eure große Hilfe. Naja...um ehrlich zu sein verstehe ich nicht wie diese funktion einen hashwert bildet? Also von der syntax gehts jetzt schon besser aber warum ist denn die darstellung wirklich eindeutig? Getestet bei mir hab ichs und es ist wirklich so dass 2.99999 und 2.99998 verschiedene werte haben und bei mehrfacheingabe von zwei "identischen" floats wirklich immer derselbe hash-wert rauskommt. Irgendwie stehe ich da noch auf dem schlauch. Warum wird denn hier geshiftet überhaupt und dann geXORed ? Womit ich also noch probleme habe ist zu verstehen warum diese vorgehensweise mir eindeutige hash-werte liefert? Ich kann mir das nur durch die Bitrepräsentation von floats erklären (was sonst? ) ?Aber warum der nutzen von 64 Bit? UNd ginge es nicht nur einfach ohne XOR nur return p zu schreiben?
Danke.... ich verstehe immer ein klein wenig mehr.... eh kann es sein dass das vregrössern der zahl (auf 64 BIt) dann das shiften und XOR Mit sich selber NUR dazu dient um die Zahl eindeutig zu machen? Also im grunde irgendwie logisch aber ginge das nicht einfacher als über einen reinterpret-cast und ohne shifting? Wenn ihr meine Frage mit Ja-beantworten könnt.....warum ist es gerade durch das shifting und XOR dass die Zahl eindeutig wird....einfach gottgegeben durch die angewandten Operationen?