In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#1

Post by todsacerdoti » Tue, May 09, 2023, 7:58 PM UTC

In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
erlangforums.com

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#2

Post by EdSchouten » Tue, May 09, 2023, 8:11 PM UTC

Quite amazing how so many environments of floating point values make the mistake of treating them as equal. YAML 1.2 does the same thing:

https://yaml.org/spec/1.2.2/#10214-floating-point

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#3

Post by cesaref » Tue, May 09, 2023, 8:13 PM UTC

As a general rule, if you find yourself comparing floating point numbers, that's probably not what you want.

I'm wondering what they are going to do with other operators, >=, <= etc

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#4

Post by yccs27 » Tue, May 09, 2023, 8:17 PM UTC

Can anyone fill me in what the meaning of == vs =:= in Erlang is? Since after the change +0. == -0. but not +0. =:= -0.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#5

Post by duskwuff » Tue, May 09, 2023, 8:17 PM UTC

This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because they have the same bit pattern. Zero is zero.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#6

Post by jbverschoor » Tue, May 09, 2023, 8:19 PM UTC

duskwuff wrote: post #5

This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because they have the same bit pattern. Zero is zero.

Unless you’re approaching the limit of 0 from one side

But yeah, you’re right

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#7

Post by zokier » Tue, May 09, 2023, 8:19 PM UTC

The word 'exactly', omitted from HN title, is relevant here:

> The == operator will continue to return true for 0.0 == -0.0.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#8

Post by ssivark » Tue, May 09, 2023, 8:20 PM UTC

cesaref wrote: post #3

As a general rule, if you find yourself comparing floating point numbers, that's probably not what you want. I'm wondering what they are going to do with other operators, >=, <= etc

This smells like the right way to think about things. Whenever thinking of real life measurements represented as real numbers, equality is always fuzzy — up to some resolution, and it would be better to make that explicit.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#9

Post by andrewmcwatters » Tue, May 09, 2023, 8:21 PM UTC

duskwuff wrote: post #5

This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because they have the same bit pattern. Zero is zero.

Zero is zero, but signs are a direction. There are multiple parts to numbers.

Stand in place and turn around: how far did you go from where you started?

Nonetheless, I agree. It's a bad idea.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#10

Post by ollien » Tue, May 09, 2023, 8:21 PM UTC

yccs27 wrote: post #4

Can anyone fill me in what the meaning of == vs =:= in Erlang is? Since after the change +0. == -0. but not +0. =:= -0.

=:= is supposed to be "exactly equals". An example given in the docs[1]:

    1> 1==1.0.
    true
    2> 1=:=1.0.
    false

You can think of it as analogous to == vs === in JS, except that the "type safety" here really only refers to different numeric types (and in JS there is no such distinction)

[1]: https://www.erlang.org/doc/reference_manual/expressions.html...