Re: python 2.3.4 for windows: float(NaN) throws exception
[EMAIL PROTECTED] my python 2.3.4 for windows refuse to execute line float(NaN). It says: float(NaN) Traceback (most recent call last): File stdin, line 1, in ? ValueError: invalid literal for float(): NaN The same line works as expected on Linux and Solaris with python 2.3.4. Could anybody explain what is possibly wrong here? is it bug or feature? Neither -- all Python behavior in the presence of float NaNs, infinities, or signed zeroes is a platform-dependent accident. In this specific case, the accident is that the platform C runtime string-double functions on your Linux and Solaris boxes recognize NaN, but Microsoft's string-double functions do not. Microsoft's libraries can't even read back the strings they *produce* for NaNs.(usually -1.#IND). -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.3.4 for windows: float(NaN) throws exception
[EMAIL PROTECTED] wrote:
my python 2.3.4 for windows refuse to execute line float(NaN). It
says:
float(NaN)
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: invalid literal for float(): NaN
The same line works as expected on Linux and Solaris with python 2.3.4.
Could anybody explain what is possibly wrong here? is it bug or
feature?
feature, sort of. see http://www.python.org/peps/pep-0754.html :
Currently, the handling of IEEE 754 special values in Python
depends on the underlying C library. Unfortunately, there is little
consistency between C libraries in how or whether these values
are handled. For instance, on some systems float('Inf') will
properly return the IEEE 754 constant for positive infinity. On
many systems, however, this expression will instead generate
an error message.
the PEP includes a pointer to a module that lets you replace that float
with the fully portable:
import fpconst
def myfloat(x):
if x == NaN:
return fpconst.NaN
return float(x)
/F
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 2.3.4 for windows: float(NaN) throws exception
Tim Peters wrote: Neither -- all Python behavior in the presence of float NaNs, infinities, or signed zeroes is a platform-dependent accident. C99 and Fortran 2003 have IEEE arithmetic. If CPython could be compiled with a C99 compiler, would it also have IEEE arithmetic? Do Python number-crunchers think this is important? -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.3.4 for windows: float(NaN) throws exception
[EMAIL PROTECTED] C99 and Fortran 2003 have IEEE arithmetic. Not that simple (e.g., C99 doesn't *require* it; but it has a pile of specified IEEE behaviors a conforming C99 compiler can choose to support (or not), along with a preprocessor symbol those that do so choose can #define to advertise that decision). If CPython could be compiled with a C99 compiler, would it also have IEEE arithmetic? Fully define have IEEE arithmetic. Not that simple either. Even on Windows using Microsoft's C89 compiler, Python's float + - * and / meet the 754 standard provided you're running on a Pentium or AMD chip. The IEEE standard says nothing about how a 754-conforming implementation has to spell infinities or NaNs in string-float conversions, so that MS produces -1.#IND for a NaN doesn't oppose the 754 standard. Do Python number-crunchers think this is important? Some do, some don't. The only contributors motivated enough to do something about it gave us Python's fpectl module, which is aimed mostly at making it look like 754 gimmicks don't exist (fiddling the C runtime system so that operations that try to produce a NaN or infinity from finite operands raise exceptions instead). -- http://mail.python.org/mailman/listinfo/python-list
