Decimals to improper fractions program?

06052018, 05:13 AM
Post: #1




Decimals to improper fractions program?
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) 

06052018, 02:26 PM
Post: #2




RE: Decimals to improper fractions program?
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.


06052018, 02:28 PM
Post: #3




RE: Decimals to improper fractions program?
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/thread18.html You'll find similar programs for other calculators, including the HP42S, as well. Happy hunting! ~Mark Remember kids, "In a democracy, you get the government you deserve." 

06052018, 06:36 PM
(This post was last modified: 06062018 01:17 PM by Dieter.)
Post: #4




RE: Decimals to improper fractions program?
(06052018 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... 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" 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 builtin decimalfraction 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 { 90Byte Prgm } Example: approximate ln 2 to six decimals. Code: [DISP] [FIX] 6 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 

06062018, 04:33 PM
Post: #5




RE: Decimals to improper fractions program?
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...t35s.html 

06062018, 08:32 PM
Post: #6




RE: Decimals to improper fractions program?
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. 

06062018, 09:12 PM
(This post was last modified: 06062018 10:15 PM by Dieter.)
Post: #7




RE: Decimals to improper fractions program?
(06062018 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 doublecheck 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 [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 

06072018, 12:08 AM
Post: #8




RE: Decimals to improper fractions program?
.
Hi, Dieter: (06052018 06:36 PM)Dieter Wrote: BTW, in ALL mode on Free42 I obtained this approximation of pi... You're using 34 digits (17digit numerator and 17digit denominator) to get 34 digits of Pi. Quite unremarkable (unlike 355/113, which gets almost 8 significant digits using just 6). Regards. V. . All My Articles & other Materials here: Valentin Albillo's HP Collection 

06072018, 07:27 AM
(This post was last modified: 06072018 07:51 AM by Dieter.)
Post: #9




RE: Decimals to improper fractions program?
(06072018 12:08 AM)Valentin Albillo Wrote: You're using 34 digits (17digit numerator and 17digit 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 34digit Free42. But then... I think I remember a 12C program where two 7digit constants were used to generate a 10digit number... #) (06072018 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 

06072018, 08:58 AM
(This post was last modified: 06072018 09:56 AM by Dieter.)
Post: #10




RE: Decimals to improper fractions program?
(06062018 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 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' 12digit 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 

06072018, 11:30 AM
Post: #11




RE: Decimals to improper fractions program?
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/QK)<=E, where E is a given error. Code:  Csaba 

06072018, 10:39 PM
Post: #12




RE: Decimals to improper fractions program?
.
Hi, Dieter: (06072018 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 34digit Free42. 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 7digit/10digit are you talking about, you have to be more specific or provide a link. Quote:(06072018 12:08 AM)Valentin Albillo Wrote: unlike 355/113, which gets almost 8 significant digits using just 6 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. . All My Articles & other Materials here: Valentin Albillo's HP Collection 

06082018, 01:11 AM
Post: #13




RE: Decimals to improper fractions program?
(06072018 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 7significant 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) (Offtopic, but I thought you’d find that interesting). Gerson. 

06082018, 02:54 AM
Post: #14




RE: Decimals to improper fractions program?
On my 48S
pi >num 3.14159265359 >Q 1146408/364913 >num 3.14159265359 Adrian Coto 

06082018, 08:17 AM
Post: #15




RE: Decimals to improper fractions program?
(06072018 10:39 PM)Valentin Albillo Wrote:(06072018 07:27 AM)Dieter Wrote: ...I think I remember a 12C program where two 7digit constants were used to generate a 10digit number... #) No sarcasm intended. The "#)" simply is a kind of *facepalm*: of course I agree that it does not make any sense to generate a 34digit value by dividing two 17digit 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. (06072018 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. ;) (06072018 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. (06072018 10:39 PM)Valentin Albillo Wrote: Sorry to have ruffled your feathers. No problem – no ruffling has occured. Dieter 

06092018, 12:55 AM
Post: #16




RE: Decimals to improper fractions program?
.
Hi, Dieter: (06082018 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:(06072018 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. 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 factbased and evidencebased, 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 almostagreement 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:(06072018 10:39 PM)Valentin Albillo Wrote: Sorry to have ruffled your feathers. Glad to know. Have a nice weekend. V. . All My Articles & other Materials here: Valentin Albillo's HP Collection 

06092018, 11:46 AM
(This post was last modified: 06092018 11:50 AM by Dieter.)
Post: #17




RE: Decimals to improper fractions program?
(06092018 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 factbased and evidencebased, 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 

06092018, 02:48 PM
(This post was last modified: 06092018 03:23 PM by pier4r.)
Post: #18




RE: Decimals to improper fractions program?
(06092018 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 factbased and evidencebased, 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. Wikis are great, Contribute :) 

06092018, 02:54 PM
Post: #19




RE: Decimals to improper fractions program?
(06092018 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, Csaba 

08132018, 03:03 AM
Post: #20




RE: Decimals to improper fractions program?
(06092018 02:54 PM)Csaba Tizedes Wrote: In engineering practice more important the relative error. In this case the results are: Above table is mistaken, 355/113 is 100 times more accurate. 355/113 vs Pi, relative error = 85e9 = 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 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)