Re: fsolve test failure

[Jaroslav Hajek]

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.

> | I don't understand what you mean by "it is irrelevant what case ...".
> | Doesn't optimset also have to work in a case insensitive way?  But
> | when it returns the struct containing the optoins, the fields must
> | have the TolX style names, right?  They can't be spelled any other
> | way, or code like I posted will fail.
>
> OK, it occurred to me that even if the structure is returned with the
> TolX style names, doing something like
>
>  x.tolx = foobar;
>
> will not actually fail.  But this could cause some confusion.  What
> would a case-insensitive optimget do if there are two field names that
> differ only by case?
>

Yes, there's no way around this. This is going to be ignored in Matlab, too.


> jwe
>



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