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

[Juergen Sauermann]

Hi Louis,

except that APL2 requires that the second jot from the left binds to the dot at its left  and not,
as in your example, to dot at its right.

That is:

∘.∘.+ is ∘(.∘)(.+) according to the APL2 binding rules with (.∘) and (.+) being
monadic operators and then the normal parsing causes this to be executed from left to right.

/// Jürgen

On 06/29/2016 03:14 AM, Louis de Forcrand wrote:

The reason Dyalog is doing weird stuff with the jot is that it uses jot to bind left or right arguments (1 jot + = increment) AND for composition in its tacit style. It must have very complicated parsing rules.

What I would suggest is:
All operators have a long left scope, except jot dot, which takes as its right (and only) argument the whole chain of jots and dots to its right up to and including the first function:

jot dot jot dot jot dot + / each
would parse as
((jot dot (jot dot ( jot dot +))) /) each

This would produce maximum compatibility, since (jot dot jot) doesn't mean anything according to the standard anyway, and APL2 clearly states that
jot dot + / 
is
(jot dot +)/
not
jot dot (+/) .

Louis

On 28 Jun 2016, at 18:20, Xiao-Yong Jin <address@hidden> wrote:

I agree that in terms of the . operator, f.g.h should parse as (f.g).h.  It seems more logical to treat ∘ as a function so ∘.∘.f parse as (∘.∘).f too, but perhaps APL2 is doing something special with ∘. as one operator?

Here is a session with Dyalog,
     ⎕ML←2
     ⍝ Some high dimensional mind twist
     (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3
 3.00060006J30.0060006 2.00080012J20.0080012
     (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3
 3.00060006J30.0060006 2.00080012J20.0080012
     (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3
 3.0006J30.006 6.0006J60.006
     ⍝ ∘.∘ completely baffled me
     1∘.∘.+2
3
     1∘.∘.+2 3
SYNTAX ERROR: The function does not take a left argument
     1∘.∘.+2 3
    ∧
     ∘.∘.+2 3
SYNTAX ERROR: The function requires a left argument
     ∘.∘.+2 3
    ∧

Unfortunately, gnu apl fails at this f.g.h fun
     (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
                              ^     ^
     )reset
     (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
                              ^     ^
     )reset
     (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
                              ^     ^

Best,
Xiao-Yong

On Jun 28, 2016, at 10:26 AM, Louis de Forcrand <address@hidden> wrote:

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