search

bo-yang / smhasher

Automatically exported from code.google.com/p/smhasher
0 stars 0 forks source link

Lacking 3 MurmurHash3 variations #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
Read the code.

What is the expected output? What do you see instead?
In MurmurHash3.h there are all 6 variations of MurmurHash3. However in 
MurmurHash3.cpp, there are only 3 implementations.

What version of the product are you using? On what operating system?
SVN repository by 4/6/2011. Revision 125.

Please provide any additional information below.
In project homepage, update on 4/2/2011 states that "MurmurHash3, all versions, 
is final." Is this suggesting that the other 3 variations are on the way? Will 
be the package that contains all 6 variation released for downloading?

Original issue reported on code.google.com by crendk...@gmail.com on 8 Apr 2011 at 3:34

GoogleCodeExporter commented 8 years ago 
Will you release MurmurHash3_x64_64 ?
I need a hash to output 40 or 48 bit.

You said "extending them to larger/smaller hash sizes or for streaming and 
incremental operation should be straightforward", so can you tell us how with 
some examples ?

Original comment by galaxy...@gmail.com on 9 Apr 2011 at 5:05

GoogleCodeExporter commented 8 years ago 
Sorry. I read the code in r76 and notes in the main page. Since the shorter 
variations are trimmed from the result of longer variations, I guess there is 
little reason to keep them. Instead users can do that from their own needs.

Technically this issue is invalid.

Original comment by crendk...@gmail.com on 11 Apr 2011 at 10:00

GoogleCodeExporter commented 8 years ago 
copmaring x86_32 and x64_128, the former only use the seed once (uint32_t h1 = 
seed;) and the latter use it twice (uint64_t h1 = seed;  uint64_t h2 = seed;). 
And, four times for x86_128.

It seems that, for a output of the same length, only "h1" needed, for a double 
length, two (h1,h2) needed and for a four times length, four is needed.

I agree that if the hash is perfect, trim x86_128 to 32bit will be a same good 
hash, but this could be slower.

Original comment by galaxy...@gmail.com on 12 Apr 2011 at 3:17

GoogleCodeExporter commented 8 years ago 
If your code needs a 64-bit hash value, it's almost always faster to generate a 
128-bit hash and only use 64 bits of the result - hence the removal of the _64 
versions.

Original comment by tanj...@gmail.com on 11 May 2012 at 5:37

GoogleCodeExporter commented 8 years ago 
Sorry for bringing up old issue, but is it right that: if I need 64bit hash 
value I should calcualte 128-bit hash and take only first 64bits of it?

As far I understand I can actually take any 64 bits from 128 bit hash, not 
stricted to first 64.

Original comment by mr.xk...@gmail.com on 1 Jul 2015 at 2:14