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

[Louis de Forcrand]

Operators are evaluated from left to right in Dyalog, NARS2000, and J at least. This seems logical:

+/{each} should parse as (+/){each}, not +(/{each}), and +/{rank}1 as (+/){rank}1, as "tacit" operators aren't supported in GNU APL or the standard (/{each} and /{rank}1 have no meaning).

The problem is that jot dot is not a usual operator since it is written to the left of its argument. I believe this is because it was originally perceived as similar to an inner product, but with no reduction, and jot was the "null function" (this comes from the original APL book). Inner products were written with the first function on top of the second, but to adapt this to terminals, a dot was instead placed between the two functions.

Thus °| became º.|

I would imagine jot dot should parse just like and inner product, except when the jot is read, an outer product is executed. So, as I see it (with * as times), °.°.* should parse as (°.°).*, just as +.*.* should parse as (+.*).* .

However, I don't see what (°.°) corresponds to.

It seems to me that APL2 parses it as 

°.(°.*) , in which case APL2 has some operators with a long left scope and others with a long right scope. Then you encounter problems such as °.*/; is that °.(*/) or (°.*)/ ?

My point is that I am almost sure that functions have a long right scope, and operators a long left scope; the exception here is jot dot, and I don't know what it has. To illustrate what Iverson thought, in J x (jot dot fun) y is written as x (fun/) y .

Louis

Sorry for the poor formatting!

On 27 Jun 2016, at 13: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
>