octave-maintainers
[Top][All Lists]
Advanced

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

plans for some cleanup in optim package


From: Olaf Till
Subject: plans for some cleanup in optim package
Date: Wed, 11 Jun 2014 21:16:34 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi all,

already a while there are new frontends in optim,
nonlin_residmin/nonlin_curvefit/residmin_stat/curvefit_stat for
residual based optimization and statistics, and nonlin_min for
minimization of scalar valued functions. Some backends for them are
also already there.

An elder frontend, minimize, is intentionally similar to nonlin_min,
but unmaintained, conceptionally different, and causing the dependency
of optim on package miscellaneous. For simplification of maintainance,
I would suggest to drop it. Since this is only possible after a period
of deprecation, I'd suggest to copy its dependency function in
miscellaneous (read_options.m) under a different name to
optim/inst/private for now, to get rid of the dependency at once. It
can be deleted again once minimize should be deleted.

minimize.m can call 3 backends: a gradient-less method
("nelder_mead_min") and two gradient methods ("d2_min",
"bfgsmin"). All 3 can also be called directly. (But d2_min had a
usage-preventing typo-bug since 4 years up to 2014-06-11. And nobody
complained.) Some properties of the 2 gradient methods and gradient
optimizers not called by minimize:

optimizer     constraints       supplied
              possible?         hessian function?
-------------------------------------------------
minimize/     no                required
d2_min

minimize/     no                not used
bfgsmin

nonlin_min/   yes, throughout   optional
lm_feasible   optimization

sqp (in       yes, in           optional (but currently
core Octave)  end result        problems if supplied)


And some tests with them, using unconstrained problems in
optim_problems.m, showing the number of needed iterations:


optimizer     Schittkowski-281   Rosenbrock   Rosenbrock, initial
                                              values nearer to minimum
----------------------------------------------------------------------
minimize/     4049               1145         12
d2_min
(hessian
 supplied)

minimize/     171                75           20
bfgsmin
(no hessian
 supplied)

nonlin_min/   136                84           15
lm_feasible
(hessian
 supplied)

nonlin_min/   158                failure      22
lm_feasible
(no hessian
 supplied)

sqp (in       89                 73           23
core Octave)
(no hessian
 supplied)


Note that in d2_min the ratio of user-function-calls to iterations was
a bit higher than in the other optimizers (have no exact values for
all others).

Both bfgsmin and d2_min could have advantages for certain problems. It
could be worth to include them as backends into the new frontend, but
this would need rewriting. I'd guess d2_min would become too "out of
sight" to be much used if not included. bfgsmin will probably be used
anyway, and maybe it should remain there in original form even if a
rewritten copy is included as backend.

My plan is to ask on the help mailing list if someone uses the
frontend minimize at all, and if not, to go on with deprecation as
outlined above. Afterwards, I'd take a look at the "orphaned"
gradient-based backends, possibly adapting them (or a copy of them)
for the new frontend nonlin_min. I don't think I'll currently consider
the gradient-less backend (nelder_mead_min).

But please speak up if necessary.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: Digital signature


reply via email to

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