octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving functions from octave to octave-forge?


From: David Bateman
Subject: Re: Moving functions from octave to octave-forge?
Date: Fri, 27 Apr 2007 23:17:58 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

John W. Eaton wrote:
>
> Also, any function currently in an Octave Forge package that is in
> the list of core Matlab functions is a candidate for moving to
> Octave.
> 

When I was working on porting the octave-forge functions I kept a list.
Updating a little, for new octave-forge functions and the graphics
changes I have

Easy Enough to Port:
  bicg brighten ode23 ode45 odeget odephas2 odephas3 odeplot odeprint
  odeset imread imwrite psi

* There are a significant number of different functions in o-f odepkg
(cf ode78) that aren't part of matlab and visa-versa (cf ode113). There
are also a number of support functions for odepkg written as mex-files
that would need work.

* imread, imwrite rely in imagemagick to do the work. Do we want another
dependency?

* psi needs checking and texinfo help string

Graphics Stuff:
  contourf fill fill3 gtext pareto patch pcolor peaks pie quiver scatter
  surf surfc zoom meshc

* contourf, fill, fill3, patch, pcolor, pie all need new graphics
objects for patches, the current code is just a hack to simulate it.

* pareto and peaks seem just to need the help text texinfo-fied...

* gtext as it stands can't be ported as it uses some X11 specific hacks.
Doing it right with gnuplot requires two way interaction and mouse
control in gnuplot..

* quiver needs to have a quivergroup object class. The o-f version is a
gnuplot specific hack.

* scatter might be ported though it also involves special object classes.

* surf and surfc are gnuplot and p3md terminal specific hacks

* zoom in o-f does nothing and gzoom is an X11 hack


Just Hard to Port:
  convhull convhulln csvread csvwrite del2 delaunay delaunay3
  delaunayn dlmread dlmwrite edit ellipj ellipke expm1 fminbnd
  funm fzero ginput griddata optimset rat rats sound soundsc
  textread tsearch voronoi voronoin waitbar xlsread xmlread xmlwrite

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

* convhull, etc needs dependency on qhull

* xlsread is a very crippled implementation

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

* Do we want to add a dependency on GSL to getsome 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]