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

71–80 of 236 posts

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

#71

Post by recursive »

stefncb wrote: post #14
nawgz wrote: post #11

Earlier quoted context omitted.

> if you find yourself comparing floating point numbers, that's probably not what you want Can you motivate this with an example for me? For instance, I think of games or location data encoded as FP; then, clearly, comparing them is a critical task to know questions like "what is closer" and so on. What am I missing?

They meant using the equal operator, because floating point is inexact and can produce different representations for the same number depending on how it was obtained. Greater and less than are fine. Equal is usually implemented by seeing if a number fits inside a tight range.

Every finite floating point value precisely represents an exact quantity. Arithmetic isn't lossless though. This isn't a special property of floats. Decimals behave the same way.

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

#72

Post by thr-nrg »

ChainOfFools wrote: post #67
regularfry wrote: post #47

Earlier quoted context omitted.

I've always held that the numbers themselves are perfectly precise. It's the operations that don't do what you expect. Of course, that observation may be more or less useful, depending on circumstances.

Somewhere in the distant past a second grade me is staring at his math homework and fuming over the frustratingly ambiguous meaning of the minus sign. Is it an operator? A property? Both?

Math notation is to mathematics as poetry is to English.

The only acceptable grammar for math is s-expressions.

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

#73

Post by lliamander »

Trufa wrote: post #68
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…

What’s the use case for different values?

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

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

#74

Post by recursive »

phoe-krk wrote: post #42
ghayes wrote: post #35

Earlier quoted context omitted.

> no division can produce a result that is exactly zero Except 0 / n

Or -0.0 / n, for what it's worth, at which point these zeroes will not be equal to one another.

Or 1e-100 / 1e300

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

#76

Post by pmarreck »

Trufa wrote: post #68
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…

What’s the use case for different values?

Because two binary values that are not bit-for-bit equal should have an equality operator that can reflect that without resorting to conversion

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

#77

Post by pclmulqdq »

Trufa wrote: post #68
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…

What’s the use case for different values?

1/Infinity in 754 is 0. 1/(-Infinity) is -0. These numbers are not strictly equal in real number terms.

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

#78

Post by ibiza »

atemerev wrote: post #21
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

We don't have fast hardware decimals, except on IBM mainframes. So, if you need fast financial calculations which are too complicated for integers (e.g. gasp division), you usually use decimally-normalized doubles and do it very very carefully. This is a sad state of affairs, but nobody was fixing this in the last 30 years, so there's that.

Power ISA includes decimal floating point, so it's available beyond mainframes.

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

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

#79

Post by spacechild1 »

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

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 safely use equality as along as you expect 'v' to be set to 'f', i.e. the value of 'v' is not the result of a computation. This may sound trivial, but this is often omitted when discussing floating point comparison. If someone knows a scenario where the examples above would break, I would be curious to hear! (My main field is audio programming and code like this is omnipresent.)

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

#80

Post by super256 »

Trufa wrote: post #68
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…

What’s the use case for different values?

Float stuff like 1.f / (+0.f) = infinity and 1.f / (-0.f) = -infinity.

And maybe complex number shenanigans and multi valued functions? Maybe someone familiar with mathematics can tell us more. :)

Post reply on HN