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 !
Post Reply
gil
Posts: 72
Joined: Mon Feb 15, 2010 12:42 am

Partitioned enclose post 17.1

Post by gil »

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?
User avatar
Phil Last
Posts: 628
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Partitioned enclose post 17.1

Post by Phil Last »

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!
paulmansour
Posts: 431
Joined: Fri Oct 03, 2008 4:14 pm

Re: Partitioned enclose post 17.1

Post by paulmansour »

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!
User avatar
Morten|Dyalog
Posts: 460
Joined: Tue Sep 09, 2008 3:52 pm

Re: Partitioned enclose post 17.1

Post by Morten|Dyalog »

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: 460
Joined: Tue Sep 09, 2008 3:52 pm

Re: Partitioned enclose post 17.1

Post by Morten|Dyalog »

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: 460
Joined: Tue Sep 09, 2008 3:52 pm

Re: Partitioned enclose post 17.1

Post by Morten|Dyalog »

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,⍺)⊂⍵}
gil
Posts: 72
Joined: Mon Feb 15, 2010 12:42 am

Re: Partitioned enclose post 17.1

Post by gil »

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.
User avatar
Phil Last
Posts: 628
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Partitioned enclose post 17.1

Post by Phil Last »

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: 628
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Partitioned enclose post 17.1

Post by Phil Last »

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.
Post Reply