RetroSearch Browse

Mon Apr 27 01:35:43 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-April/089048.html

>> it would make more sense to me if it
>>    stayed fixed at 56 sig digits for numbers larger than 1e50.
> 
> So I agree with this, even if the default # of sig digits were less.

Several reasons to accept Mark's proposal:

* It matches what C does and many languages tend to copy the
   C standards with respect to format codes.  Matching other
   languages helps in porting code, copying algorithms, and mentally
   switching back and forth when working in multiple languages.

* When a programmer has chosen %f, that means that they have
   consciously rejected choosing %e or %g.  It is generally best to
   have the code do what the programmer asked for ;-)

* Code that tested well with 1e47, 1e48, 1e49, and 1e50
   suddenly shifts behavior with 1e51.  Behavior shifts like that
   are bug bait.

* The 56 significant digits may be rooted in the longest
   decimal expansion of a 53 bit float.  For example,
   len(str(Decimal.from_float(.1))) is 57 including the leading
   zero.   But not all machines (now, in the past, or in the future)
   use 53 bits for the significand.

* Use of exponents is common but not universal.  Some converters
   for SQL specs like Decimal(10,80) may not recognize the
   e-notation.  The xmlrpc spec only accepts decimal expansions
   not %e notation.

* The programmer needs to have some way to spell-out a
   decimal expansion when needed.   Currently, %f is the only way.

Raymond

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-April/089048.html below:

[Python-Dev] Two proposed changes to float formatting