Mark Dickinson <[EMAIL PROTECTED]> added the comment: > 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 results. 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. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3724> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com