Re: Moving functions from octave to octave-forge?

[Thomas Treichl]

Hi, (and sorry for being late).

David Bateman wrote:
> 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

The ode* functions described here could be put into octave easily because they 
are *.m. I added help texts for all of these functions, tests and demos. There 
is one thing that has not been implemented by now: Sparse matrix support for the 
Mass-matrix and Jacobian-matrix, if somebody else wants to work on this topic 
then you're welcome, all the other things have already been added and validated 
with octave on Linux and OSX (and maybe you don't want to read this - also 
validated on MatR13/RedmondXP). John needs to have a look himself if he wants to 
add these functions - but I would prefer if this doesn't happen at this time 
(cf. next paragraph).

> * 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.

I wrote in the short manual of the odepkg that this package is currently under
development. I actually have not finished with the implementation so I'd like to
continue working on this before you move it to octave. Some of the topics that I
actually wanted to do with the little time I've got:

- add solvers to solve DDEs
- add solvers to solve IDEs (like octave's dassl, dasrt etc.)

I don't think that I will ever work on the PDEs and BVPs resp. the solvers for 
them similarly as they are implemented in Matlab (bvpset, bvpget, bvp4c, pdepe, 
etc.) This should become part of another new package (from my point of view) 
also written from somebody else than me.

ode113, ode23tb (Matlab) vs. oderd, odesx, etc. (odepkg): ode113 and others are 
a special Matlab implementation. I've not seen any implementation similar to 
these functions in C, Fortran etc. on Internet and have not found any 
documentation about the idea that is behind these solvers. But this doesn't mean 
that you can solve special problems only with these solvers.
So I added other functions (oderd etc.) that are also written in *.m and that 
are wrapper functions to *.mex files that once again use well known GPL 
compatible fortran solvers from internet. Adding other wrapper functions eg. 
ode113 to the odepkg that point to one of the *mex interface functions could be 
an idea for even more compatibility to Matlab.

Least but not last: The *.mex file porting to *.oct file question? I was told 
that the *.mex interface functions should become *.oct if they are moved to 
octave, but I don't like this idea (for me and my use), because as I wrote in 
the first paragraph I also have the need for this package on MatR13 - so the 
question for me is: what is the idea resp. the reason behind it for *.mex be 
ported to *.oct?

Also, if somebody else wants to help implementing solvers or other things to 
odepkg then you're very welcome.

Thomas