Infinite Decimal Numbers to Fractions

[Sam Benry]

so I am trying to convert infinite decimal numbers to proper fractions
for example,
2.333333333.... is 2 1/3

I made up this function

    public static String doubleToStringFraction(Double d)
    {
            StringBuffer result = new StringBuffer(" " + ((int) Math.floor(d)));
            int whole = (int) ((d - Math.floor(d)) * 10000);
            int gcd = gcd(whole, 10000);
            result.append(" " + (whole / gcd) + "/" + 10000 / gcd + " ");
            return result.toString();
    }

It works perfectly on finite decimal numbers, example: 5.5 = 5 1/2
but returns wrong results on infinite decimal numbers, example: 2.333333333 = 2 3333/10000
which is 2 + 0.3333

Any idea how to fix it and correct the result ?

If anyone wants to test the function, this is the gcd() function:

    private static int gcd(int a, int b)
    {
		if (b == 0)
			return a;
		else
			return gcd(b, a % b);
    }

[Paul Clapham]

You need a different algorithm. Right now you have an algorithm which rounds to 4 decimal places and makes a fraction based on that. So when you get 2+3333/10000 as the fraction representing 2.3333, that's actually a better answer than 2+1/3 because it's closer to 2.3333. But sometimes you want to produce a fraction which is farther away from the decimal value but has a smaller denominator. This would be a much more complicated algorithm than the simple one you have there.

So, this isn't a question about Java programming yet. You need to figure out the real algorithm -- the one you could use with a calculator, or a pencil -- and then program it in Java.

[Campbell Ritchie]

If you have a recurring number, eg ⅓, this will go on infinitely. So how can you enter ⅓ on screen in the first place?

[Sam Benry]

well i was thinking if i could find out the repeating pattern of the infinite decimal number then i can do computations to figure out the fraction.
but i dont have a clue how to find the repeating pattern.
some decimals are easy: 0.3333333333
others are hard: 0.78689988998899889988998899

etc

any ideas?

[Jesper de Jong]

Note that this is going to be very difficult (impossible) if you're using double (or Double) numbers. The double and float datatypes have limited precision. You can't store numbers with an arbitrary number of digits of precision in variables of those types.

[Paul Clapham]

Sam Benry wrote:well i was thinking if i could find out the repeating pattern of the infinite decimal number then i can do computations to figure out the fraction.
but i dont have a clue how to find the repeating pattern.
some decimals are easy: 0.3333333333
others are hard: 0.78689988998899889988998899

Well, that's true. For example 1/17 has a repeating pattern of length 16. You're going to find it difficult to identify that unless you have considerably more than 16 decimal places. So that doesn't look like the right approach.

So let's suppose you have 0.0588235294117647 as your input. There are no repeating patterns but it's very close to 1/17. You need an algorithm which tells you that. Looking at digit patterns isn't going to be useful so you need something completely different.

[Mike Simmons]

Jesper Young wrote:Note that this is going to be very difficult (impossible) if you're using double (or Double) numbers. The double and float datatypes have limited precision. You can't store numbers with an arbitrary number of digits of precision in variables of those types.

That's true, but it doesn't necessarily make the problem impossible, nor even overly difficult, if we approach it the right way. What if we accept that an exact answer is impossible, but instead look for the closest answer we can find? What if we assume, for the sake of argument, that the denominator must be within a certain range, say 1-100? W could then do something like this:

for each possible denominator in the range
    find the best possible numerator for that denominator
    measure the error we get from this new fraction
    is this the lowest error found so far?  
        if so, we have a new closest match

At the end, we have found the closest fraction for any fraction with a denominator in the range 1-100, or whatever.

This may not be the most efficient way to solve the problem, but I suspect it's good enough for most practical applications.

[Campbell Ritchie]

The difficulty of that approach varies from denominator to denominator. For example (I think) anything divided by 7, 14, 28, 35, etc will have 142857 in somewhere.

[Mike Simmons]

Well, it's worth noting that, for example, 1/7 is the same as 2/14 or 3/21. Of these three, which is best? Probably the first. So you'd only discard a particular solution if you had a new solution with less error than the previous best solution. If it has the same error, there's no benefit to discarding it.

Other than that, I'm not really sure how your (Campbell's) comment applies to my proposed algorithm. Is it possible you were referencing an earlier post, not mine? Or more likely I'm just missing something.

[Campbell Ritchie]

More relevant to earlier posts, I would think.