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

[Xiao-Yong Jin]

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