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
In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
191–200 of 236 posts
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#192There 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 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
#193Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#194There 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
#195Earlier 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
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#196Earlier 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?
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#197There 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
#198Earlier 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.
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#199There 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…