Other Octave-forge functions to port to the core

[David Bateman]

Thinking about porting convhull, etc I looked again at what octave-forge
functions that are core matlab functions and so might be subject to a
port to Octave itself. There are still quite a few. Some of the easy to
port ones and those that I'd propose to port to Octave before 3.0 are

* brighten, peaks, psi, meshc, del2, edit: Easy to port, will do so..

* csvread csvwrite, dlmread, dlmwrite, textread: Some minor
compatibility issues to be fixed.

* fminunc, fminbnd, fminsearch, fzero, optimset: Should be relatively
easy to port, but maybe I'm missing something..

* convhull, convhulln, delaunay, delaunay3, delaunayn, griddata,
tsearch, voronoi and voronoin: Need to add a dependence on QHULL.

As for the others these are

* imread, imwrite: Dependency on imagemagick..

* zoom: Graphics backend command to allow mouse to zoom on the plot.
Need to implement gnuplot version of this.

* gtext, ginput: Backend specific.. X11/gnuplot only version in
octave-forge..

* pie, fill, fill3, patch, pcolor, surf, surfc: Need patch graphics object

* contourf, pareto, quiver, scatter: Specialized plots, often needing
specialized graphics objects. pareto and scatter are probably easy to port.

*  ode23, ode45: subtile differences in interface for ode23 and ode45
(still true?). Need oct-file rather than mex-files of certain code.

* sound soundsc: Painful dependency of SOX function "play"..

* Is the term code in waitbar portable? Should it be rewritten to use
the GUI when written rather than like it currently is?

* xlsread is a very crippled implementation

* xmlread/xmlwrite need to be taken care of by someone else (cf mail
archive for xmltree and xml4mat)

* eliipj, ellipke, expm1: Do we want to add a dependency on GSL to get
some of these missing functions? If so there are other functions that
might be re-written to use GSL.

* To port rat/rats need to convert to C++ include in pr-output.cc to
allow "format rat" to work.

* Combine funm with thfm for trig precision, but how to deal with
function handles and inline functions of trig functions?

* eigs, svds: ARPACK license issue.

Any thoughts about what to do about these? Any thing I missed? Any
offers of help to port them? :-)

Regards
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