Decimals to improper fractions program?

[Oddballs]

Hey!

I am trying to program my HP35s and Free42 to take a decimal number and convert it to improper fractions...

Example:

6.666667 in the first stack gives me 20/3 or
20
3
as output.

But i havent found any program on this forum that does this... Does anyone have a program that i could look at?

Thanks!

(Pardon my lacking english skills)

[ijabbott]

This is the first one I found: Fractional approximation program for the HP 42S. It uses continued fractions to produce progressively closer fractions to the input. However, it displays the results as strings, not as the Y,X stack pairs you wanted.

[mfleming]

Try doing a search for "QPI" on this site, as in this form for your favorite search engine

QPI site:hpmuseum.org

One such posting for the HP Prime is

http://www.hpmuseum.org/forum/thread-18.html

You'll find similar programs for other calculators, including the HP42S, as well.

Happy hunting!
~Mark

[Dieter]

(06-05-2018 05:13 AM)Oddballs Wrote:  I am trying to program my HP35s and Free42 to take a decimal number and convert it to improper fractions...
...
But i havent found any program on this forum that does this... Does anyone have a program that i could look at?

On this site you will find various programs that convert a decimal number into fractions. For instance this program that is based on the one in the HP67/97 math pac.

Here is a slightly modified version for the HP41. Set the display mode to the desired accuracy and the result is a fraction that agrees with the original value to display precision. It should also run on the 42s. Here you can omit the PSE at the end because numerator and denominator will be returned in the two display lines as Y and X.

Code:

01 LBL"DF"
02 ENTER
03 STO 00
04 1
05 STO 02
06 STO 03
07 0
08 STO 01
09 STO 04
10 LBL 01
11 R↓
12 /
13 LASTX
14 ENTER
15 R↓
16 X<>Y
17 INT
18 STO 05
19 x
20 -
21 RCL 05
22 RCL 04
23 x
24 RCL 02
25 +
26 X<> 04
27 STO 02
28 R↓
29 RCL 05
30 RCL 03
31 x
32 RCL 01
33 +
34 X<> 03
35 STO 01
36 R↓
37 RCL 03
38 RCL 04
39 /
40 RND
41 RCL 00
42 RND
43 -
44 X≠0?
45 GTO 01
46 RCL 03
47 PSE
48 RCL 04
49 END

Example:
Find approximations for pi that agree in 2, 6 and 9 decimals.

FIX 2
[pi] XEQ"DF" => "22" 7

FIX 6
[pi] XEQ"DF" => "355" 113

FIX 9
[pi] XEQ"DF" => "104348" 33215

You can also set SCI display mode. In this case the calculated fraction agrees with the input to the specified number of significant digits.

On the 35s you could use an adapted version of this program. But why don't you simply take advantage of the built-in decimal-fraction conversion (FDISP key)? OK, this returns proper fractions, but you can easily convert these to improper ones. The 35s function can also be individually configured with flags and the /c key. Take a look at the manual for more information.

Edit and Update:
Here is a somewhat optimized version for the 42s / Free42. It returns the numerator and denominator as well as the approximation and its error. Also negative results are properly displayed.

Code:

00 { 90-Byte Prgm }
01>LBL "DF"
02 CF 00
03 X<0?
04 SF 00
05 STO 00
06 ABS
07 RCL ST X
08 1
09 STO 02
10 STO 03
11 0
12 STO 01
13 STO 04
14>LBL 01
15 Rv
16 ÷
17 LASTX
18 STO ST T
19 X<>Y
20 IP
21 STO 05
22 ×
23 -
24 RCL 05
25 RCL× 04
26 RCL+ 02
27 X<> 04
28 STO 02
29 Rv
30 RCL 05
31 RCL× 03
32 RCL+ 01
33 X<> 03
34 STO 01
35 Rv
36 RCL 03
37 RCL÷ 04
38 RND
39 RCL 00
40 ABS
41 RND
42 -
43 X!=0?
44 GTO 01
45 RCL 03
46 FS?C 00
47 +/-
48 "  "
49 AIP
50 |-"/"
51 RCL 04
52 AIP
53 ÷
54 ENTER
55 RCL- 00
56 X<>Y
57 AVIEW
58 END

