Baste Nesse Buanes created MATH-836:
---------------------------------------
Summary: Fraction(double, int) constructor strange behaviour
Key: MATH-836
URL: https://issues.apache.org/jira/browse/MATH-836
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Baste Nesse Buanes
Priority: Minor
The Fraction constructor Fraction(double, int) takes a double value and a int
maximal denominator, and approximates a fraction. When the double value is a
large, negative number with many digits in the fractional part, and the maximal
denominator is a big, positive integer (in the 100'000s), two distinct bugs can
manifest:
1: the constructor returns a positive Fraction. Calling
Fraction(-33655.1677817278, 371880) returns the fraction 410517235/243036,
which both has the wrong sign, and is far away from the absolute value of the
given value
2: the constructor does not manage to reduce the Fraction properly. Calling
Fraction(-43979.60679604749, 366081) returns the fraction -1651878166/256677,
which should have* been reduced to -24654898/3831.
I have, as of yet, not found a solution. The constructor looks like this:
public Fraction(double value, int maxDenominator)
throws FractionConversionException
{
this(value, 0, maxDenominator, 100);
}
Increasing the 100 value (max iterations) does not fix the problem for all
cases. Changing the 0-value (the epsilon, maximum allowed error) to something
small does not work either, as this breaks the tests in FractionTest.
The problem is not neccissarily that the algorithm is unable to approximate a
fraction correctly. A solution where a FractionConversionException had been
thrown in each of these examples would probably be the best solution if an
improvement on the approximation algorithm turns out to be hard to find.
This bug has been found when trying to explore the idea of axiom-based testing
(http://bldl.ii.uib.no/testing.html). Attached is a java test class
FractionTestByAxiom (junit, goes into org.apache.commons.math3.fraction) which
shows these bugs through a simplified approach to this kind of testing, and a
text file describing some of the value/maxDenominator combinations which causes
one of these failures.
* It is never specified in the documentation that the Fraction class guarantees
that completely reduced rational numbers are constructed, but a comment inside
the equals method claims that "since fractions are always in lowest terms,
numerators and can be compared directly for equality", so it seems like this is
the intention.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
