Re: Octave 3.0

[David Bateman]

Dear All,

John W. Eaton wrote:

> David suggested that I update the
> list, so here is my current list of items:
>  
The reason I suggest that John update the list is that there is a 
tremendous amount of work still to be done to get 3.0 out, and so this 
updated list should be seen as a list of things where help might be 
requested. Even if you can't code in C++, inputs to update the manual 
would be a major help.


>  * merge 64-bit changes to Octave (contributed, but needs some work)
>
>  * mpi interface for Octave (have contributed code, actually several
>    options at this point)
>
>  * better documentation for Octave internals and writing .oct files
>    (some contributed documents are available, but need work)
>
>  * make [x{:}] = f (args) work
>
>  * what to do about \ escapes?  (I will send a separate message about
>    this soon)
>
>  * revise manual to better match the current state of the code
>
>  * secondary goals for 3.0 (could be bumped to later release):
>
>    -- merge core functions from octave-forge (probably some now, some
>       later, I will post another message about this soon)
>
>    -- private functions (special treatment for functions in
>       subdirectories named "private" in the LOADPATH)
>
>    -- objects (special treatment for functions in @CLASSNAME
>       directories in the LOADPATH, and dispatching code to allow
>       function overloading)
>
>    -- nested functions compatible with matlab 7.x (I almost did this
>       when implementing subfunctions, but punted because it seemed
>       likely that whatever I chose would be incompatible with some
>       future changes in Matlab, so I'm glad I waited).
>
>    -- package system (with this, split some code out of core
>       distribution and into separate packages)
>
> I think it is reasonable to aim for a release by late summer or early
> fall (maybe sooner if all the secondary goals are pushed to a later
> release).
>
>  
My feeling is that anything that will change the api version should be 
put in before 3.0, so that oct-files might be shared between versions of 
3.0. I suspect some of the secondary goals might do this and so would 
probably also need to be done before 3.0.

I have my own personal ToDo list, mainly with things that are related to 
sparse matrices. My primary goals are

1) Finish the sparse matrix type caching code
   - xdiv function pass octave_values
   - assign function preserves type, and maybe some other functions as 
well. Rest invalidate type
   - Have lu, chol functions, etc specifically set the type
   - Use the fact that the type of sparse matrices from the lu function 
are set to test the permuted triangular matrix solve
   - In the absence of dmperm, write permuted triangular matrix 
detection that only takes into account one of row or column permutations
   - Add functions to allow user to set sparse matrix types. Maybe they 
should be internal function (ie marked with leading __) as this 
functionality can result in incorrect results

2) Add TAUCS creating a SparseChol and SparseComplexChol class. Use 
these in the chol, cholinc, symbfact and sparse solve functions.

3) Use the drop tolerance of UMFPACK to write an luinc function (this 
one should be relatively easy)

4) Include zlib to allow reading of matlab v7 files. Try to write this 
functionality as stream objects to reduce the required memory usage. 
Matlab's implementation of this (size of block in header and blocks of 
file zipped separately), the fact that we can't get a file descriptor 
from a C++ stream and the fact that zlib can't seek backwards in an 
output stream seem to make this impossible.

5) Extend the use of zlib to allow zipped files to be read/written 
within octave for all file types except HDF5. This is much easier to 
implement with C++ stream version of zlib, and has the major advantage 
that backward compatibility can be preserved just be unzipping the file 
externally with gzip.

6) Address the issue of mapper functions, such as real, abs, etc for 
sparse matrices. This might be a modification of the octave mapper 
class, a more generic change that allows the mapper functions to be 
accesses by user classes, or finally a and least attractively as it 
requires more than 50 new functions an implementation using classes or 
dispatch.

After this weekend I have much of 4) and 5) working, but still need some 
final touchs. Secondary goals I have set include

* re-writing of the dmperm function directly from the Pothen's article, 
the same for symrcm or perhaps if we can clear up the issue of the 
license use the code from PETSC,
* sparse inverse function (maybe implementation that simply uses the 
poly-morphic solve code)
* inclusion of ARPACK for the eigs functions
* give dense matrices the same treatment for the solve code and allow 
PD and triangular matrices to be solved efficiently
* port the sparse test code into the DejaGNU test code of octave itself 
(probably importing test/assert to do this)
* finish the sparse matrix documentation
* finding a good QR sparse solver and including it (perhaps the 
sparse-qr package on http://plato.la.asu.edu/topics/problems/nlolsq.html 
as identified by Paul earlier)

If anyone feels like helping out one my ToDo list, I'd much appreciate 
it as well.

Regards
David

--
David Bateman                                address@hidden
Motorola Labs - Paris                        +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