Example: approximate ln 2 to six decimals.

Code:

[DISP] [FIX] 6
2 [LN] XEQ"DF"
                1143/1649
                0,693147
[<=]
                1,814777E-7
                0,693147

BTW, in ALL mode on Free42 I obtained this approximation of pi...

66 627 445 592 888 887  /  21 208 174 623 389 167

...which indeed agrees in 34 significant digits. ;-)

Dieter

[Oddballs]

Amazing! Thanks for the links and programs!

I tried to use this program on my HP35s but i get the invlaid (I) error. Does anyone have a clue whats wrong with the code?

http://www.finetune.co.jp/~lyuka/technot...t-35s.html

[Gene]

Odd,

First thing to check is that you keyed the program in correctly. The program listing may be fine, but there may well be one slight mistake in the keyed program that causes it to fail.

[Dieter]

(06-06-2018 04:33 PM)Oddballs Wrote:  I tried to use this program [NB: from another website ] on my HP35s but i get the invlaid (I) error. Does anyone have a clue whats wrong with the code?

First of all: check the code twice. Then check it once again. Compare each and every single line in your program with the listing. STO I is different from STO (I).

Looking at the code I think several GTOs and XEQs are wrong: Some lines are printed in green color, these seem to be the intended jump targets. But then F014 says XEQ F034 while XEQ F033 would make more sense. Line F025 is marked in green but then line F020 says GTO F026.

IMHO the lines with GTOs and XEQs should read like this:

F014  XEQ F033
F020  GTO F025
F024  GTO F011
F045  GTO F038

I would also replace the PSE at the end with a R/S so that you have time to read and write down the different approximations.

Please double-check the mentioned program lines as the 35s may automatically renumber jump targets while you edit the program.

After these changes the program runs just fine.

EDIT: The 15C version on that website looks more promising. Here is an adapted (and slightly tweaked) version for the 35s:

Code:

F001  LBL F
F002  ABS
F003  ENTER
F004  STO X
F005  1
F006  STO A
F007  0
F008  STO B
F009  R↓
F010  R↓
F011  IP
F012  RCLx A
F013  RCL+ B
F014  x<> A
F015  STO B
F016  x<>y
F017  FP
F018  1/x
F019  RCL A
F020  RCL÷ X
F021  FIX 0
F022  RND
F023  ALL
F024  ENTER
F025  ENTER
F026  RCL A
F027  x<>y
F028  STOP
F029  ÷
F030  RCL- X
F031  x≠0?
F032  GTO F009
F033  R↓
F034  +/-
F035  RCL A
F036  +/-
F037  x<>y
F038  RTN

[pi] XEQ F [ENTER]
3
1

[R/S]
22
7

[R/S]
333
106

[R/S]
355
113
...

As soon as the fractional approximation exactly equals the input (within 12 digits, that is) the final fraction is returned with negative signs:

[R/S]
–1146408
–364913

This way you know the program has finished and no further fractions can be expected. ;-)

Dieter

[Valentin Albillo]

.
Hi, Dieter:

(06-05-2018 06:36 PM)Dieter Wrote:  BTW, in ALL mode on Free42 I obtained this approximation of pi...

66 627 445 592 888 887  /  21 208 174 623 389 167

...which indeed agrees in 34 significant digits. ;-)

You're using 34 digits (17-digit numerator and 17-digit denominator) to get 34 digits of Pi. Quite unremarkable (unlike 355/113, which gets almost 8 significant digits using just 6).

Regards.
V.
.

[Dieter]

(06-07-2018 12:08 AM)Valentin Albillo Wrote:  You're using 34 digits (17-digit numerator and 17-digit denominator) to get 34 digits of Pi.

