Non-existent wave[%dimensionLabel] calls should throw an error
patg
Sun, 04/18/2010 - 12:52 am
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.
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
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
orsetIgorOption
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
April 19, 2010 at 07:44 am - Permalink
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
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:
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
August 1, 2010 at 06:58 am - Permalink
I can not tell a lie - Larry did it :)
August 1, 2010 at 01:52 pm - Permalink
Thanks then to Larry (and WM collectively!).
August 1, 2010 at 10:39 pm - Permalink