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

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:

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.

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
Ranch Hand

Joined: Mar 21, 2008
Posts: 89

posted

0

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

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.

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.

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:

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
Sheriff

Joined: Oct 13, 2005
Posts: 44524

34

posted

0

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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028

10

posted

0

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.