Ron Sverdlove wrote:
> I have to agree that 0**0 is not defined in "conventional
> mathematics". Look at any calculus text. There will be a section on
> evaluating "indeterminate forms" using L'Hospital's rule.
> Indeterminate forms include 0 / 0, infinity / infinity, 0 * infinity,
> 0 ** 0, etc. Note that if you take the logarithm of 0 ** 0 using the
> usual rules, you get 0 * log(0) = 0 * (-infinity). These are all
> situations fitting Lawrie's description below where the limit may be
> undefined because it is path dependent. Only specifying a particular
> path can lead to a specific value.

Well, assuming the exponent is integral, and the base number isn't,
all limiting paths of X**0 as X->0 have a limit of 1, even if X
is COMPLEX.

Additionally, few arithmetic operations have their mathematical
definition in computing. So, even though the asterisk is called
the multiply operator, no one really expects true mathematical
products. Instead you expect an approximation that includes
rounding (for floats) and some behavior completely outside
the language's scope when overflow occurs (for both float
and integers).

What we need here is a computational definition. Fortran is mute
on that. I believe it to be deliberately mute. So, the only recourse
is to look outside the Fortran standard.

This is not to say that I think the Fortran standard is correct about
being mute on the subject. I think it shouldn't be. There is pretty
much a concensus about most of the semantics of computational
arithmetic. That includes a fairly clear concensus about what
flexibilty should be afforded to implementaitons. The work need
really only involve "rubber stamping" some existing description
of that semantics (with maybe a few variations specific to Fortran:
for example, SIGN(X) isn't even a Fortran function - since Fortran's
version takes two arguments and follows the IEEE recommended
copysign() operation).

There is no hurry. Fortran's lack of specific requirements makes
it consistent (vacuously) with the existing concensus. Quality of
implementation concerns should keep Fortran implementations
mostly in compliance with that existing concensus. The Fortran
committee has really no choices to make. If they violate the general
concensus, that will be yet another nail in Fortran's coffin. And
implementors would be forced to violate such a foolish standard
(or, at least, provide a mode that does).

It could be argued that with respect to this particular issue
(exponentiation with an integral zero exponent) the concensus
is still not settled. Maybe. I can't find anyone that would regard
any but the following two answers correct: an "invalid" exception
or one (1). The smart bet seems to be that the result should be
one (1).

Separately Asher Langton wrote:
> On 7/14/06, Peter Shenkin <[log in to unmask]> wrote:
>> But if x is a real number, we can apply L'Hopital's rule
>> to this expression in the limit x->0, which gives
>> x**0->1 as x->0.
>
> Yes, but what about the limit of 0**x as x->0?

In that case, the exponent is not of type INTEGER. That's a
semantically distinct case. It's even a mathematically distinct
case. It's certainly a computationally distinct one. Still, as
I pointed out earlier, some people might insist that the semantics
be type independent. I disagree with that. And, I can't find any
other languages or standards that agree with that either.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare