3 ms·
> Since we "know" the exact answers have a finite number of decimal digits, we can just round off the lower part of the numbers, which will produce the nearest
by Hackbraten 7y ago
> Since we "know" the exact answers have a finite number of decimal digits, we can just round off the lower part of the numbers, which will produce the nearest float with that number of digits.
What does that even mean, “produce the nearest float with that number of digits?”
If my float representation says e. g., 2.6749999999999998, and I “tell” it to round to three digits, the result is still 2.6749999999999998 in floating point representation, isn’t it?
A floating point number doesn’t care about the number of significant decimal digits you want it to have.
- yorwba 7y agoGood floating-point printing functions output the shortest possible representation. So if 2.675 and 2.6749999999999998 are indistinguishable, print(2.6749999999999998) will show 2.675
- Hackbraten 7y agoMy impression was that the article is about intermediate rounding between calculation steps, rather than about printing a number to the screen.
- andreareina 7y agoAs far as (64-bit binary) floats are concerned, 2.675 and 2.6749999999999998 are in fact the same thing: $ python3 Python 3.7.3 (default, Jun 16 2019, 16:10:46) [Clang 8.0.0 (clang-800.0.42.1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 2.675 == 2.6749999999999998 True So IF you have enough excess precision at every step, and IF you do the rounding right at each step, then you can get the same results using binary fractions as with decimal. Of course, correct rounding is still an issue when using a decimal type, since round(sum(n for n in ns)) ≠ sum(round(n) for n in ns).
- deleted 7y ago[deleted]