"Correction to Index Generator"

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
User avatar
kai
Posts: 141
Joined: Thu Jun 18, 2009 5:10 pm
Location: Hillesheim / Germany

"Correction to Index Generator"

Post by kai »

The release notes of version 13.0 innocently note that the index generator has been corrected. In the past (prior 13.0) this happened:

⍳⍬
1

This is considered incorrect. In version 13.0 it changed:

⍳⍬

]display ⍳⍬
┌─────┐
│ ┌⊖┐ │
│ │0│ │
│ └~┘ │
└∊────┘
(⊂⍬)≡⍳⍬
1

So what?!

Well, the impact is dramatic! For example, the idiom {⍵/⍳⍴⍵} stops working correctly on scalars:

{⍵/⍳⍴⍵}1 ⍝ 12.1
1

{⍵/⍳⍴⍵}1 ⍝ 13.0

Those who believe the DRY principle ("Don't repeat yourself") is a good thing will change their "Where" utility and that's it (well, not quite), but in code that has grown over decades one is likely to have plenty of lines of code which implement this idiom in one way or another. They all need to be changed.

Note that the code only stops working when a scalar homes in. Therefore it may take quite a while until the problem makes an appearance. If the code immediately breaks consider yourself lucky since otherwise the program may carry on and break far away later, or not at all but produce wrong results.

And this is just the tip of the iceberg: of course it's not only the idiom that has become jeopardized: any statement with an ⍳ may suffer from this.

I am questioning whether it was a good idea to change this at all. There are no plusses as far as I am concerned. The drawbacks are apparent: any application needs to be checked carefully.

Another problem is that this got changed in 13.0 but not in prior versions. Why is that? Is it a good idea to establish incompatibilities between different versions? I doubt that, too. For example, I am currently dealing with 4 different versions of Dyalog on an almost daily basis; such differences make life not exactly easier.
User avatar
Phil Last
Posts: 628
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: "Correction to Index Generator"

Post by Phil Last »

Kai:
Well, the impact is dramatic! For example, the idiom {⍵/⍳⍴⍵} stops working correctly on scalars:

You mean it stops working incorrectly on scalars. If you want to include scalars add the comma:
      {⍵/⍳⍴,⍵}
I guess you don't want it to work on matrices.
Kai:
I am questioning whether it was a good idea to change this at all. There are no plusses as far as I am concerned.

I have a couple of functions that contain this fragment that I'll now be able to remove:
      {⊂⍬}⍣(0∊⍴⍴⍵)⍳⍴⍵
that corrects for the incapacity of indexing to apply to scalars that should have been removed when iota was enhanced to have monadic rank of 1 instead of 0 after which for any ⍵:
      ⍵≡⍵[⍳⍴⍵]
JohnS|Dyalog

Re: "Correction to Index Generator"

Post by JohnS|Dyalog »

You mean it stops working incorrectly on scalars.

Better yet, the change means that Kai's program now works correctly on scalars:

      wh←{⍵/⍳⍴⍵}           ⍝ where (indices of 1s)

wh 0 1 0 0 1 ⍝ where the 1s at?
2 5
{⍵[wh ⍵]} 0 1 0 0 1 ⍝ use [] to fish out the 1s
1 1
{⍵[wh ⍵]} 1 ⍝ works for a scalar
1

As Phil points out, we can now assert that

      ⍵≡⍵[⍳⍴⍵]

for any array ⍵.

I am questioning whether it was a good idea to change this at all.

I think we must be allowed to make corrections to the language. Otherwise, it becomes fossilised. In this and similar cases, we defer the change to a major release because we know that many of our clients run a thorough QA of their application code at this time. We felt that a change such as this could not be issued mid-release through the DSS system.

Another problem is that this got changed in 13.0 but not in prior versions.

I don't think we can do this for the above reason. At least making this change at a major version gives people the choice of when to adopt it. I think this policy is shared by many (most? (all?)) software products.

... but I feel your pain.

John.
Post Reply