commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [math] LevenbergMarquardt Evaluation Lazy vs. Unlazy
Date Fri, 05 Feb 2016 20:16:24 GMT

On 02/05/2016 04:52 AM, Gilles wrote:
> On Thu, 4 Feb 2016 18:56:20 -0600, Ole Ersoy wrote:
>> On 02/04/2016 04:13 PM, Gilles wrote:
>>> On Thu, 4 Feb 2016 14:10:39 -0600, Ole Ersoy wrote:
>>>> Hi,
>>>> Has anyone performed any benchmarking on lazy vs. unlazy
>>>> Evaluation(s)
>>> Someone did:
>>>> or is there some obvious criteria on when to use one vs.
>>>> the other?  I only see getResiduals() being called once in the
>>>> optimize() method right after a new evaluation is created:
>>>>                 current = problem.evaluate(new
>>>> ArrayRealVector(currentPoint));
>>>>                 currentResiduals = current.getResiduals().toArray();
>>>> Thoughts?
>>> The problem is "getJacobian()", called only in the outer loop.
>>> Method "evaluate" is also called in an inner loop where only
>>> the residuals are used.
>> So if the optimizer is supplied with individual function
>> implementations that are called to calculate residuals and the
>> jacobian matrix 'on demand / when needed' then the question of whether
>> to use a lazy evaluation vs. the regular evaluation goes away (I think
>> without any drawbacks)?
> The two functions were separate in the previous design, then grouped
> in the current one because it was reported that it is often is the case
> that both are computed at the same time.
I'm still in the process of scanning through, but I think it's better if all the optimizers
parameters and functions are grouped on a single OptimizationContext instance that then provides
or calculates values on demand.  So if we need residuals, we ask for them:

double[] residuals = context.residuals(point);
double[][] jacobian = context.jacobian(point);

> So the grouping was deemed a simplification.
Spent a while scratching my noodle when I saw it ...

>   It is, but for use-cases
> where they are not computed together and the objective function is costly,
> performance can suffer badly (i.e. not just milliseconds...).
My opinion is that this (Providing multiple implementations of aggregated operations) makes
uses cases more complex both from the a client api users perspective and the core developer's
perspective. I have not looked across the board at all use cases yet (Developer perspective),
but having a single context that provides values on demand I believe will be simpler in all


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message