This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author noam
Recipients christian.heimes, gvanrossum, nascheme, noam, rhettinger, tim.peters
Date 2007-12-12.23:34:16
SpamBayes Score 0.0014766776
Marked as misclassified No
Message-id <b348a0850712121534l3527adb5y44c6f15f83b58643@mail.gmail.com>
In-reply-to <ca471dc20712111631r10ec54cyc34bb22c270485a5@mail.gmail.com>
Content
Ok, so if I understand correctly, the ideal thing would be to
implement decimal to binary conversion by ourselves. This would make
str <-> float conversion do the same thing on all platforms, and would
make repr(1.1)=='1.1'. This would also allow us to define exactly how
floats operate, with regard to infinities and NaNs. All this is for
IEEE-754 platforms -- for the rare platforms which don't support it,
the current state remains.

However, I don't think I'm going, in the near future, to add a decimal
to binary implementation -- the Tcl code looks very nice, but it's
quite complicated and I don't want to fiddle with it right now.

If nobody is going to implement the correctly rounding decimal to
binary conversion, then I see three options:
1. Revert to previous situation
2. Keep the binary to shortest decimal routine and use it only when we
know that the system's decimal to binary routine is correctly rounding
(we can check - perhaps Microsoft has changed theirs?)
3. Keep the binary to shortest decimal routine and drop repr(f) == f
(I don't like that option).

If options 2 or 3 are chosen, we can check the 1e5 bug.
History
Date User Action Args
2007-12-12 23:34:18noamsetspambayes_score: 0.00147668 -> 0.0014766776
recipients: + noam, gvanrossum, tim.peters, nascheme, rhettinger, christian.heimes
2007-12-12 23:34:18noamlinkissue1580 messages
2007-12-12 23:34:17noamcreate