Floating point considered harmful Edit: this is not a blanket statement. It was meant in the context.
Not so much floating point as “using float point type for exact decimal literals”.
Fair...
0.1 and 0.2 Returns 0.30000000000000004 (2018)
31–40 of 161 posts
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#32Indeed, and therefore: 0.1 + 0.2 != 0.3 You can check it in the JavaScript console. This actually makes me wonder if anyone's ever attempted a floating-point representation that builds in an error range , and correctly propagated/amplified error over operations. E.g. a simple operation like "1 / 10" (to generate 0.1) would be stored not as a single floating-point value, but really as the range between the closest rep…
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.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#33Indeed, and therefore: 0.1 + 0.2 != 0.3 You can check it in the JavaScript console. This actually makes me wonder if anyone's ever attempted a floating-point representation that builds in an error range , and correctly propagated/amplified error over operations. E.g. a simple operation like "1 / 10" (to generate 0.1) would be stored not as a single floating-point value, but really as the range between the closest rep…
Perhaps something like https://pythonhosted.org/mcerp/index.html
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#34Indeed, and therefore: 0.1 + 0.2 != 0.3 You can check it in the JavaScript console. This actually makes me wonder if anyone's ever attempted a floating-point representation that builds in an error range , and correctly propagated/amplified error over operations. E.g. a simple operation like "1 / 10" (to generate 0.1) would be stored not as a single floating-point value, but really as the range between the closest rep…
Interval arithmetic is what you're looking for, and there's an IEEE standard and many implementations.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#35Earlier quoted context omitted.
Floating point is fine. Non-integers are inherently tricky to represent, especially when you have to pack it into 32 bits. You could maybe quibble with some of the decisions around NaN and denormals and things like that, but mostly IEEE-754 got it right. There's a reason it's been the standard for three and a half decades now, and it's served the computer industry very well. Incidentally: the fact that 0.1+0.2 does n…
I think one of the problems today is that floating point remains the default even for scripting languages like python. I'd wager that the huge majority of users of floating point arithmetic in their programs actually want correct math rather than efficient operations. This feels a bit like Random vs SecureRandom. So many people use the default and then accidentally shoot themselves in the foot. IMO, for scripting lan…
What precise number representation do you want that's free of such "surprises"?
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#36Indeed, and therefore: 0.1 + 0.2 != 0.3 You can check it in the JavaScript console. This actually makes me wonder if anyone's ever attempted a floating-point representation that builds in an error range , and correctly propagated/amplified error over operations. E.g. a simple operation like "1 / 10" (to generate 0.1) would be stored not as a single floating-point value, but really as the range between the closest rep…
[deleted]
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#37Indeed, and therefore: 0.1 + 0.2 != 0.3 You can check it in the JavaScript console. This actually makes me wonder if anyone's ever attempted a floating-point representation that builds in an error range , and correctly propagated/amplified error over operations. E.g. a simple operation like "1 / 10" (to generate 0.1) would be stored not as a single floating-point value, but really as the range between the closest rep…
But what you would actually get is something like this: x---0.1 + 0.2 ---x x---0.3---x That is, the range of 0.1 + 0.2 would be wider than the range of 0.3. And now what do you do? There is overlap, so are they equal? But there are parts that don't overlap, so are they different?
Make equality checks illegal, and instead define specific operations for contains and overlaps.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#38It 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
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#39In 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.3Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#40Golly. 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