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

31–40 of 236 posts

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

#31

Post by nvy »

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.

High-frequency trading, perhaps.

Physics simulations too.

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

#32

Post by jandrese »

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?

IMHO That was poorly worded. What it should have said is "if you find yourself using equals to compare floating point numbers...". With Floating Point your comparisons should always be less than or greater than. Precision artifacts make the equals unreliable, and you should always be mindful of that when dealing with them.

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

#33

Post by BlueTemplar »

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?

It's the hard task of trying to figure out the magnitude of the expected errors (which can accumulate), in the simplest case of a single operation you compare within epsilon distance :

https://en.wikibooks.org/wiki/Floating_Point/Epsilon

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

#34

Post by atemerev »

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.

Algorithmic trading, of course. High-frequency trading in particular. But any trading, in fact, when you run simulations for thousands of instruments and search among millions of parameters. Or when you implement an exchange, or route orders between exchanges according to their complicated criteria. Or when you do options pricing. Basically, everything in this field.

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

#35

Post by ghayes »

alerighi wrote: post #24
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 t…

> no division can produce a result that is exactly zero

Except 0 / n

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

#36

Post by tobr »

zdragnar wrote: post #28
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?

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 anyt…

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

You never use the word “comparison” again in the comment!

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

#37

Post by zwischenzug »

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.

Gambling.

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

#38

Post by FpUser »

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.

I would add generating large financial reports, enterprise billing etc. There is a huge business effect between for example 2 hours needed to calculate monthly invoices and 24 hours.

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

#39

Post by wtallis »

nvy wrote: post #31
cubefox wrote: post #30

Earlier quoted context omitted.

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

High-frequency trading, perhaps. Physics simulations too.

Physics simulations are a great example of where there's obviously no need to do arithmetic in decimal rather than binary floating point.

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

#40

Post by wtallis »

FpUser wrote: post #38
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.

I would add generating large financial reports, enterprise billing etc. There is a huge business effect between for example 2 hours needed to calculate monthly invoices and 24 hours.

Is any of that actually bottlenecked by arithmetic rather than pointer chasing?
Post reply on HN