bug-apl
[Top][All Lists]

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

 From: Xiao-Yong Jin Subject: Re: [Bug-apl] jot dot jot dot? Date: Tue, 28 Jun 2016 11:20:15 -0500

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

```