[issue1580] Use shorter float repr when possible

Guido van Rossum report at bugs.python.org
Thu Dec 13 00:43:27 CET 2007


Guido van Rossum added the comment:

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

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

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
__________________________________


More information about the Python-bugs-list mailing list