bug-apl
[Top][All Lists]
Advanced

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

Re: APL2 code no longer works


From: Dr . Jürgen Sauermann
Subject: Re: APL2 code no longer works
Date: Tue, 22 Mar 2022 13:16:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

Hi Blake,

thanks, see below,

Best Rgeads,
Jürgen


On 3/21/22 8:41 PM, Blake McBride wrote:
Greetings,

I wrote the following APL1 code a long time ago.

    ∇
[0]   r←d Parse v
[1]  ⍝ Convert vector v into a matrix breaking at delimiter d
[2]   r←(((0≠⍴v)×⍴r),⌈/r)⍴(,r∘.≥⍳⌈/r←¯1+(r,1+⍴v)-0,r←r/⍳⍴v)\(~r←v∈d)/v←,v
    ∇

It worked in 1981 and it works now.

I believe at some point someone on this list re-wrote the above in GNU APL (APL2) as follows:

    ∇
[0]   r←d Parse2 v
[1]  ⍝ break up vector v according to delimiter d into seperate arrays
[2]   r←1↓1↓¨(1++\r∊d)⊂r←(1↑d),(1↑d),v
    ∇

Interestingly, Parse2 used to work but doesn't anymore.  I suppose the APL2 logic in GNU APL has changed.  Two points:

1.  Can someone help me fix this?  (I don't know too much about APL2.)

Try ⊃Parse2 instead of Parse2:

      8 ⎕CR ',' Parse2 'One,Two,Three,Four'
┌→─────────────────────────┐
│┌→──┐ ┌→──┐ ┌→────┐ ┌→───┐│
││One│ │Two│ │Three│ │Four││
│└───┘ └───┘ └─────┘ └────┘│
└ϵ─────────────────────────┘
     
      8 ⎕CR ⊃ ',' Parse2 'One,Two,Three,Four'
┌→────┐
↓One  │
│Two  │
│Three│
│Four │
└─────┘

Or change Parse2[2] to:

[2]   r←⊃1↓1↓¨(1++\r∊d)⊂r←(1↑d),(1↑d),v

2.  How good is APL2 if it can morph like this?  (APL1 seems much more straightforward and consistent and less open to interpretation.)

I am pretty sure that this change was caused by a trouble report followed by a bug fix at some point in time.
The current behaviour of GNU APL looks OK to me (although I am not really an APL expert). My humble argument
would be that in order to get a not-nested result, the ⊂ in line 2 of Parse2 would require a matching ⊃.

Put differently, the original Parse2 was working around a bug in GNU APL which was fixed later on.

BTW, for long v, the following is probably more efficient:

[2] r←⊃1↓1↓¨(1++\r∊d)⊂r←(2/↑d),v

Thanks.

Blake McBride



reply via email to

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