commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Math] Counters in "LeastSquaresProblem" (Was: [...] ConvergenceChecker)
Date Mon, 08 Feb 2016 23:11:12 GMT
Hi.

On Mon, 8 Feb 2016 15:18:37 -0600, Ole Ersoy wrote:
> [...]
>
>>> Also could you please look at this:
>>>
>>>      public static LeastSquaresProblem countEvaluations(final
>>> LeastSquaresProblem problem,
>>>                                                         final
>>> Incrementor counter) {
>>>          return new LeastSquaresAdapter(problem) {
>>>
>>>              /** {@inheritDoc} */
>>>              @Override
>>>              public Evaluation evaluate(final RealVector point) {
>>>                  counter.incrementCount();
>>>                  return super.evaluate(point);
>>>              }
>>>
>>>              // Delegate the rest.
>>>          };
>>>      }
>>>
>>> Should this exist?
>> Looks useful for counting evaluations, but I think all of the LS
>> optimizers already do this. Anyone have a use case for 
>> countEvaluations?
> I think you are right.  I think it's code that was accidentally left
> in...Anyone...?

No it was not accidentally left in, it was added on purpose with the
new design.
Now, I seem to recall that it was an example of how information could
be passed from the optimization algorithm to the user, by wrapping the
"basic" context ("LeastSquaresProblem") within an extended one (here an
evaluation counter context).

The "maxEvaluations" and "maxEvaluations" settings are currently passed
at construction of the "LocalLeastSquaresProblem"; maybe it is that 
which
was supposed to go in the new design: "LevenbergMarquardtOptimizer"
increments the counters but otherwise does not use them (for loop
control, that is).

Was it something that waited for the refactoring of the rest of the
optimizers?  Indeed, the "LeastSquareProblem interface" extends
"OptimizationProblem" that defines "getEvaluationCounter()",
"getIterationCounter()" and ... "getConvergenceChecker()".

So the wrapper/adapter provides external control of what happens (e.g.
raising an exception) when the counter is exhausted.
IOW, the counter(s) are not part of the standard algorithm, and the
new design is able to make that clear.


Regards,
Gilles

> 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