Yes, I know. This is not meant to be a shortcut to pi. It just shows that the program runs fine with 34-digit Free42.

But then... I think I remember a 12C program where two 7-digit constants were used to generate a 10-digit number... #-)

(06-07-2018 12:08 AM)Valentin Albillo Wrote:  unlike 355/113, which gets almost 8 significant digits using just 6

?!? – 355/113 = 3,14159292... which agrees with pi in exactly 7 significant digits. Both truncated (3,141592) and rounded (3,141593).
The 8th significant digit is 3 units off.

Dieter

[Dieter]

(06-06-2018 09:12 PM)Dieter Wrote:  The 15C version on that website looks more promising. Here is an adapted (and slightly tweaked) version for the 35s:

Here is an improved version for the 35s that uses two more data registers, but when the program stops to display the current fraction the stack does not have to be preserved. So this version is safer to use. And it allows an additional feature: You can always press the [÷] key to see the approximated value. The upper display line then shows the input so that you can compare both values easily.

I also added an x≠0? test to avoid a zero division error if the fraction exactly matches the input.

Code:

F001  LBL F
F002  STO X
F003  STO C
F004  CLx
F005  STO D
F006  e^x
F007  STO A
F008  RCL C
F009  IP
F010  RCLx A
F011  RCL+ D
F012  x<> A
F013  STO D
F014  RCL C
F015  FP
F016  x≠0?
F017  1/x
F018  STO C
F019  RCL A
F020  x=0?
F021  GTO F008
F022  RCL÷ X
F023  FIX 0
F024  RND
F025  STO B
F026  ALL
F027  RCL X
F028  RCL A
F029  RCL B
F030  STOP
F031  RCL A
F032  RCL÷ B
F033  RCL- X
F034  x≠0?
F035  GTO F008
F036  CLSTK
F037  RTN

When the fraction agrees with the input the next [R/S] now just exits the program with two zeros in the display. If you don't like this replace the final CLSTK with GTO F026, so that after another [R/S] the last fraction is displayed once again. You may also replace all lines from F031 to the end with GTO F008. This will return even more fractions that are even more exact than the previous ones, although the 35s' 12-digit precision cannot show this.

At any time the numerator and denominator can be recalled with RCL A and RCL B.

The original algorithm does not work for input < 1. In such a case you may enter 1/x and swap numerator and denominator.
I now have edited the program so that – I think – this issue is fixed. Try it and see if it works.

The program also works for negative input. Here the minus sign is returned once in the numerator and once in the denominator.

Example:

10 [√x] XEQ F [ENTER]

3
1

[R/S]
19
6

[R/S]
117
37

[R/S]
721
228

Check accuracy now:

[÷]
3,16227766017
3,16228070175

Continue:

[R/S]
4443
1405
...

Dieter

[Csaba Tizedes]

A slow and stupid - but short for 32SII:
This routine find an estimation of K as P/Q fraction, where P and Q are relative primes and ABS(P/Q-K)<=E, where E is a given error.

Code:

---------------------
LBL Q
  RCL P
  RCL / Q
  RCL - K
  STO D        //D=P/Q-K
  ABS
  RCL E
  X>=Y?        //E>=ABS(D)?
RTN            //Yes, end of the program
  RCL D        
  X<0?         //P/Q<K ?
  GTO P        //Yes, increase P
  1            // No, increase Q
  STO + Q
  GTO Q        
---------------------
LBL P          // Increase P
  1
  STO + P
  GTO Q
---------------------

Checksums:
==========
LBL Q: CK=9676 / 22.5 byte
LBL P: CK=C1C6 / 6.0 byte

Variables:
==========
P, Q, K, E, D

Timing:
=======
| Number (K) | Error (E) | P    | Q   | Number of steps (P-1+Q-1) | Running time | Steps/secs |
| PI         | 1E-5      |  355 | 113 |  466                      |   41.5s      | 11.2/s     |
| SQRT(2)    | 1E-5      |  577 | 408 |  983                      |   86.1s      | 11.4/s     |
| e          | 1E-5      | 1071 | 394 | 1463                      |  129.7s      | 11.3/s     |

