Live data from Hacker News

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

erlangforums.com

191–200 of 236 posts

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

#191
post #100

Earlier quoted context omitted.

Honestly - I rather dislike this change. I'd much rather have 0 & -0 be precisely equal to each other and have some obscure library function like `isNegativeZero` for the extremely rare cases they'd need to be differentiated. 0 and -0 being distinct values is honestly just an accident of convenience with how floats are stored - there are two bit patterns that result in a value of 0 but because they're different patte…

I don't think it's just that. 1/0 is infinity but 1/(-0) is -infinity

Rigorously division by zero is "undefined" in mathematics.

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

#192

There is a huge misconception here which really should be clarified in the title. Erlang has an "exactly equal" or strict equality operator, called =:=, which is different from just usual equality, which is ==. The usual equality operator will keep having +0.0 = -0.0, and floating point arithmetic will keep behaving as you would expect... It's that we no longer have +0.0 =:= -0.0, which is a very different thing (and…

> there should be some special operator that can differentiate between these two values).

What for though?

I was expecting as I learned Rust that I would soon find the == operator (which is just the predicate PartialEq::eq) wasn't quite enough and need some === type operator (Rust doesn't have one), but I never did. Turns out actually in most cases equality is what I cared about.

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

#194

There is a huge misconception here which really should be clarified in the title. Erlang has an "exactly equal" or strict equality operator, called =:=, which is different from just usual equality, which is ==. The usual equality operator will keep having +0.0 = -0.0, and floating point arithmetic will keep behaving as you would expect... It's that we no longer have +0.0 =:= -0.0, which is a very different thing (and…

> there should be some special operator that can differentiate between these two values). What for though? I was expecting as I learned Rust that I would soon find the == operator (which is just the predicate PartialEq::eq) wasn't quite enough and need some === type operator (Rust doesn't have one), but I never did. Turns out actually in most cases equality is what I cared about.

There is an example in the article about compiler optimization, and they state that other similar instances may exist.

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

#195

Earlier quoted context omitted.

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?

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 probably compares bits/does integer comparisons on same data

Ah, so == is compliant, and =:= is extra. Makes sense!

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

#196
post #190

Earlier quoted context omitted.

I'd prefer living in a world where social security is enough for me not to worry about things like "saving money".

So no pensions, sovereign wealth funds, or scholarship funds? And by what mechanism is capital allocated?

https://en.wikipedia.org/wiki/Communism

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

#197

There is a huge misconception here which really should be clarified in the title. Erlang has an "exactly equal" or strict equality operator, called =:=, which is different from just usual equality, which is ==. The usual equality operator will keep having +0.0 = -0.0, and floating point arithmetic will keep behaving as you would expect... It's that we no longer have +0.0 =:= -0.0, which is a very different thing (and…

> there should be some special operator that can differentiate between these two values). What for though? I was expecting as I learned Rust that I would soon find the == operator (which is just the predicate PartialEq::eq) wasn't quite enough and need some === type operator (Rust doesn't have one), but I never did. Turns out actually in most cases equality is what I cared about.

I could also imagine dumping binary to a file and expectingb the hashes to be equal.

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

#198
post #194

Earlier quoted context omitted.

> there should be some special operator that can differentiate between these two values). What for though? I was expecting as I learned Rust that I would soon find the == operator (which is just the predicate PartialEq::eq) wasn't quite enough and need some === type operator (Rust doesn't have one), but I never did. Turns out actually in most cases equality is what I cared about.

There is an example in the article about compiler optimization, and they state that other similar instances may exist.

The example for the compiler just seems like it wants a property that types don't necessarily even have (Equivalence), so my instinct would be that it's probably just broken and this is the tip of the iceberg or if the compiler does care about this property it should know floats don't have Equivalence and thus 0.0 == -0.0 isn't cause to perform this optimisation.

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

#199

There is a huge misconception here which really should be clarified in the title. Erlang has an "exactly equal" or strict equality operator, called =:=, which is different from just usual equality, which is ==. The usual equality operator will keep having +0.0 = -0.0, and floating point arithmetic will keep behaving as you would expect... It's that we no longer have +0.0 =:= -0.0, which is a very different thing (and…

What about the N number of NaN values that are treated the same, but are physically different values?
Post reply on HN