3.3 Wishlist : [Fwd: Re: treelayout and spaugment procedures]

[David Bateman]

John,

While responding to Ivana offline, I speculated on a 3.3 Wishlist. The 
wishlist I came up with was

* Write a tree walker evaluator class
   - Implement the current evaluation code in terms of this tree walker
   - Write an instrumented version of the same evaluator to implement 
the profile command
   - Write an Octave to C++ filter based on this class
   - Write an Octave to Matlab (ie remove Octave specific code) filter 
based on this class
   - Include a LLVM based JIT in this tree walker class based on work in 
FreeMat and use it in the first three of the above evaluators.

* Implement the saving of anonymous function handles (with their 
associated workspace) to Matlab file formats. This is complex as the 
file format for this case is not documented. Octave includes a first 
attempt at the loading of anonymous function handles previously saved by 
Matlab and might be used as a basis for this work.

* Allow newer versions of HDF5 to be used with Octave without special 
compilation flags given to the compilation of HDF5. Write the autoconf 
magic necessary to recognize the different APIs

* Write a Matlab v7.4 file format based on the HDF5 format to allow 
transfer of large variables to be transfered between Octave and Matlab

* Rewrite the ftp package functions in octave-forge based on the CURL 
library and import these in to Octave itself

* Write single precision version of the lsode, etc functions

* Move some of the methods in the classes like Matrix upto the Array<T> 
to simplify these classes (based on previous discussion when introducing 
the single precision type)

I was originally hoping to get the last two done for Octave 3.2, but 
will see how far I get. I'm not sure how realistic the tree walker 
evaluator class is as its a lot of work and I'm probably not the best 
placed to address this point. However, it was goal 14 (after the cutoff) 
for the 3.1 goals and its important to address the two major missing 
Octave features in my mind (ie the profiler and simplify the inclusion 
of LLVM support for JIT) so I'd hope it will be seen as needed for 3.3

The other 3.1 goals that were after the cutoff were

<quote>
12. Implement nested functions

13. Eliminate explicit dispatch on type in various functions (for
example, the NATIVE_REDUCTION macro in data.cc, the if/else mess
in sort, or any other similar constructs) in favor of dispatch
via virtual functions in the octave_value class.

15. BLAS/LAPACK:
-- Stop distributing Fortran sources? If we do this, should
we make it possible to compile Octave without any
BLAS/LAPACK library, or should BLAS/LAPACK be required?
-- Use cblas interface?

16. Update the configure script and make checks for header files and
libraries more consistent (maybe we could recruit an autoconf
expert to help with this job).
</quote>

though I believe I've at least partially addressed goal 13 (ie in sort 
and some of the sparse function now don't use dispatch). With this and 
the fact we are getting close to a 3.2 release, maybe its time to start 
looking at a 3.3 goals list.

D.

-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary