Brian S O'Neill wrote:
> I don't understand why the continued fraction implementation exists at all.
> Why not just get the bits from the double floating point number directly
> rather than introduce error? The floating point number is already a
> fraction, just encoded specially.
The point as I see it is to get the best rational approximation of a
double value with bounded denominator. The continued fraction
decomposition will do this better and more efficiently than just
reducing the fraction implied by the decimal or binary representation of
the number. Consider, for example, the number 0.66666, to be
represented by a fraction with denominator <=10,000. The direct
approach using the decimal representation would give 6667/10000, which
is not as good as 2/3, which you would get by continued fractions.
Phil
>
>  Original Message 
> From: "Phil Steitz" <phil@steitz.com>
> To: "Jakarta Commons Developers List" <commonsdev@jakarta.apache.org>
> Sent: Sunday, August 10, 2003 02:48 P
> Subject: [lang] Fraction.getFraction(double) uses magic numbers
>
>
>
>>o.a.c.l.math.Fraction includes a getFraction factory method that takes a
>>double and uses continued fractions to find a fractional approximation
>>of the input. The continued fraction implementation has a hardcoded
>>maximum number of iterations (25) and maximum denominator (1000). These
>>should be documented (and the ArithmeticException if maximum iterations
>>is reached before convergence). Better (IMHO) would be to add another
>>version that takes these as parameters, possibly even replacing the
>>current method (I think this is new in 2.0, so there would be no problem
>>with backward compatability).
>>
>>If there are no objections, I will submit a patch that clarifies current
>>behavior and adds another method that takes maximum iterations and
>>maximum denominator as additional parameters.
>>
>>I would also like to improve the implementation, but this can wait until
>>after 2.0.
>>
>>Phil
>>
>>
>>
>>To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
>>For additional commands, email: commonsdevhelp@jakarta.apache.org
>>
>
>
>
> 
> To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> For additional commands, email: commonsdevhelp@jakarta.apache.org
>
