[Python-Dev] Two proposed changes to float formatting

Eric Smith eric at trueblade.com
Sun Apr 26 18:59:14 CEST 2009


Mark Dickinson wrote:
> I'd like to propose two minor changes to float and complex
> formatting, for 3.1.  I don't think either change should prove
> particularly disruptive.
> 
> (1) Currently, '%f' formatting automatically changes to '%g' formatting for
> numbers larger than 1e50.  For example:
...
> I propose removing this feature for 3.1

I'm +1 on this.

> I have a suspicion that at least part of the
> motivation for the '%f' -> '%g' switch is that it means the
> implementation can use a fixed-size buffer.  But Eric has
> fixed this (in 3.1, at least) and the buffer is now dynamically
> allocated, so this isn't a concern any more.

I agree that this is a big part of the reason it was done. There's still 
some work to be done in the fallback code which we use if we can't use 
Gay's implementation of _Py_dg_dtoa. But it's reasonably easy to 
calculate the maximum buffer size needed given the precision, for 
passing on to PyOS_snprintf. (At least I think that sentence is true, 
I'll very with Mark offline).

> Other reasons not to switch from '%f' to '%g' in this way:
> 
>  - the change isn't gentle:  as you go over the 1e50 boundary,
>    the number of significant digits produced suddenly changes
>    from 56 to 6;  it would make more sense to me if it
>    stayed fixed at 56 sig digits for numbers larger than 1e50.

This is the big reason for me.

>  - float formatting is already quite complicated enough; no
>    need to add to the mental complexity

And this, too.

> (2) complex str and repr don't behave like float str and repr, in that
> the float version always adds a trailing '.0' (unless there's an
> exponent), but the complex version doesn't:
...
> I propose changing the complex str and repr to behave like the
> float version.  That is, repr(4. + 10.j) should be "(4.0 + 10.0j)"
> rather than "(4+10j)".

I'm +0.5 on this. I'd probably be +1 if I were a big complex user. Also, 
I'm not sure about the spaces around the sign. If we do want the spaces 
there, we can get rid of Py_DTSF_SIGN, since that's the only place it's 
used and we won't be able to use it for complex going forward.

Eric.



More information about the Python-Dev mailing list