bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] jot dot jot dot?


From: Jay Foad
Subject: Re: [Bug-apl] jot dot jot dot?
Date: Wed, 29 Jun 2016 09:33:50 +0100

Can you explain what cases you have fixed? All the cases I showed seemed to working correctly already in GNU APL.

Thanks,
Jay.

On 28 June 2016 at 19:09, Juergen Sauermann <address@hidden> wrote:
Hi,

thanks, fixed in SVN 620.

/// Jürgen


On 06/28/2016 01:23 PM, Jay Foad wrote:
The APL2 manual (p35) says "The right operand of a dyadic operator is the function or array to its immediate right." This is their way of saying that operator expressions are left-associative. For example, in ∘.∘.+ the right operand of the leftmost dot is ∘ (not ∘.+); so ∘.∘.+ is parsed as (∘.∘).+

The fact that operator-operand expressions are left-associative while function-array expressions are right-associative is one of the beautiful symmetries of APL!

Some more examples demonstrating the left-associativity of operator expressions:

      ≡⊂⍣4⍣6⊢'hello'
25
      ≡(⊂⍣4)⍣6⊢'hello'
25
      ≡⊂⍣(4⍣6)⊢'hello'
DOMAIN ERROR

      ⎕FX'R←(F L G)Y' 'R←F Y'
L
      ⎕FX'R←(F R G)Y' 'R←G Y'
R
      + L × R - 33
¯33
      (+ L ×) R - 33
¯33
      + L (× R -) 33
33

Jay.

On 27 June 2016 at 12:37, Juergen Sauermann <address@hidden> wrote:
Hi,

not sure. First of all, both IBM APL2 and GNU APL return the same result in Alex's  example:

      5 ∘.∘.+ 9
14
      5 (∘.∘).+ 9
14
      5 ∘.(∘.+) 9
14

Then the IBM language reference says this (p. 35):

"For example, the function _expression_ +.×/ is a reduction by a +.×   inner product
because the × binds as right operand to the array product operator (. ), and not as
left operand to the slash operator (/). The + binds as left operand to the dot; then
the resulting product binds to the slash as its left operand.

+.×/  ←→ (+.× )/ not + .(× /)
"

However, the binding strength resolves the ambiguity in the IBM example only
because / is not a dyadic operator. In Alex's example the operator is dyadic, and one
could either bind the middle ∘ to the left ∘ or the + to the middle ∘ without violating
the binding strengths. In this case I would argue that the "basic APL2 evaluation rule"
should be applied because ∘.+ can be evaluated (yielding a derived function) because all arguments
of . are available before the . and ∘ on the left show up.
 
What is missing in both the ISO standard and in the APL2 language reference is a
statement about left-to-right or right-to-left associativity of APL operators. I personally
would find it counter-intuitive if functions are evaluated left-to-right while operators are
evaluated right-to-left.

/// Jürgen


On 06/27/2016 11:48 AM, Jay Foad wrote:
So it looks like GNU APL parses ∘.∘.+ as ∘.(∘.+).

IBM APL2 and Dyalog appear to parse it as (∘.∘).+.

Jay.

On 15 June 2016 at 04:05, Xiao-Yong Jin <address@hidden> wrote:
Hi Alex,

It is correct.  You need nested vectors to see the effect.

Try the following.

      (⊂[2]2 3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺,'I',⍵}⍵⊣⎕←⍺,'O',⍵}(⊂[2]10×2 3⍴⍳6)

Best,
Xiao-Yong

> On Jun 14, 2016, at 6:39 PM, Alex Weiner <address@hidden> wrote:
>
> Hi Bug-APL,
>
> Surely this is not correct:
>
>      5∘.∘.+9
> 14
>
>
> I would expect a syntax error.
> If this is valid, then I stand corrected
>
> -Alex
>








reply via email to

[Prev in Thread] Current Thread [Next in Thread]