Mark Dickinson <[email protected]> added the comment:
> I'm wondering if the NaN arises in the C code for random():
I don't think that's possible. In the second line:
return PyFloat_FromDouble((a*67108864.0+b)*(1.0/9007199254740992.0));
a and b are already C unsigned longs, so no matter what their value, the result
of the expression is well in range for an IEEE 754 double, and on a normal
machine there's just no realistic way that this calculation could produce a
NaN. PyFloat_FromDouble does no manipulation of the C double, but just stores
it directly in the PyFloat object.
I think there are two different things going on here.
(1) The Ubuntu error reporter seems to be using something other than the
standard Random class, so all bets are off there without knowing more about
what's being used. Chances seem good that whatever random number generator
they're using really *is* producing a NaN.
(2) That leaves Greg's report above, where the standard Random class is
apparently what's being used. Here I'm baffled---I can't see any realistic
mechanism that might produce that traceback.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue14028>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
