Measuring Fractal Dimension ?

Mark Dickinson dickinsm at
Wed Jun 24 08:32:13 EDT 2009

On Jun 24, 10:12 am, pdpi <pdpinhe... at> 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:

The C99 rationale document has some explanations for the
choices for special values in Annex F.  Look at pages 179--182

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.


More information about the Python-list mailing list