"Gerd Stolpmann" <i...@gerd-stolpmann.de> writes: > Well, looks like that the upper 32 bits aren't considered at all for > computing the hash value. This is for sure surprising - I would have > expected that these bits somehow go in to the final value (e.g. that they > are xor-ed with the lower half). > > My guess is that this was done to ensure that an int-to-something > hashtable can be marshalled from 64 to 32 bit systems. Not sure for what > this is important, but it looks like a nice symmetry.
Marshaling hashtables of ints might be an argument. BUT: # Hashtbl.hash (1 lsr 40);; - : int = 0 # Hashtbl.hash (Int64.of_int (1 lsr 40));; - : int = 0 # Hashtbl.hash (Int64.of_int (1 lsr 40 + 1));; - : int = 1 > In trunk the method for ensuring this seems to have changed (see function > caml_hash_mix_intnat in > http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/byterun/hash.c?revision=12072&view=markup). > > Gerd Lets hope that fixes this. MfG Goswin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
