odeset/odeget

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

odeset/odeget

Francesco Faccio-2

Dear all,


as discussed with Carlo, Jacopo and Marco, we would like to modify functions odeset and odeget in order to allow the user to add new fields required by some particular solver and to standardize the input check to avoid code duplication. 

The first idea we had was to use function validateattributes or, for complex input checking, the class inputParser.

Are we going to use this strategy or there are some better ways to do that (unfortunately I missed last discussion about it)?
Any suggestion is appreciated.

Thank you,

Francesco

Reply | Threaded
Open this post in threaded view
|

Re: odeset/odeget

Olaf Till-2
On Sun, Jul 24, 2016 at 06:08:42AM +0000, Francesco Faccio wrote:

> Dear all,
>
> as discussed with Carlo, Jacopo and Marco, we would like to modify
> functions odeset and odeget in order to allow the user to add new
> fields required by some particular solver and to standardize the
> input check to avoid code duplication.
>
> The first idea we had was to use function validateattributes or, for
> complex input checking, the class inputParser.
>
> Are we going to use this strategy or there are some better ways to
> do that (unfortunately I missed last discussion about it)?  Any
> suggestion is appreciated.
I probably didn't follow this discussion, though remember faintly that
I mentioned the following before:

Why don't odeset/odeget use the same scheme as the already existing
optimset/optimget/__all_opts__ ? Don't we now have solutions with
conceptually different code for two problems (optimization and ode
options) similar enough to use equivalent code?

In the optimget/optimset/__all_opts__ scheme the client functions can
advertise their options themselves. And the defaults depend on the
client function, which seems reasonable to me.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: odeset/odeget

Jacopo Corno


Il 24/07/2016 20:01, Olaf Till ha scritto:

> On Sun, Jul 24, 2016 at 06:08:42AM +0000, Francesco Faccio wrote:
>> Dear all,
>>
>> as discussed with Carlo, Jacopo and Marco, we would like to modify
>> functions odeset and odeget in order to allow the user to add new
>> fields required by some particular solver and to standardize the
>> input check to avoid code duplication.
>>
>> The first idea we had was to use function validateattributes or, for
>> complex input checking, the class inputParser.
>>
>> Are we going to use this strategy or there are some better ways to
>> do that (unfortunately I missed last discussion about it)?  Any
>> suggestion is appreciated.
> I probably didn't follow this discussion, though remember faintly that
> I mentioned the following before:
>
> Why don't odeset/odeget use the same scheme as the already existing
> optimset/optimget/__all_opts__ ? Don't we now have solutions with
> conceptually different code for two problems (optimization and ode
> options) similar enough to use equivalent code?
>
> In the optimget/optimset/__all_opts__ scheme the client functions can
> advertise their options themselves. And the defaults depend on the
> client function, which seems reasonable to me.
>
> Olaf
>
It's a good idea to look into those function to avoid unnecessary
hassle. However
I did some tests with Matlab and I found out some differences in how
optimset
and odeset works there. They should be considered to have compatibility.

First of all optimset allows passing the name of a solver to
automatically set the
specific options for that solver and its default values, while odeset
does not have
this feature.

Moreover, optimset seems to perform checks on the values passed and
returns an
error if the value is incompatible with the field. odeset lets
everything pass
through. The check on the options validity is performed by some internal
function
in the solvers themselves.

Cheers,
Jacopo


--
Jacopo Corno M.Sc.
Technische Universit├Ąt Darmstadt
Graduate School of Computational Engineering
Dolivostra├če 15
64293 Darmstadt / Germany

Office: S4|10-232
Phone: +49 6151 16 - 76877
Email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: odeset/odeget

Olaf Till-2
On Mon, Jul 25, 2016 at 10:28:40AM +0200, Jacopo Corno wrote:

> It's a good idea to look into those function to avoid unnecessary hassle.
> However
> I did some tests with Matlab and I found out some differences in how
> optimset
> and odeset works there. They should be considered to have compatibility.
>
> First of all optimset allows passing the name of a solver to automatically
> set the
> specific options for that solver and its default values, while odeset does
> not have
> this feature.
>
> Moreover, optimset seems to perform checks on the values passed and returns
> an
> error if the value is incompatible with the field. odeset lets everything
> pass
> through. The check on the options validity is performed by some internal
> function
> in the solvers themselves.
Still the desired behaviour of odeset/odeget could be implemented with
the copied code of optimset/optimget/__all_opts__, by only slightly
changing it and keeping its overall design. I think this would address
the issue in the original post.

BTW, the last feature you mention for Matlabs optimset is not
implemented in current Octaves optimset, but could be added.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment