python 2.3.4 for windows: float("NaN") throws exception

[asmirnov1234567890]

Hi

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?

Andrei

[Tim Peters]

[as************* ***@yahoo.com]

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").

[Fredrik Lundh]

<as************ ****@yahoo.com> 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>

[Peter Hansen]

as************* ***@yahoo.com 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?

Differences in the underlying platform/C library. No difference
here with similar platforms.

-Peter

[beliavsky]

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?

[Tim Peters]

[be*******@aol.c om]

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).

[John Roth]

<as************ ****@yahoo.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

Hi

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?

Andrei

As others have gently tiptoed around, it's basically
the lack of a group of enthusiastic and dedicated
volunteers to make it happen.

Nobody is really happy with the current situation,
but Python is a volunteer effort, and the current
set of volunteers isn't really motivated to put in
a very large amount of work on something that
they think would have relatively little benefit.

In other words, if someone wants to dig in and
do the work, I'm sure the core developers will
look at it favorably - as long as it meets the
usual standards for core development, including
documentation and maintainability .

The bar is lower than it has ever been, by the
way. It used to be: It has to work the same way
on all supported platforms. Now it's just: it has
to work the same on the core platforms, and
if anyone else really wants to work on the others,
more power to them.

John Roth