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