Partitioned enclose post 17.1

APL-related discussions - a stream of APL consciousness.
Not sure where to start a discussion ? Here's the place to be
Forum rules
This forum is for discussing APL-related issues. If you think that the subject is off-topic, then the Chat forum is probably a better place for your thoughts !

Partitioned enclose post 17.1

Postby gil on Thu Sep 23, 2021 9:17 am

Partitioned enclose was extended with version 18.0 to accept a wider range in the left argument. In previous versions it is limited to a boolean scalar or boolean vector matching the length of the right argument. With 18.0 it now accepts a non-negative scalar number or a vector with length up to 1+≢Y (it is extended to ≢Y if shorter).

I have mixed feelings about this. I like the possibilities it offers, but on the other hand it can cause issues if you rely on the old behavior (expect DOMAIN or LENGTH errors to be signaled).

It was probably announced loud and clear and I just missed the news, but it came as a surprise when I found out from a colleague (who thought APL was broken).

How do you feel about this feature and what are the strong arguments for this extension?
gil
 
Posts: 71
Joined: Mon Feb 15, 2010 12:42 am

Re: Partitioned enclose post 17.1

Postby Phil Last on Thu Sep 23, 2021 2:35 pm

My thought when the discussion was in progress was that here we have a function with clear domains, an obvious relation between them and the result and simple well known transformations from other domains to get to the boolean argument - and a mixed bag of unusual requirements that could possibly be shoe-horned into it if we radically change both the domain and structure of the arguments.
What's to lose?
Lets go for it!
User avatar
Phil Last
 
Posts: 624
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Partitioned enclose post 17.1

Postby paulmansour on Mon Sep 27, 2021 6:05 pm

I'm with Phil I think, but I don't have enough experience to say on this particular primitive extension. I will say that in general it's a very fine line when overloading functionality between making things better and just making things more complicated. I'm probably not the sharpest tool in the shed, but if have to go to the documentation every time I use a primitive, maybe there is something wrong with it. This is why I'm not a big fan of key or at. Of course, it took me at least 10 years before I understood why someone would need a user defined operator, so I may well be wrong!
paulmansour
 
Posts: 418
Joined: Fri Oct 03, 2008 4:14 pm

Re: Partitioned enclose post 17.1

Postby Morten|Dyalog on Tue Sep 28, 2021 7:54 am

gil wrote:... it can cause issues if you rely on the old behavior (expect DOMAIN or LENGTH errors to be signaled).


Quite apart from the discussion about this particular extension, relying on a primitive to signal a very specific error is an VERY questionable technique. It is a time honoured tradition to extend APL by replacing in particular DOMAIN and LENGTH errors with new behaviour (complex numbers, decimal numbers, short left arguments to take and drop, etc).
User avatar
Morten|Dyalog
 
Posts: 451
Joined: Tue Sep 09, 2008 3:52 pm

Re: Partitioned enclose post 17.1

Postby Morten|Dyalog on Tue Sep 28, 2021 8:26 am

gil wrote:what are the strong arguments for this extension?

In my mind, the main motivation for the extension is that it provides an elegant way to deal with zero length partitions, something that has eluded us for decades. It works together with "where inverse", which converts a vector of starting points into a suitable left argument for partitioned enclose:

Code: Select all
      data←⍳9
      plen←3 4 0 2 ⍝ Partition lengths
      ⎕←+\¯1↓1,plen  ⍝ Where does each partition begin?
1 4 8 8
      ⍸⍣¯1 +\ ¯1↓1,plen ⍝ Where Inverse: 2 means two partitions "start here"
1 0 0 1 0 0 0 2
      part←{(⍸⍣¯1+\¯1↓1,⍺)⊂⍵}
      lengths part data
┌─────┬───────┬┬───┐
│1 2 3│4 5 6 7││8 9│
└─────┴───────┴┴───┘

If we did not allow a short left argument, you would need to copy the partition vector to pad it, using (⍴data)↑... on the left. And since the partition vector only shows where partitions begin, trailing zeros *are* superfluous.
User avatar
Morten|Dyalog
 
Posts: 451
Joined: Tue Sep 09, 2008 3:52 pm

Re: Partitioned enclose post 17.1

Postby Morten|Dyalog on Tue Sep 28, 2021 8:38 am

P.S. Apologies for the origin-1 specific solution. Replace 1 by 0 in the definition of part, or ⎕IO if you want an origin-independent solution:

Code: Select all
      part←{(⍸⍣¯1+\¯1↓⎕IO,⍺)⊂⍵}
User avatar
Morten|Dyalog
 
Posts: 451
Joined: Tue Sep 09, 2008 3:52 pm

Re: Partitioned enclose post 17.1

Postby gil on Tue Sep 28, 2021 8:53 am

Thanks for the explanation Morten, and for highlighting the (undocumented?) extension to the where primitive.

      ⍸⍣1⊢,3
1 1 1
⍸⍣2⊢,3
1 2 3
⍸⍣3⊢,3
1 2 2 3 3 3
⍸⍣4⊢,3
1 2 2 3 3 4 4 4 5 5 5 6 6 6
⍸⍣¯1⊢⍸⍣4⊢,3
1 2 2 3 3 3
⍸⍣¯2⊢⍸⍣4⊢,3
1 2 3
⍸⍣¯3⊢⍸⍣4⊢,3
1 1 1
⍸⍣¯4⊢⍸⍣4⊢,3
3
⍴⍸⍣¯4⊢⍸⍣4⊢,3
1


I'll need to explore this a little bit I think.
gil
 
Posts: 71
Joined: Mon Feb 15, 2010 12:42 am

Re: Partitioned enclose post 17.1

Postby Phil Last on Tue Sep 28, 2021 1:27 pm

Gil

Given
      ∇ii←{
[1] (,⍵)/,⍳⍴⍵ ⍝ ⍸ ⍵
[2] }

∇iiu←{
[1] (⍴z)⍴((,z←⍳+1-⎕IO-⊃⌈/⍵)∊⍵)\{≢⍵}⌸⍨,⍵ ⍝ ⍸⍣¯1⊢⍵
[2] }
that I believe cover most cases I think you'll see that if there's been a change it's rather the removal of a shortcoming than an extension.
      iiu⍣0⊢ii⍣1⊢,3
1 1 1
iiu⍣0⊢ii⍣2⊢,3
1 2 3
iiu⍣0⊢ii⍣3⊢,3
1 2 2 3 3 3
iiu⍣0⊢ii⍣4⊢,3
1 2 2 3 3 4 4 4 5 5 5 6 6 6
iiu⍣1⊢ii⍣4⊢,3
1 2 2 3 3 3
iiu⍣2⊢ii⍣4⊢,3
1 2 3
iiu⍣3⊢ii⍣4⊢,3
1 1 1
iiu⍣4⊢ii⍣4⊢,3
3
User avatar
Phil Last
 
Posts: 624
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Partitioned enclose post 17.1

Postby Phil Last on Tue Sep 28, 2021 1:41 pm

But back to the main issue the addition or otherwise of (⍴z)⍴(z←... to an expression or any of the other end corrections that we require - for instance with n-wise reduction, or Morten's ¯1↓1, that he needed in his part function - I believe to be insufficient reason to break the time-honoured tradition of scalar conformity. And no - short left arguments to take and drop do not constitute an infringement of scalar conformity.
User avatar
Phil Last
 
Posts: 624
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex


Return to APL Chat

Who is online

Users browsing this forum: No registered users and 1 guest