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
Jürgen,
Thanks for clearing up the usage.
I pulled my example from this paper: 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 < address@hidden>
Date: Sun, February 07, 2016 5:27 am
To: address@hidden, address@hidden
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
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
|