Tim Peters wrote: > Suppose you had a binary float format with 3 bits of precision, and the > result of a computation on that box is .001 binary = 1/8 = 0.125 decimal. > The "shortest-possible reproducing decimal representation" on that box is > 0.1. Is it more accurate to move that result to a wider machine via the > string "0.1" or via the string "0.125"? The former is off by 25%, but the > latter is exactly right. repr() on the former machine has no way to guess > whether the 1/8 it's fed is the result of the user typing in "0.1" or the > result of dividing 1.0 by 8.0. By taking the bits at face value, and > striving to communicate that as faithfully as possible, it's explainable, > predictable, and indeed as faithful as possible. "Looks pretty too" isn't a > requirement for serious floating-point work. It seems like most people who write '1.1' don't really want to dive into serious floating-point work. I wonder if literals like 1.1 should generate decimal objects as described by PEP 327, rather than floats. Operations on decimals that have no finite decimal representation (like 1.1 / 3) should use floating-point arithmetic internally, but they should store in decimal rather than floating-point format. Shane
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4