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

61–70 of 236 posts

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

#61

Post by abhgh »

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

As a followup to this comment, in Python you have the option of using `isclose()` which is present in both `numpy`[1] and the standard `math` [2] libraries. This has been quite helpful for me in comparing small probability values.

[1] https://numpy.org/doc/stable/reference/generated/numpy.isclo...

[2] https://docs.python.org/3/library/math.html#math.isclose

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

#62

Post by mamcx »

cubefox wrote: post #30
atemerev wrote: post #21

Earlier quoted context omitted.

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.

Business apps? Like all of them?

As matter of fact, business apps are by far the longest portion of the apps. Just considering all spreadsheets, almost all RDBMS, etc alone.

Binary Floating-point is what is ACTUALLY niche. And it not look like it just because is the default, similar how in certain niches "0" is "true".

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

#63

Post by Kwpolska »

Y_Y wrote: post #59
wslh wrote: post #22

Earlier quoted context omitted.

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); }

Erlang too, now and in the future will say that minuszero==zero, it's a different more specific operator that's changing. You'll get the same in python with >>> -0. is 0. False

The `is` operator is checking object identity by comparing addresses. It is useless, although it may sometimes produce reasonable-looking results due to optimisations.

Python 3.11 gives me this:

>>> -0 is 0 :1: SyntaxWarning: "is" with a literal. Did you mean "=="? True

Because (a) -0 is an integer, and there is only one integer zero, (b) small numbers have only one instance in memory as an optimization.

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

#64

Post by quietbritishjim »

andrewmcwatters wrote: post #9
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.

Zero is zero, but signs are a direction. There are multiple parts to numbers. Stand in place and turn around: how far did you go from where you started? Nonetheless, I agree. It's a bad idea.

By that logic there should be e.g. +4.0 and +4.0- (for when you go 4m forwards vs when you go 4m forwards but also turn around at the end).

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

#65

Post by bjourne »

Negative zero is very, very annoying because it means that many floating point identities flies out of the window. x + 0.0 != x, x * 0.0 != 0.0, etc. It makes it much harder for the compiler to optimize arithmetic. Thus, at least some SIMD circuits do not follow ieee754 to the letter because it would result in performance degradations.

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

#66

Post by stkdump »

bjourne wrote: post #65

Negative zero is very, very annoying because it means that many floating point identities flies out of the window. x + 0.0 != x, x * 0.0 != 0.0, etc. It makes it much harder for the compiler to optimize arithmetic. Thus, at least some SIMD circuits do not follow ieee754 to the letter because it would result in performance degradations.

Those identities do hold though, as long as zero and negative zero compare equal, which according to ieee754 they should. Performance degredations happen in other places such as denormals.

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

#67

Post by ChainOfFools »

regularfry wrote: post #47
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

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?

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

#68

Post by Trufa »

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?

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

#69

Post by justeleblanc »

atemerev wrote: post #60
justeleblanc wrote: post #58

Earlier quoted context omitted.

So something that produces nothing of value to civilization. Gotcha.

Well, I assume you want to sell your hard-earned stocks of civilization-helping companies sometimes...

Nope. I'd rather there not be a thing called a stock market at all.

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

#70

Post by pklausler »

bjourne wrote: post #65

Negative zero is very, very annoying because it means that many floating point identities flies out of the window. x + 0.0 != x, x * 0.0 != 0.0, etc. It makes it much harder for the compiler to optimize arithmetic. Thus, at least some SIMD circuits do not follow ieee754 to the letter because it would result in performance degradations.

I find it so strange that IEEE-754 SQRT(-0.) is -0., even though (-0.)*(-0.) is +0.
Post reply on HN