Re: Turning function return into array & subscripting (Was: Re: rotating 3d array: help for the braindead!)

[chase(at)retro.jhuapl.edu (Chris Chase S1A)]

Fergus> It's not in the IDL manuals either (at least, not in any obviuos place)
Fergus> - I discovered it by accident.

I stumbled across this from my interpretation of "Appendix A. Syntax
of IDL" in the "IDL User's Guide" for version 2.0.  The syntax
definition is no longer included in the IDL manuals.  I suppose that
means that we should not rely on specific behaviour from the syntax
definition because IDL's specific syntax may change or be augmented.

>From the syntax description I also found that "(assignment statement)"
is considered an expression.  This means that one can produce side
effects similar to those that are used quite often in C.  For example,
one can do the following:

c = 1
if ((c = c+1)) eq 2 then print,'side effect'
print,c

The double parentheses are required because of a quirk in the syntax.

I never actually use this in a program since I expect that the
specific IDL beyond the natural syntax may be modified.

Some of my ramblings about allowed syntax:

I wish IDL allowed expressions which are of structure type to have
structure references analogous to (size(image))(1:3).  For example, if
foo() was a function returning a structure with field bar I would like
to enter: 

print,foo().bar

or, like the size() example,

print,(foo()).bar

It would also be nice if associated file variables acted exactly like
arrays. For example, if d is an associated file:

openr,1,'test.dat'
d=assoc(1,intarr(5,50))
help,d
D INT = File< 'test.dat'> Array(5, 50)

Then the following are valid:

z = d(0) ; 5x50 array
z = d(0,1,2) ; a scalar

But it would be better if they behaved like arrays, i.e.,:

z = d(0) ; a scalar from the first array in the file, d(0,0,0)
z = d(0:2) ; a size 3 vector
z = d(0:3,*,1:2) ; size 4x50x2
z = d(1:2,3:5,0).bar ; Should be a 2x3 array of type bar if the file
contained arrays of structures instead of integers.

But then things like n_elements() and size would not work like arrays
(unless the file size was checked to compute the last dimension).

If the above expressions were valid (although they could be very
inefficient), then the use of associated file variables would be
exactly like array/structures - making associated file variables a
transparent data type that looks like any other in IDL.  They could be
passed to any procedure/function and operated on as if they were an
array/structure.  As it is I have to write special purpose versions of
my programs when I want to use associated file variables.

I think associated file variables are a fantastic idea for dealing
with files that are too big to fit in memory all at once.  They would
be even better if they worked transparently like arrays, making
disk-based data versus in-core data equivalent from the user's
perspective (except for speed).

Just my two cents worth.

I have a number of these type of IDL suggestions/concerns that are of
the class that would make IDL more consistent.  RSI seems to be good
about implementing reasonable suggestions that don't require an
overhaul.  They have done so in the past.

Later,
Chris
--
===============================
Bldg 24-E188
The Applied Physics Laboratory
The Johns Hopkins University
Laurel, MD 20723-6099
(301)953-6000 x8529
chris.chase@jhuapl.edu