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

Discussion in 'Python' started by asmirnov1234567890@yahoo.com, Jan 13, 2005.

  1. Guest

    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
     
    , Jan 13, 2005
    #1
    1. Advertising

  2. Tim Peters Guest

    []
    > 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").
     
    Tim Peters, Jan 13, 2005
    #2
    1. Advertising

  3. <> 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>
     
    Fredrik Lundh, Jan 13, 2005
    #3
  4. Peter Hansen Guest

    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
     
    Peter Hansen, Jan 13, 2005
    #4
  5. Guest

    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?
     
    , Jan 13, 2005
    #5
  6. Tim Peters Guest

    []
    > 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).
     
    Tim Peters, Jan 13, 2005
    #6
  7. John Roth Guest

    <> wrote in message
    news:...
    > 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


    >
     
    John Roth, Jan 13, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Miller
    Replies:
    4
    Views:
    13,404
    Chris Smith
    Nov 22, 2003
  2. bd
    Replies:
    0
    Views:
    642
  3. max(NaN,0) should be NaN

    , Aug 28, 2006, in forum: C Programming
    Replies:
    61
    Views:
    1,261
    Michel Hack
    Sep 8, 2006
  4. Replies:
    6
    Views:
    1,534
    Richard Tobin
    Mar 19, 2009
  5. Carsten Fuchs
    Replies:
    45
    Views:
    1,580
    James Kanze
    Oct 8, 2009
Loading...

Share This Page