[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Other Octave-forge functions to port to the core
From: |
David Bateman |
Subject: |
Other Octave-forge functions to port to the core |
Date: |
Mon, 16 Jul 2007 14:35:31 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
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
- Other Octave-forge functions to port to the core,
David Bateman <=