RE: Octave 3.0

[Lippert, Ross A.]

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.

An implementor trying to create
support for N-d arrays finds himself able to support things like sum and
prod, and .*, and various .m files, once he makes some painful changes to
their interfaces, only to find that * can never be defined well (though
perhaps if one used the notion of tensorial contraction one could get
something cool -- last time I checked MATLAB did nothing, but maybe that
has changed).

* 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.

Private functions would be a nice way to clean up the ever growing octave
namespace, whether MATLAB allows this currently or not.

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.

An ABI for plotting isn't a bad idea at all.  Openning the door for a
gnuplot replacement would be wonderful.  Not that that isn't a mountain of
work to do.



-r

-----Original Message-----
From: John W. Eaton [mailto:address@hidden
Sent: Friday, February 21, 2003 8:48 PM
To: octave-maintainers mailing list
Subject: Octave 3.0


I'd like to try to come up with a list of must-have items for the next
major release of Octave, then we can start making sure that all those
items are done (not necessarily complete, but at least implemented
well enough to be usable).

My current top 10 list is, more or less in order of importance:

  * some support for MPI

  * N-dimensional arrays

  * sparse matrices

  * clean up the load-save mess

  * extend cell arrays, struct arrays, and function handles to also be
    N-dimensional

  * finish implementation of cell arrays and struct arrays:
      -- cell(idx) = [] to delete elements
      -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
      -- allow [x{:}] = f (...) to work
      -- and other little details like this...

  * [ ... ] should concatenate array-like objects other than matrices

  * inline functions

  * private functions

  * bring the manual up to date


Yes, this is a relatively large list, but I think it is possible to do
most of these things in the next six months or so.

It will probably help Octave a lot to have all of these things in a
new "stable"[2] release.  Perhaps that can happen by sometime this
coming (northern) summer (that would only be about a year later than I
had hoped for the last time I tried making a list like this).

Comments?

Thanks,

jwe


  [1] MPI is at the top because we have some code that is almost ready
      to be checked in.  The manual is at the bottom because I usually
      don't like working on it unless I can focus only on the manual
      for a few weeks.

  [2] Even if we call it "stable" I don't expect to try to do some
      kind of split "stable" vs. "development" releases unless someone
      steps forward to maintain the stable release.  It simply takes
      too much effort (for me, anywya) to try to maintain two
      branches.