Re: Octave 3.0

[Paul Kienzle]

Lippert, Ross A. wrote:

> I think it is important to separate those items which are on this list
> for the sake of MATLAB compatibility and those items on this list which
> are for the general improvement of the package.  For example, MATLAB's
> N-dimensional arrays are a convenient storage class, but they don't
> interface with the mathematical operations very well.  Many times people
> think they want an N-dimensional array because they are dealing with,
> say a 3D mesh, but I think one quickly finds that it is more worthwhile
> to keep these values in a 1D vector and the does 'reshape' as necessary.
reshape as currently implemented requires a matrix copy,
but that would be easy to fix.

There is something to be said for convenient data
structures, especially if it is convenient to operate
with slices.  The results are going to be more readable
than tricky indexing and reshaping operations.  It's
not clear to me that Matlab does the right thing --- not
while squeeze/reshape are required to transform a
slice using a matrix operation.

> * Maybe I am just shooting my mouth off, but is there anyone out there who
> makes any serious use of N-d arrays in their MATLAB work?
>
> ** On the other hand, if this is a move to further increase octave's .m
> compatability, then it is necessary, however awful.
>
> As for sparse matrices, I have gotten a lot of mileage out of a DLD function
> Paul Kienzle and I came up with called idxop which does the following:
>   y = idxop(idx,x,['sum'|'prod'|'max'|'min'])
> where idx is an index vector whose length is equal to the number of rows of x
> and the resulting y is essentially given by
>   y = zeros(max(idx),size(x,2))+[0|1|-inf|inf]
>   for i=1:size(x,1),
>      y(idx(i),:) = [plus|times|max|min] ( y(idx(i),:), x(i,:) )
>   endfor
> This single function allows for a variety of sparse operations to occur on
> regular vectors/matrices without the need for a sparse data structure.  The
> advantage of doing things in terms of sparse ops and not sparse data is that
> quite often the operations one wishes to perform are a mix of sparse and
> dense ops (e.g. you have a graph laplacian on a disconnected graph and you
> wish to form the dense laplacian for each graph component and take its
> eigenvalues).  It is my belief that in practise, one spends quite a bit
> of time doing 'sparse' and 'full' when using MATLAB sparse matrix functions
> just so they can do a sparse op on their data at some point in the compute.
>
> Again * and ** apply.
* applies until you can provide recipes for
common 3-D and sparse operations that
unsophisticated users can apply --- yes you
can program everything in machine code but
macro assemblers sure help a lot.  The octave
wiki is a good forum for doing this:
   http://www.scarymath.org/octave

** applies while there exists interesting
code on the web that you want to use
without having to rewrite.

> Private functions would be a nice way to clean up the ever growing octave
> namespace, whether MATLAB allows this currently or not.
Not enough I expect.  To get that you need something
like namespace support.

> MPI support would raise a lot of eyebrows.  It is something my PhD advisor
> was once trying to shoe-horn into a customized version of MATLAB, but with
> little support from the mathworks.  Such a feature would really differentiate
> octave.
Has anyone looked at the PVM project for scilab?