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, steve21
Date 2009-08-24.13:09:43
SpamBayes Score 1.110223e-16
Marked as misclassified No
Message-id <1251119387.15.0.404650783256.issue6765@psf.upfronthosting.co.za>
In-reply-to
Content
> If Python functions are inconsistent then I think they should either 
be
> made consistent, or if that's not possible they should be clearly
> documented as being inconsistent.

I think 'inconsistent' is a bit strong for what happens here.  In my 
view, the expressions log10(x) and log(x, 10) behave consistently:  they 
both give (good) floating-point approximations to the base-10 logarithm 
of x.  However, since they use slightly different methods to get those 
approximations, the approximations are not identical.

Would you also say that atan2(y, x) is inconsistent with atan(y/x)  (for 
positive x, y, say), because they give minutely different results in 
some cases?

> The docs for log10(x) could be improved to say:
> "this function gives the correct result for powers of 10,
> but breaks consistency with log(a,10) == log10(a)"

I find this unnecessarily negative.  I propose instead to leave the log 
documentation as it is, and add something like the following to the 
log10 documentation, as an explanation of why log10 is still valuable in 
the presence of the two-argument log function:

"""Since this function directly wraps the platform log10 function, 
``log10(x)`` will usually (depending on the platform) be faster and more 
accurate than the mathematically equivalent ``log(x, 10)``."""

Note that historically, the two-argument version of math.log appeared 
long after math.log10 did;  this might help explain the apparent 
redundancy.  (I'd actually argue that the two-argument log should not 
have been added in the first place:  it doesn't wrap a standard C math 
function, and it's really no different from log(x)/log(y), except that 
having it as a built-in library function gives the illusion that it 
might be more accurate than it actually is.  However, that's academic 
now.)

One possible 'fix' for this situation does occur to me:  instead of 
computing log(x, y) internally as log(x)/log(y), compute it as 
log10(x)/log10(y).  This at least doesn't involve extensive changes or 
additions to the code.  I don't think it really makes any practical 
difference, except perhaps in reducing the number of bug reports like 
this one.  And it won't help make log2(x) == log(x, 2) if/when the C99 
log2 function is added to the math library, either.  I'd be -0 on making 
this change.
History
Date User Action Args
2009-08-24 13:09:47mark.dickinsonsetrecipients: + mark.dickinson, steve21
2009-08-24 13:09:47mark.dickinsonsetmessageid: <1251119387.15.0.404650783256.issue6765@psf.upfronthosting.co.za>
2009-08-24 13:09:45mark.dickinsonlinkissue6765 messages
2009-08-24 13:09:43mark.dickinsoncreate