From maintainers-request at octave dot org Thu Nov 18 03:08:00 2004 Subject: Re: Octave 2.1.63 available for ftp From: David Bateman To: "John W. Eaton" Cc: maintainers at octave dot org Date: Thu, 18 Nov 2004 10:03:57 +0100 According to John W. Eaton (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 David dot Bateman at motorola dot com 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