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 mark.dickinson
Recipients mark.dickinson, rhettinger, steven.daprano
Date 2009-01-02.11:31:37
SpamBayes Score 1.1657342e-15
Marked as misclassified No
Message-id <1230895898.96.0.199448932616.issue4796@psf.upfronthosting.co.za>
In-reply-to
Content
> Accordingly, I recommend Decimal.from_float(f) with no qualifiers or
> optional arguments.

I agree with this.  Since lossless conversion is feasible, this seems 
the obvious way to go.

It's lucky that the exponent range for (binary) floats is relatively 
small, though:  for IEEE 754 floats the worst case conversions (e.g., 
(2**53-1)/2**1074) produce Decimals with something like 767 significant 
digits, which is still plenty small enough not to cause difficulties.

The recipe in the docs is not industrial strength: it doesn't handle 
infinities, nans and negative zero.  I think there's a place for a 
from_float method that handles these special cases correctly---or at 
least as correctly as reasonable:  +-infinity should convert to +-
infinity, nans to (quiet) nans.  I don't think it's worth worrying about 
preserving the sign or payload of a binary nan: just convert all float 
nans to Decimal('NaN').    I do however think it's worth trying to 
preserve the sign of negative zero.  Note: I'm not suggesting changing 
the *documentation* at all---the recipe there is fine as it is, IMO, but 
I think an official version should include these corner cases.
History
Date User Action Args
2009-01-02 11:31:39mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, steven.daprano
2009-01-02 11:31:38mark.dickinsonsetmessageid: <1230895898.96.0.199448932616.issue4796@psf.upfronthosting.co.za>
2009-01-02 11:31:38mark.dickinsonlinkissue4796 messages
2009-01-02 11:31:37mark.dickinsoncreate