midsummer på er! Larry  Get your free email from www.linuxmail.org Powered by Outblaze
As a previously very active poster here on edusig, I thought I'd drop in to say I'm still focused on maththroughprogramming (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 K12). 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 Pythonfocused 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/mathteach/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 Adathelanguage whereas I like Adathegirl [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 **(nr)) 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: edusigadmin@python.org [mailto:edusigadmin@python.org]On Behalf Of Danny Yoo Sent: Thursday, July 25, 2002 10:42 To: Kirby Urner Cc: edusig@python.org Subject: Re: [Edusig] 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 **(nr)) 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! _______________________________________________ Edusig mailing list Edusig@python.org http://mail.python.org/mailman/listinfo/edusig
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 nono. When I published my fast algorithm for integer powers [Dr. Dobbs J. 11, 2 (Feb. 1986), 3642ff], 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 nonstandard 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 sleightofhand 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 nonstandard 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**(11) = 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 overcautious 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 secondguess 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: edusigadmin@python.org [mailto:edusigadmin@python.org]On Behalf Of Danny Yoo Sent: Thursday, July 25, 2002 10:42 To: Kirby Urner Cc: edusig@python.org Subject: Re: [Edusig] 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 **(nr)) 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! _______________________________________________ Edusig mailing list Edusig@python.org http://mail.python.org/mailman/listinfo/edusig
Thanks for the discussion.
An explanation of why 0^0 is undefined in standard arithmetic
is that anythingexcept0 to the 0th power is 1, while 0 to
the anythingexcept0th 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 mathteach, you don't want 0^0 to be
defined because:
======
Subject: Re: "0^0"
From: Soroban
participants (5)

Bill Bradley

Danny Yoo

Dennis E. Hamilton

Kirby Urner

Will Well