commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [Math] LeastSquaresOptimizer Design
Date Sun, 20 Sep 2015 20:04:08 GMT


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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message