octave-maintainers
[Top][All Lists]
Advanced

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

Re: fsolve test failure


From: Jaroslav Hajek
Subject: Re: fsolve test failure
Date: Fri, 30 Jan 2009 21:23:47 +0100

On Fri, Jan 30, 2009 at 4:55 PM, John W. Eaton <address@hidden> wrote:
> On 30-Jan-2009, Jaroslav Hajek wrote:
>
> | 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
> | [...]
> | > See
> | > http://www.nabble.com/3.2-status-report-td18740866.html#a18854563
>
> OK.  I'm not sure I completely understood how Matlab's optimset worked
> then.  But OK, it does seem clear to me that the intent is for these
> options to be managed by the optimget and optimset funtions and not by
> manipulating the structure elements directly.  I guess we'll see how
> many complaints we get for this incompatibility.  If there are not too
> many, I suppose we can tell people to use the optimget and optimset
> functions.  But we may have to reconsider if manipulating the struct
> directly turns out to be common and there are lots of complaints.
>

Technically, there is no incompatibility. In Matlab, you can also set
a field directly, and if you use invalid case, the field will be
silently ignored. We can only try to be smarter than Matlab, and, for
instance, check for the condition in optimget, but I think we should
discourage direct manipulation of the struct anyway.

> | 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).
>
> I'm slightly confused here.  What function accepts the function names
> as arguments?

__all_opts__ ('optimfunc')

will call optimfunc('defaults') and then add all the options.

> Maybe instead of including the initial list directly in
> fzero, fsolve lsqnonneg, these should also be added using PKG_ADD?
> Then each of these functions would not have special treatment, and the
> PKG_ADD line in each of them would serve as an example of how to
> properly add an optimization function to the list.

That's a good idea. I forgot Octave can have its own PKG_ADD commands.
This also simplifies the function nicely. So, right now,
optimization/PKG_ADD contains
__all_opts__ ("fzero", "fsolve", "lsqnonneg");
which registers all their options.

>
> | 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?
>
> Yes.  I see one other small problem.  You have
>
>      ## Display possibilities.
>      tmp = opts';
>      disp (struct (tmp{:}));
>
> in optimset, but that prints
>
>  {
>    FunValCheck = Jacobian
>    MaxFunEvals = MaxIter
>    OutputFcn = TolFun
>    TolX = Updating
>  }
>
> How about changing it to
>
>      ## Display possibilities.
>      puts ("\nAll possible optimization options:\n\n");
>      printf ("  %s\n", opts{:});
>      puts ("\n");
>
> ?
>

Done.


> Other than that I think this is a good solution.
>
> Thanks,
>
> jwe
>

OK, I pushed the changeset.

regards


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


reply via email to

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