commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: svn commit: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integration/ main/java/org/apache/commons/math/analysis/interpolat...
Date Wed, 03 Nov 2010 19:28:47 GMT
On 11/3/10 12:01 PM, Gilles Sadowski wrote:
>>> URL:
>>> Log:
>>> MATH-195
>>> Created an unchecked "FunctionEvaluationException" in package
>>> "exception".
>>> Removed "throws" clause from interface "UnivariateRealFunction".
>>> "PolynomialFunctionLagrangeForm": Added early check on the
>>> interpolating
>>> array having distinct points; removed redundant test in methods
>>> "evaluate"
>>> and "computeCoefficients".
>>> "DividedDifferenceInerpolator": Removed redundant check.
>>> "Mathutils": Added method "sortInPlace". Removed (most) references to
>>> the
>>> deprecated "MathRuntimeException" class.
>>> "": Removed deprecated classes.
>>> Javadoc clean up.
>> Some of theses changes should have been on separate commits. [...]
> This *might* be true, but not necessarily so; some changes/additions (e.g.
> "sortInPlace" were cascaded from a previous modification, and were necessary
> to allow compilation and/or tests to pass. Please trust me that I try to
> change things by small bits. One cannot always easily foresee all the
> implications of a modification, and it's simply not worth the time it
> would take.

I disagree.  We need to separate and fully document our commits. 
Whatever client-side tooling we want to use, the requirement is 
individually documented atomic commits.  Large commits should be few 
and far between.  Large refactorings and changes to exception 
processing like what you are doing now in the 3.0 branch will 
necessarily lead to some large commits.  Especially in these cases, 
however, we want to carefully avoid introducing other changes that 
may be overlooked by reviewers and/or people later on trying to 
figure out how changes were made (the two main reasons that we favor 
smaller, individually documented commits).


> Also I'm not going to "svn co" a fresh copy of CM every time I
> encounter an issue that should have been better dealt with *before* the
> changes I'm currently performing (I already have two active ones).
> All of the above commit is related to issue MATH-195 (the aim of which is
> that all CM's exceptions should be in package "exception" and unchecked).
> "sortInPlace" was added here because it made it possible not to change
> something else (namely, allowing unsorted arrays).
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message