Measuring Fractal Dimension ?
pdpi
pdpinheiro at gmail.com
Wed Jun 24 13:06:05 EDT 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:
>
> 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.
More information about the Python-list
mailing list