On Aug 23, 2006, at 3:13 PM, martin at v.loewis.de wrote: > Zitat von Tim Peters <tim.peters at gmail.com>: > >> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4