Csaba

[Valentin Albillo]

.
Hi, Dieter:

(06-07-2018 07:27 AM)Dieter Wrote:  Yes, I know. This is not meant to be a shortcut to pi. It just shows that the program runs fine with 34-digit Free42.
But then... I think I remember a 12C program where two 7-digit constants were used to generate a 10-digit number... #-)

Seems to me I notice some kind of sarcarsm in that last remark. If that's the case, it's lost on me, I don't get what 7-digit/10-digit are you talking about, you have to be more specific or provide a link.

Quote:

(06-07-2018 12:08 AM)Valentin Albillo Wrote:  unlike 355/113, which gets almost 8 significant digits using just 6

?!? – 355/113 = 3,14159292... which agrees with pi in exactly 7 significant digits. Both truncated (3,141592) and rounded (3,141593). The 8th significant digit is 3 units off.

I also don't understand your "?!?", I said "almost". Rounded to 8 significant digits Pi is 3.1415927 while 355/113 is 3.1415929, so the 8th digit is just 2 ulps off (out of a possible 10) so my "almost" is more than justified.

Sorry to have ruffled your feathers.

Regards.
V.
.

[Gerson W. Barbosa]

(06-07-2018 07:27 AM)Dieter Wrote:  355/113 = 3,14159292... which agrees with pi in exactly 7 significant digits. Both truncated (3,141592) and rounded (3,141593).

Starting with 355/113 and its rounded 7-significant digit result, we can easily double the number of digits in the approximation:

355/113 = 3.141593 (rounded)

3.141593 - SQRT(3)/5000000 = 3.1415926535898 (rounded)

(Off-topic, but I thought you’d find that interesting).

Gerson.

[acoto]

On my 48S
pi
->num
3.14159265359
->Q
1146408/364913
->num
3.14159265359

[Dieter]

(06-07-2018 10:39 PM)Valentin Albillo Wrote:  

(06-07-2018 07:27 AM)Dieter Wrote:  ...I think I remember a 12C program where two 7-digit constants were used to generate a 10-digit number... #-)

Seems to me I notice some kind of sarcarsm in that last remark. If that's the case, it's lost on me, I don't get what 7-digit/10-digit are you talking about, you have to be more specific or provide a link.

