commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Math] Counters in "LeastSquaresProblem" (Was: [...] ConvergenceChecker)
Date Tue, 09 Feb 2016 15:29:47 GMT
On 8 February 2016 at 23:11, Gilles <gilles@harfang.homelinux.org> wrote:
> 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.

However clearly the purpose of the method(s) is not immediately
obvious from the source code.
Perhaps it was in the commit message or mailing list discussions?
Such external documentation is rarely sufficient, so if would be very
helpful if the code could be updated with the rationale as explained
above.

>
> Regards,
> Gilles
>
>> Cheers,
>> Ole
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message