Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

9999999999999999.0 – 9999999999999998.0

geocar.sdf1.org

Post reply on HN
Print view View original

171–180 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#171

Post by InclinedPlane »

zamadatix wrote: post #78
dangerbird2 wrote: post #76

Earlier quoted context omitted.

The right answer is to convert to an integer or bignum. If the language reads 9999999999999999.0 as a 32 bit float, you will get 0.0. If it's a double, you'll get 2.0.

I don't think there is a "right" answer. Defaulting to bignum makes no more sense than defaulting to float for inputs "1" and "3" if the operation to be performed on the next line is division. Symbolic doesn't make sense all of the time either, what if it's a calculator app and the user enters "2*π", they probably don't want "2π" to be the result. If we're going to try to find a "right" answer from a language view wi…

There's is a mathematically correct answer for this problem given their decimal representation. That's the correct answer for the math, period. What "good enough" behavior is for a system that uses numbers under the hood depends on context and is only something that the developer can know. Maybe they're doing 3D graphics and single precision floats are fine, maybe they're doing accounting and they need accuracy to 100ths or 1000ths of a whole number.

The appropriate default is, I would argue, the one which preserves the mathematically correct answer (as close as possible) in the majority of cases and enables coders to override the default behavior if they want to specify the exact underlying numerical representation they desire (instead of it being automatic). That goes along with the "principle of least surprise" which is always a good de facto starting point for any human/computer interaction.

Re: 9999999999999999.0 – 9999999999999998.0

#172

Post by mikey_p »

preinheimer wrote: post #12

$ php -v PHP 7.2.10 (cli) (built: Oct 9 2018 14:56:43) ( NTS ) $ php -r "echo 9999999999999999.0 - 9999999999999998.0;" 2 $ php -r "echo bcsub('9999999999999999.0', '9999999999999998.0', 1);" 1.0 bcmath - http://php.net/manual/en/function.bcsub.php

Result for all versions of PHP: https://3v4l.org/JYlrp

Re: 9999999999999999.0 – 9999999999999998.0

#173

Post by mikey_p »

mikey_p wrote: post #172
preinheimer wrote: post #12

$ php -v PHP 7.2.10 (cli) (built: Oct 9 2018 14:56:43) ( NTS ) $ php -r "echo 9999999999999999.0 - 9999999999999998.0;" 2 $ php -r "echo bcsub('9999999999999999.0', '9999999999999998.0', 1);" 1.0 bcmath - http://php.net/manual/en/function.bcsub.php

Result for all versions of PHP: https://3v4l.org/JYlrp

And with bcmath: https://3v4l.org/AmOQt

Re: 9999999999999999.0 – 9999999999999998.0

#174

Post by ChrisLomont »

3pt14159 wrote: post #122
lenticular wrote: post #52

Earlier quoted context omitted.

Yeah, the limitations of FP are well-known to anyone who does much numerical work. Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery's prior distribution. A Jeffery's prior is a prior that is invariant under reparameterization, which is a mandatory property for approximating the reals. In this case, it is where Prob(log(|x|)) is proportional to a const…

Outside of the academic world decimals are almost always a better solution if performance isn't critical. Most logic is multiplicative. For example, apply a 30% tax on a dollar quantity and display both subtotal and grand total. With floats, there are inequalities. With decimal there usually aren't unless you're dividing, but we already have to deal with divide errors in base ten, and it is much more likely to need t…

You cannot do anything in finance with such reasoning. Take something simple, say a mortgage at 5% compounded 12 times a year. To compute payments using some fixed length representation or decimal is going to lead to more error than to use the usual floating point. This rabbit hole would continue for many applications.

Floating point makes them all much easier to do well.

Re: 9999999999999999.0 – 9999999999999998.0

#175

Post by ChrisLomont »

empath75 wrote: post #100
crankylinuxuser wrote: post #86

Earlier quoted context omitted.

When NASA can't even get it right, because of "surprises", there's no chance in hell I'm blaming us mere mortal programmers... or even 10x wizards. (0) It's time to look at other ways to depict fractional parts of numbers in a computer. I know that one can express any rational number as a integer fraction. And our computers are incapable of expressing a irrational number exactly - it does so to a certain precision...…

You can work directly in reals. http://hackage.haskell.org/package/exact-real

That package approximates reals. It fails to do equality on infinite precision reals, for example.

Re: 9999999999999999.0 – 9999999999999998.0

#177

Post by jes5199 »

ChrisLomont wrote: post #174
3pt14159 wrote: post #122

Earlier quoted context omitted.

Outside of the academic world decimals are almost always a better solution if performance isn't critical. Most logic is multiplicative. For example, apply a 30% tax on a dollar quantity and display both subtotal and grand total. With floats, there are inequalities. With decimal there usually aren't unless you're dividing, but we already have to deal with divide errors in base ten, and it is much more likely to need t…

You cannot do anything in finance with such reasoning. Take something simple, say a mortgage at 5% compounded 12 times a year. To compute payments using some fixed length representation or decimal is going to lead to more error than to use the usual floating point. This rabbit hole would continue for many applications. Floating point makes them all much easier to do well.

Have you worked on finance software? I have - we always used ints for everything, so we could avoid rounding suprises

Re: 9999999999999999.0 – 9999999999999998.0

#178

Post by hedora »

twtw wrote: post #39

I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…

I took the table to be a handy guide to where arbitrary precision is the default vs. hw accelerated math.

Filtered by languages I care about, I guess I have no choice but to learn perl 6 if I want correct (but presumably slow) floating point with elegant syntax (my taste might not match yours).

I’d be curious to know what the random GPU languages and new vector instruction sets do with this computation. I don’t think they’re all 754 compliant.

Re: 9999999999999999.0 – 9999999999999998.0

#179

Post by copperx »

jimmaswell wrote: post #132
Aeolun wrote: post #130

Earlier quoted context omitted.

Not in many of the CS related majors. Though I guess it is for hard CS.

My CS course at a community college went over the limitations of floats in detail, in the CS class.

How detailed, if I may ask?

Re: 9999999999999999.0 – 9999999999999998.0

#180

Post by shakna »

ChrisLomont wrote: post #174
3pt14159 wrote: post #122

Earlier quoted context omitted.

Outside of the academic world decimals are almost always a better solution if performance isn't critical. Most logic is multiplicative. For example, apply a 30% tax on a dollar quantity and display both subtotal and grand total. With floats, there are inequalities. With decimal there usually aren't unless you're dividing, but we already have to deal with divide errors in base ten, and it is much more likely to need t…

You cannot do anything in finance with such reasoning. Take something simple, say a mortgage at 5% compounded 12 times a year. To compute payments using some fixed length representation or decimal is going to lead to more error than to use the usual floating point. This rabbit hole would continue for many applications. Floating point makes them all much easier to do well.

IBM Decimals are the standard for finance applications. Integers, not floating point.

Floats don't have the precision required.

Post reply on HN