Live data from Hacker News

9999999999999999.0 – 9999999999999998.0

geocar.sdf1.org

211–220 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#211
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…

To me the only downside of IEEE 754 is that most languages including C and C++ do not provide a sensible canonical comparison methods. This leads to surprised beginners and then a ton of home made solutions which are often not appropriate.

Re: 9999999999999999.0 – 9999999999999998.0

#212
post #46

Are there any mainstream languages that consider a decimal number to be a primitive type? I feel like floating point numbers are far less meaningful in every day programs. Even 2d graphics would be easier with decimal numbers. Unless you're using numbers that scale from very small to very large, like 3d games or scientific calculations, you don't actually want to use floating point.

Julia has built in rationals (as do a few other languages). I'm not aware of any language (other than Wolfram) that defaults to storing something like 0.1 as 1/10 - i.e. uses the decimal constant notation for rationals, rather than having some secondary syntax or library.

Yes, but the Julia REPL produces 2.0 as an answer and casting both these to BigInt doesn't work either.

Re: 9999999999999999.0 – 9999999999999998.0

#214
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…

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…

The limitations should be well known. One of the first things I check when joining a financial software project is how the system represents money. I’m rarely surprised.

(It’s inevitably floats or doubles)

Re: 9999999999999999.0 – 9999999999999998.0

#215
With python, I get 2 even when using Decimals.

    Python 2.7.3 (default, Oct 26 2016, 21:01:49)
    [GCC 4.6.3] on linux2
    Type "help", "copyright", "credits" or "license" for more 
    information.
    >>> from decimal import *
    >>> getcontext().prec
    28
    >>> a=Decimal(9999999999999999.0)
    >>> b=Decimal(9999999999999998.0)
    >>> a-b
    Decimal('2')
That is unexpected.

Re: 9999999999999999.0 – 9999999999999998.0

#216

Earlier quoted context omitted.

Rationals get unwieldy quickly, even with the simplest of arithmetic. A couple of additions is enough to get a large denominator.

That has not been my experience using a language with builtin support for rationals. The rational is simplified after each operation so it never grows unwieldy large. It is slower than floats, but imo vastly superior for most use cases.

> The rational is simplified after each operation so it never grows unwieldy large.

We recently had an exponential memory growth bug because rationals can not always be simplified, for example if you start with (2/3) and repeatedly square it. Fortunately, this was not in user-facing code, so there was no chance of a denial-of-service attack, but that's definitely something to watch out for with rationals.

Re: 9999999999999999.0 – 9999999999999998.0

#217

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…

> Thus, we aren't going to ever do better than floats if we are programming on physical computers that exist in this universe. Maybe, but that doesn't mean the particular implementation of floats being used is the best one. See also: Unums and Posits https://posithub.org/

To my understanding, experiments with Unums showed shortcoming that Gustafson didn't anticipate and lead to Posits which drop the fixed length constraint. Doing that makes improving precision a lot easier but at the cost of computation time. Overall I am not convinced that the current implementation is optimal but it is a very good trade-off between speed and precision.

Re: 9999999999999999.0 – 9999999999999998.0

#218
post #215

With python, I get 2 even when using Decimals. Python 2.7.3 (default, Oct 26 2016, 21:01:49) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import * >>> getcontext().prec 28 >>> a=Decimal(9999999999999999.0) >>> b=Decimal(9999999999999998.0) >>> a-b Decimal('2') That is unexpected.

The issue is that 9999999999999999.0 == 10000000000000000.0. You need to pass a string: Decimal('9999999999999999.0')

Re: 9999999999999999.0 – 9999999999999998.0

#219
post #215

With python, I get 2 even when using Decimals. Python 2.7.3 (default, Oct 26 2016, 21:01:49) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import * >>> getcontext().prec 28 >>> a=Decimal(9999999999999999.0) >>> b=Decimal(9999999999999998.0) >>> a-b Decimal('2') That is unexpected.

  >>> Decimal('9999999999999999.0')-Decimal('9999999999999998.0')
  Decimal('1.0')

Re: 9999999999999999.0 – 9999999999999998.0

#220
The accounting software we use has a built in calculator which has a similar problem.

5.55 * 1.5 = 8.3249999999999....

26.93 * 3 = 80.7899999999999....

I raised it with the supplier some time ago, they said it's just the calculator app and the main program isn't affected. Quite shocking that they are happy to leave it like this.

Post reply on HN