mid-summer på er! Larry -- Get your free email from www.linuxmail.org Powered by Outblaze
As a previously very active poster here on edu-sig, I thought I'd drop in to say I'm still focused on math-through-programming (as a great way to teach), but am off sojourning in J these days. Earlier, Tim Peters pointed me to ISETL as in some ways a precursor to Python, and that was cool (I enjoyed my experiences with that language). He also pointed me to 'Concrete Mathematics' as a paradigm text at the college level, which was a good resource (good to work back from in K-12). I was a philosophy major in the old days and don't necessarily know what's what in computer science. I find Kenneth Iverson has these same interests (math through programming), has already done a companion to 'Concrete Mathematics', and is working on another re 'The Book of Numbers' (Conway and Guy). Excellent! Ken helped me with a close read of my first J essay: http://www.inetarena.com/~pdx4d/ocn/Jlang.html (he found a few typos, a misused grammatical term (conjunctive instead of conjunction), and suggested I include viewmat, though not in quite the way I did (to look at totient(n) powers modulo n)). APL was the first language I really got into, in the 1970s, but I'd lost track of Ken (APL's designer), and hadn't really tuned in J until some J guy hit my Python-focused website ( http://www.inetarena.com/~pdx4d/ocn/cp4e.html ) and suggested I check it out. Why is this relevant? Well, I'm always going to be a Python fan, so that'll keep bubbling up in my postings to math teacher groups (another one of those just tonight: http://www.mathforum.com/epigone/math-teach/taytrismoo (see mine of 25 July 2002 re passing functions to functions, with Python illustrating)). The fact that I'm mixing it up with J (long, steep learning curve) is probably somewhat indicative of where I might be finding synergies and curriculum ideas. Fortune tellers will tell. Perhaps some other Pythoneers tracking this list have some overlap with J as well? Anyone care to opine re J? (I see D. Ajoy on Jforum -- he's been helpful with Python, used to send me Logo programs in Spanish too). Cliff Nelson is over there too, but I'm not planning to argue with him anymore (we've mostly argued to date, maybe cuz he likes Ada-the-language whereas I like Ada-the-girl [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? Speaking of Wolfram, I did the simplest cellular automata from NKS in J. Output looks like this: http://www.inetarena.com/~pdx4d/ocn/graphics/Jnks1.png (this is after doing similar stuff in Python -- posted about it to this list in late May of this year). Kirby [1] http://www.grunch.net/synergetics/adaessay.html
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!
Sounds backwards to me. If you're writing a binomial function you should trap the special case, not break the mathematical function so you don't have to. Bill
-----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
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
Thanks for the discussion. An explanation of why 0^0 is undefined in standard arithmetic is that anything-except-0 to the 0th power is 1, while 0 to the anything-except-0th power is 0. So when you try to deal with the exception (0^0), you've got two rules which converge to different answers at the limit i.e. lim x^0 = 1 versus lim 0^x = 0 x->0 x->0 To take an excerpt from math-teach, you don't want 0^0 to be defined because: ====== Subject: Re: "0^0" From: Soroban <afetrmath2@aol.com> Date: 14 Jul 02 22:10:35 -0400 (EDT) I use the following approach. Remember the problem with "zero power"? What does 5^0 mean? And why does it equal 1? I remind them that: x^6/x^2 = x^4. (The Division Rule: "With like bases, subtract exponents." So when first confronted with: x^4/x^4, we may invoke the Division Rule and get x^(4-4) = x^0, which seems to be meaningless. But wait! We know that x^4/x^4 = 1, either by "cancelling" or from "anything divided by itself is 1". [Okay - there's ONE exception to that!] Hence, the answer must be 1. And x^0 (as strange as it looks) must also equal 1. Now, where or why does 0^0 show up at all? It must have come from a division problem. For example: 0^4/0^4 And what is the answer? Using the Division Rule, the answer is 0^0. Using arithmetic, 0^4 = 0, so the fraction becomes 0/0. Why is this called "indeterminate"? Why isn't it 1? How do we CHECK a division problem? For example: does 12/3 = 4? How do we check? We multiply the quotient (4) by the divisor (3) and we get the dividend (12). Correct! Very well, I claim that 0/0 = 7. Care to check it? Someone else claims that 0/0 = 1. It too checks out. The same for 0/0 = -137, etc. It turns out that 0/0 equals ANY NUMBER. There are TOO MANY answers (the value is indeterminate, can't be determiined). That renders the "number" 0^0 useless to us. ====== [Full text in Jul 15 posting under: http://www.mathforum.com/epigone/math-teach/brandghaichox ] Sounds to me like there are good arguments on both sides, but I personally am tilting towards 0^0 should produce a ValueError (or whatever exception), as it does in Mathematica (but not in MathCad, which says it's 1). In the real world, we have to conclude that there's no universal agreement on how best to evaluate 0^0. Interesting. Kirby
participants (5)
-
Bill Bradley -
Danny Yoo -
Dennis E. Hamilton -
Kirby Urner -
Will Well