Re: Updated odeset/odeget

[Rik]

On 10/10/2015 09:11 AM, address@hidden wrote:

Subject:

Re: Updated odeset/odeget in core

From:

Sebastian Schöps <address@hidden>

Date:

10/09/2015 11:53 PM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=us-ascii

Message:

2

Rik-4 wrote

> Can anyone who solves odes regularly comment whether these are needed
> anymore?  Otherwise, I would remove them to lower the number of lines of
> code that need to be maintained.
> 
> Cheers,
> Rik

Some of the options were renamed due to Matlab compatibility and Jacopo kept
them because of backward compatibility with odepkg. I think we can break
with that. 
Some other options are solver specific (e.g. I have introduced 5 years ago
NewtonTol for radau5). I suggest that we remove them but we should allow
arbitrary parameter/value pairs (maybe with a warning). This is different
from Matlab (I believe) but still allows odepkg to work. More elegant but
rather complicated: odeset/get checks if odepkg is installed and loads a
corresponding list of acceptable strings.

Sebastian

10/16/15

Sebastian,

I implemented the first solution of accepting and passing through unknown options, but with a warning.  The non-Matlab compliant options have been removed.  See this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/00caf63edcdf).

In addition I got rid of the function odepkg_structure_check since it was nearly identical to ode_struct_value_check.  There was no point in trying to maintain two very long, nearly identical, functions.  All errors and warnings now use the Octave core id "Octave:invalid-input-arg" rather than the package id "OdePkg:InvalidArgument".

In terms of what remains to be done before ODE support is fully in core, I see 1) a final review of ode45.m for style and efficiency, and 2) dealing with the unnecessary variable 'v' prefix.  For item 2, is this likely to cause a problem with OdePkg interactions between core and package?  Or are the core routines standalone since ode45 and all of it's necessary solver routines are in the ode/private directory?

--Rik