Hi folks.
My recently acquired 48g continues to amaze me. If I use the Q symbolic function to convert .2356789 into a fraction, it comes up with 238010/1009791, which of course is correct. What amazes me is how the 48G found it. For instance, if I were to convert .2356789 to a fraction manually, I wouldn't be able to get past 2356789/10000000, since there are no common integer factors to the numerator and denominator. But the (amazing!) 48G found a non-integer common factor of 9.90205873703, which reduced 2356789/10000000 to 238010/1009791. This must be one sophisticated algorithm to do that. Can any of you math guru's shed any light on how this algorithm works?
Thanks, and best regards, Hal
48G fraction capability...WOW!!
|
09-17-2006, 05:48 PM
09-17-2006, 09:24 PM
If you like the built in ->Q function, you'll love QPI_4.3 for the 48, which "...approximates any floating point numbers by a rational number, square root, multiple of PI, exponential or a logarithm depending on which approximation seems best." If you've got your serial cable, it's available for free download under "Best Programs" from Eric Rechlin's HP Program Archive: http://www.hpcalc.org/best.php
09-17-2006, 11:41 PM
When I divide 238010 by 1009791, I get .235702239 on my 41CX. On my 50g I get .235702239374. I think the denominator is supposed to be 1009891.
09-18-2006, 04:10 AM
The algorithm for simple P/Q representation relies (usually) on continuous fractions, you can probably google something useful out of these words.
09-18-2006, 04:41 AM
For the 49 series, see Joe Horn's PDQ2 application, which he posted as UserRPL source code for a directory object, so you can study his algorithm if you like. Of
Regards,
09-18-2006, 05:12 AM
First, as was already pointed out, the OP made a typo--the fraction given by the HP48G is 238010/1009891. Second, I suspect the OP was being a little facetious. The result is of course "correct", but only correct within the displayed twelve digits of the calc. Both Maple and Mathematica give exactly the same 100 digit approximation to the fraction: .2356789000000990205873703201632651444561838851915701793559899038609117221561534858712474910658675045 I don't know what algorithm the calculator uses in the calculation of -> Q, but the user should beware that the result approximates the first twelve digits of what may actually be a slightly different decimal fraction. It is correct, yes, but only within the 12 digit confines of the calculator. Les
09-18-2006, 05:26 AM
While were at it can someone help me find the analogous function to -> Q on the HP49G+? Not having much luck with the notoriously difficult PDF manual. best, Les
09-18-2006, 06:00 AM
Hi, Hal: Hal posted:
"But the (amazing!) 48G found a non-integer common factor of
As part of one of my S&SMC challenges (#13, to be precise), I gave this simple routine, DEC2FRC, which does exactly that, and further allows The listing, description, and examples follows. Best regards from V. ---------
Here's a 5-line subprogram I wrote for the occasion which will do the conversion: 100 SUB DEC2FRC(X,N,D,W) @ IF X=0 THEN N=0 @ D=1 @ ENDThis subprogram is based in the continued fraction expansion of the given decimal number, and it simply computes the subsequent approximants till the tolerance is met, returning the last one.
To use it, you simply call DEC2FRC, passing it the following parameters: X: passed by value, is the decimal number to convert to fractional formFor example, let's convert -PI to fractional form calling DEC2FRC from the command line: >CALL DEC2FRC(-PI,N,D,0) @ N,D,N/D,PIso our fraction is -1146408/364913, which agrees with PI to 12 digits. Let's suppose that we don't want so close an approximation, but prefer instead a simpler fraction. We'll call DEC2FRC again, but this time we'll specify a tolerance of 0.00001 for the maximum relative error: >CALL DEC2FRC(-PI,N,D,1E-5) @ N,D,N/D,PIand so this time our fraction is -355/113, which agrees with -PI to nearly 8 digits, far better than our tolerance would have us believe. So our subprogram does work, and you can freely use it in your own programs which require fraction output.
---------------
Edited: 18 Sept 2006, 6:02 a.m.
09-18-2006, 06:23 AM
Well, you can always do ALPHA RightShift -> (over the 0 key), Q. Or you could press CAT, RightShift CursorDown, and then LeftShift CursorUp a few times until you find ->Q. Or LeftShift CONVERT (over the 6 key), REWRI, NXT, ->Q. In general, I find that if I know which command I want and its correct spelling, it's easiest to just type it in. In the 49g+ AUR manual, see pages 3-135 and I-17. Note that the result depends on the display mode.
Regards, Edited: 18 Sept 2006, 6:26 a.m.
09-18-2006, 07:54 AM
Thank you so much. I don't have the AUR and it seems the function is not documented in the standard User's Guide that ships on the CD. Les
09-18-2006, 10:44 AM
The AUR can be downloaded from http://www.hpcalc.org/details.php?id=6374. The only change, other than the model name, for the 50g would be that flag -78 controls which port (USB or serial) "wired" communications uses. There would be very few differences from the 49G, for that matter, although that depends on which ROM revision is used. I recommend updating the 49G to the latest available; see this thread for an example of how to do this.
Regards,
09-18-2006, 10:47 AM
Thank you all for your responces, and my appologies for the typo in the original post.
09-18-2006, 11:32 AM
Hi, Hal: Hal posted:
"Thanks especially to you, Valentin for your detailed responce, and your sub-program. I'm going to try porting the program to RPN...if I have any trouble I'll get back
100 SUB DEC2FRC(X,N,D,W) @ IF X=0 THEN N=0 @ D=1 @ END
I hope this helps.
09-18-2006, 11:39 AM
What's also interesting in this regard is that if you set the 'Number Format' to a "fixed" mode, such as 8 places, the calculation of the result appears to ONLY use that number of digits. So the decimal number will be diplayed as entered except that it will have a trailing zero if you push it into the stack, but the resulting fraction will be DIFFERENT. At 8 decimal places calculated precision, .2356789 ~ 4900/20791. At 9 decimal places calculated precision, .2356789 ~ 23311/98910. Deep down, computers may always be inherently dumb, but they are EXCELLENT workers! |
« Next Oldest | Next Newest »
|