Found it. It is in the very same paper. http://arxiv.org/PS_cache/math/pdf/9205/9205211v1.pdf .
On page 6, Knuth wrote: ... The debate stopped there, apparently with the conclusion that 0^0 should be undefined. But no, no, ten thousand times no! Anybody who wants the binomial theorem ... to hold for at least one non-negative integer n _must_ before that 0^0 = 1, ... "Ask a Mathematican" http://www.askamathematician.com/2010/12/q-what-does-00-zero-raised-to-the-zeroth-power-equal-why-do-mathematicians-and-high-school-teachers-disagree/ has an interesting and useful discussion on this issue. In it the "Mathematician" wrote: Zero raised to the zero power is one. Why? Because mathematicians said so. No really, it’s true. And then goes on to explain why 1=0^0 is a good idea. On Fri, Jan 17, 2014 at 12:30 PM, Roger Hui <rogerhui.can...@gmail.com>wrote: > BTW, Knuth did something else which typifies APL thinking. In a note or > paper (I can not find it now), he argued strongly that 1=0^0, not > undefined, not 0, not anything else. The common conventional statement of > a polynomial, p(x)=sigma(k=0;k<=n) a[k]*x^k, requires that x^0 be 1. Some > writers are aware of this dependency and, being careful, write instead the > ugly p(x)=a[0]+sigma(k=1;k<=n)a[k]*x^k. > > Attention to edge cases is typical of APL thinking. It's another way to > stay in the world of expressions and away from the world of statements. > You know: > > if k=0 then > a[0] > else > a[k]*x^k > endif > > > > > On Wed, Jan 15, 2014 at 6:20 PM, Roger Hui <rogerhui.can...@gmail.com>wrote: > >> One aspect: J/APL programmers tend to stay in the nice world of >> expressions and avoid the nastier world of statements. This tendency >> pushes you towards array thinking and away from scalar thinking. >> >> For example, if b is a boolean array, and you want 4 where b is 0 and 17 >> where b is 1, write: >> >> (4*0=b)+(17*1=b) >> >> And of course the signs of real numbers x are: >> >> (x>0)-(x<0) >> >> Even Knuth, an eminent mathematician and computer scientist but not an >> APL programmer, knows to <strike>steal</strike> adopt this idea. See: Knuth, >> *Two Notes on >> Notation*<http://arxiv.org/PS_cache/math/pdf/9205/9205211v1.pdf>, >> 1992-05-01. In the first half of the paper he describes how "Iverson's >> convention" can be used to simplify the statement and manipulation of sums. >> >> See also: >> >> http://www.jsoftware.com/papers/perlis77.htm >> http://www.jsoftware.com/papers/perlis78.htm >> http://www.jsoftware.com/papers/APLQA.htm#Perlis-foreword >> >> >> >> >> >> On Wed, Jan 15, 2014 at 5:32 PM, Joe Bogner <joebog...@gmail.com> wrote: >> >>> I went googling for some deeper material on how to think like an APL >>> programmer. I have read/skimmed through a good set of the material on >>> http://jsoftware.com/papers/ and have skimmed through many of the >>> books listed on http://www.jsoftware.com/jwiki/Books. >>> >>> Are there any specific recommendations, free or for purchase? Or, >>> perhaps I should spend more time with the list above. >>> >>> I found this, The APL Idiom List by Perlis and Rugaber, which looks >>> similar to what I'm looking for: >>> http://archive.vector.org.uk/resource/yaleidioms.pdf. >>> >>> The review of this book looks like what I'm after, >>> >>> http://www.amazon.com/Handbook-APL-programming-Clark-Wiedmann/dp/0884050262 >>> , >>> constructing useful programs and going into more depth. >>> >>> Or something of the style of The Little Schemer, >>> http://scottn.us/downloads/The_Little_Schemer.pdf >>> >>> I searched the forum and had trouble finding a relevant post >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> >> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
