On Aug 23, 2006, at 3:13 PM, [EMAIL PROTECTED] wrote: > Zitat von Tim Peters <[EMAIL PROTECTED]>: > >> Huh. It's been a (mildly controversial, but intentional all the >> same) >> feature that Python tries to raise raise OverflowError on overflowing >> libm operations. Doesn't work all that well, since there's no >> consistency across platforms about when libm sets errno, or to what >> (when it does). > > The other question is whether pow() is guaranteed to return inf > when it sets errno to ERANGE; I believe there is no such guarantee.
Summarizing my longer mail that crossed with yours: the guarantee is there in the 1999 C Standard; I don't have access any more to a copy of the 1990 C Standard to check how things were back then. > So I think the change should be reverted. I have reverted the change, but I think it (or rather "something like" it -- *SOME* fix for x**2 raising OverflowError while x*x proceeds happily for a certain range of floats) is important and should go back in again. Using Py_HUGE_VAL instead of trusting pow's result might be OK, for example, if the 1990 C Standard is that much weaker on this than 1999's and we need to stick to it anyway. But the problem is that testing this sensibly requires fpconst (from PEP 754) or the equivalent, otherwise it may be impossible to write unittest to show the presence or absence of this bug. Alex _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
