commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Baste Nesse Buanes (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MATH-836) Fraction(double, int) constructor strange behaviour
Date Tue, 31 Jul 2012 17:06:34 GMT

     [ 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

        

Mime
View raw message