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.
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.
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 1100? 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 1100, 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. 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 1100? 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 1100, 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
Marshal
Posts: 57453
175
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 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.
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.
When it is used for evil, then watch out! When it is used for good, then things are much nicer. Like this tiny ad:
The WEB SERVICES and JAXRS Course
https://coderanch.com/t/690789/WEBSERVICESJAXRS
