Non-existent wave[%dimensionLabel] calls should throw an error

Share icon

I would like to see a change in behaviour of the use of dimension labels in wave elements. It makes no sense to call up a wave element by dimension label and have it silently default to element 0, because the dimension label has been misspelled, or never assigned. This is different from the numerical indexing where it can be quite useful to have the index clipped to legal values.
Regards,
Patrick.
This is something that could be argued either way, but changing the current behavior might break the code of a lot of our users, so is probably not going to happen.

When I write code using dimension labels and I'm not certain that the dimension label will exist, I first call FindDimLabel to get the column (or row, layer, or chunk) number with a certain label. I test that the returned value is non-negative, and I then use that numeric variable as the index for wave assignment or reading.

One caveat of using the above method is that dimension labels do not have to be unique. If, for example, you have two columns with the same dimension label, FindDimLabel returns the greatest index number with that dimension label. So if you have a 2 column wave and both column dimension labels are "aa", FindDimLabel will return 1.

April 18, 2010 at 09:57 am - Permalink

I don't see how code that tries to access non-existent dimension labels isn't already broken. I stress the difference between the behaviour of the numerical indices, where there are clearly two reasonable options and you can (and I do) exploit whichever choice WM made back in Igor 1.0. findDimLabel() is great at transferring dimLabels to numerical indices, but is actually a kludge if you are merely ascertaining the validity of a dimension label that you were trying to access anyway: the program should do that.

If there were reasonable grounds to maintain the default-to-element-zero behaviour, there are many precedents with #pragma or setIgorOption for similar changed functionality.

I take Adam's point about the wrinkle of having multiple identical dimension labels, but this is not something a programmer should do if using the dimension labels for access purposes. (It is of course fine for presentation in a table, for instance.)

Regards,

April 18, 2010 at 11:26 pm - Permalink

I would argue that there is no difference in "broken-ness" as both myWave[-1] and myWave[%invalidDimLabel] actually evaluate to myWave[0]. Adding a new #pragma under which using a non-existent dimension label is probably possible, but I don't see that becoming the default behavior. I could be wrong, but my guess is that when dimension labels were first created, they weren't meant to be used to make waves into something like an associative array.

April 19, 2010 at 07:44 am - Permalink

I am mulling this over.

I may include this along with the #pragma rtGlobals= 3 setting since that is part of 6.2 and has not been released yet.

It is a bit tricky because that would be a compile-time change, not just a runtime check that could be done with a SetIgorOption. But it has the advantage of affecting only new code.

April 19, 2010 at 09:54 am - Permalink

I have in fact implemented this checking for code compiled under rtGlobals=3.

One thing led to another and I added extensive out of bounds index checking also. After we do some more in-house testing, I plan on providing beta of this version.

The following example should illustrate this change:
Function badfoo()
    Make/O big=x
    Make/O/N=10 small

    variable v1=1000, v2= 7, v3
   
    // Each of these lines should cause an error at runtime under rtGlobals=3
    big= small
    v3= big[%row1]
    v3= big[v1]
    v3= big[1000]
    big[v2]= small[v1]
    big[v1]= small[v2]
    big[v1][1]= 1
    big[v1]= v2
end

April 26, 2010 at 09:27 am - Permalink

I have given the rtGlobals=3 a working over and it performs flawlessly for missing dimension labels. When programming with known labels this improves the debugging of code greatly, and cleans the program of dimension label checking, while still alerting, at testing time, any problems with typos, etc. It makes using unordered lists a breeze. Thanks to Howard for adding this great choice.

August 1, 2010 at 06:58 am - Permalink

Quote:
Thanks to Howard for adding this great choice.

I can not tell a lie - Larry did it :)

August 1, 2010 at 01:52 pm - Permalink

Given Larry's name in big blue letters just above my post, my only feeble excuse is reading a separate Howard post at the time...
Thanks then to Larry (and WM collectively!).

August 1, 2010 at 10:39 pm - Permalink