I have come across the following annoying "feature" of IDL through
a programming project: If you type e.g.,
IDL> HELP, fltarr(10,1,1) ; you get:
<Expression> FLOAT = Array(10)
But if you say
IDL> HELP, fltarr(1,1,10) ; you get:
<Expression> FLOAT = Array(1, 1, 10)
In our applications, it matters that the data arrays retain the
correct number of dimensions, as we have e.g., axis names for each
dimension. The above behaviour is clearly inconsistent, and IDL
is definitely doing something that is not intuitively obvious,
nor is it desirable at all times.
The behaviour I would like is:
Whenever I create an array with so and so many dimensions
(singular as well..), I'd like it to stay that way, until explicitly
told otherwise.
When I'm indexing an array with a scalar, I'd like the dimension to
disappear ("reformed away"), e.g.:
IDL> a=fltarr(10,10)
IDL> help,a(1,1)
<Expression> FLOAT = 0.00000
This is OK, and it's what happens with today's version, but if I do
the following:
IDL> help,a(1,*)
<Expression> FLOAT = Array(1, 10)
or, to make the example complete, we try:
IDL> help,a(*,1)
<Expression> FLOAT = Array(10)
Here I would have liked both expressions (a(1,*) and a(*,1)) to
return the same thing (an Array(10)). I'd still like to be able to
retain a singular dimension by indexing with an array, e.g.:
IDL> help,a(*,[1])
<Expression> FLOAT = Array(10, 1)
So, to sum up: Arrays stay unaltered until otherwise is specified.
Dimensions disappear when indexed with a scalar value, but remain
when indexed with an array (even a single-element one).
In order to make these changes go through with RSI, I'd like to
hear (in this newsgroup) from as many as possible. Of course, if
anyone has large sets of procedures that are tuned directly to
today's behaviour, they are welcome to raise their voice, but
I would argue that their programs would be better off rewritten
with a logical behaviour instead of sneaking dimensions out the
back door.
Sincerely,
Stein Vidar H. Haugan
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
