Re: Re: [Q] multidimensional array?

[Jonathan King]

Joao Cardoso wrote:
>(Ted Harding) wrote:
>> On 24-Mar-99 Jae-Hoon Jeong wrote:
>> > Hello.
>> > Is it possible using mutidimensional array more than 2
>> > in octave?
>> 
>> Although it is not possible to do it directly, in the form A(i,j,k), it
>> can be simulated by computing an index into a linear array stored in a
>> structure:

OK, so who *else* has tried to re-invent the wheel this way? :-)

>> octave:11> A.ndim = 3;
>> octave:12> A.dims = [3 2 4];
>> octave:13> A.elems = ...
>> >  [111 112 113 114 121 122 123 124 \
>> >   211 212 213 214 221 222 223 224 \
>> >   311 312 312 314 321 322 323 324 ];

Hmm...I think matlab would order the dimensions differently,
but that's not important for the moment.

>> octave:14> function y = elem(A,i,j,k)
>> > y = A.elems(k + A.dims(3)*(j-1) + A.dims(3)*A.dims(2)*(i-1));
>> > endfunction
>> octave:15> elem(A,1,2,3)
>> ans = 123
>>
>> octave:16> elem(A,2,2,4)
>> ans = 224

Another thing to do here is use the fact that function call syntax
and array indexing syntax look very similar, and wrap a function
around your structure like this:

octave:18> _A_.ndims=3;
octave:19> _A_.dims=[3,2,4];
octave:20> _A_.elems= # What you had...
octave:21> global _A_;
octave:22> function y= A(x,y,z)
> global _A_;
> y = _A_.elems(z + _A_.dims(3)*(y-1) + _A_.dims(3)*_A_.dims(2)*(x-1));
> end;

octave:23> A(3,2,4)
ans = 324

And you can even take slices:

octave:24> A(1:3,2,1)
ans =
  121  221  321

Trust me that you could also re-write my function A to return slices
as 2-d matrices (or lists of 2-d matrices), and other cool stuff.

I was thrilled with this kind of trick until I realized that this is
about as far as you can go before you run right up against the
following two problems.

The first problem is that you'd really like to assign to your
hand-made multidimensional matrix, but that's painful, since
functions aren't lvalues:

A(3,2,4) = 0;  # Bzzt!
B = A;         # This could be made to do something by tweaking your
               # definition of A, but B(3,2,4) would then be 
               # meaningless since B wouldn't be a function.

The second problem is that your home-made m-d arrays can't interact
with standard operators.  A+B = zilch.  You could actually view the first
problem as a particular instance of this one: if you could overload
() and = for the home-made m-d array type, then you could do almost
anything with them that you can currently do with built-in types.

It would also mean that the next time somebody wanted to add Smith's
Wacko Tree Structures to Octave, you could tell them to roll their
own, and they might actually be able to do it.

>I rather use lists:
>
>a=list(rand(3),eye(3),ones(3))
>nth(a,1)(3,2)
>sum(nth(a,1)(3,:))

Last I checked, the implementation of arrays as lists of lists (of
lists...) was a religious issue.  Note that you could also spiff up
the interface to this using my function hack, but you'd still be
in pain when it came to assignments or using operators the way you'd
really like to.

(Also, at the moment, there are some issues with directly assigning
into a list, but I think those are pretty easily solved.)

I didn't used to think this, but it seems pretty clear to me now
that the most important feature introduced in Matlab 5 was the
operator overloading stuff, since it makes structures and lists
(think one-d "cell arrays") vastly more useful than they currently
are in Octave.

Consider: most of the people on this list could code up
multidimensional arrays, sets, all kinds of tree structures, almost
all of the stuff on the new datatypes wishlist and more if they
could just bang out m-files to do this.  Right now, as I understand
it, you have to drop down to C++ to define your own types, which
apparently means that nobody much ever gets around to it.

In addition to Matlab, I know that Python provides
operator-overloading and user defined types pretty nicely.  Perl can
do this too, although it's not very pretty even by Perl's standards.

A truly stunning paper making this particular argument quite forcefully
is Guy Steele's "Growing a Language", which is available at:

http://cm.bell-labs.com/cm/cs/who/wadler/oopsla.ps

and probably other places.  The more I think about this, the more
obvious it becomes.  Sigh.  There are days when I wish I really knew
C++...

jking