On 09/20/2015 05:51 AM, Gilles wrote:
On Sun, 20 Sep 2015 01:12:49 -0500, Ole Ersoy wrote:
Wanted to float some ideas for the LeastSquaresOptimizer (Possibly
General Optimizer) design. For example with the
LevenbergMarquardtOptimizer we would do:
`LevenbergMarquardtOptimizer.optimize(OptimizationContext c);`
Rough optimize() outline:
public static void optimise() {
//perform the optimization
//If successful
c.notify(LevenberMarquardtResultsEnum.SUCCESS, solution);
//If not successful
c.notify(LevenberMarquardtResultsEnum.TOO_SMALL_COST_RELATIVE_TOLERANCE,
diagnostic);
//or
c.notify(LevenberMarquardtResultsEnum.TOO_SMALL_PARAMETERS_RELATIVE_TOLERANCE,
diagnostic)
//etc
}
The diagnostic, when turned on, will contain a trace of the last N
iterations leading up to the failure. When turned off, the Diagnostic
instance only contains the parameters used to detect failure. The
diagnostic could be viewed as an indirect way to log optimizer
iterations.
WDYT?
I'm wary of having several different ways to convey information to the
caller.
It would just be one way. But the caller may not be the receiver (It could
be). The receiver would be an observer attached to the OptimizationContext
that implements an interface allowing it to observe the optimization.
It seems that the reporting interfaces could quickly overwhelm
the "actual" code (one type of context per algorithm).
There would one type of Observer interface per algorithm. It would act on the
solution and what are currently exceptions, although these would be translated
into enums.
The current reporting is based on exceptions, and assumes that if no
exception was thrown, then the user's request completed successfully.
Sure - personally I'd much rather deal with something similar to an HTTP status
code in a callback, than an exception . I think the code is cleaner and the
calback makes it more elegant to apply an adaptive approach to handling the
response, like slightly relaxing constraints, convergence parameters, etc.
Also by getting rid of the exceptions, we no longer depend on the I18N layer
that they are tied to and now the messages can be more informative, since they
target the root cause. The observer can also run in the 'main' thread' while
the optimization can run asynchronously. Also WRT JDK9 and modules, loosing
the exceptions would mean one less dependency when the library is up into JDK9
modules...which would be more in line with this philosophy:
https://github.com/substack/browserify-handbook#module-philosophy
I totally agree that in some circumstances, more information on the
inner working of an algorithm would be quite useful.
... Algorithm iterations become unit testable.
But I don't see the point in devoting resources to reinvent the wheel:
You mean pimping the wheel? Big pimpin.
I longed several times for the use of a logging library.
The only show-stopper has been the informal "no-dependency" policy...
JDK9 Jigsaw should solve dependency hell, so the less coupling between commons
math classes the better. Anyways I'm obviously interested in playing with this
stuff, so when I get something up into a repository I'll to do a callback :).
Cheers,
Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
