[math] LevenbergMarquardt Evaluation Lazy vs. Unlazy

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[math] LevenbergMarquardt Evaluation Lazy vs. Unlazy

ole ersoy
Hi,

Has anyone performed any benchmarking on lazy vs. unlazy Evaluation(s) 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?

TIA,
Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] LevenbergMarquardt Evaluation Lazy vs. Unlazy

Gilles Sadowski
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:
   https://issues.apache.org/jira/browse/MATH-1128

> 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.

Gilles

>
> TIA,
> Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] LevenbergMarquardt Evaluation Lazy vs. Unlazy

ole ersoy


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:
>   https://issues.apache.org/jira/browse/MATH-1128
>
>> 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)?

Ole

>
> Gilles
>
>>
>> TIA,
>> Ole
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] LevenbergMarquardt Evaluation Lazy vs. Unlazy

Gilles Sadowski
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:
>>   https://issues.apache.org/jira/browse/MATH-1128
>>
>>> 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.
So the grouping was deemed a simplification.  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...).

Regards,
Gilles

>
> Ole
>
>>
>> Gilles
>>
>>>
>>> TIA,
>>> Ole
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] LevenbergMarquardt Evaluation Lazy vs. Unlazy

ole ersoy


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:
>>>   https://issues.apache.org/jira/browse/MATH-1128
>>>
>>>> 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 cases.

Cheers,
Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]