| msg28408 - (view) |
Author: Erik Dahl (edahl) |
Date: 2006-05-03 18:39 |
| 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 |
|
|
| msg28409 - (view) |
Author: Tim Peters (tim.peters) *  |
Date: 2006-05-03 19:09 |
| Logged In: YES user_id=31435 Try it on Windows and you'll get: >>> long(float('nan')) Traceback (most recent call last): File "", 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). |
|
|
| msg28410 - (view) |
Author: Michael Hudson (mwh) |
Date: 2006-05-09 18:47 |
| 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. |
|
|
| msg28411 - (view) |
Author: Erik Dahl (edahl) |
Date: 2006-05-10 12:36 |
| Logged In: YES user_id=1482543 Just to be clear this does cause a crash in the interpreter. |
|
|
| msg28412 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2006-05-27 18:34 |
| 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). |
|
|
| msg59193 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-01-04 00:38 |
| Fixed in r59689 trunk Backport it to 2.5? |
|
|
| msg59217 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2008-01-04 06:35 |
| The change in the trunk seems like a good backport candidate, it fixes an issue with float conversion on OSX compared to other platforms. That said, I don't like the patch. This makes the current behaviour of converting float NaN's to 0 the defined behaviour, which feels wrong (he says without having the slightest idea of what the relevant standards might say about this). Shouldn't this raise an exception instead of silently converting? |
|
|
| msg62301 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-02-12 02:20 |
| A late comment: I agree with Ronald here; mightn't it make more sense to raise an exception (ValueError?) for long(float("nan"))? For comparison, long(float("inf")) currently raises OverflowError, at least on OS X. |
|
|
| msg62679 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2008-02-22 07:26 |
| FYI: IEEE Standard 754 requires an invalid operation exception when inf/nan conversion to integer is attempted. |
|
|
| msg70077 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-07-20 11:21 |
| It seems backporting this is not useful. |
|
|
| msg70121 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-07-21 21:56 |
| I still think this is the wrong solution, and should be fixed before 2.6; long(float('nan')) should raise ValueError. As Alexander points out, this fits much better with the IEEE 754 standard, and also with the C99 standard. It also just "feels right", to me; an attempt to convert a nan to an integer should not pass silently. Here's a patch, based on Ronald's original patch. Christian, what was the motivation for returning 0 here? (One could also argue on the basis of IEEE 754 and C99 that long(float('inf')) should raise ValueError instead of OverflowError; personally, I'm content that long(float('inf')) raises an exception---I'm not too bothered which one.) I agree that there doesn't seem much value in backporting the fix. |
|
|
| msg70123 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-07-21 22:23 |
| Assigning to me; I'd like to check in the new fix for 2.6/3.0, but I'll give it a couple of weeks for any objections to surface first. |
|
|
| msg70143 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-07-22 10:18 |
| > It also just "feels right", to me; an attempt to convert a nan > to an integer should not pass silently. I have the same gut feeling. |
|
|
| msg70721 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-08-04 21:32 |
| New patch committed, r65518. Conversion of a nan to an integer now raises ValueError consistently across platforms. |
|
|