[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave 3.0

From: David Bateman
Subject: Re: Octave 3.0
Date: Mon, 04 Apr 2005 10:37:38 +0200
User-agent: Mozilla Thunderbird 0.8 (X11/20040923)

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]