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

21–30 of 236 posts

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

#21

Post by atemerev »

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.

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

#22

Post by wslh »

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

Floating point numbers are dangerous but in 2023 we should find a way to improve the side effects.

Playing with Python3:

>>> +0.0==-0.0 True

The C in GCC below also returns 1:

#include

int main()

{

        float a = +0.0;
        float b = -0.0;
        printf("%d\n", a == b);
}

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

#23

Post by HexDecOctBin »

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?

Ideally, you'll want to do distance calculations in fixed point numbers (of desired resolution). Floating point works well as a first approximation, but unless you can make sure that you are not going to end up wandering in the weeds (and ensuring that required understanding of computational numerics), you should probably replace them with fixed point once you understand the problem and the solution and know the limits involved.

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

#24

Post by alerighi »

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.

In case of floating points, since they are an approximation, zero is not zero. Zero is a quantity approaching to zero. In fact dividing by zero with floats is entirely possible! (it leads to infinite, positive or negative depending on the sign).

For example, the quantity (try it in Python):

    0.1 ** 100 / 1000**100 evaluates to 0.0
while the quantity

    0.1 ** 100 / (-1000**100) evaluates to -0.0
It's clear that neither the two quantities are 0 (no division can produce a result that is exactly zero!) but they approach the zero. But one quantity is slightly less than zero, the other slightly more than zero.

Of course for integers -0 doesn't make sense (that is the reason why we invented 2 complement, to not have 2 "zeros")

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

#25

Post by nawgz »

orthoxerox wrote: post #20
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?

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.

Ok, sure, so it was just for a specific case of comparison.

Well, followup, if some error Epsilon can be introduced during any manipulations, when you check for strict inequalities do you check x < y + Epsilon? Does the language implicitly do it for you?

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

#28

Post by zdragnar »

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?

Caveat: In the following, I use "comparison" to mean "check for equality".

Floating point numbers lose precision because binary arithmetic doesn't represent decimal in all cases ( 1/3 is an easy example). It's not hard to get into a situation where you're asking if a number is 0.0 but due to a precision error the number you have is 0.00000000000001 or whatever and it should have been zero.

If you're dealing with anything where precision is paramount (i.e. money or high precision machining) you should consider using something else that matches the real work precision you are trying to model.

You can, of course, use floats and test differences rather than strict equality (i.e. distance is if you remember to do it, and account for the potential for small precision differences to propagate throughout your calculations and accumulate into larger errors.

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

#29

Post by yifanl »

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

floating point math is math like any other, just with a vastly different number system. There are valid arguments on both side if we should hide or expose those differences in the implementation, but there's always going to be pretty big implications (i.e. the compiler behaviour mentioned here)

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

#30

Post by cubefox »

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.

Are there even any applications where one needs a) decimal precision and b) fast computation? Financial calculations don't need to be fast.
Post reply on HN