No sarcasm intended. The "#-)" simply is a kind of *facepalm*: of course I agree that it does not make any sense to generate a 34-digit value by dividing two 17-digit numbers. This simply reminded me of a program I saw somewhere (can't remember where exactly it was) where indeed a numeric value was replaced with a fraction that required more digits and thus more program steps than coding the value directly.

(06-07-2018 10:39 PM)Valentin Albillo Wrote:  I also don't understand your "?!?"

Oh, sorry, that's simply a sign for not understanding, being astonished, puzzled, wondering what the meaning might be. Just imagine a big question mark above my head. ;-)

(06-07-2018 10:39 PM)Valentin Albillo Wrote:  I said "almost". Rounded to 8 significant digits Pi is 3.1415927 while 355/113 is 3.1415929, so the 8th digit is just 2 ulps off (out of a possible 10) so my "almost" is more than justified.

OK, let's agree to disagree on this.

(06-07-2018 10:39 PM)Valentin Albillo Wrote:  Sorry to have ruffled your feathers.

No problem – no ruffling has occured.

Dieter

[Valentin Albillo]

.
Hi, Dieter:

(06-08-2018 08:17 AM)Dieter Wrote:  No sarcasm intended. [...] This simply reminded me of a program I saw somewhere (can't remember where exactly it was) where indeed a numeric value was replaced with a fraction that required more digits and thus more program steps than coding the value directly.

Understood. I thought that you were sarcastically referring to one of my 12C's programs in which I supposedly did that and I couldn't remember which one.

Quote:

(06-07-2018 10:39 PM)Valentin Albillo Wrote:  I said "almost". Rounded to 8 significant digits Pi is 3.1415927 while 355/113 is 3.1415929, so the 8th digit is just 2 ulps off (out of a possible 10) so my "almost" is more than justified.

OK, let's agree to disagree on this.

Not necessarily. Rational people can "agree to disagree" in fields which are amenable to subjective opinions but Mathematics is not one of them, Mathematics is fact-based and evidence-based, so there's little or no place for subjectivism. No one can rationally "agree to disagree" whether 11111 is prime or not, you just produce its factors or lack of prime factorization and that settles the question once and for all.

This said, if you'd be so kind as to indulge me on this, let's analyze the subject matter, for the benefit of our readers if nothing else. I stated the following:

      "unlike 355/113, which gets almost 8 significant digits using just 6"

and you then stated:

      "355/113 = 3,14159292... which agrees with pi in exactly 7 significant digits. Both truncated (3,141592) and rounded (3,141593). The 8th significant digit is 3 units off".

Well, let's see if you agree with the following:

      1) The rounded value of Pi to 8 significant digits is 3.1415927. Once rounded, the value becomes exactly 3.141592700000... Do you agree ?

      2) The rounded value of 355/113 to 8 significant digits is 3.1415929. Once rounded, the value becomes exactly 3.141592900000... Do you agree ?

      3) Both rounded values differ from one another by exactly 2 units in the last place, not 3, not 2.6676, just 2. Do you agree ?

      4) Two values which exactly agree to 7 significant digits may differ in their last, 8th digit by from 0 to 9 units in the last place. If they differ by 0 ulps, they can be said to exactly agree to 8 digits, and if they differ by 1 or 2 ulps they can be said to almost agree to 8 digits. If they differ by 3, 4, 5, 6, 7, 8 or 9 ulps that would not be the case, but for just 1 or 2 ulps the qualifier "almost" is justified.

Do you agree ?

My intention when I stated this almost-agreement to 8 digits while using just 6 (3,5,5,1,1,3) was to get home the fact that 355/113 is a most remarkable approximation to Pi, relatively much better than any other which might agree with Pi to more significant digits but at the cost of using relatively much longer numerators and denominators.

That's not a subjective opinion but a mathematical fact that can be substantiated by looking at Pi's continued fraction and at Pi's convergent fractions.

1) Pi's continued fraction is (3,7,15,1,292,1,1,1,2,1,...), which can be readily evaluated:

>3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/1)))))))), PI

      3.14159265359       3.14159265359

so it agrees to a full 12 significant digits with the terms used. Notice that big 292 term, much bigger that any of the other terms. This indicates that the equivalent fraction stopping at the previous term, 1, is so good that you need to go all the way to 292 to try and get something better.

That extremely good fraction, the one with continued fraction (3,7,15,1) is precisely 355/113, while the following fraction that improves on it is 103993/33102, using 11 digits in all vs. 6 digits.

2) Pi's convergent fractions can be readily obtained from the continued fraction expansion and are as follows:

      3/1            = 3
      22/7           = 3.14285714286
      333/106        = 3.14150943396
      355/113        = 3.14159292035
      103993/33102   = 3.14159265301
      104348/33215   = 3.14159265392
      208341/66317   = 3.14159265347
      312689/99532   = 3.14159265362
      833719/265381  = 3.14159265358
      1146408/364913 = 3.14159265359

Notice the big increase in the sizes of numerator and denominator between 355/113 and the next convergent, 103993/33102. There's no similar huge difference in size between other consecutive convergents, because the terms of Pi's continued fraction are so small in comparison and that's what makes 355/113 so exceptionally accurate.

Do you agree ? :-)

Quote:

(06-07-2018 10:39 PM)Valentin Albillo Wrote:  Sorry to have ruffled your feathers.

No problem – no ruffling has occured.

