Coq Compute 0.1.
> ^^^
Warning: The constant 0.1 is not a binary64 floating-point value. A closest
value 0x1.999999999999ap-4 will be used and unambiguously printed
0.10000000000000001. [inexact-float,parsing]
= 0.10000000000000001
: float0.1 and 0.2 Returns 0.30000000000000004 (2018)
61–70 of 161 posts
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#62Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#63Floating point considered harmful Edit: this is not a blanket statement. It was meant in the context.
"People repeating stuff without understanding it considered harmful." Floating point is extremely useful. Too bad so many people have no idea how and when to use it. Including some people that design programming languages. Please, tell me, mister, how would you perform complex numerical calculations efficiently? I guess we should just forget about drones and bunch other stuff because 90% of developers have no clue ho…
If your calculation turned out to be incorrect it doesn't matter if it's efficient. Correct FP calculation requires error analysis, which is a concrete definition of "how to use it". If you mostly use packaged routines like LAPACK, then you don't exactly need FP; you need routines that internally use FP.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#64Golly. Surprised by floating point arithmetic? 1.99999999.... == 2.0 There are limits to computer representation of floating point numbers. Computers are finite state, floating point numbers are not. sigh
No, floating point numbers are finite state. That’s the whole point behind this discussion. There are only so many possible floating point numbers representable in so many bits.
I never understand this confusion - you have finite memory - with this you can only represent a finite set of real numbers. So of course all the real numbers can’t be mapped directly.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#65Earlier quoted context omitted.
Interval arithmetic is what you're looking for, and there's an IEEE standard and many implementations.
Thank you!! Yes, that turns out to be exactly it [1]. Looks like there's even at least one JavaScript library for it [2]. It seems like such a useful and intuitive idea I have to wonder why it isn't a primitive in any of the common programming languages. [1] https://en.wikipedia.org/wiki/Interval_arithmetic [2] https://github.com/mauriciopoppe/interval-arithmetic
Consider x in [-1, 1], and y in [-1, 1]. x*y is also in [-1,1], and x-y in [-2, 2]. But now consider actually that y=x. That's consistent, but our intervals could be smaller than what we've computed.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#66Earlier quoted context omitted.
Interval arithmetic is what you're looking for, and there's an IEEE standard and many implementations.
Thank you!! Yes, that turns out to be exactly it [1]. Looks like there's even at least one JavaScript library for it [2]. It seems like such a useful and intuitive idea I have to wonder why it isn't a primitive in any of the common programming languages. [1] https://en.wikipedia.org/wiki/Interval_arithmetic [2] https://github.com/mauriciopoppe/interval-arithmetic
It is basically useless for numerical computation when you perform iterations. Even good convergent algorithms can diverge with interval arithmetic. As you accumulate operations on the same numbers, their intervals become larger and larger, growing eventually to infinity. It has some applications, but they are quite niche.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#67Earlier quoted context omitted.
That sounds interesting, but I would imagine it would become very complicated once you start applying nontrivial functions (discontinuous functions, for example). In that case the range of possible values could actually become discontinuous. I would imagine accounting for that is actually more computationally expensive than just using arbitrary precision decimals.
Yeah, you call tan() on that number, and suddenly your interval is like most of the number line. Actually, you don't even have to be that fancy: if the number is close to epsilon, the error bars on 1/x would be huge.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#68It sure does: https://0.30000000000000004.com/
Their summary of Mysql 5.6 ( https://0.30000000000000004.com/#mysql ) isn't telling the whole story. "SELECT .1 + .2;" does return 0.3 However, CREATE TABLE t1 (f FLOAT); INSERT INTO t1 VALUES(0.1),(0.2); SELECT SUM(f) FROM t1; // returns 0.30000000447034836 Which feels odd to me. http://sqlfiddle.com/#!9/2e75e/3
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#69In python, 0.3 prints as 0.3, but it's a double, so it should be 0.299999999999999988897769753748434595763683319091796875 (according to the article, and the 0.1+0.2 != 0.3 trick also works) What controls this rounding? e.g., in an interactive python prompt i get: >>> b = 0.299999999999999988897769753748434595763683319091796875 >>> b 0.3
It is the shortest decimal number that converts back to that exact FP number. There are tons of complex algorithms for that [1]. [1] See my past comment for the overview: https://news.ycombinator.com/item?id=26054079
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#70Earlier quoted context omitted.
Thank you!! Yes, that turns out to be exactly it [1]. Looks like there's even at least one JavaScript library for it [2]. It seems like such a useful and intuitive idea I have to wonder why it isn't a primitive in any of the common programming languages. [1] https://en.wikipedia.org/wiki/Interval_arithmetic [2] https://github.com/mauriciopoppe/interval-arithmetic
> It seems like such a useful and intuitive idea I have to wonder why it isn't a primitive in any of the common programming languages. It is basically useless for numerical computation when you perform iterations. Even good convergent algorithms can diverge with interval arithmetic. As you accumulate operations on the same numbers, their intervals become larger and larger, growing eventually to infinity. It has some…