The problem with that is that, if you add it to arithmetic and reason with
it, you can derive
0/0 = 1
and that is a big no-no.
When I published my fast algorithm for integer powers [Dr. Dobbs J. 11, 2
(Feb. 1986), 36-42ff], I addressed this by actually using
0/0
for 0**0 and letting the underlying arithmetic system deal with it. If you
have a "standard" arithmetic it fails, if you are using one of the
non-standard arithmetic settings (assuming IEEE floats), you will get
whatever NaN that is appropriate to the system of arithmetic.
Because all divisions by 0 are undefined in the standard model for reals, it
is important to keep it that way.
There is no harm with having an algorithm that produces something rather
than fail, but if that is projected back onto the mathematics of it and used
in deductions, great mischief can occur. And the use of a determined result
for 0**0 in further calculations based on deductions derived in standard
arithmetic can be incorrect and inconsistent, just like the usual
sleight-of-hand in "proving" 0 = 1. (Or weird arguments around the
transfinite and the like, which I have been encountering lately.)
In 1985, I corresponded with Don Knuth about this, after noticing that
Newton was pretty casual about all of the 0 cases in his laying out of the
binomial theorem. Don was satisfied with what he has to say about it in Art
if Computer Programming at formula 1.2.6(14) (which I claim is not a valid
inference from 1.2.6(13), because 1.2.6(13) is not an accurate statement of
the theorem.).
On review, today, I am even more satisfied that there is no mathematical
justification for concluding that the answer should be 1. It is at best a
convention for computer solutions and, though presumably harmless -- it can
even be said to make sense, it will lead to erroneous results when used in
subsequent calculations where the use of a non-standard operation is masked.
I did find the justification on p.162 in Concrete Mathematics, in the
discussion of 5.12 preceding formula (5.12). First, reasoning from limits
doesn't seem to apply, though I recall stumbling on that too. I must say I
find the justification used at (5.14) to be rather ridiculous, almost like
voting on which theorems we want to be true, since it asks us to accept the
damage of x/x = x**(1-1) = x**0 (no conditions on x) for the sake of an
unsupportable harmony at a boundary case in the expression of a theorem.
The boundary condition on the binomial theorem (for (x+y)**n) seems to be
that x*y*(x+y) != 0 when n =< 0. I may be over-cautious here, but it seems
sufficient without digging deeper.
I don't believe that it is necessary to repair the Pascal's triangle C(n,0)
case, acknowledging that determination of C(0,0) [Computational Mathematics
(5.1)] involves the justifiable convention for 0! = 1 [ACP 1.2.6(2) and ACP
1.2.6(5) justified by 1.2.6(5) and 1.2.3(20)]. The Pascal recurrence works
independently, and the definition of 0! is not in any danger that I can
find. It's definition does not challenge any of the axioms of arithmetic.
My algorithmic compromise (computing 0**0 by "computing" 0/0) is not that
satisfying to me, though I found it rather elegant in the expression of the
algorithm. It leaves it to the underlying implementation of arithmetic to
deal with error conditions and does not attempt to second-guess what is and
is not an error. For myself, when I want more certainty than that, I simply
avoid cases that are not defined in the standard model. Where it is
important to do derivations that have implicit requirements that some
quantity not be zero, I endeavor to keep that condition explicit in stating
the derived expressions.
-- Dennis
-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On
Behalf Of Danny Yoo
Sent: Thursday, July 25, 2002 10:42
To: Kirby Urner
Cc: edu-sig@python.org
Subject: Re: [Edu-sig] Update from Urner [why 0**0 == 1?]
> Question: why do both J and Python define 0**0 (or 0^0 in J) to be 1,
> when mathematicians (and Wolfram's Mathematica) call this undefined?
Concrete Mathematics actually covers a reason for defining 0**0 as 1 in
the chapter on binomial coefficients --- I think it's somewhere in Chapter
5.
Although the functions 0**x and x**0 have different limiting values as x
approaches zero, we should define 0**0 == 1 so that the binomial theorem:
(x+y)**r = sum_k (n choose r) (x**r) (y **(n-r))
works for all r >= 0, even if x == -y. If you have The Art of Computer
Programming Volume 1 handy, see section 1.2.6 on the explanation of the
binomial theorem, and you'll see it.
Hope this helps!
_______________________________________________
Edu-sig mailing list
Edu-sig@python.orghttp://mail.python.org/mailman/listinfo/edu-sig