On Jun 24, 1:32 pm, Mark Dickinson <dicki...@gmail.com> wrote: > On Jun 24, 10:12 am, pdpi <pdpinhe...@gmail.com> wrote: > > > Regarding inf ** 0, why does IEEE745 define it as 1, when there is a > > perfectly fine NaN value? > > Other links: the IEEE 754 revision working group mailing list > archives are public; there was extensive discussion about > special values of pow and similar functions. Here's a relevant > Google search: > > http://www.google.com/search?q=site:grouper.ieee.org++pow+annex+D > > The C99 rationale document has some explanations for the > choices for special values in Annex F. Look at pages 179--182 > in: > > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf > > Note that the original IEEE 754-1985 didn't give specifications > for pow and other transcendental functions; so a complete > specification for pow appeared in the C99 standard before it > appeared in the current IEEE standard, IEEE 754-2008. Thus > C99 Annex F probably had at least some small influence on the > choices made for IEEE 754-2008 (and in turn, IEEE 754-1985 > heavily influenced C99 Annex F). > > My own take on all this, briefly: > > - floating-point numbers are not real numbers, so mathematics > can only take you so far in deciding what the 'right' values > are for special cases; pragmatics has to play a role too. > > - there's general consensus in the numerical and mathematical > community that it's useful to define pow(0.0, 0.0) to be 1. > > - once you've decided to define pow(0.0, 0.0) to be 1.0, it's > easy to justify taking pow(inf, 0.0) to be 1.0: the same > limiting arguments can be used as justification; or one can > use reflection formulae like pow(1/x, y) = 1/pow(x, y), or... > > - one piece of general philosophy used for C99 and IEEE 754 > seems to have been that NaN results should be avoided > when it's possible to give a meaningful non-nan value instead. > > - part of the reason that pow is particularly controversial > is that it's really trying to be two different functions > at once: it's trying to be both a generalization of the > `analytic' power function x**y = exp(y*log(x)), for > real y and positive real x, and in this context one can > make a good argument that 0**0 should be undefined; but > at the same time it's also used in contexts where y is > naturally thought of as an integer; and in the latter > context bad things happen if you don't define pow(0, 0) > to be 1. > > I really should get back to work now. > > Mark
Thanks for the engrossing read (and damn you for making me waste valuable work hours). After perusing both C99 and the previous presentation on IEEE754, I find myself unconvinced regarding the special cases. It just stinks of bug-proneness, and I fail to see how assuming common values for exceptional cases relieves you from testing for those special cases and getting them behaving right (in an application-specific way) just the same. -- http://mail.python.org/mailman/listinfo/python-list
