Thanks, interesting point. In my specific use case -0.0 and 0.0 actually need to have the same hash, as they represent conceptually the same abstract quantity. My data is the result of an iterative computation which is eventually rounded to 10 decimal places and then hashed. I use the result's hash to check if a given computation, (with tolerance a bit finer than the rounding), produces a new solution.
A more robust approach would be to test if abs(result - result_i) < \delta for each result_i in a collection of previous results. However, this operation scales linearly with the length of the collection, whereas using a set, hence requiring overloading hash(::result), is a constant-time operation. Any thoughts on possible alternatives? On Saturday, July 9, 2016 at 12:40:58 PM UTC+1, Tom Breloff wrote: > > Yes. They are different numbers. In a way, negative zero represents "a > really small negative number" that can't be represented exactly using > floating point. > > On Saturday, July 9, 2016, Davide Lasagna <lasagn...@gmail.com > <javascript:>> wrote: > >> Hi, >> >> I have just been bitten by a function hashing a custom type containing a >> vector of floats. It turns out that hashing positive and negative floating >> point zeros returns different hashes. >> >> Demo: >> julia> hash(-0.0) >> 0x3be7d0f7780de548 >> >> julia> hash(0.0) >> 0x77cfa1eef01bca90 >> >> julia> hash(0) >> 0x77cfa1eef01bca90 >> >> Is this expected behaviour? >> >>
