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