In regards to your first comments. I do not understand your point. You
are implementing large API changes, but refuse to take the final step
that would tie everything together and make it robust for future
changes.
In regards to second comments, you can make it whatever interface
hierarchy that you want. I was just pointing out that there is a new
to propagate information from previous evaluations in a way that is
not known ahead of time. I am not presenting some implementation
version of the code.
On Mon, Aug 26, 2013 at 3:43 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Mon, 26 Aug 2013 15:11:22 -0400, Konstantin Berlin wrote:
>>
>> I looked only at the GuassNewton class as a general guide to how
>> things work. I like it a lot! I only wish all of the optimizations
>> were rewritten in this way.
>>
>> Several comments
>>
>> 1) I believe this code can now be simplified
>>
>> // build the linear problem
>> final double[] b = new double[nC];
>> final double[][] a = new double[nC][nC];
>> for (int i = 0; i < nR; ++i) {
>>
>> final double[] grad = weightedJacobian.getRow(i);
>> final double residual = currentResiduals.getEntry(i);
>>
>> // compute the normal equation
>> //residual is already weighted
>> for (int j = 0; j < nC; ++j) {
>> b[j] += residual * grad[j];
>> }
>>
>> // build the contribution matrix for measurement i
>> for (int k = 0; k < nC; ++k) {
>> double[] ak = a[k];
>> //Jacobian/gradient is already weighted
>> for (int l = 0; l < nC; ++l) {
>> ak[l] += grad[k] * grad[l];
>> }
>> }
>> }
>>
>> Should be just this (I haven't checked the math)
>>
>> jt = weightedJacobian.transpose();
>> a = jt* weightedJacobian;
>> b= jt*currentResiduals;
>
>
> I've adviced against too many changes at once.
> [A good idea will not become stale if its application is delayed
> a little.]
>
>
>>
>> 2) Based on the reasons I previously describe, would it be possible to
>> separate the newton step into a separate function (which you would
>> also add to the interface)?
>> The idea here is that solving for the newton step can be
>> computationally intensive depending on the size of the problem. So
>> there is no one universal approach. There are several somewhat
>> different ways that his can be solved, with
>> some methods requiring information from previous steps in order to
>> work. This would also allow to plug in line search or trust region
>> control of step size. In order to allow all of these approaches, I
>> would suggest this function:
>>
>> //this function would solve for dX
>> public NewtonStepResult solveStep(LeastSquaresProblem lsp, RealVector
>> currentPoint, Object prevStepInfo)
>> {
>> NewtonStepResult result = new NewtonStepResult();
>>
>> //code to solve for the next step dx followed by
>> result.newtonStep = dx;
>>
>> //code to update the step information
>> //leave blank for now
>> result.stepInfo = null;
>> }
>>
>> where
>>
>> public class NewtonStepResult
>> {
>> public class RealVector newtonStep;
>> public class Object stepInfo;
>> }
>
>
> I can't comment on the math principle but on from a programming
> viewpoint, an "Object" is a no-no. :-)
>
>
> Gilles
>
>
>>
>>
>> Please tell me if what I wrote is not clear.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
