[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
3.3 Wishlist : [Fwd: Re: treelayout and spaugment procedures]
From: |
David Bateman |
Subject: |
3.3 Wishlist : [Fwd: Re: treelayout and spaugment procedures] |
Date: |
Wed, 27 Aug 2008 16:23:33 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080725) |
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 address@hidden
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
- 3.3 Wishlist : [Fwd: Re: treelayout and spaugment procedures],
David Bateman <=