commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] refactoring least squares
Date Wed, 19 Feb 2014 08:34:16 GMT
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,

> Best Regards,
> Evan
>> best regards
>> Luc
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message