don't NaN & infinities hide FP errors
Gandalf
gandalf at geochemsource.com
Wed Nov 17 09:00:05 EST 2004
More information about the Python-list mailing list
Wed Nov 17 09:00:05 EST 2004
- Previous message (by thread): don't NaN & infinities hide FP errors
- Next message (by thread): don't NaN & infinities hide FP errors
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>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. 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
- Previous message (by thread): don't NaN & infinities hide FP errors
- Next message (by thread): don't NaN & infinities hide FP errors
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list