On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels <scott.dani...@acm.org> wrote:
> 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. Understood. > _but_ the printed decimal number I am proposing is within one ULP of > the value of the binary numbery. But there are plenty of ways to get this if this is what you want: if you want a displayed result that's within 1 ulp (or 0.5 ulps, which would be better) of the true value then repr should serve your needs. If you want more control over the number of significant digits then '%g' formatting gives that, together with a nice-looking output for small numbers. It's only '%f' formatting that I'm proposing changing: I see a '%.2f' formatting request as a very specific, precise one: give me exactly 2 digits after the point---no more, no less, and it seems wrong and arbitrary that this request should be ignored for numbers larger than 1e50 in absolute value. That is, for general float formatting needs, use %g, str and repr. %e and %f are for when you want fine control. > That is, the majority of the digits > in int(1e308) are a fiction Not really: the float that Python stores has a very specific value, and the '%f' formatting is showing exactly that value. (Yes, I know that some people advocate viewing a float as a range of values rather than a specific value; but I'm pretty sure that that's not the way that the creators of IEEE 754 were thinking.) > 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. As of 3.1, the printing code should be fine: it's using David Gay's 'perfect rounding' code, so what's displayed should be correctly rounded to the requested precision. Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
