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.org http://mail.python.org/mailman/listinfo/edu-sig