Decimals to improper fractions program? - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html) +--- Forum: General Forum (/forum-4.html) +--- Thread: Decimals to improper fractions program? (/thread-10873.html) Pages: 1 2 Decimals to improper fractions program? - Oddballs - 06-05-2018 05:13 AM 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) RE: Decimals to improper fractions program? - ijabbott - 06-05-2018 02:26 PM 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. RE: Decimals to improper fractions program? - mfleming - 06-05-2018 02:28 PM 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 RE: Decimals to improper fractions program? - Dieter - 06-05-2018 06:36 PM (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 RE: Decimals to improper fractions program? - Oddballs - 06-06-2018 04:33 PM 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/technote/fract/fract-35s.html RE: Decimals to improper fractions program? - Gene - 06-06-2018 08:32 PM 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. RE: Decimals to improper fractions program? - Dieter - 06-06-2018 09:12 PM (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 RE: Decimals to improper fractions program? - Valentin Albillo - 06-07-2018 12:08 AM . 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. . RE: Decimals to improper fractions program? - Dieter - 06-07-2018 07:27 AM (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 RE: Decimals to improper fractions program? - Dieter - 06-07-2018 08:58 AM (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 RE: Decimals to improper fractions program? - Csaba Tizedes - 06-07-2018 11:30 AM 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/Qnum 3.14159265359 ->Q 1146408/364913 ->num 3.14159265359 RE: Decimals to improper fractions program? - Dieter - 06-08-2018 08:17 AM (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 RE: Decimals to improper fractions program? - Valentin Albillo - 06-09-2018 12:55 AM . 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. . RE: Decimals to improper fractions program? - Dieter - 06-09-2018 11:46 AM (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 RE: Decimals to improper fractions program? - pier4r - 06-09-2018 02:48 PM (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. RE: Decimals to improper fractions program? - Csaba Tizedes - 06-09-2018 02:54 PM (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 RE: Decimals to improper fractions program? - Albert Chan - 08-13-2018 03:03 AM (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```