Talk:MurmurHash

As posted, the Algorithm diagram is incomprehensible. Specifically because it uses several operators: Cross and Circle-Plus that are variable operators in both Computer Science and Theoretical Mathematics. That is, they have no standard definition, but are intended to be defined in context. There is no in-context definition here, nor any pointer to one. Worse, it also uses a operator shr, which may be "shift right" except that the << / >> convention is already in use in the diagram.

By fishing around in Google, I might guess that Circle-Plus is intended to be XOR here, but that still leaves the Cross operator up in the air, as it could easily be either multiplication or the OR operation. Either a Legend should be provided or they should be replaced with less ambiguous symbols (such as *, if Cross is intended to be multiplication).

I also note the completely random use of semicolons, which I could easily fix on my own, but seems pointless until the larger confusion is resolved.

--RBarryYoung (talk) 17:04, 24 June 2012 (UTC)

:Never mind. I found a good unambiguous description of the algorithm at one of the references, so I will just fix it myself. ... RBarryYoung (talk) 17:46, 24 June 2012 (UTC)

Where do the numbers c1 0xcc9e2d51, c2 0x1b873593, r1 15, r2 13, m 5, n 0xe6546b64 come from? QuentinUK (talk) 20:23, 22 March 2013 (UTC)

what are the qualities of murmur that qualify it as a non-cryptographic hash function? --Abdull (talk) 14:03, 18 July 2013 (UTC)

:All hash functions qualify as non-cryptographic, it's the default. A hash function qualifies for cryptographic if it meets certain criteria of the cryptographic community. You can see those by following the link at the beginning of the article to the Cryptographic Hash Function page.

RBarryYoung (talk) 18:41, 27 December 2013 (UTC)

The algorithm pseudo-code shows a line "hash ← hash XOR len" but by time the C version executes the equivalent line "hash ^= len;" len has been reduced to a number between 0 and 3 inclusive. This looks like a bug to me.

80.254.146.68 (talk) 09:44, 26 March 2014 (UTC)

I think the cast from const char* to const uint32_t* in:

const uint32_t *blocks = (const uint32_t *) key;

is in violation of C/C++'s Strict Aliasing Rules and can cause undefined behaviour. — Preceding unsigned comment added by 195.171.92.42 (talk) 11:10, 1 November 2016 (UTC)

Should not key = &key[i - 1]; rather be key = &key[len - 1];?

Hello fellow Wikipedians,

I have just modified one external link on MurmurHash. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120112023407/http://hbase.apache.org/docs/current/api/org/apache/hadoop/hbase/util/MurmurHash.html to http://hbase.apache.org/docs/current/api/org/apache/hadoop/hbase/util/MurmurHash.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

{{sourcecheck|checked=false|needhelp=}}

Cheers.—InternetArchiveBot (Report bug) 18:32, 8 February 2018 (UTC)

Another link illustrating the flaw: https://simonhf.wordpress.com/2008/11/01/murmur-hash-very-fast-and-collision-resistant/ SimonHF (talk) 03:55, 11 December 2023 (UTC)