(12C) Decimal to Fraction

[Dieter]

(08-07-2018 01:19 AM)Albert Chan Wrote:  Can the code changed to limit size of denominator instead ?

Sure it can be modified. The denominator is calculated in line 11 and stored in R2. You can change the program so that it checks whether this value is larger than a certain limit. In that case it may not store the new denominator (exceeds the limit) and return the last one from R2 instead. The following test whether the rounded fraction agrees with the input should then be removed.

(08-07-2018 01:19 AM)Albert Chan Wrote:  Above example, fractions using 6 digits only get 5 decimal digits accuracy.
Instead of 239/169, you are better off with 1.41421

these six digits are better: 816/577 = 1.414211438

Let me try to understand what you mean here. Maybe you want more correct digits in the approximation than used for numerator and denominator. This is not how the program works. Instead you say "give me a fraction with 5 correct decimals" and the program returns a result. You may simply adjust the display format to get even more accurate results. Or you change the program so that it limits the denominator. Or choose a completely different algorithm. ;-)

Edit:
The result 239/169 was obtained with a setting of four (!) decimals, or five significant digits, in FIX 4 mode. And that's exactly the target it meets. If you want six significant digits, or five decimals, set FIX 5 and see what you get. Maybe the following table gives some more insights here.

The algorithm used here generates the following fractions for √2:

Code:

fraction      result        error
-------------------------------------
    1/1       1             -4,1 E-1
    3/2       1,5            8,6 E-2
    7/5       1,4           -1,4 E-2
   17/12      1,416666667    2,5 E-3
   41/29      1,413793103   -4,2 E-4
   99/70      1,414285714    7,2 E-5
  239/169     1,414201183   -1,2 E-5
  577/408     1,414215686    2,1 E-6
 1393/985     1,414213198   -3,6 E-7
 3363/2378    1,414213625    6,3 E-8
 8119/5741    1,414213552    1,1 E-8
19601/13860   1,414213564    1,8 E-9
47321/33461   1,414213562    3,1 E-10

Now compare the seventh line with your result:

Code:

  577/408     1,414215686    2,12390 E-6
  816/577     1,414211438   -2,12390 E-6

Even with 12 digit precision the error of 577/408 produced by the program is the same as for 816/577. The former even has a lower denominator. In FIX 5 mode the result 577/408 is not returned only because the fifth decimal is rounded up (1,41422) so that it does not meet the implemented exit condition (rounded input = rounded fraction).

That's why I think the algorithm is not that bad at all. If you want to see all possible fractions, like the ones in the table above, the program can easily be adjusted accordingly.

By the way – I almost forget to mention this: the original program was a 15C version by Joe Horn, published in HP Solve. I did some optimizations and streamlined Joe's program a bit to get a <40 step version for the HP35s. This in turn was the base for the above 12C program which includes less "stackrobatics" and avoids the R↑ command which the 12C does not feature. It requires R0...R3, but with three more steps it can be adjusted so that only R0...R2 are used. After applying the 12C changes to the 35s again the latter was down to 32 steps.

Dieter