Octave 3.0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave 3.0

John W. Eaton-6
It's been more than two years (!) since I posted the following list of
goals for the mythical Octave 3.0

  * some support for MPI

  * N-dimensional arrays

  * sparse matrices

  * clean up the load-save mess

  * extend cell arrays, struct arrays, and function handles to also be
    N-dimensional

  * finish implementation of cell arrays and struct arrays:
      -- cell(idx) = [] to delete elements
      -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
      -- allow [x{:}] = f (...) to work
      -- and other little details like this...

  * [ ... ] should concatenate array-like objects other than matrices

  * inline functions

  * private functions

  * bring the manual up to date

Most of these items have been completed (thanks to David Bateman for
his work on a number of large changes).  In addition, we have other
significant new features that were not on the list, including integer
data types, linear programming, and many bug fixes (I hope we have not
added mroe than we have fixed).  David suggested that I update the
list, so here is my current list of items:

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

Comments?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Quentin Spencer
John W. Eaton wrote:

>  * mpi interface for Octave (have contributed code, actually several
>    options at this point)
>  
>
I noticed that the latest Matlab service pack (released in the last few
weeks) now includes a Distributed Computing Toolbox and Distributed
Computing Engine (see http://www.mathworks.com/products/distribtb/). I
haven't used any of the Octave MPI stuff, so I'm pretty ignorant about
all this, but I just wondered whether it is feasible or worthwhile to
try to be compatible with their way of doing things. In briefly looking
over the function definitions, it appears that it would require support
for objects.

-Quentin


Reply | Threaded
Open this post in threaded view
|

Re: Re: Octave 3.0

Jeffrey B. Layton
In reply to this post by John W. Eaton-6
> I noticed that the latest Matlab service pack (released in the last few
> weeks) now includes a Distributed Computing Toolbox and Distributed
> Computing Engine (see http://www.mathworks.com/products/distribtb/). I
> haven't used any of the Octave MPI stuff, so I'm pretty ignorant about
> all this, but I just wondered whether it is feasible or worthwhile to
> try to be compatible with their way of doing things. In briefly looking
> over the function definitions, it appears that it would require support
> for objects.
>
> -Quentin

The toolbox does not do MPI. It's for embarrasingly
parallel applications (i.e. no communication).

Jeff

>
>


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Paul Kienzle
In reply to this post by John W. Eaton-6

On Apr 1, 2005, at 2:26 PM, John W. Eaton wrote:

> It's been more than two years (!) since I posted the following list of
> goals for the mythical Octave 3.0
>
> ...
> Comments?

One possible 3.0 goal that was mentioned was a stable API that would
not require a recompile of conforming oct-files whenever octave changed.

Currently octave has API version numbers, presumably tagged to changes
in octave_value.  If instead octave_value could be treated as an opaque
pointer with functions to access its methods and instance data this
would provide even more stability.  Tcl uses a jump table to avoid
binding to a particular library version.

Many oct-files only need minimal access to octave internals.  Functions
for checking type and dimension, for accessing array pointers and for
allocating returned arrays covers most operations.  Calling back
into octave is also common.

This could be put off until after the 3.0 release and still be valuable.

- Paul


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

David Bateman-3
In reply to this post by John W. Eaton-6
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                                [hidden email]
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