You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Baste Nesse Buanes (JIRA)" <ji...@apache.org> on 2012/07/31 19:04:35 UTC
[jira] [Created] (MATH-836) Fraction(double, int) constructor
strange behaviour
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
[jira] [Comment Edited] (MATH-836) Fraction(double, int)
constructor strange behaviour
Posted by "Baste Nesse Buanes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425925#comment-13425925 ]
Baste Nesse Buanes edited comment on MATH-836 at 7/31/12 5:07 PM:
------------------------------------------------------------------
FractionTestByAxiom added: Tests the Fraction class through axioms. Not intended to be a part of a finished product, but to explore the class, looking for bugs.
was (Author: snalin):
Tests the Fraction class through axioms. Not intended to be a part of a finished product, but to explore the class, looking for bugs.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Commented] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Thomas Neidhart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426914#comment-13426914 ]
Thomas Neidhart commented on MATH-836:
--------------------------------------
Committed the changes in r1368253.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Comment Edited] (MATH-836) Fraction(double, int)
constructor strange behaviour
Posted by "Baste Nesse Buanes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425925#comment-13425925 ]
Baste Nesse Buanes edited comment on MATH-836 at 7/31/12 5:08 PM:
------------------------------------------------------------------
FractionTestByAxiom.java added: Tests the Fraction class through axioms. Not intended to be a part of a finished product, but to explore the class, looking for bugs.
was (Author: snalin):
FractionTestByAxiom added: Tests the Fraction class through axioms. Not intended to be a part of a finished product, but to explore the class, looking for bugs.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Resolved] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Thomas Neidhart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Neidhart resolved MATH-836.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.1
Thanks for the info. This work looks really interested. If you need any support in further testing commons-math or any other commons component, do not hesitate to ask.
I resolve this issue now, as it seems to fix your problems.
Thomas
> 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
> Labels: Fraction
> Fix For: 3.1
>
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Commented] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Baste Nesse Buanes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427212#comment-13427212 ]
Baste Nesse Buanes commented on MATH-836:
-----------------------------------------
Thomas - the test cases are not auto-generated, they are hand-written. We're working on a tool - JaxT2 - that interprets axioms for classes and auto-generates unit tests through reflection, to improve on the old JaxT tool (http://www.ii.uib.no/mouldable/testing/jaxt/index.html).
Good job with the overflow.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Updated] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Baste Nesse Buanes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Baste Nesse Buanes updated MATH-836:
------------------------------------
Attachment: FractionTestByAxiom.java
Tests the Fraction class through axioms. Not intended to be a part of a finished product, but to explore the class, looking for bugs.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java
>
>
> 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
[jira] [Comment Edited] (MATH-836) Fraction(double, int)
constructor strange behaviour
Posted by "Baste Nesse Buanes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425926#comment-13425926 ]
Baste Nesse Buanes edited comment on MATH-836 at 7/31/12 5:07 PM:
------------------------------------------------------------------
value-maxDenominator_pairs_that_fails added: pairs of doubles and ints that makes the constructor Fraction(double, int) return faulty Fractions.
was (Author: snalin):
pairs of doubles and ints that makes the constructor Fraction(double, int) return faulty Fractions.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Commented] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Thomas Neidhart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426943#comment-13426943 ]
Thomas Neidhart commented on MATH-836:
--------------------------------------
While looking into this issue, I realized that there is a very similar class in commons-lang, which also does a reduction when creating a Fraction object from a double value. We should consider also doing this for commons-math.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Commented] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428906#comment-13428906 ]
Phil Steitz commented on MATH-836:
----------------------------------
JaxT definitely looks very interesting and broadly useful for us. Looking forward to more applications to commons math and other commons components.
> 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
> Labels: Fraction
> Fix For: 3.1
>
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Commented] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Thomas Neidhart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426902#comment-13426902 ]
Thomas Neidhart commented on MATH-836:
--------------------------------------
The overflow check in Fraction does not take negative values into account, it has to be changed to the following:
{noformat}
if ((FastMath.abs(p2) > overflow) || (FastMath.abs(q2) > overflow)) {
throw new FractionConversionException(value, p2, q2);
}
{noformat}
In that case your examples fail correctly with a FractionConversionException and all unit tests run through successfully.
I would be interested how you generated the test cases. Are these auto-generated?
Thanks,
Thomas
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Comment Edited] (MATH-836) Fraction(double, int)
constructor strange behaviour
Posted by "Thomas Neidhart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426902#comment-13426902 ]
Thomas Neidhart edited comment on MATH-836 at 8/1/12 9:26 PM:
--------------------------------------------------------------
The overflow check in Fraction does not take negative values into account, it has to be changed to the following:
{noformat}
if (FastMath.abs(a0) > overflow) {
throw new FractionConversionException(value, a0, 1l);
}
...
if ((FastMath.abs(p2) > overflow) || (FastMath.abs(q2) > overflow)) {
throw new FractionConversionException(value, p2, q2);
}
{noformat}
In that case your examples fail correctly with a FractionConversionException and all unit tests run through successfully.
I would be interested how you generated the test cases. Are these auto-generated?
Thanks,
Thomas
was (Author: tn):
The overflow check in Fraction does not take negative values into account, it has to be changed to the following:
{noformat}
if ((FastMath.abs(p2) > overflow) || (FastMath.abs(q2) > overflow)) {
throw new FractionConversionException(value, p2, q2);
}
{noformat}
In that case your examples fail correctly with a FractionConversionException and all unit tests run through successfully.
I would be interested how you generated the test cases. Are these auto-generated?
Thanks,
Thomas
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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
[jira] [Updated] (MATH-836) Fraction(double, int) constructor
strange behaviour
Posted by "Baste Nesse Buanes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Baste Nesse Buanes updated MATH-836:
------------------------------------
Attachment: value-maxDenominator_pairs_that_fails
pairs of doubles and ints that makes the constructor Fraction(double, int) return faulty Fractions.
> 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
> Labels: Fraction
> Attachments: FractionTestByAxiom.java, value-maxDenominator_pairs_that_fails
>
>
> 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