[jira] Created: (LANG-685) EqualsBuilder synchronizes on HashCodeBuilder
EqualsBuilder synchronizes on HashCodeBuilder - Key: LANG-685 URL: https://issues.apache.org/jira/browse/LANG-685 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: Nightly Builds Reporter: Christian Semrau Priority: Minor EqualsBuilder synchronizes on HashCodeBuilder.class for updates to its own threadlocal REGISTRY variable. While this should not lead to malfunction, it looks like a copypaste oversight. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-663) org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy and divideBy
[
https://issues.apache.org/jira/browse/LANG-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976662#action_12976662
]
Christian Semrau commented on LANG-663:
---
I favor having only one Fraction class, preferably in Math.
In MATH-251, the solution to overflow is using a larger number range
(BigInteger). This issue (LANG-663) and LANG-662 mention spurious overflows
that need not occur when using int: The overflows mentioned here can be
avoided. Of course, there are many overflows that cannot be avoided, and
therefore BigFraction was a valueable addition.
org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy
and divideBy
-
Key: LANG-663
URL: https://issues.apache.org/jira/browse/LANG-663
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
Fix For: 3.0
The Fraction.multiplyBy and divideBy methods fail sometimes when the
arguments are not reduced.
{code:title=FunctionTest.java|borderStyle=solid}
public void testMultiply() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.multiplyBy(f2);
assertEquals(42, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testDivide() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.divideBy(f2);
assertEquals(1, f.getNumerator());
assertEquals(42, f.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-663) org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy and divideBy
[
https://issues.apache.org/jira/browse/LANG-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976735#action_12976735
]
Christian Semrau commented on LANG-663:
---
Oh, and seeing that method Fraction.addSub (both in Lang and Math) does all it
can to ensure that spurious overflow is prevented (by using a BigInteger for an
intermediate value), I wonder if the overflow of 2 / 3 divided by MIN_VALUE / 3
would be acceptable (in the Math version!), when it can be prevented too.
org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy
and divideBy
-
Key: LANG-663
URL: https://issues.apache.org/jira/browse/LANG-663
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
Fix For: 3.0
The Fraction.multiplyBy and divideBy methods fail sometimes when the
arguments are not reduced.
{code:title=FunctionTest.java|borderStyle=solid}
public void testMultiply() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.multiplyBy(f2);
assertEquals(42, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testDivide() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.divideBy(f2);
assertEquals(1, f.getNumerator());
assertEquals(42, f.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-662) org.apache.commons.lang3.math.Fraction does not reduce (Integer.MIN_VALUE, 2^k)
[
https://issues.apache.org/jira/browse/LANG-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976744#action_12976744
]
Christian Semrau commented on LANG-662:
---
The commons-math version does not have this overflow in its gcd implementation,
and it can be easily prevented.
But as written in LANG-663, I'd drop the commons-lang Fraction class in favor
of commons-math Fraction.
org.apache.commons.lang3.math.Fraction does not reduce (Integer.MIN_VALUE,
2^k)
---
Key: LANG-662
URL: https://issues.apache.org/jira/browse/LANG-662
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
Fix For: 3.0
The greatestCommonDivisor method in class Fraction does not find the gcd of
Integer.MIN_VALUE and 2^k, and this case can be triggered by taking
Integer.MIN_VALUE as the numerator. Note that the case of taking
Integer.MIN_VALUE as the denominator is handled explicitly in the
getReducedFraction factory method.
{code:title=FractionTest.java|borderStyle=solid}
// additional test cases
public void testReducedFactory_int_int() {
// ...
f = Fraction.getReducedFraction(Integer.MIN_VALUE, 2);
assertEquals(Integer.MIN_VALUE / 2, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testReduce() {
// ...
f = Fraction.getFraction(Integer.MIN_VALUE, 2);
result = f.reduce();
assertEquals(Integer.MIN_VALUE / 2, result.getNumerator());
assertEquals(1, result.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-662) org.apache.commons.lang3.math.Fraction does not reduce (Integer.MIN_VALUE, 2^k)
org.apache.commons.lang3.math.Fraction does not reduce (Integer.MIN_VALUE, 2^k)
---
Key: LANG-662
URL: https://issues.apache.org/jira/browse/LANG-662
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
The greatestCommonDivisor method in class Fraction does not find the gcd of
Integer.MIN_VALUE and 2^k, and this case can be triggered by taking
Integer.MIN_VALUE as the numerator. Note that the case of taking
Integer.MIN_VALUE as the denominator is handled explicitly in the
getReducedFraction factory method.
{code:title=FractionTest.java|borderStyle=solid}
// additional test cases
public void testReducedFactory_int_int() {
// ...
f = Fraction.getReducedFraction(Integer.MIN_VALUE, 2);
assertEquals(Integer.MIN_VALUE / 2, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testReduce() {
// ...
f = Fraction.getFraction(Integer.MIN_VALUE, 2);
result = f.reduce();
assertEquals(Integer.MIN_VALUE / 2, result.getNumerator());
assertEquals(1, result.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-662) org.apache.commons.lang3.math.Fraction does not reduce (Integer.MIN_VALUE, 2^k)
[
https://issues.apache.org/jira/browse/LANG-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968469#action_12968469
]
Christian Semrau commented on LANG-662:
---
The current implementation:
{code:title=Fraction.java|borderStyle=solid}
private static int greatestCommonDivisor(int u, int v) {
//if either op. is abs 0 or 1, return 1:
if (Math.abs(u) = 1 || Math.abs(v) = 1) {
return 1;
}
{code}
The case u==0 || v==0 is already handled at the calling site (). So you might
switch to testing for abs==1 only:
{code:title=Fraction.java|borderStyle=solid}
private static int greatestCommonDivisor(int u, int v) {
// the case u==0 || v==0 is handled by the caller.
// if either op. is abs 1, return 1:
if (Math.abs(u) == 1 || Math.abs(v) == 1) {
return 1;
}
{code}
Dropping this test altogether does not change correctness, but might influence
performance. If you expect many fractions with numerator 1 or denominator 1,
keep the test.
org.apache.commons.lang3.math.Fraction does not reduce (Integer.MIN_VALUE,
2^k)
---
Key: LANG-662
URL: https://issues.apache.org/jira/browse/LANG-662
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
The greatestCommonDivisor method in class Fraction does not find the gcd of
Integer.MIN_VALUE and 2^k, and this case can be triggered by taking
Integer.MIN_VALUE as the numerator. Note that the case of taking
Integer.MIN_VALUE as the denominator is handled explicitly in the
getReducedFraction factory method.
{code:title=FractionTest.java|borderStyle=solid}
// additional test cases
public void testReducedFactory_int_int() {
// ...
f = Fraction.getReducedFraction(Integer.MIN_VALUE, 2);
assertEquals(Integer.MIN_VALUE / 2, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testReduce() {
// ...
f = Fraction.getFraction(Integer.MIN_VALUE, 2);
result = f.reduce();
assertEquals(Integer.MIN_VALUE / 2, result.getNumerator());
assertEquals(1, result.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-663) org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy and divideBy
org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy
and divideBy
-
Key: LANG-663
URL: https://issues.apache.org/jira/browse/LANG-663
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
The Fraction.multiplyBy and divideBy methods fail sometimes when the arguments
are not reduced.
{code:title=FunctionTest.java|borderStyle=solid}
public void testMultiply() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.multiplyBy(f2);
assertEquals(42, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testDivide() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.divideBy(f2);
assertEquals(1, f.getNumerator());
assertEquals(42, f.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-663) org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy and divideBy
[
https://issues.apache.org/jira/browse/LANG-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968478#action_12968478
]
Christian Semrau commented on LANG-663:
---
These methods fail to reduce their arguments. This may be due to the
commons-math Fraction (which seems to be the source) is always in reduced form.
But commons-lang Fraction is not always reduced, and so multiplyBy must reduce
its arguments, before cross-reducing the two arguments.
org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy
and divideBy
-
Key: LANG-663
URL: https://issues.apache.org/jira/browse/LANG-663
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
The Fraction.multiplyBy and divideBy methods fail sometimes when the
arguments are not reduced.
{code:title=FunctionTest.java|borderStyle=solid}
public void testMultiply() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.multiplyBy(f2);
assertEquals(42, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testDivide() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.divideBy(f2);
assertEquals(1, f.getNumerator());
assertEquals(42, f.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-663) org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy and divideBy
[
https://issues.apache.org/jira/browse/LANG-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968480#action_12968480
]
Christian Semrau commented on LANG-663:
---
Even if both arguments are reduced, if the divisor has numerator
Integer.MIN_VALUE, divideBy may fail despite the quotient being representable
with positive denominator.
{code:title=FractionTest.java|borderStyle=solid}
public void testDivide() {
// ...
f1 = Fraction.getFraction(2, 3);
f2 = Fraction.getFraction(Integer.MIN_VALUE, 3);
f = f1.divideBy(f2);
assertEquals(-1, f.getNumerator());
assertEquals(-Integer.MIN_VALUE / 2, f.getDenominator());
{code}
org.apache.commons.lang3.math.Fraction does not always succeed in multiplyBy
and divideBy
-
Key: LANG-663
URL: https://issues.apache.org/jira/browse/LANG-663
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.0
Reporter: Christian Semrau
Priority: Minor
The Fraction.multiplyBy and divideBy methods fail sometimes when the
arguments are not reduced.
{code:title=FunctionTest.java|borderStyle=solid}
public void testMultiply() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.multiplyBy(f2);
assertEquals(42, f.getNumerator());
assertEquals(1, f.getDenominator());
public void testDivide() {
// ...
f1 = Fraction.getFraction(Integer.MAX_VALUE, Integer.MAX_VALUE);
f2 = Fraction.getFraction(42, 1);
f = f1.divideBy(f2);
assertEquals(1, f.getNumerator());
assertEquals(42, f.getDenominator());
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-239) Add gcd and lcm for long values in MathUtils
[ https://issues.apache.org/jira/browse/MATH-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Semrau updated MATH-239: -- Attachment: gcdForLong.txt The long versions of gcd and lcm are adapted copies of the int versions. I added some verification of exception messages to the tests, because I saw the change to gcd(int, int) where the exception message now contains the illegal arguments. To facilitate these (and possibly other) verifications, I added TestUtils.assertMessageContains(). Two of these verifications fail, because the exception is thrown by mulAndCheck without the illegal arguments; they are commented. Add gcd and lcm for long values in MathUtils Key: MATH-239 URL: https://issues.apache.org/jira/browse/MATH-239 Project: Commons Math Issue Type: New Feature Reporter: Christian Semrau Priority: Minor Fix For: 2.1 Attachments: gcdForLong.txt I suggest adding MathUtils.gcd and MathUtils.lcm for long values in addition to the methods for int values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-248) Multiplying sparse matrices is slow
Multiplying sparse matrices is slow --- Key: MATH-248 URL: https://issues.apache.org/jira/browse/MATH-248 Project: Commons Math Issue Type: Improvement Reporter: Christian Semrau Priority: Minor The multiplication of sparse real matrices is very slow compared to real matrices: Ten times as slow for size 200, four times as slow for size 400. The time is independent of the number of nonzero entries, because the general algorithm inherited from AbstractRealMatrix is used. I suggest using a specialized multiplication algorithm for matrices that are sparse enough, walking only over the nonzero entries in one of the matrices. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-248) Multiplying sparse matrices is slow
[ https://issues.apache.org/jira/browse/MATH-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675698#action_12675698 ] Christian Semrau commented on MATH-248: --- According to my little tests, walking in optimized order and adding the pairwise products to the result matrix is much faster for very sparse matrices, but for a full matrix (every entry set to 1), it is about 50% slower than the current implementation. So the implementation might switch between the two algorithms. Also one might wish to walk the other matrix if it is more sparse than this. Multiplying sparse matrices is slow --- Key: MATH-248 URL: https://issues.apache.org/jira/browse/MATH-248 Project: Commons Math Issue Type: Improvement Reporter: Christian Semrau Priority: Minor The multiplication of sparse real matrices is very slow compared to real matrices: Ten times as slow for size 200, four times as slow for size 400. The time is independent of the number of nonzero entries, because the general algorithm inherited from AbstractRealMatrix is used. I suggest using a specialized multiplication algorithm for matrices that are sparse enough, walking only over the nonzero entries in one of the matrices. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-243) MathUtils.gcd(Integer.MIN_VALUE, 0) should throw an Exception instead of returning Integer.MIN_VALUE
MathUtils.gcd(Integer.MIN_VALUE, 0) should throw an Exception instead of returning Integer.MIN_VALUE Key: MATH-243 URL: https://issues.apache.org/jira/browse/MATH-243 Project: Commons Math Issue Type: Bug Reporter: Christian Semrau Priority: Minor The gcd method should throw an Exception for gcd(Integer.MIN_VALUE, 0), like for gcd(Integer.MIN_VALUE, Integer.MIN_VALUE). The method should only return nonnegative results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-242) Missing tests in MathUtilsTest
[ https://issues.apache.org/jira/browse/MATH-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665979#action_12665979 ] Christian Semrau commented on MATH-242: --- Opened another issue: MATH-243 Missing tests in MathUtilsTest -- Key: MATH-242 URL: https://issues.apache.org/jira/browse/MATH-242 Project: Commons Math Issue Type: Test Affects Versions: 1.0, 1.1, 1.2 Reporter: Christian Semrau Priority: Minor Fix For: 2.0 Attachments: MathUtilsTestPatch.txt Using EclEmma, I spotted some methods and special cases in MathUtils that were not tested. I will attach a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-243) MathUtils.gcd(Integer.MIN_VALUE, 0) should throw an Exception instead of returning Integer.MIN_VALUE
[ https://issues.apache.org/jira/browse/MATH-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Semrau updated MATH-243: -- Attachment: gcdPatch.txt Attached is a patch for gcd, and also for lcm, which failed for some special cases: lcm failed for (0,0) and for (Integer.MIN_VALUE, power of 2). I also added Javadoc for special cases. MathUtils.gcd(Integer.MIN_VALUE, 0) should throw an Exception instead of returning Integer.MIN_VALUE Key: MATH-243 URL: https://issues.apache.org/jira/browse/MATH-243 Project: Commons Math Issue Type: Bug Reporter: Christian Semrau Priority: Minor Attachments: gcdPatch.txt The gcd method should throw an Exception for gcd(Integer.MIN_VALUE, 0), like for gcd(Integer.MIN_VALUE, Integer.MIN_VALUE). The method should only return nonnegative results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-242) Missing tests in MathUtilsTest
Missing tests in MathUtilsTest -- Key: MATH-242 URL: https://issues.apache.org/jira/browse/MATH-242 Project: Commons Math Issue Type: Test Affects Versions: 2.0 Reporter: Christian Semrau Priority: Minor Using EclEmma, I spotted some methods and special cases in MathUtils that were not tested. I will attach a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-242) Missing tests in MathUtilsTest
[ https://issues.apache.org/jira/browse/MATH-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665583#action_12665583 ] Christian Semrau commented on MATH-242: --- After thinking a bit longer, I think the gcd method should throw an Exception for gcd(Integer.MIN_VALUE, 0) too, like for gcd(Integer.MIN_VALUE, Integer.MIN_VALUE). So my patch verifies the current behaviour, but I suggest changing that: gcd should only return nonnegative results (a result of 0 can come from gcd(0,0)). Missing tests in MathUtilsTest -- Key: MATH-242 URL: https://issues.apache.org/jira/browse/MATH-242 Project: Commons Math Issue Type: Test Affects Versions: 2.0 Reporter: Christian Semrau Priority: Minor Attachments: MathUtilsTestPatch.txt Using EclEmma, I spotted some methods and special cases in MathUtils that were not tested. I will attach a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-241) MathUtils.binomialCoefficient(n,k) fails for large results
[
https://issues.apache.org/jira/browse/MATH-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665253#action_12665253
]
Christian Semrau commented on MATH-241:
---
I think the recursive computation of Pascal's triangle (even with caching or
dynamic programming) is unnecessarily complicated except to ensure correct
values.
The attached patch ensures accuracy for all values that can be represented as a
long integer, with a running time proportional to k*log(k) (assuming gcd(i,j)
takes log(j) steps). It should be faster than the current version for n = 61,
but for n 61 my version computes as much as k different gcd values, which
might be slower.
I did not modify the double and log version, but your patch can be applied to
these.
MathUtils.binomialCoefficient(n,k) fails for large results
--
Key: MATH-241
URL: https://issues.apache.org/jira/browse/MATH-241
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.0
Reporter: Christian Semrau
Assignee: Phil Steitz
Fix For: 2.0
Attachments: binomialPatch.txt, binomialPatch_cs.txt
Probably due to rounding errors, MathUtils.binomialCoefficient(n,k) fails for
results near Long.MAX_VALUE.
The existence of failures can be demonstrated by testing the recursive
property:
{noformat}
assertEquals(MathUtils.binomialCoefficient(65,32) +
MathUtils.binomialCoefficient(65,33),
MathUtils.binomialCoefficient(66,33));
{noformat}
Or by directly using the (externally calculated and hopefully correct)
expected value:
{noformat}
assertEquals(7219428434016265740L,
MathUtils.binomialCoefficient(66,33));
{noformat}
I suggest a nonrecursive test implementation along the lines of
{code:title=MathUtilsTest.java|borderStyle=solid}
/**
* Exact implementation using BigInteger and the explicit formula
* (n, k) == ((k-1)*...*n) / (1*...*(n-k))
*/
public static long binomialCoefficient(int n, int k) {
if (k == 0 || k == n)
return 1;
BigInteger result = BigInteger.ONE;
for (int i = k + 1; i = n; i++) {
result = result.multiply(BigInteger.valueOf(i));
}
for (int i = 1; i = n - k; i++) {
result = result.divide(BigInteger.valueOf(i));
}
if (result.compareTo(BigInteger.valueOf(Long.MAX_VALUE)) 0) {
throw new ArithmeticException(
Binomial coefficient overflow: + n + ,
+ k);
}
return result.longValue();
}
{code}
Which would allow you to test the expected values directly:
{noformat}
assertEquals(binomialCoefficient(66,33),
MathUtils.binomialCoefficient(66,33));
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-238) MathUtils.gcd(u, v) fails when u and v both contain a high power of 2
MathUtils.gcd(u, v) fails when u and v both contain a high power of 2
-
Key: MATH-238
URL: https://issues.apache.org/jira/browse/MATH-238
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.0
Reporter: Christian Semrau
Priority: Minor
The test at the beginning of MathUtils.gcd(u, v) for arguments equal to zero
fails when u and v contain high enough powers of 2 so that their product
overflows to zero.
assertEquals(3 * (115), MathUtils.gcd(3 * (120), 9 * (115)));
Fix: Replace the test at the start of MathUtils.gcd()
if (u * v == 0) {
by
if (u == 0 || v == 0) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-239) Add gcd and lcm for long values in MathUtils
Add gcd and lcm for long values in MathUtils Key: MATH-239 URL: https://issues.apache.org/jira/browse/MATH-239 Project: Commons Math Issue Type: New Feature Reporter: Christian Semrau Priority: Minor I suggest adding MathUtils.gcd and MathUtils.lcm for long values in addition to the methods for int values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-240) MathUtils.factorial(n) fails for n = 17
[
https://issues.apache.org/jira/browse/MATH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Semrau updated MATH-240:
--
Description:
The result of MathUtils.factorial( n ) for n = 17...20 is wrong, probably
because of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
was:
The result of MathUtils.factorial(n) for n = 17...20 is wrong, probably because
of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
MathUtils.factorial(n) fails for n = 17
Key: MATH-240
URL: https://issues.apache.org/jira/browse/MATH-240
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.0
Reporter: Christian Semrau
Priority: Minor
The result of MathUtils.factorial( n ) for n = 17...20 is wrong, probably
because of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-240) MathUtils.factorial(n) fails for n = 17
MathUtils.factorial(n) fails for n = 17
Key: MATH-240
URL: https://issues.apache.org/jira/browse/MATH-240
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.0
Reporter: Christian Semrau
Priority: Minor
The result of MathUtils.factorial(n) for n = 17...20 is wrong, probably because
of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-240) MathUtils.factorial(n) fails for n = 17
[
https://issues.apache.org/jira/browse/MATH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Semrau updated MATH-240:
--
Description:
The result of MathUtils.factorial( n ) for n = 17, 18, 19 is wrong, probably
because of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
I suggest implementing a simple loop to multiply the long result - or even
using a precomputed long[] - instead of adding logarithms.
was:
The result of MathUtils.factorial( n ) for n = 17...20 is wrong, probably
because of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
MathUtils.factorial(n) fails for n = 17
Key: MATH-240
URL: https://issues.apache.org/jira/browse/MATH-240
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.0
Reporter: Christian Semrau
Priority: Minor
The result of MathUtils.factorial( n ) for n = 17, 18, 19 is wrong, probably
because of rounding errors in the double calculations.
Replace the first line of MathUtilsTest.testFactorial() by
for (int i = 1; i = 20; i++) {
to check all valid arguments for the long result and see the failure.
I suggest implementing a simple loop to multiply the long result - or even
using a precomputed long[] - instead of adding logarithms.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-241) MathUtils.binomialCoefficient(n,k) fails for large results
[
https://issues.apache.org/jira/browse/MATH-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Semrau updated MATH-241:
--
Description:
Probably due to rounding errors, MathUtils.binomialCoefficient(n,k) fails for
results near Long.MAX_VALUE.
The existence of failures can be demonstrated by testing the recursive property:
{noformat}
assertEquals(MathUtils.binomialCoefficient(65,32) +
MathUtils.binomialCoefficient(65,33),
MathUtils.binomialCoefficient(66,33));
{noformat}
Or by directly using the (externally calculated and hopefully correct) expected
value:
{noformat}
assertEquals(7219428434016265740L,
MathUtils.binomialCoefficient(66,33));
{noformat}
I suggest a nonrecursive test implementation along the lines of
{code:title=MathUtilsTest.java|borderStyle=solid}
/**
* Exact implementation using BigInteger and the explicit formula
* (n, k) == ((k-1)*...*n) / (1*...*(n-k))
*/
public static long binomialCoefficient(int n, int k) {
if (k == 0 || k == n)
return 1;
BigInteger result = BigInteger.ONE;
for (int i = k + 1; i = n; i++) {
result = result.multiply(BigInteger.valueOf(i));
}
for (int i = 1; i = n - k; i++) {
result = result.divide(BigInteger.valueOf(i));
}
if (result.compareTo(BigInteger.valueOf(Long.MAX_VALUE)) 0) {
throw new ArithmeticException(
Binomial coefficient overflow: + n + , +
k);
}
return result.longValue();
}
{code}
Which would allow you to test the expected values directly:
{noformat}
assertEquals(binomialCoefficient(66,33),
MathUtils.binomialCoefficient(66,33));
{noformat}
was:
Probably due to rounding errors, MathUtils.binomialCoefficient(n,k) fails for
results near Long.MAX_VALUE.
The existence of failures can be demonstrated by testing the recursion property:
assertEquals(MathUtils.binomialCoefficient(66,33),
MathUtils.binomialCoefficient(65,32) + MathUtils.binomialCoefficient(65,33));
I suggest a nonrecursive test implementation along the lines of
/**
* Exact implementation using BigInteger and the explicit formula (n, k) ==
((k-1)*...*n) / (1*...*(n-k))
*/
public static long binomialCoefficient(int n, int k) {
if (k == 0 || k == n)
return 1;
BigInteger result = BigInteger.ONE;
for (int i = k + 1; i = n; i++) {
result = result.multiply(BigInteger.valueOf(i));
}
for (int i = 1; i = n - k; i++) {
result = result.divide(BigInteger.valueOf(i));
}
if (result.compareTo(BigInteger.valueOf(Long.MAX_VALUE)) 0) {
throw new ArithmeticException(Binomial coefficient
overflow: + n + , + k);
}
return result.longValue();
}
Which would allow you to test the expected values directly:
assertEquals(binomialCoefficient(66,33),
MathUtils.binomialCoefficient(66,33));
MathUtils.binomialCoefficient(n,k) fails for large results
--
Key: MATH-241
URL: https://issues.apache.org/jira/browse/MATH-241
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.0
Reporter: Christian Semrau
Probably due to rounding errors, MathUtils.binomialCoefficient(n,k) fails for
results near Long.MAX_VALUE.
The existence of failures can be demonstrated by testing the recursive
property:
{noformat}
assertEquals(MathUtils.binomialCoefficient(65,32) +
MathUtils.binomialCoefficient(65,33),
MathUtils.binomialCoefficient(66,33));
{noformat}
Or by directly using the (externally calculated and hopefully correct)
expected value:
{noformat}
assertEquals(7219428434016265740L,
MathUtils.binomialCoefficient(66,33));
{noformat}
I suggest a nonrecursive test implementation along the lines of
{code:title=MathUtilsTest.java|borderStyle=solid}
/**
* Exact implementation using BigInteger and the explicit formula
* (n, k) == ((k-1)*...*n) / (1*...*(n-k))
*/
public static long binomialCoefficient(int n, int k) {
if (k == 0 || k == n)
return 1;
BigInteger result = BigInteger.ONE;
for (int i = k + 1; i = n; i++) {
result = result.multiply(BigInteger.valueOf(i));
}
for (int i = 1; i = n - k; i++) {
result = result.divide(BigInteger.valueOf(i));
[jira] Created: (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
Modifications of a SetUniqueList.subList() invalidate the parent list
-
Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello, contained
in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed (which
fails).
And of course the parent list should know what happens to it (specifically, its
uniqueness Set) (which fails in the current snapshot).
public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Goodbye);
List expectedSubList = Arrays.asList(new Object[] { World,
Goodbye });
List expectedParentList = Arrays.asList(new Object[] { Hello,
World, Goodbye });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains(Goodbye)); // fails
}
public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Hello);
List expectedSubList = Arrays.asList(new Object[] { World,
Hello });
List expectedParentList = Arrays.asList(new Object[] { World,
Hello });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.set(0, Hello);
List expectedSubList = Arrays.asList(new Object[] { Hello });
List expectedParentList = Arrays.asList(new Object[] { Hello
});
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662689#action_12662689
]
Christian Semrau commented on COLLECTIONS-310:
--
It seems that properties of the SetUniqueList.subList are currently not tested:
The bulk tests for TestSetUniqueList are disabled.
I managed to enable them by using a copy of BulkTestSubList which is subclassed
from TestSetUniqueList instead of AbstractTestList, and which disables
extraVerify for itself and the outer test. For the bulkTestListIterator,
TestListIterator.supportsSet() must return false (but then still one test
fails).
But maybe this should be subject of a different jira issue.
Modifications of a SetUniqueList.subList() invalidate the parent list
-
Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello,
contained in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed
(which fails).
And of course the parent list should know what happens to it (specifically,
its uniqueness Set) (which fails in the current snapshot).
public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Goodbye);
List expectedSubList = Arrays.asList(new Object[] { World,
Goodbye });
List expectedParentList = Arrays.asList(new Object[] { Hello,
World, Goodbye });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains(Goodbye)); // fails
}
public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Hello);
List expectedSubList = Arrays.asList(new Object[] { World,
Hello });
List expectedParentList = Arrays.asList(new Object[] { World,
Hello });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.set(0, Hello);
List expectedSubList = Arrays.asList(new Object[] { Hello });
List expectedParentList = Arrays.asList(new Object[] { Hello
});
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-307) SetUniqueList.subList().contains() method checks against full parent list, not sublist range
[ https://issues.apache.org/jira/browse/COLLECTIONS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646952#action_12646952 ] Christian Semrau commented on COLLECTIONS-307: -- The same problem occurs with containsAll(). SetUniqueList.subList().contains() method checks against full parent list, not sublist range Key: COLLECTIONS-307 URL: https://issues.apache.org/jira/browse/COLLECTIONS-307 Project: Commons Collections Issue Type: Bug Components: List Affects Versions: 3.2 Reporter: Christian Semrau Priority: Minor The view returned by the subList() method of a SetUniqueList checks contains() against the set of the original list. As shown by the following test snippet. List list = new ArrayList(); List uniqueList = SetUniqueList.decorate(list); uniqueList.add(Hello); uniqueList.add(World); List subList = list.subList(0, 0); List subUniqueList = uniqueList.subList(0, 0); assertFalse(subList.contains(World)); // passes assertFalse(subUniqueList.contains(World)); // fails -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
