Re: Other Octave-forge functions to port to the core

[Sylvain Pelissier]

I think expint function is also a core matlab function. But it will
maybe better to implement this function with GSL functions for a better
precision.

David Bateman a écrit :
> 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.
>
>