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

[Vtile]

Hello

I were faced on the problem at work today where I need to solve the length of arc and to be honest the algebraic solution had buried so deep dust in my head that it didn't ring any bells. So next step open 50g AUR and look a function No there is none unfortunately. So next best thing were a net search with 50g solution: http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=140178

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.

Length of arch of given function:

Code:

<<
IFERR // Works as documentation mainly
->
a
b
f
x
<<
RAD  // Radians mode - Just to be sure it does give a right solutions
a
b
'DERIV(f,x)'  // Could be implemented as RPN
EVAL // This is here because of algebraic expression above
DUP
*
1
+
SQRT
x
INTEGRAL  // Symbol
>>
THEN // These 4 objects are mainly as a description of use
" Give RANGE, f(x), x (a,b,f,x)
The speed and accuracy is disp.
format dependent."
MSGBOX
END 
>>

I have tested this against wolfram alpha and so far it does give approx. right values, but only in 1 decimal accuracy depends on the display settings/mode/format. Another option is that Wolfram Alpha does calculate incorrectly as it gives "Standard computational time exceeded..." message. I also did misuse the Parisses XCAS and copypasted the derivative of the f(x)=2x*Sin(10*x) from WA to XCAS and used integral there from 1 to 2 and the values between XCAS and WA do agree, while 50g with above program do not after the first digit. Any ideas? EDIT1: Above program also generates at times IERR variable "Integral ERROR" maybe, unfortunately at this time of night I can not recall.

Hopefully this is useful to somebody, but read the above notes about accuracy (see posts #2 and #3).

Cheers.

[Dieter]

First of all: I have absolute no experience with RPL, so I cannot comment on your code. But maybe this helps get you on the right track.

(06-05-2018 07:51 PM)Vtile Wrote:  I have tested this against wolfram alpha and so far it does give approx. right values, but only in 1 decimal accuracy. Another option is that Wolfram Alpha does calculate incorrectly as it gives "Standard computational time exceeded..." message.

I just entered "arc length of 2x*sin(10*x) x=1..2" and got a result with the integral of sqrt(1 + 4 (10 x cos(10 x) + sin(10 x))^2) dx and a numeric value of 19,628792649... The "Standard computation time exceeded..." message appears below the results, but this does not mean that these are incorrect.

(06-05-2018 07:51 PM)Vtile Wrote:  I also did misuse the Parisses XCAS and copypasted the derivative of the f(x)=2x*Sin(10*x) from WA to XCAS and used integral there from 1 to 2 and the values between XCAS and WA do agree, while 50g with above program do not after the first digit. Any ideas?

What does the 50g return as the derivative?
What exactly do you get as a result for the integral?
What do you get if you manually calculate the integral of sqrt(1 + 4 (10 x cos(10 x) + sin(10 x))^2) ?

For the record: my 35s returns 19,64 ±0,20 in FIX 2 mode and 19,642 ±0,020 in FIX 3. Trying to get more accurate results with FIX 4 or more causes a very long calculation which I finally interrupted. Here the display setting controls the accuracy, but I don't know how this is handled on the 50g.

So the integral seems to be a bit tricky. ;-) I tried it on the WP34s. Here FIX 2 yielded 19,62876... with an error estimate of ~0,0002 while FIX 4 returned 19,6287948... with an error estimate of ~0,00003. Finally, FIX 6 returned 19,628792649 which agrees with the WA value above. So the 34s performed better here. The last values took a few seconds on the emulator, so a hardware 34s would have required quite some time to come up with these results – and it is much faster than the 35s.

(06-05-2018 07:51 PM)Vtile Wrote:  EDIT1: Above program also generates at times IERR variable "Integral ERROR" maybe, unfortunately at this time of night I can not recall.

IERR is the estimated error of the result of a numeric integration, actually more like an upper bound of this error. So this tells you how accurate the 50g thinks the returned integral is. What value do you get here?

Dieter

[Vtile]

Hello Dieter!

I also think that the integration accuracy is dependent on the selected display format. I normally use ENG 3 format. That display format dependency is also what J. Horn did mention on some old post I did find at the morning. Weren't the 15C (and maybe other classic machines) like that also?

With ENG 6 mode, the above code indeed does give answer (50g):
ArcLength(2x*sin(10x)) = 19.6287926576
IERR = 1.962879...E-5
So it does agree with the wolfram alpha in 7 decimals, but it takes a while (coffee break) to calculate.
...a surprise is that WA refuges to go above integer value 3 (upper integration limit), it seems. XCAS (MODE: exact,real,RAD,16,MAPLE) as a whole calculation in a worksheet does give a value: 19.628792649016e0 simultaneously when I hit run (Intel i5-4690K Stock).

For ENG 4 mode, the given value (50g) is :
ArcLength(2x*sin(10x)) = 19.6287694327
IERR = 1.96E-3
(takes somewhat long)

For ENG 3 mode, the given value (50g) is:
ArcLength(2x*sin(10x)) = 19.6416300627
IERR = 19.6404..E-3

For FIX 3 mode, the given value (50g) is the same as above.

Standard mode the answer is (after a lunch):
ArcLength(2x*sin(10x)) = 19.628792649
IERR = 1.9.628..E-10

So summa summarum, the above code do give correct numerical approximations.

PS. here is the results as a table like format:

19.628792649016e0 XCAS
19.628792649... Wo.Al.
19.628792649 50g Standard mode
19.6287926576 50g ENG 6
19.6287694327 50g ENG 4
19.6416300627 50g ENG 3

[Carsen]

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

[Vtile]

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

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