Re: Octave 2.1.63 available for ftp

[John W. Eaton]

On 17-Nov-2004, David Bateman <address@hidden> wrote:

| > In addition to these changes, I think we still have the following
| > items for Octave 3.0:
| >
| >  * allow [x{:}] = f (...) to work
| >
| >  * private functions
| >
| >  * some support for MPI
| >
| >  * bring the manual up to date
| 
| If we are discussing the wish-list for 3.0 again, I'd suggest that if
| private functions are in the classes should also be added, since the
| two are closely related. Classes are just private directories for a
| certain data-type. Once such a private direcory for a data-type
| existing adding the overload functions won't be too difficult.

OK, but we have to draw the line somewhere...

| Another thing you might need in that case is the dispatch code from
| octave-forge, rewritten to fit into the class structure.

Yes, with classes, we will need some method of dispatch.

| In any case,
| unless you intend to add the sparse code to all of the functions like
| lu, inv, chol, qr, det, ranks, sum, reshape, atan2, diag, etc, etc,
| etc, then a proper dispatch/class structure will be needed.

Yes, I'd rather have a method for dispatch than have to modify all
these functions.

| Another thing that I'd wish for, for version 3, would be that the
| FIXES and patches directories of octave-forge are gone through and the
| stuff there either updated and ported to the version 3.0 or definitely
| dropped. These directories shouldn't exist in octave-forge.

I agree.  Having obsolete updates and patches in octave-forge can
cause trouble.

| It would also be nice if the "\" and "/" operators could recognize a
| triangular matrix and call the appropriate lapack/blas code. The stuff in
| octave-forge for this is a bit of a kludge as it only works for chol and
| doesn't use the lapack code for "\" and "/". Maybe something like
| 
|    enum {diagonal = 0, upper, lower, full} matrix_type;
|    matrix_type typ = diagonal;

You could also add banded matrices.

Again, since these are just storage techniques (as is sparse), perhaps
they should be handled by different internal rep types in the Array
class?  At the very least, even if we don't have special methods of
storage for the different types, we should probably cache the
attribute once it is discovered.
| 
| this might be added to the Matrix::solve and ComplexMatrix::solve
| functions. I don't think this would be very costly, as in most cases
| you'd quickly identify full matrices. It would be interest to see how
| this performs ralative to the chol function in octave-forge.

Is it only useful for a few solvers?  Would it be too much work (with
too many operators to define) to have new data types for each of these
special storage types?

| I also think version 3.0 should be the release where octave-forge is 
| decruftified;

Yes, that would probably be a good thing.  I think it will eventually
be too much trouble to try to keep octave-forge compatible with very
obsolete versions of Octave.

jwe