On 8/23/06, alex.martelli <python-checkins@python.org> wrote:
--- python/trunk/Objects/floatobject.c (original) +++ python/trunk/Objects/floatobject.c Wed Aug 23 22:42:02 2006 @@ -821,12 +821,12 @@ ix = pow(iv, iw); PyFPE_END_PROTECT(ix) Py_ADJUST_ERANGE1(ix); - if (errno != 0) { + /* we need to ignore ERANGE here and just return inf */ + if (errno != 0 && errno != ERANGE) { /* We don't expect any errno value other than ERANGE, but * the range of libm bugs appears unbounded. */ - PyErr_SetFromErrno(errno == ERANGE ? PyExc_OverflowError : - PyExc_ValueError); + PyErr_SetFromErrno(PyExc_ValueError); return NULL;
I don't think this can be right. The returnvalue of pow() in the case of ERANGE isn't defined anywhere that I can find, at least. How can we assume it is +Infinity? As I tried to say over the visiphone, you can't even use compile-time or startup-time checks for the behaviour because 'undefined' also means it need not be consistent, either. The best we could do, if we really wanted to return +inf instead of raising OverflowError (which I don't, but don't really care about either), is generate +Infinity in some guaranteed way. I'm sure Tim can come up with a convenient, portable way < 0.9 wink>. But I'd prefer to keep it the way it was: x*x and x**2 don't always do the same thing. Floats have a lot more confusing features like that, such as 10*x - 9*x need not be x. I don't see the added value of trying to make it consistent in just this case, even if it's portable. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!