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, segfaulthunter
Date 2008-10-09.14:25:50
SpamBayes Score 1.2267964e-14
Marked as misclassified No
Message-id <>
> Mark, is some of the inaccuracy due to double rounding?

No, I don't think so;  at least, not in the sense of rounding the same 
value twice (with different precisions).  I get similar results on my 
Core 2 Duo machine, which should be immune to x87 style problems 
(because Apple's gcc turns sse instructions on by default, I guess).  
It's just a result of three separate rounds: one for each log, and one 
for the result of the division.

> Could we make the two argument form more accurate by allowing the
> compiler to generate code that uses full internal precision,
> log(n)/log(d), instead of prematurely forcing the intermediate results
> to a PyFloat?

Seems to me that would only work on older x86 hardware, unless we 
deliberately use long double in place of double for the intermediate 

Personally, I don't think it's worth the effort of fixing this:  the 
result of log(x, 10) is accurate to within a few ulps anyway, which 
should be plenty good enough for any well-coded numerical work:  any 
numerically aware programmer should be well aware that it's dangerous to 
rely on floating-point operations giving exact results.

And in any case there's always log10.

As a separate issue, it may be worth exposing C99's log2 function in 
some future version of Python.  This, presumably, can be relied upon 
always to give exact results for powers of 2, which could be useful in 
some applications.
Date User Action Args
2008-10-09 14:25:53mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, segfaulthunter
2008-10-09 14:25:53mark.dickinsonsetmessageid: <>
2008-10-09 14:25:52mark.dickinsonlinkissue3724 messages
2008-10-09 14:25:50mark.dickinsoncreate