a. Under the current definition, m = # u^:(<m) y, and the current definition is shorter than u^:(i.m+1) y .
b. Arguing for i.m+1 would be similar to arguing that i.m should be 0 1 2 ... m . c. There are no problems with the current defn for u^:(<m), in particular, no problems with when m is infinite. ----- Original Message ----- From: Dan Bron <[EMAIL PROTECTED]> Date: Monday, April 9, 2007 12:30 pm Subject: [Jgeneral] Decision in definition of ^:(<m) > I'm curious about a decision made in the definition of u^:(<m) . > The Vocabulary page for ^: at > http://www.jsoftware.com/help/dictionary/d202n.htm defines the > case thus: > > > 2081 235 qdoj '^:' > > If n is boxed it must be an atom, and u^:(<m) > > <==> u^:(i.m) y if m is a non-negative integer > > > what I want to know is: why is it not <==> u^:(i.m+1) ? > > Purely from the perspective of notation, I would expect f^:(<3) > to be "the same as f^:3, but including intermediate results". Or, > equivalently, "all the powers of f up to _and including_ 3". > Put another way, would expect the last item of u^:(<m) to match > u^:m (modulo fills). > > Another factor influencing my expectation is the treatment of > infinite m . As it stands, u^:(<_) gives all the > intermediate results up to _and including_ the convergent point k > of u . That is, the last item of u^:(<_) y is the limit of > u on y , not result of the penultimate functional power. To > put it another way, if i._ were legitimate J, without the > additional specification: > > > 2326 271 qdoj '^:' > > <==> u^:(i.k) y if m is _ or '' , where k is the > smallest positive > integer such that (u^:(k-1) y) -: > u^:k y > > the Vocabulary page for ^: would be incorrect; the last item of > f^:(<_) y would be f^:(_-1) y (A). So, my question could be > phrased: why (theoretically) require the special case? But the > is better stated as above: > > What are the advantages of defining > > u^:(<m) <==> u^:(i.m ) > > instead of > > u^:(<m) <==> u^:(i.m+1) > > ? > > I suspect that even if the latter language is superior (I won't > claim it is), there's probably too much extant code which relies > on the former to change it. But I am curious as to why the former > was chosen. > > -Dan > > (A) We could "fix" this by retaining the quoted specification for > infinite m but substituting +1 for -1 . ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
