Author mark.dickinson
Recipients belopolsky, drj, ggenellina, mark.dickinson, vstinner
Date 2008-12-09.19:18:26
SpamBayes Score 3.43067e-06
Marked as misclassified No
Message-id <1228850311.4.0.978737318628.issue3166@psf.upfronthosting.co.za>
In-reply-to
Content
By the way, the algorithm here is essentially the same as the algorithm that I 
implemented for the float.fromhex method, except that the float.fromhex method is more 
complicated in that it may have to deal with signed zeros or subnormals.

So any mathematical defects that you find in this patch probably indicate a defect in 
float.fromhex too.

In fact, the code *does* do integer arithmetic, except that one of the integers happens 
to be stored as a double.  If you look at the code you'll find that at every stage, the 
floating-point variable "x" has an exact nonnegative integer value between 0 and 
2**DBL_MANT_DIG.  All such values are exactly representable as a double, and all the 
arithmetic operations involved are exact.  This holds right up to the ldexp call at the 
end.  So the arithmetic with x is essentially integer arithmetic.

I accept the code needs extra documentation;  I was planning to put the equivalent 
Python code into the comments to make things clearer.
History
Date User Action Args
2008-12-09 19:18:31mark.dickinsonsetrecipients: + mark.dickinson, belopolsky, ggenellina, vstinner, drj
2008-12-09 19:18:31mark.dickinsonsetmessageid: <1228850311.4.0.978737318628.issue3166@psf.upfronthosting.co.za>
2008-12-09 19:18:28mark.dickinsonlinkissue3166 messages
2008-12-09 19:18:26mark.dickinsoncreate