RE: A few (Octave) ideas

[Jake]

They are great solvers, I wasn't questioning their quality at all.

My reasoning behind wanting to implement these functions is to attract more
MATLAB users to Octave.  Octave is such a great piece of software but people
still find reasons to pick MATLAB over it, and language compatibility is one
of them.  People say things like, "Oh, well Octave doesn't have this
function, we need MATLAB."  If we have a complete set of the more commonly
used functions (which you pretty much already have), then people can't use
that argument.  I know we can't probably don't want to duplicate all of
MATLAB's toolboxes, but ODEs are common across all fields so I think it
would be expected to at least have wrapper functions for them.  That way,
people coming from MATLAB don't see errors.  I think wrapper functions are
pretty much the best we could do anyway, as I'm not sure if we could find
enough information to completely duplicate the algorithms used in MATLAB.

-----Original Message-----
From: John W. Eaton [mailto:address@hidden 
Sent: Friday, June 04, 2010 10:54 AM
To: Jake
Cc: address@hidden; address@hidden;
address@hidden
Subject: A few (Octave) ideas

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