News for hackers. Stuff that matters.
Re:In Erlang/OTP 27, +0.0 will no longer be exactly equal to... by bee_rider on Tuesday May 09, 2023 @10:16PM (#35882858)
So, in Erlang it will be the case that:

+0.0 == -0.0 is true, I guess because they are very close

+0.0 =:= -0.0 is false, I guess because they have different bits

A =:= B for two different numbers of course, because they have different bits

How does == work for other very close floating point values in Erlang? Is there some inconsistency here?

Re:In Erlang/OTP 27, +0.0 will no longer be exactly equal to... by throwawaymaths on Wednesday May 10, 2023 @01:19AM (#35883921)
The only other distinction between == and =:= is for integers and floats. Integers are not =:= to the corresponding float, but are ==, so it has nothing to do with closeness.

-0.0 is a weird dumb no mathematical value that IEEE 754 put in (for example the standardized value for sqrt(-0.0) is not even justifiable based on their choices). I think they didn't want 1/(1/-Inf) to be Inf, or something.

In the end think of erlang's "==" as "equal in value" and "=:=" as "equal in representation in memory".

Now if you really want to raise the hackles of someone using Erlang, should ask why integers and floats don't have a well ordering, and what you should do when you sort them.

Re:In Erlang/OTP 27, +0.0 will no longer be exactly equal to... by shultays on Wednesday May 10, 2023 @02:13AM (#35884226)
It is not about being very close. IEEE says "Comparisons shall ignore the sign of zero" and erlang (or rather CPU instructions erlang outputs for float == float) respects that

While =:= is not something mandated by IEEE. Erlang implements such an operator on floats and it decides to compare false for 0.0 & -0.0. So it compare bits/does integer comparisons on same data

Re:In Erlang/OTP 27, +0.0 will no longer be exactly equal to... by bee_rider on Wednesday May 10, 2023 @08:59AM (#35886683)
Ah, so == is compliant, and =:= is extra. Makes sense!