Re: Octave 2.1.63 available for ftp

[David Bateman]

According to John W. Eaton <address@hidden> (on 11/18/04):
> | 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...

I only suggested classes as it would be relatively trivial after private
functions are added.

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

Ahh, but I suggested using the DTR* blas/lapack functions not the DTP*
for packed triangular storage. The idea being that its the same storage
class as a matrix, but we can make use of the matrices special properties
to accelerate things.

However, if you add banded matrices to the mix, then yes that really 
only makes sense if we add a banded storage class. It is also not clear
to me at what point the probing of an arbitrary matrix to determine its
type should be done. At its creation in the maybe_mutate function? At the
first use of the matrix in a function whose general version is much slower
(eg Matrix::solve, etc), or elsewhere?

> | 
> | 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?

Frankly I believe triangular matrices would profit enormously in the solvers,
and much less so elsewhere. This idea is pretty much what is currently done
in octave-forge. However adding banded matrices to the mix changes things.

Maybe we could consider that a banded matrix should be represented by a general
sparse matrix, which if done well should have similar properties to the 
banded matrix, if only a slight memory overhead. In that case its upto the
user to identify a banded matrix at its creation. In that case have seperate
types for triangular matrices makes sense, and is easy to do. I'll suggest
a patch when I have time.

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

Yes, the cruft is really beginning to accumulate in octave-forge... 
Some of it is obvious as it is marked with a config option and is easy 
to remove with sed. However, there is code like

  try ar = automatic_replot;
  catch ar = 0;
  end

  unwind_protect
    automatic_replot = 1;
    ...
  unwind_protect_cleanup
    automatic_replot = ar;
  end_unwind_protect

in quite a few m-files that is less obvious, that should also be cleaned
up for version 3.0.

Regards
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary