hash(s::ByteString, seed::Uint32)

[avibryant]

It's occasionally useful to have control over the seed being used by
the hash algorithm. This adds a hash() method with an extra parameter
to allow this. Currently, it's 32bit only - not sure what the best way
is to allow 64bit as well.

[JeffBezanson]

Since there are hash functions for several types (some of which are recursive), and potentially for user-defined types, would it be better for this to be global like the random number generator seed?

[avibryant]

A couple of use cases: bloom filters and minhash signatures. In both cases you want to hash the same value with N different hash functions (or the same hash function with different seeds). For this, you don't want it to be global; however it's fine if it doesn't apply for all types... strings or byte arrays are by far the most common here. Maybe we need a different function name?

[JeffBezanson]

Ok, that makes sense. Do you see value in the 32-bit hash, which is presumably faster on 32-bit machines, or maybe we should just use the 64-bit hash function everywhere for simplicity? If we want to keep both, then memhash_seed should follow the pattern that's there for 64- and 32-bit platforms.

Exported symbols also need to be added to src/julia.expmap, since on linux we set symbols to be hidden by default.

While we're on the subject I'd like to get your opinion on another hashing issue. Currently we have isequal true for equal numbers of different types, so for example

julia> isequal(int8([1,2]), [1.0,2.0])
true

This seems to preclude efficient block-based hashing of Int8 or Uint8 arrays. Maybe we should make isequal stricter so byte arrays can be hashed faster?

[avibryant]

I think we need to keep both. For the uses I have in mind, you're going to want to have explicit control over the memory use tradeoffs. So either two different functions or it should take a type parameter... I don't have a good enough sense yet of what would be idiomatic, let me know what you'd like to see.

For the second question: I think it's useful to have an equality function that automatically promotes, but I think you're right that the one used by hash tables should be stricter; maybe the looser one should be named isequivalent?

[JeffBezanson]

Then let's continue to use memhash32 on 32-bit, and memhash on 64-bit. On 64-bit machines, I believe MurmurHash3_x64_128 is basically as fast as MurmurHash3_x86_32 (if not faster), so we should just call that and you can truncate the value to 32 bits if you want to save space.

Thanks for the feedback. We will probably be making some changes along those lines soon.

[avibryant]

Ok, I'll make that change. What do you think about it being a method on hash that takes the seed param but only works for strings, vs. a separate function?

[JeffBezanson]

It's ok for it to be a method of hash, unless there's some other use for calling hash with multiple arguments. I can't really think of one, except maybe having hash(x, y, z, ...) hash and mix multiple values, but that's reaching a bit.