[ python-Bugs-1481296 ] long(float('nan'))!=0L
SourceForge.net
noreply at sourceforge.net
Sat May 27 20:34:06 CEST 2006
Bugs item #1481296, was opened at 2006-05-03 20:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L
Initial Comment:
on all platforms I can test long(float('nan'))=0L
But on maxos X intel long(float('nan'))!=0L
it returns:
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
This is a problem because:
>>> 344 - long(float('nan'))
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap
----------------------------------------------------------------------
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-27 20:34
Message:
Logged In: YES
user_id=580910
This could quite easily be fixed by testing for NaN in PyLong_FromDouble, such
as the attached patch. This works correctly on OSX, but I have no idea if this will
work on other platforms, that depends on how portable the already existing
Py_IS_NAN macro is. C99 also introduces an fpclassify and isnan functions that
could be used (Py_IS_NAN uses neither because Python is written in C89 instead
of C99).
----------------------------------------------------------------------
Comment By: Erik Dahl (edahl)
Date: 2006-05-10 14:36
Message:
Logged In: YES
user_id=1482543
Just to be clear this does cause a crash in the interpreter.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2006-05-09 20:47
Message:
Logged In: YES
user_id=6656
Nevertheless, assuming that a compiler implements the relavent standards (i.e.
Appendix F of C99) it's pretty clear that what PyLong_FromDouble does with a
nan is pretty random. frexp(dval, &expo); for dval nan stores an unspecified
value in expo which is then used to compute the length of the resulting long. If
the unspecified value is large-ish and positive, hilarity ensues.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2006-05-03 21:09
Message:
Logged In: YES
user_id=31435
Try it on Windows and you'll get:
>>> long(float('nan'))
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: invalid literal for float(): nan
Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python. You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470
More information about the Python-bugs-list
mailing list