Measuring Fractal Dimension ?
pdpinheiro at gmail.com
Wed Jun 24 19:06:05 CEST 2009
On Jun 24, 1:32 pm, Mark Dickinson <dicki... at gmail.com> wrote:
> On Jun 24, 10:12 am, pdpi <pdpinhe... at 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:
> 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.
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.
More information about the Python-list