Sam Benry

Ranch Hand

Posts: 89

posted 7 years ago

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:

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:

posted 7 years ago

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.

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

Sheriff

Posts: 53742

127

Sam Benry

Ranch Hand

Posts: 89

posted 7 years ago

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?

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?

posted 7 years ago

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.

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

Ranch Hand

Posts: 3090

14

posted 7 years ago

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.

Jesper Young wrote:Note that this is going to be very difficult (impossible) if you're using double (or Double) numbers. Thedoubleandfloatdatatypes 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

Posts: 53742

127

Mike Simmons

Ranch Hand

Posts: 3090

14

posted 7 years ago

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

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.

*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.