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…
9999999999999999.0 – 9999999999999998.0
211–220 of 274 posts
Re: 9999999999999999.0 – 9999999999999998.0
#212Are 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.
Re: 9999999999999999.0 – 9999999999999998.0
#213Re: 9999999999999999.0 – 9999999999999998.0
#214I 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…
(It’s inevitably floats or doubles)
Re: 9999999999999999.0 – 9999999999999998.0
#215 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
#216Earlier 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.
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
#217Earlier 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/
Re: 9999999999999999.0 – 9999999999999998.0
#218With 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
#219With 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
#2205.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.