don't NaN & infinities hide FP errors

John Roth newsgroups at jhrothjr.com
Wed Nov 17 18:48:38 CET 2004


"Gandalf" <gandalf at geochemsource.com> wrote in message 
news:mailman.6483.1100700011.5135.python-list at python.org...
>
>>The rest varies across platforms, as explained in this note at the end
>>of Python's math module docs:
>>
>>"""
>>The math module consists mostly of thin wrappers around the platform C
>>math library functions. Behavior in exceptional cases is loosely
>>specified by the C standards, and Python inherits much of its
>>math-function error-reporting behavior from the platform C
>>implementation. As a result, the specific exceptions raised in error
>>cases (and even whether some arguments are considered to be
>>exceptional at all) are not defined in any useful cross-platform or
>>cross-release way. For example, whether math.log(0) returns -Inf or
>>raises ValueError or OverflowError isn't defined, and in cases where
>>math.log(0) raises OverflowError, math.log(0L) may raise ValueError
>>instead.
>>"""
>>
> I still feel that it would be possible to use some assembly code and 
> achieve the same behaviour on all platforms.

As Jeff points out, the core developers would really like this.
However, they don't have the time to do it, so if you want to
do it, they would be grateful - as long as you follow a few
simple rules.

As I understand it, it's not quite as bad as Jeff says: the
problem is nasty enough that if you simply handle several
major platforms _consistently_, then the minor platforms
can still behave inconsistently. Then someone else can do
any of them that she wants to.

I think making Windows (both native and Cygwin) and
all the Unices (including Linux and Mac OS 10) behave
consistently would be a good start. You might also want
to look at the new floating decimal package in release 2.4
for ideas about how to handle exceptions and so forth.

There are guidelines for both Python and C code in
the Peps, and becoming familiar with the source is something
you want to do.

Make sure  you've got a thorough test suite: if something
breaks this will save a maintainer a lot of time figuring out
what.

Otherwise, have at it. Lots of people will bless you.

John Roth

> It is really not difficult to calculate log on a 387. It can be more 
> difficult on a RISC but not impossible.
> Why the implementation stuck on the C standards? Okay, maybe it is not 
> possible or too difficult to use asm code
> on some platforms. But at least Python should try to do the same thing 
> when it is possible. It could be an 'option'
> to compile low level code for the most popular operating systems. What do 
> you think?
>
>   Laci 2.0
>
> 




More information about the Python-list mailing list