(50g, 49g) ArcLength v1.1 - The lenght of arch of given function

[Carsen]

If you are interested, here is the thread where Joe Horn points out to me that the 50g integration accuracy is dependent on the display format. Should be post # 6, 7, & 9. Took me awhile to find the thread but I'm proud to have found it at last.

(06-06-2018 04:36 PM)Vtile Wrote:  That display format dependency is also what J. Horn did mention on some old post I did find at the morning.

I wonder if that old post was the thread I just linked in this post.

(06-05-2018 07:51 PM)Vtile Wrote:  Unfortunately the solution given on that oldish MoHPC thread doesn't work for some reason on my 50g, the derivative inside integral somehow generates a bug. In RPL stack it does work, but not as a defined algebraic function so I did create a code snippet for it.

The old solution works for my HP 50g. Both in RPN and ALG mode. Although the user has to manually tell the calculator to produce a numerical answer and it takes a really long time to get compared to your (Vtile's) program. Your program can numerically evaluate an arc length by putting the calculator in Approx. mode when entering the data and gets the answer faster. With the example of solving for the arc length of 2*x*sin(10*x) from 1 to 2, your program gets the numeric answer 1 min and 38 seconds faster.

(06-06-2018 05:03 PM)Vtile Wrote:  

(06-06-2018 04:44 PM)Carsen Wrote:  Yes Vtile. The HP 50g integration is accurate to the number of set decimal digits, just like the 15C. I learned this from a senior member here some time ago.

If you will allow me, I will go through your code to help improve it. After all, I just finished reading how to program in UserRPL from the HP 50g User's Guide, AUR Guide, and a tutorial written by Eduardo M Kalinowski. So helping improve this code will help my programming skills and help your program (hopefully).

Indeed it is interesting (but somewhat logical decision) that the accuracy is display format dependent.

Go for it, the system state check and adjustment could be optimized at least. This program snippet is of course a free domain as it is in the end just RPN (or RPL) representation of the math formula.

I would add a PUSH command before setting it to Radian mode. This saves the current flags. Then at the end of the program, I would add the POP command to "pop" the settings saved with PUSH back into place. (Fun fact: PUSH also saves what directory you were in. I just learned this and improved my own programs with this. Pretty cool!)

I debated adding a INPUT form to aid the user with what data to input where. And this could work really well because the Equation Writer can be used when using an input form too. However, I decided not to add it because I am assuming the reader just wants to type a short program from this forum into the calculator directly. Plus, I personally like typing in the equation into the stack via RPN rather than the Equation Writer.

Lastly, the message you are displaying with MSGBOX will not display all of the text when using if the user has Flag 72 clear and is using font 8. So I would simply add a -72 SF to let all of the text fit in the MSGBOX.

In the particular example of the Arc length of 2x*sin(10x), it takes a really long time to get a numeric answer. I wish I could improve this time via programming but I don't know anything that UserRPL can do. Maybe when I learn SystemRPL, I can manage to create something...

Anyway, here is the program with the tiny bit of improvements described above. ( I just added 4 commands)

Code:


<< PUSH IFERR  --> a  b  f  x  
<<  RAD  a  b  'DERIV(f,x)'  EVAL DUP * 1 + SQRT x Integral (Found on the TAN key in orange)  >>  
THEN "Give RANGE, f(x), x (a,b,f,x) The speed and accuracy is disp. format dependent" -72 SF MSGBOX END POP >>