[math] refactoring least squares

[luc <lu...@spaceroots.org>]

Hi all,

As you have probably noticed, I have committed the changes proposed by 
Evan. This ends up to about 20 different commits,
as I have tried to stick with the progressive changes he made in his 
Github repository. Some of the initial commits
do not abide by our development rules (missing Apache headers, author 
tags or some checkstyle problems), but some have been
fixed in intermediate commits by Evan himself months ago during the 
discussions with Gilles, and I have fixed the remaining
ones in the final commits. So if you take the current status, it is 
compliant.

I kept the single leastsquares package, so did not introduce an 
additional leastsquares2.

I have also taken care to preserve all changes already done since last 
summer when Evan designed his code. In particular, this
means the new curve fitters have been adapted so they both use the new 
package and fix MAX-1014 has Gilles already did that.

I would like to ask Evan to check in case I have mixed something, and 
after this check we can look at polishing this and
perhaps extending some parts to other optimizers or move some interfaces 
upward if necessary.

best regards
Luc

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

Re: [math] refactoring least squares

[Luc Maisonobe <lu...@spaceroots.org>]

Le 18/02/2014 23:57, Evan Ward a écrit :
> 
> On 02/18/2014 09:51 AM, luc wrote:
>> Hi all,
>>
>> As you have probably noticed, I have committed the changes proposed by
>> Evan. This ends up to about 20 different commits,
>> as I have tried to stick with the progressive changes he made in his
>> Github repository. Some of the initial commits
>> do not abide by our development rules (missing Apache headers, author
>> tags or some checkstyle problems), but some have been
>> fixed in intermediate commits by Evan himself months ago during the
>> discussions with Gilles, and I have fixed the remaining
>> ones in the final commits. So if you take the current status, it is
>> compliant.
>>
>> I kept the single leastsquares package, so did not introduce an
>> additional leastsquares2.
>>
>> I have also taken care to preserve all changes already done since last
>> summer when Evan designed his code. In particular, this
>> means the new curve fitters have been adapted so they both use the new
>> package and fix MAX-1014 has Gilles already did that.
>>
>> I would like to ask Evan to check in case I have mixed something, and
>> after this check we can look at polishing this and
>> perhaps extending some parts to other optimizers or move some
>> interfaces upward if necessary.
> 
> Thanks Luc! It looks good to me.
> 
> One thing I would like to change/add before the 3.3 release are the
> decomposition algorithms for GaussNewton. Using a CholeskyDecomposition
> on the normal equations should be faster than LU by a factor of 2.
> Similarly, using QR on the Jacobian, before forming the normal equations
> should be more stable than any method that forms the normal equations. I
> can implement these changes as extra Decomposition options. What is the
> best way to send the patches? Attachments on JIRA? Pull requests on github?

The best way is attachments to JIRA for now.
As our git-svn clone was started differently, your repository and mine
do not share common history (its probably my fault as I think I created
a clone by myself instead of using the one from git.apache). This
implies that bringing in patches is done using "git cherry-pick" and not
a simpler "git merge".

> 
> Out of curiosity, why is /** {@inheritDoc} */ required? Isn't that the
> default?

It is the default for the javadoc tool itself, but checkstyle still
complains about missing javadoc.

best regards,
Luc

> 
> Best Regards,
> Evan
> 
>> best regards
>> Luc
>>
>> ---------------------------------------------------------------------
>> 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
> 
> 
> 


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

Re: [math] refactoring least squares

[Evan Ward <ev...@nrl.navy.mil>]

On 02/18/2014 09:51 AM, luc wrote:
> Hi all,
>
> As you have probably noticed, I have committed the changes proposed by
> Evan. This ends up to about 20 different commits,
> as I have tried to stick with the progressive changes he made in his
> Github repository. Some of the initial commits
> do not abide by our development rules (missing Apache headers, author
> tags or some checkstyle problems), but some have been
> fixed in intermediate commits by Evan himself months ago during the
> discussions with Gilles, and I have fixed the remaining
> ones in the final commits. So if you take the current status, it is
> compliant.
>
> I kept the single leastsquares package, so did not introduce an
> additional leastsquares2.
>
> I have also taken care to preserve all changes already done since last
> summer when Evan designed his code. In particular, this
> means the new curve fitters have been adapted so they both use the new
> package and fix MAX-1014 has Gilles already did that.
>
> I would like to ask Evan to check in case I have mixed something, and
> after this check we can look at polishing this and
> perhaps extending some parts to other optimizers or move some
> interfaces upward if necessary.

Thanks Luc! It looks good to me.

One thing I would like to change/add before the 3.3 release are the
decomposition algorithms for GaussNewton. Using a CholeskyDecomposition
on the normal equations should be faster than LU by a factor of 2.
Similarly, using QR on the Jacobian, before forming the normal equations
should be more stable than any method that forms the normal equations. I
can implement these changes as extra Decomposition options. What is the
best way to send the patches? Attachments on JIRA? Pull requests on github?

Out of curiosity, why is /** {@inheritDoc} */ required? Isn't that the
default?

Best Regards,
Evan

> best regards
> Luc
>
> ---------------------------------------------------------------------
> 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