Re: n-dim arrays

[Daniel Heiserer]

address@hidden wrote:
> 
> When will octave handle n-dimensional arrays?  I would at least like to see
> three dimensions...
> 

Ups. You are not the first one.
If you are looking for bigger arrays you should think of more than
just data storage.

1) How do you define operations on that?
+/- ok, what about multiplication.
In fact you have something like tensors. You should 
then take care that the whole tensor calculus works
on n-dimensional stuff.

2) Sparsity. Even for 2d arrays this is very important request, but if
you
go for more dimensions this is a must, and it 
should be mentioned, that the braindead solution
for this approach is really braindead.
Matlab allows n-dimensional arrays, but they must be full.
Even if you have a big machine your core is full 
very soon.
So if you *REALLY* want n-dimensions (3 or more), it makes only
sense with a smart approach for sparse data.
And if you *really* want n-dimensions you probably
already work around something like a function
consisting of 3 parameters. For all that kind
of stuff I would recommend using hash-arrays
anyway. Multiple dimensional hashes, but hashes.



> Would this require a whole rewrite?

I don't know. I don't know the code so much.

I have some ohter things I am interested in as mentioned above.
If data-structures are going to change in octave I would do 
it in a whole rewrite for the data-structues to cover many things that
come up.

Currently octave keeps all in core, which is nice for
small problems and big machines. I have here problems
where I deal with really big matrices 1e6*1e6 (sparse of course).
I also have full matrices, which have the size of 6GB.
This is nothing what octave could handle with it's current
data-structure.
If you look at software packages, which can handle such
data, without having 5GB of main memory then you see a smart 
approach, which may be not perfect for an interactive tool like octave.
They have a database where they store everything. Nothing
is kept in core execept precompiled functions and 
1x1 "parameters". For a multiplication of a
A*B matrix they can get very efficently 
1 row from matrix A and 1 column from matrix B from the
database multiply it and store the result on the database,
then they take the next one.
If you look at the interactivity all the user really needs
is:
o       a plot
o       some small amount of data to look at
and that as fast as possible.
If you have a fast database, which can support direct
access to what you need I think that would be a fast 
enough approach for interactivity.

All the parsing stuff and language could remain.

What do others think about that?

daniel



---------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see www.che.wisc.edu/octave/giftform.html
Instructions for unsubscribing: www.che.wisc.edu/octave/archive.html
---------------------------------------------------------------------