0.30000000000000004

The big issue here is what you're going to use your numbers for. If you're going to do a lot of fast floating point operations for something like graphics or neural networks, these errors are fine. Speed is more important than exact accuracy. If you're handling money, or numbers representing some other real, important concern where accuracy matters, most likely any number you intend to show to the user as a number, floats are not what you need. Back when…

Just adding 0.1 to 0.2 in the language of your choice can be misleading because printing the number might just cut off the digits at some point. Here's an example using perl5: perl -e 'print 0.1+0.2' yields '0.3', which looks OK, however perl -e 'print 0.1+0.2-0.3' reveals '5.55111512312578e-17' So, it's better to print the result of 0.1+0.2-0.3 For what its worth, perl6 passes this test with flying colours.

Once I wrote a library for double-to-string conversion and vice versa, which handles such roundings nicely: https://github.com/mkupchik/dconvstr Key idea is not just to map binary floating point value X to a decimal floating point value Y, but instead (in extended precision, with 64-bit mantissa) compute an interval of decimal floating point values [Y1, Y2] which maps back to X (in standard precision, with 53-bit mantissa). Then choose such Y from [Y1, Y2] that Y has the shortest decimal representation.

A couple of thoughts I've always had about floating-point arithmetic: 1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, programmers would be a lot less confused about floating-point arithmetic if they had to opt in to it…