Tim Peters <[EMAIL PROTECTED]> added the comment: About (2**52-1)*2.**(-1074): same outcome under Cygwin 2.5.1, which is presumably based on David Gay's "perfect rounding" code. Cool ;-)
Under the native Windows 2.5.1: >>> x = (2**52-1)*2.**(-1074) >>> x 2.2250738585072009e-308 >>> y = eval(repr(x)) >>> y 0.0 Hard to say whether that's actually worse :-( About %.15g, good point! It probably would "make Guido happy". It's hard to know for sure, because despite what people say about this, the real objection to the status quo is aesthetic, not technical, and there's no disputing tastes. My tastes agree that %.17g is a pain in the ass when using the interactive shell -- I rarely want to see so many digits. But %.15g, and even %.12g, would /still/ be a pain in the ass, and for the same reason. Most times I'd be happiest with plain old %g (same as %.6g). OTOH, sometimes I do want to see all the bits, and sometimes I'd like a fixed format (like %.2f), and so on. Alas, all choices suck for strong reasons (either technical or aesthetic -- and, BTW, your "lots of trailing zeroes" idea won't fly because of the latter). The introduction of hex formats for floats should make this starkly clear: using hex I/O for float repr would be the ideal technical choice: easy to code, extremely fast, compact representation, and highly portable. Those are supposedly repr's goals, regardless of whether the repr string is easily readable by humans. But you know without asking that using hex format for repr(float) has no chance of being adopted -- because it's ugly :-) _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
