Mark Dickinson wrote:
> ... """[5] These numbers are fairly arbitrary. They are intended to
> avoid printing endless strings of meaningless digits without
> hampering correct use and without having to know the exact
> precision of floating point values on a particular machine."""
> I don't find this particularly convincing, though---I just don't see
> a really good reason not to give the user exactly what she/he
> asks for here.
As a user of Idle, I would not like to see the change you seek of
having %f stay full-precision. When a number gets too long to print
on a single line, the wrap depends on the current window width, and
is calculated dynamically. One section of the display with a 8000
-digit (100-line) text makes Idle slow to scroll around in. It is
too easy for numbers to go massively positive in a bug.
> - the change isn't gentle: as you go over the 1e50 boundary,
> the number of significant digits produced suddenly changes
> from 56 to 6; it would make more sense to me if it
> stayed fixed at 56 sig digits for numbers larger than 1e50.
> - now that we're using David Gay's 'perfect rounding'
> code, we can be sure that the digits aren't entirely
> meaningless, or at least that they're the 'right' meaningless
> digits. This wasn't true before.
However, this is, I agree, a problem. Since all of these numbers
should end in a massive number of zeroes, how about we replace
only the trailing zeroes with the e, so we wind up with:
1157920892373161954235709850086879078532699846656405640e+23
or 115792089237316195423570985008687907853269984665640564.0e+24
or some such, rather than
1.157920892373162e+77
or 1.15792089237316195423570985008687907853269984665640564e+77
--Scott David Daniels
Scott.Daniels at Acm.Org
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