[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: odeset/odeget
From: |
Olaf Till |
Subject: |
Re: odeset/odeget |
Date: |
Sun, 24 Jul 2016 20:01:47 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
Description: Digital signature
- odeset/odeget, Francesco Faccio, 2016/07/24
- Re: odeset/odeget,
Olaf Till <=