[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: behavior of arrays
David Kastrup wrote:
> Jack Saba <firstname.lastname@example.org> writes:
> > But more often than not, I WANT the extra dimension to be lost,
> > or at least I want IDL to be willing to ignore it where appropriate.
> > Consider this unrealistic example that nevertheless illustrates a
> > problem that occurs all too often in IDL:
> > IDL> x=findgen(100)
> > IDL> ijk=where(x eq 10)
> > IDL> for i=ijk,99 do print, i
> > % Expression must be a scalar in this context: I.
> > % Execution halted at: $MAIN$
> > I could have written i=ijk,99, or i=REFORM(ijk),99 to avoid the
> > error. But it shouldn't be necessary -- this should be handled
> > transparently.
Fact is, there are too many situations where it is *not* handled
transparently, and there are situations when you want extra dimensions
to stick around. For example, when we planned our 3D model output
analysis tool, the first thought was to store all data in 4 dimensional
arrays, signifying x,y,z, and time. But as soon as you extract something
out of these cubes, you loose one dimension, and with IDL that really
means "loose" so that you don't know any longer whether you have an
x,z,t array or an x,y,z array. I know one can "think different" and come
up with a working mechanism (we did), but still I sometimes regard this
"transparency" issue as quite annoying. But I agree, that at least the
IF statement should be able to recognize a 1-element array by itself.
> It is handled transparently. If you want a scalar, write ijk.
> This works even where ijk is *indeed* a scalar.
> This is, BTW, about the only way to check for the result of "where" in a
> useful way:
> w = where(x)
> if (w lt 0)
well, not the *only* way. You can also test
w = where(x,count)
if (count eq 0) then ...
Martin Schultz, DEAS, Harvard University, 29 Oxford St., Pierce 109,
Cambridge, MA 02138 phone (617) 496 8318 fax (617) 495 4551
e-mail email@example.com web http://www-as/people/staff/mgs/