octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Odeset - Odeget


From: c.
Subject: Re: Odeset - Odeget
Date: Sun, 1 Sep 2013 12:42:36 +0200

On 31 Aug 2013, at 12:54, Olaf Till <address@hidden> wrote:

> On Sat, Aug 31, 2013 at 03:22:16AM +0000, Roberto Porcù wrote:
>> Hi everybody,
>> i'm working on the Octave Socis project and i developed a program which
>> implements a geometric integrator for Hamiltonian systems; this solver
>> is a spectral variational integrator. The goal is to add this function to
>> OdePkg so i implemented that with the same signature of other functions of 
>> this
>> package, like ode45 whose arguments are (@functionHandle, time, 
>> initial_conditions, odeset).
>> My problem is that i need more options than those you can set with odeset,
>> so that i need to define new fields in odeset struct. Till now i just added
>> a new argument at the end, which is a struct containing these missing fields
>> but i think it is not very nice.
>> My idea is to modify the existing odeset function, adding the possibility to
>> set the values of new fields that are not pre-established, just like a 
>> normal struct.
>> Is it reasonable or are there reasons that make it not possible?
>> I will really appreciate your suggestions and observations.
>> Thanks
>> 
>> Roberto
> 
> 'odeset' and 'optimset' seem to be intended (in Matlab) to work
> identically, only for different sets of options. So I'd suggest
> copying core-Octaves 'optimset.m', 'optimget.m', and '__all_opts__.m',
> just formally changing them a bit.
> 
> This done, each new function using odeset/get can define new options
> within itself, without changing odeset anymore (by including something
> like:
> 
> ## PKG_ADD: __all_odeset_opts__ ("my_function");
> 
> and making 'my_function', if called with single argument "defaults",
> return all options it uses. Octaves and some of optims optimization
> functions are examples.)
> 
> This would probably require formally changing the other functions
> already using odeset.
> 
> Of course new options should be chosen carefully (they might be
> generally applicable), possibly discussing them before.
> 
> Thomas?
> 
> Regards,
> 
> Olaf

Roberto,

I like the suggestion from Olaf to make odeset as similar as possible to 
optimeset,
and the approache he suggests for creating new options seems convenient.

c.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]