-------- Original Message --------
Subject: Re: [Bug-apl] value error when using 'Cut'
From: Juergen Sauermann <
address@hidden>
Date: Mon, February 08, 2016 5:05 am
To:
address@hidden,
address@hidden
Hi Alex,
it is not available in GNU APL. There have been many improvement
proposals for APL
over the years, but many of them have not made it into the ISO standard
(which is GNU
APL's implementation blueprint).
By literals I mean explicit values like *1 2 3 *or *(1 2) 'abc' *or *42*
as opposed to
values returned by functions or by referencing variablea.
In IBM APL2 and in GNU APL, the right operand of a dyadic operator (like
*⍤*) binds
stronger than vector notation. Therefore an _expression_ like:
*A f ⍤ 1 2 3 B*
is supposed to be computed as:
*A (f ⍤ 1) (2 3 B)*
which may surprise many of those that are familiar with APL. On the
other hand,
*j←1 2 3**
**A f ⍤ **j**B**
*
that is, using variable *j* instead of literal *1 2 3* directly, gives
the (different) result that was apparently
intended in the examples of the ISO standard, That is why I believe that
literals (like *1 2 3*) in the context
of *⍤* are dangerous and do often not produce the intended result.
/// Jürgen
On 02/07/2016 08:32 PM,
address@hidden 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 <
address@hidden
> <
mailto:address@hidden>>
> Date: Sun, February 07, 2016 5:27 am
> To:
address@hidden <
mailto:address@hidden>,
>
address@hidden <
mailto: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
>
>
>
> On 02/06/2016 05:17 PM,
address@hidden 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
>