A few (Octave) ideas

[John W. Eaton]

On  3-Jun-2010, Jake wrote:

| 1. Is there a reason why these functions haven't already been implemented? 
| Lack of information on the algorithms, perhaps?

Or, given that we have other ODE/DAE solvers that are quite good, no
compelling reason other than compatibility to write them?

| 3. Are there any reasons why I shouldn't try to implement these functions?

I think it would be fine to have them, and even include them in the
core Octave distribution.  For that to happen, the code should follow
Octave's coding conventions, and it is essential that the work be
independent of Matlab, so you must not base your implementation on the
Matlab functions in any way, other than making the interface
compatible.

In the past, when I've needed the odeNM functions for compatibility,
I've used wrapper functions for lsode or daspk that provide the odeNM
interface.  That works well enough for me that I haven't had the need
to actually have the odeNM functions that use the same class of
algorithms used in the Matlab functions.  I haven't included my
wrapper functions in Octave because they've never been complete
implementations.

Is it necessary to have odeNM functions that use the same algorithms
as the corresponding Matlab functions, or is it sufficient to simply
provide the same interface while using some other algorithm to solve
the same problem.  If the latter, then wrappers around lsode and daspk
might be easier to implement.

jwe