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 gvanrossum
Recipients christian.heimes, gvanrossum, nascheme, noam, rhettinger, tim.peters
Date 2007-12-12.23:43:26
SpamBayes Score 0.0019931823
Marked as misclassified No
Message-id <>
In-reply-to <>
> 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.

Does doubledigits.c not work for non-754 platforms?

> 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.

Fair enough. And the glibc code is better anyway, according to Tim.
(Although probably even more complex.)

> If nobody is going to implement the correctly rounding decimal to
> binary conversion, then I see three options:
> 1. Revert to previous situation

That would be sad since we're so close.

> 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?)

Tim says you can't check (test) for this -- you have to prove it from
source, or trust the vendor's documentation. I would have no idea
where to find this documented.

> 3. Keep the binary to shortest decimal routine and drop repr(f) == f
> (I don't like that option).

It would mean that on platforms with unknown-correct rounding *input*
the *output* would be ugly again. I wouldn't mind so much if this was
only VAX or Cray; but if we had to do this on Windows it'd be a real

> If options 2 or 3 are chosen, we can check the 1e5 bug.

First you'll have to reproduce it -- I can't afford to spend much
quality time with gdb, especially since I don't understand the source
code at all. Though you may be able to pinpoint a possible candidate
based on the characteristics of the error -- it seems to have to do
with not placing the decimal point correctly when there are trailing
Date User Action Args
2007-12-12 23:43:27gvanrossumsetspambayes_score: 0.00199318 -> 0.0019931823
recipients: + gvanrossum, tim.peters, nascheme, rhettinger, christian.heimes, noam
2007-12-12 23:43:27gvanrossumlinkissue1580 messages
2007-12-12 23:43:26gvanrossumcreate