Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

erlangforums.com

Post reply on HN
Print view View original

171–180 of 236 posts

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

#171

Post by kragen »

Tuna-Fish wrote: post #93
lliamander wrote: post #73

Earlier quoted context omitted.

It's a natural consequence of the IEEE 754 standard for floating point numbers.

To be clear, it was added to the standard because there was user demand for it. Zero is already special cased in IEEE 754 (along with the rest of the denormals, because of the implied leading mantissa bit), the implementation would be no harder if you just only had a single zero. However, back when the standard was being created, when a single zero value was proposed there was pushback from people in the user communi…

i think the rationale in https://people.freebsd.org/~das/kahan86branch.pdf goes well above and beyond 'an engineering artefact in a previous system that someone managed to depend on'

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

#172

Post by xxs »

distortedsignal wrote: post #132
sebzim4500 wrote: post #109

Earlier quoted context omitted.

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

Shouldn't both of those be NaN? Does Erlang have a NaN?

>both of those be NaN

Totally NOT. NaN is defined as 0.0/0.0. That's it.

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

#173

Post by shultays »

kragen wrote: post #160
spacechild1 wrote: post #79

Earlier quoted context omitted.

In general, this is good advice. However, there are cases where comparing floating point numbers for equality works just fine. For example, if you have a variable 'v' and want to update it to a new value 'f', you can do 'if (v == f)' to check if the variable would change. Or if you have a sentinel value -1.0, it is perfectly ok to do 'if (a == -1.0)' In general, if you look for a number 'f' in variable 'v', you can s…

cesaref's comment is not good advice, it's not advice at all, it's a snarky take on how floating point is trickier than it looks almost invariably floating-point calculations end up in some kind of comparison; if they didn't we'd probably do the calculations in a galois field or something instead even equality comparison of floats is useful; there are an abundance of seminumerical algorithms which use it correctly on…

well you shouldn't expect much if you are comparing floats to doubles

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

#174

Post by okaleniuk »

This makes sense. They are different entities and you have to have a way to acknowledge that they are. Breaking strict equality seems a fitting way to do so.

In Geometry for Programmers, I reference a case when an automated test system caught a "zero-not-zero" bug, and I couldn't reproduce it with a unit test until I finally realized that the test system was comparing XMLs not numbers. In print, "-0." and "0." are, of course, different, although in runtime they pretend to be the same.

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

#175

Post by arcticbull »

distortedsignal wrote: post #132
sebzim4500 wrote: post #109

Earlier quoted context omitted.

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

Shouldn't both of those be NaN? Does Erlang have a NaN?

IEEE754 has a separate +Infinity and -Infinity to go along with SNaN and QNaN.

For instance:

- as parent said 1/0 is Inf.

- as parent said 1/(-0) and log(0) is -Inf.

- sqrt(-1) and 0/0 is NaN.

[1] https://www.gnu.org/software/libc/manual/html_node/Infinity-...

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

#177

Post by spacechild1 »

shultays wrote: post #173
kragen wrote: post #160

Earlier quoted context omitted.

cesaref's comment is not good advice, it's not advice at all, it's a snarky take on how floating point is trickier than it looks almost invariably floating-point calculations end up in some kind of comparison; if they didn't we'd probably do the calculations in a galois field or something instead even equality comparison of floats is useful; there are an abundance of seminumerical algorithms which use it correctly on…

well you shouldn't expect much if you are comparing floats to doubles

True, but it's an easy mistake to make.

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

#178

Post by thr-nrg »

Conscat wrote: post #146
thr-nrg wrote: post #72

Earlier quoted context omitted.

Math notation is to mathematics as poetry is to English. The only acceptable grammar for math is s-expressions.

Well, idiomatic C++23 is an acceptable math notation too.

No it isn't. S-expressions are the simplest serialisation or trees. Trees are the simplest grammar that can encode mathematical expressions. C++ by comparison is as usable as doing cube roots using roman numerals.

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

#180

Post by mFixman »

munk-a wrote: post #100
ComplexSystems wrote: post #54

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…

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…

> 0 and -0 being distinct values is honestly just an accident of convenience with how floats are stored

This is actually a valid distinction because these values can represent different values.

Floating point values are not numbers, but ranges of possible values: float -0 is a number in the range (-FLT_TRUE_MIN / 2, 0] and float +0 is a number in the range [0, FLT_TRUE_MIN).

IMO if I were to redesign IEEE 754 I would add a third float 0 value that always represents exactly 0 and redefine float -0 and float +0 as open limits, but that would probably make everything a lot more complicated.

Post reply on HN