More octave-forge functions!!!

[David Bateman]

Here is several more of the octave-forge functions that are in the core
of matlab converted for the core of octave. In addition this a a small
typo in spline's help fixed... There were also a couple of supporting
functions that I converted. The converted functions are

  bicubic gradient inputname interp1 interp2 interpft mat2str ndgrid
quadl pcg pchip
  pchip_deriv pcr plot3 polyarea __plt3__

Note that NDArrays and gradient don't work at the moment due to the bug
I just reported on address@hidden in NDArray indexed assignment.

Note ndgrid was from the maintainers mailing list recently and I'm just
duplicating it in this patch..

I also included pcr as well as pcg, even though only pcg is a core
function, as pcr is the only iterative sparse solver we currently have
that doesn't require a PD matrix.

What I did was basically texinfo'fy all help strings, convert to octaves
coding style, check matlab compatibility and treat inconsistencies where
needed. Some of the inconsistencies I treated include

* Add NDArray capabilities to a number of functions including gradient
and interp1
* Add the 'pp' argument to interp1
* Convert __plt3__ to use the NaN values to flag missing data to gnuplot
to largely speed up plot3

There are a couple of little points in the converted functions, mainly
with interp2, where I didn't implement 2-D spline interpolation and
there is a comment about the bicubic function not allowing general meshs
that I didn't address.

This basically finishings all of the functions that I consider
relatively simple to convert from octave-forge for use in octave. The
remaining functions I consider to fall into two groups. The first of
these groups of function in octave-forge which are core matlab functions is

  brighten contourf drawnow fill fill3 gtext imread imwrite
  legend meshc pareto patch pcolor peaks pie psi quiver
  scatter stem surf surfc text view zoom

Essentially these are all graphics functions and the graphics handles
stuff will either largely change these functions, or simplify them and
so I don't think these should be treated until the graphics handles
stuff is addressed. Though they should go on someones todo list.

The second group of functions in octave-forge that should be octave are

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

There are many reasons why not to port these yet, but basically I
believe all need either additional work or discussion.

For convhull, convgulln, delaunay, etc, which all depend on qhull there
is the question of whether we want to add a dependency to octave on
qhull. Otherwise they are essentially easy to port.

For csvread, dlmread, csvwrite, dlmwrite it seems to me there must be a
much simpler way of implementing these efficiently in a script file
without the need for an oct-file.

del2 should be relatively simple to convert, using the example of
gradient.m, but it needs significant changes to allow NDArrays and be
compatible to the current matlab version

For edit I suspect some of the code here is not compatible with MinGW
and so some changes are inevitably needed.

For ellipj, expm1, do we want to add a dependency on GSL. If so then
there are many many other functions that should be converted to use GSL
as well. The list is really quite long, and should be discussed if the
choice to make octave dependent on GSL is taken.

For fminbnd there are significant changes to add the Options flags for
full matlab compatibility.

funm is fairly simple to convert, though function handles and inline
functions should be added. However, it seems to me that thfm should be
combined with funm to make the precision of calculation of trig
functions better. However how to do this, particularly with function
handles and inline functions doesn't seem obvious to me. Should we just
take funm as is? Should in that case thfm also be added?

I can't remember why I add fzero to my too hard list. Someone want to
comment?

ginput depends on an oct-file grab, that is dependent on Xlib. There
should be a better way of doing this that is more portable if it is to
be included in octave.

There is a comment in ode23/ode45 of subtle differences in the interface
between the octave and matlab versions. Do we want versions with such
subtle differences? Would someone like to fix it to be completely
compatible?

Why port optimset if fminunc isn't ported.

To port rat/rats need to convert to C++ include in pr-output.cc to allow
"format rat" to work. This is just work, and should be fairly direct.

sound/soundsc seem to be very system dependent, what is the best way of
making these completely portable?

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, that only takes tab separated
text files.

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

I'm looking for both comments and help porting the above. So don't
hesitate to respond..

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

patch.bz2
Description: BZip2 compressed data