Glad to know. Have a nice weekend.
V.
.

[Dieter]

(06-09-2018 12:55 AM)Valentin Albillo Wrote:  Rational people can "agree to disagree" in fields which are amenable to subjective opinions but Mathematics is not one of them, Mathematics is fact-based and evidence-based, so there's little or no place for subjectivism. No one can rationally "agree to disagree" whether 11111 is prime or not, you just produce its factors or lack of prime factorization and that settles the question once and for all.

Great. So let's look at the facts.

355/113 = 3,141592920353982...
while pi = 3,141592653589793...

How many digits agree? Seven. A simple matter of fact. The difference is ≈2,7 E–7, so the 7th decimal or 8th significant digit differs. That's a mathematical fact, nothing that could be subject to opinions, exactly as you said. So I think we can agree on this.

Now the subjective part comes in: you say that the 8th digit is only 2 units off. 2 out of 10. And this allows to describe the accuracy as "almost 8 digits". Here is the point where we do not agree. It's the way how we name a difference of a few units in the 8th digit. I say "that's 7 digits" while you say "but it's almost 8".

Finally you said that 355/113 is an exceptionally good approximation to pi. Agreed. It's much better than 333/106 and far more efficient than the "next best" fraction 103993/33102. It's indeed a quite accurate and effective approximation. Accurate to... ;-)

Dieter

[pier4r]

(06-09-2018 12:55 AM)Valentin Albillo Wrote:  Not necessarily. Rational people can "agree to disagree" in fields which are amenable to subjective opinions but Mathematics is not one of them, Mathematics is fact-based and evidence-based, so there's little or no place for subjectivism.

For the little that I know there is something really subjective to which every system is based (math, logic, English, whatever). They are called axioms (or postulates, or in other cases assumptions and definitions). If I reject one of your axioms, a legit action (if you think the contrary, well...), there is little to discuss.

If I remember correctly already Aristotle in the "Sophistical Refutations" said more or less something like "if we do not set a common base of concepts from which we discuss, we may end talking about different things". (n1)

I guess in the particular case one agrees to disagree when the terms are not well specified for the participants and therefore there is ample space for personal interpretation. In this case I see it in the part "almost".

For example I can say "the number 1 is almost equal to the number R, with R arbitrarily large". Immediate problems in the sentence: "almost", "large".

This to say: let's not claim total precision in mathematics when there are a lot of source of misunderstandings and interpretation.

n1: Then, but that is another story, there is the extreme unlucky case of total absence of fruitful communication in the case that, even when all the speakers agree on the definitions, axioms and so on; there is the chance that the language used to describe them is used by each speaker with a different arrangement of meaning for each word used in the description.

[Csaba Tizedes]

(06-09-2018 11:46 AM)Dieter Wrote:  355/113 It's much better than 333/106 and far more efficient than the "next best" fraction 103993/33102.

In engineering practice more important the relative error. In this case the results are:

Code:

+/- 1.000% error:  19/6, 
+/- 0.100% error:  22/7, 
+/- 0.010% error: 289/92, 
+/- 0.001% error: 355/113

Csaba

[Albert Chan]

(06-09-2018 02:54 PM)Csaba Tizedes Wrote:  In engineering practice more important the relative error. In this case the results are:

Code:

+/- 1.000% error:  19/6, 
+/- 0.100% error:  22/7, 
+/- 0.010% error: 289/92, 
+/- 0.001% error: 355/113

Above table is mistaken, 355/113 is 100 times more accurate.
355/113 vs Pi, relative error = 85e-9 = 0.0000085%

I agree that relative error is more useful than digits matched.
All estimates below had 5% relative error, but digits matched are all over the place.

Code:

original  estimate  relative error
9.44      9.90      4.9% -- match 0 digit when rounded
9.03      9.48      5.0% -- match 1 digit when rounded
1.44      1.51      4.9% -- match 0 digit when rounded
1.35      1.42      5.2% -- match 2 digits when rounded