Re: fsolve test failure

[Jaroslav Hajek]

On Fri, Jan 30, 2009 at 7:29 AM, Jaroslav Hajek <address@hidden> wrote:
> On Thu, Jan 29, 2009 at 10:38 PM, John W. Eaton <address@hidden> wrote:
>> On 29-Jan-2009, John W. Eaton wrote:
>>
>> | On 29-Jan-2009, Jaroslav Hajek wrote:
>> |
>> | | >  x = optimset ();
>> | | >
>> | |
>> | | This call returns an empty structure. What do you mean?
>>
>> OK, this may be part of the confusion.  In Matlab, I think this
>> returns a structure with all the known options as fields, but each has
>> the value of an empty matrix.  But in Octave, we are returning a
>> structure with no fields.  Should we be compatible here?
>
> We've discussed this some time ago and IIRC you agreed with me. The
> problem is that if
> optimset always sets all possible optimization options (and there are
> scors of them in Matlab),
> the result is not visually inspectible (at least not in the console).
> When I'm setting options for, say, fzero, like opts = optimset("TolX",
> 1e-6, "MaxIter", 1e-7),
> when I display opts, I want to see what options I set. I'm not
> interested in the fact that
> MaxPCGIter and JacobianSparsityPattern or whatever are not set,
> because they don't even make sense for fzero.
> Maybe in the Matlab GUI, a struct with lots of empty ([]) fields can
> be displayed so that the empty fields don't clutter the rest, but in
> console, it hurts. The fact that Matlab is disregrading the console a
> little is an old story.
> What's more illogical, optimset ('fzero') and similar calls in fact do
> *not* return the empty fields set, just like we do. Apparently here
> someone thought a little more about it.
> I say, don't copy this behaviour of Matlab. It's stupid.
>
> See
> http://www.nabble.com/3.2-status-report-td18740866.html#a18854563
>
>
>> How would
>> optimset know about all options used by all optimization functions
>> that can accept options structures as arguments?  I would prefer to
>> avoid embedding that knowlege directly in optimset if possible.
>>
>
> Unless you make the set of all possible options somehow accessible to 
> optimset,
> I don't think there's any way to make opt = optimset('tolx', 1e-6)
> actually set opt.TolX.
> But I think there's a more elegant way than simply embedding a list somewhere.
> I'll try to create a patch.
>


And here it is (attached).
Summary:

There is an internal function __all_opts__ that returns all
"registered" options sorted in alphabetical case-insensitive order.
Options are registered by querying the default options from a
function. Octave's existing optim function are queried by default at
startup, and more can be added at runtime by giving the function names
as arguments (for instance from OctaveForge using PKG_ADD).

optimset and optimget always obtain the list of registered options
from this function, then for each option being set/get, they look up a
case-insensitive match and replace if available, otherwise warn that
the option is unregistered.

This keeps both optimget & optimset case insensitive and also gives
warning for misspelled options.
Options directly assigned with incorrect casing (like "opts.tolx =
1e-2") will be ignored (like in Matlab).
The only incompatibility with Matlab is that we won't add fields
corresponding to unset options, so that the resulting struct remains
readable.

Comments? OK to push?

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

opts.diff
Description: Text Data