Data.HashTable.hashInt seems somewhat sub-optimal

[Simon Marlow]

Simon.Frankau at barclayscapital.com wrote:
> I tried submitting this bug through the tracker, but it seemed to give
> me permissions errors - probably a firewall issue here. :( Apologies.
> Anyway...
> 
> Prelude> Data.HashTable.hashInt 0
> 0
> Prelude> Data.HashTable.hashInt 1
> -1
> Prelude> Data.HashTable.hashInt 2
> -1
> Prelude> Data.HashTable.hashInt 3
> -2
> Prelude> Data.HashTable.hashInt 4
> -2
> Prelude> Data.HashTable.hashInt 5
> -2
> Prelude> Data.HashTable.hashInt 6
> -3
> Prelude> Data.HashTable.hashInt 7
> -3
> Prelude> Data.HashTable.hashInt 8
> -4
> Prelude> Data.HashTable.hashInt 9
> -4
> Prelude> Data.HashTable.hashInt 10
> -4
> Prelude> Data.HashTable.hashInt 200
> -77
> Prelude> Data.HashTable.hashInt 201
> -77
> Prelude> Data.HashTable.hashInt 202
> -78
> 
> I prefer to use hashing to decrease the likelihood of collisions, not
> increase them. ;)
> 
> I think the original algorithm was quite possibly supposed to use the
> bottom 32 bits of the result, although this means that changes in higher
> bits of the input do not affect lower bits of the hash. It should
> probably also use unsigned multiplication. Perhaps a better solution
> would be to xor or add together the high and low 32 bits? (I'm not sure
> as I haven't read the literature).

FYI, this was a bug that has since been fixed.

Cheers,
	Simon