Mark Dickinson wrote:
> On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
> <Scott.Daniels at acm.org> wrote:
>> 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.
>
I had also said (without explaining:
> > 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
These are all possible representations for 2 ** 256.
> I see your point. Since we're talking about floats, thought, there
> should never be more than 316 characters in a '%f' % x: the
> largest float is around 1.8e308, giving 308 digits before the
> point, 6 after, a decimal point, and possibly a minus sign.
> (Assuming that your platform uses IEEE 754 doubles.)
You are correct that I had not thought long and hard about that.
308 is livable, if not desireable. I was remebering accidentally
displaying the result of a factorial call.
>> However, this is, I agree, a problem. Since all of these numbers
>> should end in a massive number of zeroes
>
> But they typically don't end in zeros (except the six zeros following
> the point),
> because they're stored in binary rather than decimal....
_but_ the printed decimal number I am proposing is within one ULP of
the value of the binary numbery. That is, the majority of the digits
in int(1e308) are a fiction -- they could just as well be the digits of
int(1e308) + int(1e100) because 1e308 + 1e100 == 1e308
That is the sense in which I say those digits in decimal are zeroes.
My proposal was to have the integer part of the expansion be a
representation of the accuracy of the number in a visible form.
I chose the value I chose since a zero lies at the very end, and
tried to indicate I did not really care where trailing actual accuracy
zeros get taken off the representation. The reason I don't care is
that the code from getting a floating point value is tricky, and I
suspect the printing code might not easily be able to distinguish
between a significant trailing zero and fictitous bits.
--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