Re: fsolve test failure

[John W. Eaton]

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.

| 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?  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.

| 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");

?

Other than that I think this is a good solution.

Thanks,

jwe