I would suggest replace `round(result, 10)` with `round(result, 10) + 0.0`
On Saturday, July 9, 2016 at 1:34:43 PM UTC+1, Davide Lasagna wrote: > > 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> 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? >>> >>>
