[Top][All Lists]

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

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

From: Juergen Sauermann
Subject: Re: [Bug-apl] jot dot jot dot?
Date: Tue, 28 Jun 2016 20:09:18 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0


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:


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


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

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

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

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 (∘.∘).+.


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)


> 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]