hashing of ranges is awful

[StefanKarpinski]

julia> @which hash(1:10)
hash(a::AbstractArray{T,N}) at dict.jl:247

The first issue is that this is incredibly slow:

julia/base/dict.jl

Lines 246 to 252 in 72a65be

	function hash(a::AbstractArray)
	h::Uint = hash(size(a))+1
	for i=1:length(a)
	h = bitmix(h,int(hash(a[i])))
	end
	return h
	end

It's unclear to me why we're using indexing here instead of just iterating, but the code if very old so maybe it made sense at the time.

[jakebolewski]

I'm curious, why do you have to iterate through the entire range?

[JeffBezanson]

That's the point, you don't. It's just that ranges lack a specific implementation of hash and fall back on a generic array method.

[JeffBezanson]

Oh I know how this happened: ranges are isequal to vectors with the same contents.

[StefanKarpinski]

Add this to the list of isequal issues. We should maybe have a label for this.

[JeffBezanson]

There might not be anything we can do here; I expect 1:10 == [1:10] is uncontroversial. Making isequal different in that case is possible, but that doesn't seem to be the direction we're moving with it.

[jakebolewski]

I didn't realize that 1:10 == [1:10]. Personally this doesn't make much sense, but I realize that this follows Matlab's behavior.

[JeffBezanson]

We also have A == sparse(A).

[staticfloat]

I feel like the isequal issue is separate from this one though; we can just write a new hash() function that specializes on ranges and this performance issue disappears, right?

[JeffBezanson]

In theory; but there would need to be an O(1) algorithm that gives the same answer as the O(n) hash of a dense array of the same values. Or we could check whether a given dense vector is equal to some range, but that doesn't sound very easy either.

[stevengj]

We already decided in #3385 to make isequal(1,1.0) == false even though 1 == 1.0, precisely because it was impractical to hash different numeric types to the same value.

Why doesn't the same logic apply here? Have 1:10 == [1:10] but isequal(1:10, [1:10]) == false, and let them hash to different values.

[StefanKarpinski]

That decision has been an almost unmitigated disaster. We really need to change it back.

[stevengj]

What disastrous consequences have ensued? I just don't see how any other decision could possibly be practical if you want (a) isequal(a,b) to imply hash(a) == hash(b) and (b) hashing to be fast.

[JeffBezanson]

I wouldn't describe it as an unmitigated disaster, but as sometimes mildly inconvenient.

[StefanKarpinski]

This, among other things:

julia> d = Dict{Int32,Any}()
Dict{Int32,Any}()

julia> d[1] = "foo"
ERROR: 1 is not a valid key for type Int32
 in setindex! at dict.jl:502

I don't have time to give a comprehensive list of the problems, but it does not work well. It makes dictionaries super finicky and brittle.