Hi Louis,
FYI NARS2000 overloads jot even more than Dyalog does: it is both a
composition operator (f∘g, A∘g, f∘B) and a general null operand for any
user-defined operator (not just dot).
I'm not convinced that it's a good idea to treat ∘. as a *monadic* operator
taking an operand on the *right*!
Jay.
On 29 June 2016 at 02:14, Louis de Forcrand <ol...@bluewin.ch> 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 <jinxiaoy...@gmail.com> 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 <ol...@bluewin.ch>
> 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 <
> juergen.sauerm...@t-online.de> 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 <jinxiaoy...@gmail.com>
> 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 <alexwei...@alexweiner.com>
> 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
> >
>
>
>
