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

[asmirnov1234567890@yahoo.com]

Hi

my python 2.3.4 for windows refuse to execute line float("NaN"). It
says:
[color=blue][color=green][color=darkred]
>>> float("NaN")[/color][/color][/color]
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]

Re: python 2.3.4 for windows: float(&quot;NaN &quot;) throws exception

[asmirnov1234567 890@yahoo.com][color=blue]
> my python 2.3.4 for windows refuse to execute line float("NaN"). It
> says:
>[color=green][color=darkred]
> >>> float("NaN")[/color][/color]
> 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?[/color]

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]

Re: python 2.3.4 for windows: float(&quot;NaN &quot;) throws exception

<asmirnov123456 7890@yahoo.com> wrote:
[color=blue]
> my python 2.3.4 for windows refuse to execute line float("NaN"). It
> says:
>[color=green][color=darkred]
>>>> float("NaN")[/color][/color]
> 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?[/color]

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]

Re: python 2.3.4 for windows: float(&quot;NaN &quot;) throws exception

asmirnov1234567 890@yahoo.com wrote:[color=blue]
> my python 2.3.4 for windows refuse to execute line float("NaN"). It
> says:
>[color=green][color=darkred]
>>>>float("NaN" )[/color][/color]
>
> 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?[/color]

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

-Peter

[beliavsky@aol.com]

Re: python 2.3.4 for windows: float(&quot;NaN &quot;) throws exception

Tim Peters wrote:[color=blue]
>Neither -- all Python behavior in the presence of float NaNs,[/color]
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]

Re: python 2.3.4 for windows: float(&quot;NaN &quot;) throws exception

[beliavsky@aol.c om][color=blue]
> C99 and Fortran 2003 have IEEE arithmetic.[/color]

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).
[color=blue]
> If CPython could be compiled with a C99 compiler, would it
> also have IEEE arithmetic?[/color]

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.
[color=blue]
> Do Python number-crunchers think this is important?[/color]

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]

Re: python 2.3.4 for windows: float(&quot;NaN &quot;) throws exception


<asmirnov123456 7890@yahoo.com> wrote in message
news:1105629033 .442397.124820@ c13g2000cwb.goo glegroups.com.. .[color=blue]
> Hi
>
> my python 2.3.4 for windows refuse to execute line float("NaN"). It
> says:
>[color=green][color=darkred]
>>>> float("NaN")[/color][/color]
> 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[/color]

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

[color=blue]
>[/color]