<br>Since Alex isn't on python-dev, forwarding this for his convenience (he said he wanted to reply.) Tim also replied to his checkin, but I didn't forward that message.<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">
From: <b class="gmail_sendername">Thomas Wouters</b> <<a href="mailto:thomas@python.org">thomas@python.org</a>><br>Date: Aug 24, 2006 12:16 AM<br>Subject: Re: [Python-checkins] r51525 - in python/trunk: Lib/test/test_float.py Objects/floatobject.c
<br>To: "alex. martelli" <<a href="mailto:python-checkins@python.org">python-checkins@python.org</a>><br><br></span><div><br><br><div></div><div><span class="q"><span class="gmail_quote">On 8/23/06, <b class="gmail_sendername">
alex.martelli</b> <<a href="mailto:python-checkins@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">python-checkins@python.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>--- python/trunk/Objects/floatobject.c (original)<br>+++ python/trunk/Objects/floatobject.c Wed Aug 23 22:42:02 2006<br>@@ -821,12 +821,12 @@<br> ix = pow(iv, iw);<br> PyFPE_END_PROTECT(ix)<br> Py_ADJUST_ERANGE1(ix);
<br>- if (errno != 0) {<br>+ /* we need to ignore ERANGE here and just return inf */<br>+ if (errno != 0 && errno != ERANGE) {<br> /* We don't expect any errno value other than ERANGE, but
<br> * the range of libm bugs appears unbounded.<br> */<br>- PyErr_SetFromErrno(errno == ERANGE ? PyExc_OverflowError :<br>- PyExc_ValueError);
<br>+ PyErr_SetFromErrno(PyExc_ValueError);<br> return NULL;</blockquote></span></div><div><div><br>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>.<br></div><br>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.
<br></div></div><div><span class="sg"><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
</span></div><br clear="all"><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!