FYI Dyalog are considering introducing Cut into a future version of Dyalog APL and would welcome feedback or collaboration on the design:
http://video.dyalog.com/Dyalog15/?v=9KOto3xXS3c http://www.dyalog.com/uploads/conference/dyalog15/presentations/D16_Future_Operator_Proposals.zip http://www.dyalog.com/blog/2015/11/response-to-feedback-on-cut-under-and-merge/ Jay. On 8 February 2016 at 01:58, Louis de Forcrand <ol...@bluewin.ch> wrote: > AFAIK, Rationalised APL was the model for Sharp APL (which by the way is > still downloadable for DOS from the > resurrected Waterloo APL archives) and eventually led to J. The way Sharp > APL deals with nested arrays is > slightly different from ISO APL or APL2 (or any other APL2-like > implementation), and uses < to “box” any array > regardless of its shape (scalars too!) and raise its level by one (as does > J), unlike enclosing does in the standard. > In fact, many (quite useful) features such as composition and, by extension, > inverses of composed functions, are > either missing or not completely implemented in the ISO standard. > I haven’t read Rationalised APL, but I wouldn't expect everything in there > to work out-of-the-box in GNU or any > other standard APL; I’ve tried SAPL and it is quite similar to J (and so > quite different from the standard). > > Best regards! > Louis > > On 07 Feb 2016, at 20:32, <alexwei...@alexweiner.com> > <alexwei...@alexweiner.com> wrote: > > Jürgen, > > Thanks for clearing up the usage. > > I pulled my example from this paper: > http://www.jsoftware.com/papers/RationalizedAPL.htm (search the page for > the term 'tessellation' to see where I am looking) > which seems to be using < in place of ⊂ ....which still seems to cause an > error for me in GNU APL. > The more I read that paper, it seems that it is intended as suggestions to > add on to APL, rather than act as a reference... > > Is the tessellation available in GNU APL, and I am just messing something up > (might be b/c I'm not sure what you mean by "literals")? > > > -------- Original Message -------- > Subject: Re: [Bug-apl] value error when using 'Cut' > From: Juergen Sauermann <juergen.sauerm...@t-online.de> > Date: Sun, February 07, 2016 5:27 am > To: alexwei...@alexweiner.com, bug-apl@gnu.org > > Hi Alex, > > not sure what a ¯3⍤< m is supposed to mean. > > According to the ISO standard the syntax for ⍤ is: > > Z ← f ⍤ j B (monadic, page 124) or > Z ← A f ⍤ j B (dyadic, page 125) > > If you compare that with your example: > > a ¯3 ⍤ < m > > then the (expected value) j is the primitive function <, which triggers the > VALUE ERROR. > The fact that the caret points to a is not because a is the culprit, but > because a is the left > end of the phrase being reduced. > > Unfortunately the syntax in the ISO standard is somewhat ambiguous: j is a > one, two, or three > element vector, and B is the rest. Therefore it is sometimes impossible to > decide where j ends > and where B begins, and the examples for ⍤ in the ISO standard are in > conflict with the IBM APL2 > binding rules. This conflict occurs only with ⍤ which - wise decision - is > not implemented at all > in IBM APL2. > > The conflict can be avoided by always putting j and B into separate > variables. If you use literals for j > or B, heaven forbid, then be prepared for fairly nasty error messages at > times. > > /// Jürgen > > > > On 02/06/2016 05:17 PM, alexwei...@alexweiner.com wrote: > > > Hi bug-apl, > > Why am I getting a value error here? It seems that the variable 'a' > definitely exists: > > a←2 2 ⍴2 > m←4 4 ⍴⍳16 > a > 2 2 > 2 2 > m > 1 2 3 4 > 5 6 7 8 > 9 10 11 12 > 13 14 15 16 > > > > VALUE ERROR > a ¯3⍤<m > ^ > a > 2 2 > 2 2 > > > > > SVN 693 > -Alex > > >
