bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Operator binding


From: Hans-Peter Sorge
Subject: Re: Fwd: Operator binding
Date: Fri, 4 Dec 2020 01:06:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

Hi Jürgen,

amazing - thank you.

I thought I asked because you were just a moment away from the code:-)

Best Regards
Hans-Peter

Am 03.12.20 um 18:45 schrieb Dr. Jürgen Sauermann:
Hi Hans-Peter,

some of the simple answers below (I am not an experienced APL programmer,
therefore I can't answer the tricky ones).

Best Regards,
Jürgen


On 12/3/20 2:26 PM, Hans-Peter Sorge wrote:
Sorry, did not hit the mailing list...

Hi,

frankly I try to find out what it does...

       4/2 2⍴⍳4
1 1 1 1 2 2 2 2
3 3 3 3 4 4 4 4

basically replicates the last column
       4//2 2⍴⍳4
 2 2 2 2  4 4 4 4

But how do I get to.
 1 1 1 1  2 2 2 2
      4/ 1 0 ⌿2 2⍴⍳4   ⍝ simple
1 1 1 1 2 2 2 2

      4/¯ 1 0 ⌿2 2⍴⍳4  ⍝ nested
 
1 1 1 1  2 2 2 2
or
 1 1 1 1  3 3 3 3
or
      4/ ,1 0 /2 2⍴⍳4   ⍝ simple
1 1 1 1 3 3 3 3
      4/¨ ,1 0 /2 2⍴⍳4  ⍝ nested
 1 1 1 1  3 3 3 3
 3 3 3 3  4 4 4 4
???

      4/ 0 1 ⌿2 2⍴⍳4   ⍝ simple
3 3 3 3 4 4 4 4
      4/¨ 0 1 ⌿2 2⍴⍳4  ⍝ nested
 
3 3 3 3  4 4 4 4

and why is  (n*n-1) = ⍴1⊃n//(n,n)⍴⍳n*2  ? ⍝ n ← 2 ....
e.g.
      n←5
      n/(n,n)⍴⍳n*2
 1  1  1  1  1  2  2  2  2  2  3  3  3  3  3  4  4  4  4  4  5  5  5  5  5
 6  6  6  6  6  7  7  7  7  7  8  8  8  8  8  9  9  9  9  9 10 10 10 10 10
11 11 11 11 11 12 12 12 12 12 13 13 13 13 13 14 14 14 14 14 15 15 15 15 15
16 16 16 16 16 17 17 17 17 17 18 18 18 18 18 19 19 19 19 19 20 20 20 20 20
21 21 21 21 21 22 22 22 22 22 23 23 23 23 23 24 24 24 24 24 25 25 25 25 25

      n//(n,n)⍴⍳n*2 ⍝ could be
 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 ....
   but it is
 625¨⍴5 10 15 20 25    


Just asking ..:-)

Best Regards
Hans-Peter


Am 02.12.20 um 17:27 schrieb Dr. Jürgen Sauermann:
Hi,

in following up the recent email discussions with Jay Foad and Hans-Peter Sorge,
I have changed the operator-to-operator binding in GNU APL. SVN 1367.

Before the change an _expression_ with 2 adjacent operators,
for example
2 / / 3 4⍴5, would have given this:

     B←3 4⍴5
     2 / / B
 5 5 5 5 5  5 5 5 5 5  5 5 5 5 5·
 5 5 5 5 5  5 5 5 5 5  5 5 5 5 5·
 5 5 5 5 5  5 5 5 5 5  5 5 5 5 5·

GNU APL would have bound the left / to the right / and evaluation
the _expression_ with:

* the left / being function compress, and
* the right / being operator reduce with function compress as left operand.

After the change the same _expression_ now evaluates to:

           B←3 4⍴5
           2 / / B
 5 5 5 5 5 5 5 5  5 5 5 5 5 5 5 5  5 5 5 5 5 5 5 5

GNU APL now binds 2 to / as discussed earlier. This creates a derived function,
say TWICE, like:

∇ Z←A TWICE B
  ⍝ A not used
  Z←2 / B


and then reduces TWICE with B:

      TWICE / B
 5 5 5 5 5 5 5 5  5 5 5 5 5 5 5 5  5 5 5 5 5 5 5 5

Interestingly:

* as seen above, TWICE / B  and  2 / / B now give the same result in GNU APL,

* TWICE / B gives the same result in GNU APL and in IBM APL2,
  but:  2 / / B gives a DOMAIN ERROR in IBM APL2, and

* TWICE / B also give the same results in GNU APL and in Dyalog APL,
but  Dyalog APL gives a different result (apparently the same as  the old
GNU APL implementation) for 2 / / B (from tryapl.org):


      B←3 4 ⍴ 5 
      TWICE←{⍺ ⊢ 2/⍵}
      TWICE / B
┌───────────────┬───────────────┬───────────────┐
│5 5 5 5 5 5 5 5│5 5 5 5 5 5 5 5│5 5 5 5 5 5 5 5│
└───────────────┴───────────────┴───────────────┘
     
      2 / / B
┌─────────┬─────────┬─────────┐
│5 5 5 5 5│5 5 5 5 5│5 5 5 5 5│
├─────────┼─────────┼─────────┤
│5 5 5 5 5│5 5 5 5 5│5 5 5 5 5│
├─────────┼─────────┼─────────┤
│5 5 5 5 5│5 5 5 5 5│5 5 5 5 5│
└─────────┴─────────┴─────────┘

That suggest that the binding of operators is not very portable
between interpreters and one should not rely on them in the first
place. It seems to be more reliable bind explicitly as shown above
as to avoid unexpected surprises later on.

Best Regards,
Jürgen













reply via email to

[Prev in Thread] Current Thread [Next in Thread]