classification
Title: math.log(0) differs from math.log(0L)
Type: Stage:
Components: Documentation Versions: Python 2.3
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: skip.montanaro Nosy List: fdrake, skip.montanaro, tim.peters
Priority: normal Keywords:

Created on 2003-03-27 21:30 by skip.montanaro, last changed 2003-04-26 03:00 by skip.montanaro. This issue is now closed.

Messages (7)
msg15283 - (view) Author: Skip Montanaro (skip.montanaro) * (Python committer) Date: 2003-03-27 21:30
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.
msg15284 - (view) Author: Skip Montanaro (skip.montanaro) * (Python committer) Date: 2003-03-28 22:50
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError
msg15285 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2003-04-25 20:09
Logged In: YES 
user_id=31435

I'm happy enough the way it is.

2.2 specifically added the ability to get a good result for log
(long) even when the long is far too large to fit in a float.  
That's why log(long) takes a different path starting in 2.2, and 
why there's no inconsistency across platforms in log(0L) 
behavior since 2.2.

If you want consistency for log(0.0), then Python cannot allow 
the platfrom log to see 0.0:  "standard" libm error behavior is 
platform-dependent, and error cases for log aren't unique in 
this respect:  Python would have to write its own error-
checking code around all libm functions.  That's a much 
larger project than it may sound, and short of doing that, 
there's really no point special-casing the snot out of one 
specific log case.

It might be better if the math module docs explained that the 
specific exceptions raised in assorted error cases (and even 
whether some arguments are considered to be exceptional at 
all) are, in reality, not defined in any useful cross-platform or 
cross-release way.
msg15286 - (view) Author: Skip Montanaro (skip.montanaro) * (Python committer) Date: 2003-04-25 21:15
Logged In: YES 
user_id=44345

Thanks, I'll see about getting a blurb added to the math module docs.
msg15287 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2003-04-25 21:21
Logged In: YES 
user_id=3066

Reopened and assigned to Skip for a documentation patch he
has.  It will be applied *after* the 2.3b1 release; we're
too far along at this point.
msg15288 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2003-04-25 21:22
Logged In: YES 
user_id=3066

I'll also note that the patch should be applied for 2.2.3;
there's no need to delay committing it on that branch.

Thanks, Skip!
msg15289 - (view) Author: Skip Montanaro (skip.montanaro) * (Python committer) Date: 2003-04-26 03:00
Logged In: YES 
user_id=44345

added note to Doc/lib/libmath.tex (v. 1.29 and 1.25.22.1).
History
Date User Action Args
2003-03-27 21:30:22skip.montanarocreate