Perhaps the case could be made for
(v^:(<m) -: v^:(>:i.m)) x
Which solves the shape problem, and ensures that
(v^:m e. v^:<m) x
and also eliminates v^:0 x which is simply x.
>: ...
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.64.78/
-----------------------------------------------------(INTP)----{ gnat }-
----- Original Message -----
From: "Roger Hui" <[EMAIL PROTECTED]>
To: "General forum" <[email protected]>
Sent: Monday, April 09, 2007 5:04 PM
Subject: Re: [Jgeneral] Decision in definition of ^:(<m)
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
