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

11–20 of 236 posts

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

#11

Post by nawgz »

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

> 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?

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

#13

Post by mananaysiempre »

duskwuff wrote: post #5

This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because they have the same bit pattern. Zero is zero.

IEEE 754’s idea was that if you got a zero in a floating-point calculation (which, at the time, meant one with physical quantities), it’s probably underflow, not a legitimate result, so the FPU might as well try to give you at least a sign even if it can’t give you any significant digits. Though 754 says comparison must treat positive and negative zero as equal nevertheless, you have to deliberately choose to look at the sign (with e.g. C99’s copysign) to see the difference.

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

#14

Post by stefncb »

nawgz wrote: post #11
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

> 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.

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

#15

Post by zokier »

nawgz wrote: post #11
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

> 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?

Common way of comparing floats is to compare the difference to some epsilon value. See Python PEP-485 for example https://peps.python.org/pep-0485/

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

#16

Post by Taniwha »

ilyt wrote: post #12
EdSchouten wrote: post #2

Quite amazing how so many environments of floating point values make the mistake of treating them as equal. YAML 1.2 does the same thing: https://yaml.org/spec/1.2.2/#10214-floating-point

Because they are equal in real math

Yes but this is floating point - +0.0 represents all numbers between 0 and the smallest +ve FP number, -0.0 represents all numbers between 0 and the smallest -ve FP number - both can represent actual 0 - remember these can be generated by underflow so those meanings can be important in context

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

#17

Post by murderfs »

EdSchouten wrote: post #2

Quite amazing how so many environments of floating point values make the mistake of treating them as equal. YAML 1.2 does the same thing: https://yaml.org/spec/1.2.2/#10214-floating-point

Is it surprising that so many environments that use IEEE 754 floating point numbers obey IEEE 754 on equality?

IEEE 754-2008 5.11: "Comparisons shall ignore the sign of zero (so +0 = −0)."

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

#18

Post by [deleted] »

nawgz wrote: post #11
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

> 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?

[deleted]

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

#19

Post by zokier »

ilyt wrote: post #12
EdSchouten wrote: post #2

Quite amazing how so many environments of floating point values make the mistake of treating them as equal. YAML 1.2 does the same thing: https://yaml.org/spec/1.2.2/#10214-floating-point

Because they are equal in real math

Floats are not real numbers though

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

#20

Post by orthoxerox »

nawgz wrote: post #11
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

> 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?

This is specifically about equality. Comparing FPs for equality is very risky, as your numbers can differ by 0.00000000000001 without anyone noticing.

Strict inequality (> and <) comparison are generally fine as long as you avoid NaNs.

Post reply on HN