Decimals to improper fractions program?

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/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

RE: Decimals to improper fractions program? - Valentin Albillo - 06-07-2018 10:39 PM

.
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.
.

RE: Decimals to improper fractions program? - Gerson W. Barbosa - 06-08-2018 01:11 AM

(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.

RE: Decimals to improper fractions program? - acoto - 06-08-2018 02:54 AM

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

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