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 belopolsky, drj, mark.dickinson, vstinner
Date 2008-12-09.16:43:21
SpamBayes Score 6.25711e-08
Marked as misclassified No
Message-id <>
> The flags you may be looking for are -msse2 -mfpmath=sse

Thanks, Alexander!

[Alexander again, from an earlier post...]
> I noticed that you replaced a call to _PyLong_AsScaledDouble with your 
> round to nearest algorithm.  I wonder if _PyLong_AsScaledDouble itself 
> would benefit from your change.  Currently it is used in 
> and long_true_divide.  I would think that long_true_divide would be 
> accurate if longs were rounded to the nearest float.

You read my mind!  I've got another issue open about making long 
division round correctly, somewhere.  And indeed I'd like to make 
_PyLong_AsScaledDouble do correct rounding.  (I'd also like to make it 
return the exponent in bits, rather than digits, so that mathmodule.c 
doesn't have to know about the long int representation, but that's 
another story...)

> I believe _PyLong_AsScaledDouble is written the way it is to support 
> non-IEEE floating formats, but I am not sure that your algorithm would 
> always return the nearest float on an arbitrary non-IEEE platform.

Well, I had other possible formats in mind when I wrote the code, and I 
hope it's good whenever FLT_RADIX is 2.  If you can think of explicit 
cases where it's not going to work, please let me know.  My belief that 
it's safe rests on two facts: (1) it entirely avoids IEEE 754 oddities 
like negative zero, denormals and NaNs, and (2) all the floating-point 
operations actually performed should have exact results, so rounding 
doesn't come into play anywhere.

When FLT_RADIX is some other power of 2 (FLT_RADIX=16 is the only 
example I know of that exists in the wild) the code probably doesn't 
produce correctly rounded results in all cases, but it shouldn't do 
anything catastrophic either---I think the error still should't be more 
than 1ulp in this case.  When FLT_RADIX is not a power of 2 then so much 
else is going to be broken anyway that it's not worth worrying about.
Date User Action Args
2008-12-09 16:43:26mark.dickinsonsetrecipients: + mark.dickinson, belopolsky, vstinner, drj
2008-12-09 16:43:25mark.dickinsonsetmessageid: <>
2008-12-09 16:43:24mark.dickinsonlinkissue3166 messages
2008-12-09 16:43:22mark.dickinsoncreate