[kstenerud]

The problem is that the creeping imprecision actually comes from the exponential mismatch, not the actual float itself. If we were inputting floats in binary format, most of our problems would disappear. But since we think in decimal, we input in decimal, and then magical complicated algorithms convert those "decimal" values to the "nearest" binary representation. And then the trouble ensues when we try to use them in calculations and get weird results.

Decimal floats would operate just as we're used to, and would solve 95% of our floating point problems.

[jcranmer]

> Decimal floats would operate just as we're used to, and would solve 95% of our floating point problems.

It does not in fact solve the problem identified in this blog post (a non-associative issue). It does not solve any of the problems I generally see mentioned in topics like multiplayer video game desyncs (math libraries on different platforms don't return the same results). It's a pretty bold assertion that "95% of our floating point problems" would be solved.

[kstenerud]

Every single one of the problems in the article are due to binary-exponent / decimal-exponent mismatch and the inevitable differences in how different platforms do the conversions. With decimal floats, that problem disappears. There is no converted-it-to-90.34326374227855; all implementations would correctly have 90.34326 because there's no lossy conversion-to-binary-exponent to make; it's just stored in decimal with a decimal exponent, the end.

Multiply 90.34326 by 0.1 and then 0.1 again? Once again, all platforms will correctly and EXACTLY give the result 0.9034326. No loss of precision at all. Or do it 0.1 times 90.34326 times 0.1. Same result (exactly the same). Do that with binary floats and you're in for a world of hurt.

[jcranmer]

> Every single one of the problems in the article are due to binary-exponent / decimal-exponent mismatch and the inevitable differences in how different platforms do the conversions.

The article itself actually started with your assumption... and found it wasn't true. The type conversion wasn't the issue--it was coming back as the same value on all the different systems.

The flaw was that the sum came out wrong depending on the order that it was done. And the input numbers were (if I'm understanding correctly) computed as a / b, for some integer values a and b, which are not generally perfectly precise in decimal or binary floating point.

[kstenerud]

I think I need to do a blog post on this. I get the same kind of reaction from pretty much anyone I talk to about this, and it takes hours of explanations & diagrams to get them to understand. It's a real shame too, because a correct understanding would have a LOT more people putting pressure on implementors to support decimal floats :/