Crash when Solve for Integral with 15C

[Thomas Okken]

(09-02-2017 01:24 PM)grsbanks Wrote:  

(09-02-2017 02:41 AM)rprosperi Wrote:  Then it occurred to me that I was running in FIX 2 mode, which could be affecting behavior. So I changed display mode to SCI 4, and I then got the same result in about the same time as your results.

Bingo! The display format is why my DM15L just kept on running. Should have remembered that is how it derives (no pun intended) its accuracy.

What accuracy and display format did you use when you tested this on the DM42? I just get an "Out of range" error when attempting the integration.

It works fine for me -- my program looks like this:

01 LBL "ECUBE"
02 MVAR "X"
03 RCL "X"
04 3
05 Y^X
06 E^X
07 END

LLIM=0, ULIM=6; for ACC I tried 0 and 1E-12, and the integration works fine with both (though it takes about 26 minutes with ACC=0).

[rprosperi]

(09-02-2017 08:09 PM)Thomas Okken Wrote:  No, INTEG doesn't change or unset ACC. I was referring to the case in which the ACC variable doesn't exist (hasn't been created, or has been CLV-ed); in that case, INTEG behaves as with ACC=0.

Thanks. Some quick checking reveals the 42S/Free42 create ACC (=0.0) if it doesn't exist when entering Integrate, but thereafter it is retained, like any other Real VAR, unless redefined or CLV-ed.

[Thomas Okken]

(09-02-2017 08:24 PM)rprosperi Wrote:  

(09-02-2017 08:09 PM)Thomas Okken Wrote:  No, INTEG doesn't change or unset ACC. I was referring to the case in which the ACC variable doesn't exist (hasn't been created, or has been CLV-ed); in that case, INTEG behaves as with ACC=0.

Thanks. Some quick checking reveals the 42S/Free42 create ACC (=0.0) if it doesn't exist when entering Integrate, but thereafter it is retained, like any other Real VAR, unless redefined or CLV-ed.

Correct, but if you call INTEG without using the ∫f(x) menu, e.g.

PGMINT "ECUBE"
0
STO "LLIM"
6
STO "ULIM"
CLV "ACC"
INTEG "X"

ACC is not created. In other words, it is created by the ∫f(x) menu, not by the INTEG function.

[Dieter]

(09-02-2017 08:14 PM)rprosperi Wrote:  

(09-02-2017 06:42 PM)Gerson W. Barbosa Wrote:  ...
0 ENTER 216 ALPHA EE ALPHA XEQ ALPHA INTEG ALPHA => 1.7892E92 (5'17")
...

Ok, I just have to ask... why 216?

The integration limits have to be substituted, i.e. they are now 0³ = 0  and  6³ = 216.

Dieter

[rprosperi]

(09-02-2017 08:29 PM)Thomas Okken Wrote:  Correct, but if you call INTEG without using the ∫f(x) menu, e.g.

PGMINT "ECUBE"
0
STO "LLIM"
6
STO "ULIM"
CLV "ACC"
INTEG "X"

ACC is not created. In other words, it is created by the ∫f(x) menu, not by the INTEG function.

Those damn GUIs! Always doing stuff in the background, whether you ask them to or not. But in this case, it's a good thing.

[Gerson W. Barbosa]

(09-02-2017 08:34 PM)Dieter Wrote:  

(09-02-2017 08:14 PM)rprosperi Wrote:  Ok, I just have to ask... why 216?

The integration limits have to be substituted, i.e. they are now 0³ = 0  and  6³ = 216.

Yes, because of the variable change suggested by you, BTW, as an attempt to improve the execution time.

I did

u=x^3 -> x=u^(1/3)

du/dx=3*x^2 -> dx=du/(3*x^2)

-> Integ(e^x^3 dx, 0, 6) = 1/3*Integ(e^u/u^(2/3), 0, 216)

Interestingly the speed improvement on the 34C, as reported by AndyGer, and the HP-41CV (w/ Advantage ROM) is about only 20%, not so good as the 50% I had observed on the iOS HP-15C emulator by HP.

Gerson.

PS: W|A gives a closed form solution for the latter in terms of Gamma and Incomplete Gamma functions:

1/6(1+i*sqrt(3))*(Gamma(1/3)-Gamma(1/3,-6^3))

Unfortunately the Incomplete Gamma implementation on the WP34S won't handle these arguments.

PPS: Edited to fix a typo per Bob Prosperi's observation below.

PPPS: Edited again to add a 1/3 constant I had missed when transcribing my own hand-written note, as spotted by Pekis ahead.

[rprosperi]

(09-02-2017 08:55 PM)Gerson W. Barbosa Wrote:  

(09-02-2017 08:34 PM)Dieter Wrote:  The integration limits have to be substituted, i.e. they are now 0³ = 0  and  6³ = 216.

Yes, because of the variable change suggested by you, BTW, as an attempt to improve the execution time.

I did

u=x^3 -> x=u^(2/3)

du/dx=3*x^2 -> dx=du/(3*x^2)

-> Integ(e^x^3 dx, 0, 6) = Integ(e^u/e^(2/3), 0, 216)

Interestingly the speed improvement on the 34C, as reported by AndyGer, and the HP-41CV is about only 20%, not so good as the 50% I had observed on the HP-15C emulator.

Gerson.

PS: W|A gives a closed form solution for the latter in terms of Gamma and Incomplete Gamma functions:

1/6(1+i*sqrt(3))*(Gamma(1/3)-Gamma(1/3,-6^3))

Unfortunately the a Incomplete Gamma implementation on the WP34S won't handle these arguments.

Thanks for breaking that down for us mere mortals Gerson. I had puzzled over it for a few moments and had just given up.

[Gerson W. Barbosa]

(09-02-2017 09:06 PM)rprosperi Wrote:  Thanks for breaking that down for us mere mortals Gerson. I had puzzled over it for a few moments and had just given up.

You're much welcome, Bob! My fault as I didn't provide more information in the first place. It took me a while to remember how to do it by hand as well. Notice I'd replaced a 'u' for an 'e' in the second integral, which has been corrected now.

Gerson.

[grsbanks]

(09-02-2017 08:19 PM)Thomas Okken Wrote:  

(09-02-2017 01:24 PM)grsbanks Wrote:  Bingo! The display format is why my DM15L just kept on running. Should have remembered that is how it derives (no pun intended) its accuracy.

What accuracy and display format did you use when you tested this on the DM42? I just get an "Out of range" error when attempting the integration.

It works fine for me -- my program looks like this:

01 LBL "ECUBE"
02 MVAR "X"
03 RCL "X"
04 3
05 Y^X
06 E^X
07 END

LLIM=0, ULIM=6; for ACC I tried 0 and 1E-12, and the integration works fine with both (though it takes about 26 minutes with ACC=0).

Thanks to you both. I can't think what I must have been doing wrong earlier.

[rprosperi]

(09-02-2017 09:56 PM)Gerson W. Barbosa Wrote:  You're much welcome, Bob! My fault as I didn't provide more information in the first place. It took me a while to remember how to do it by hand as well. Notice I'd replaced a 'u' for an 'e' in the second integral, which has been corrected now.

That's quite alright. If you had explained it in the initial post, I likely would have just skimmed over it and spent no time thinking about (vs. the little time I did spend, but better little than none!) so by showing just the solution and a hint, it helped me to explore it and learn a bit more.

But in the top line of the notes you show:

u=x^3 -> x=u^(2/3)

Shouldn't x=u^(1/3) ?

[Gerson W. Barbosa]

(09-02-2017 11:29 PM)rprosperi Wrote:  

(09-02-2017 09:56 PM)Gerson W. Barbosa Wrote:  You're much welcome, Bob! My fault as I didn't provide more information in the first place. It took me a while to remember how to do it by hand as well. Notice I'd replaced a 'u' for an 'e' in the second integral, which has been corrected now.

That's quite alright. If you had explained it in the initial post, I likely would have just skimmed over it and spent no time thinking about (vs. the little time I did spend, but better little than none!) so by showing just the solution and a hint, it helped me to explore it and learn a bit more.

But in the top line of the notes you show:

u=x^3 -> x=u^(2/3)

Shouldn't x=u^(1/3) ?

Thank you for spotting yet a second typo. Fixed!

Gerson.

[rprosperi]

(09-03-2017 12:57 AM)Gerson W. Barbosa Wrote:  Thank you for spotting yet a second typo. Fixed!

Gerson.

Thank heavens for typos, else I would have been sooo confused. Thx!

[Gilles59]

I tried again with with the HP15LE,

SCI 4
HP15LE : 5.9639E91 in 7 seconds
HP50G : 5.9639E91 in 17 seconds
HP49G : 5.9639E91 ~ 40 seconds


SCI 6
HP15LE : 5.963938E91 in 20 seconds
HP50g : 5.963938E91 in 32 seconds
HP49g : 5.963938E91 in ~ 65s

All digits :
5.9639380919E91 in ~1mn with the 50G
Always displaying "Running" with the 15LE after few minutes, I stopped by pressing ON

[brickviking]

For my two Casio fx-9750s, I got the following results. fx-9750g+ wouldn't integrate it, claiming a Ma Error on both the Gauss and Simpson methods. However, the fx-9750GII SH4 (with the OS upgraded to 9760GII) gave me 5.963938092 E91 using this formula (where $ means integration symbol): $(f(x), lower, upper, tolerance). It took about 3.5 seconds for $(e^x^3, 0, 6, 0.001), about 5.8 seconds for 0.00001, about 10.6 seconds for 0.00000001 and about 12.3 seconds for 0.000000001.

My HP-50G took about 1m5s $(0,6,e^x^3,x) ->NUM and coughed up 5.9639380919 E91 with Std number format and 16 seconds with FIX4. Switching it back to Std coughed up 5.96393743779E91, but I expected this. What I didn't expect was that a Casio with SH4A (and no known FPU) clocked at 29.5MHz (or thereabouts), a supposedly inferior machine, came up with a significantly faster time than a calculator clocked roughly at 75MHz.

EDIT: added data for clock speeds.

(Post 72)

[grsbanks]

(09-03-2017 08:01 AM)brickviking Wrote:  What I didn't expect was that a Casio with SH4A (and no known FPU) clocked at 29.5MHz (or thereabouts), a supposedly inferior machine, came up with a significantly faster time than a calculator clocked roughly at 75MHz.

The machine running at 75MHz is an ARM machine emulating a Saturn processor. The effective speed of the emulated Saturn machine is going to be far lower than 75MHz and quite possibly lower than your Casio's 29.5MHz. TTBOMK there is no FPU in the HP either.

[Gerson W. Barbosa]

375

« 0 DUP ROT
FOR n n 3 * 1 + DUP n ! * 6 ROT ^ SWAP / +
NEXT EXPAND →STR "/" " " SREPL DROP "'" " " SREPL DROP OBJ→ SWAP OVER IDIV2 ROT / →NUM →STR SWAP →STR SWAP +
»

EVAL =>

5963938091897677519629167884945125687567068238536000
80366842664928717762274710443143932443681.0000000000

Only the first 22 digits are correct. 600+ terms would be necessary for 100 digits, but a clean 50g will run out of memory after around 380 terms. Also, it takes 414 seconds to get this result on the m48+ iOS emulator. Definitely neither the right tool nor the right method for this task, but it doesn't hurt trying.

The series was obtained by integrating the Taylor series of the original integral, term by term.

[Matt Agajanian]

Gotta ask. Even using iPhone's version of Vicinno's 15E with FIX 6 accuracy, after 10 minites, still running. So I guess it's just the nature of e^(x^3) regardless of the calculator, laptop?

[Thomas Okken]

(09-03-2017 07:38 PM)Matt Agajanian Wrote:  Gotta ask. Even using iPhone's version of Vicinno's 15E with FIX 6 accuracy, after 10 minites, still running. So I guess it's just the nature of e^(x^3) regardless of the calculator, laptop?

Evaluating that integral to that degree of accuracy requires the integrand to be sampled 1023 times by the Romberg integrator in Free42. Depending on implementation details, other calculators may get there in one fewer iteration, which would mean 511 samples.

This is all independent of the speed of the hardware on which you're running the calculation; I'm only talking about how often the function has to be executed.

If you insert 1 STO+ 0 in your function somewhere, you can keep track of how often it is called, and at what rate. More than 1023 points to a buggy integrator; an invocation count that increases very slowly points to a slow calculator.

[Matt Agajanian]

(09-03-2017 08:00 PM)Thomas Okken Wrote:  

(09-03-2017 07:38 PM)Matt Agajanian Wrote:  Gotta ask. Even using iPhone's version of Vicinno's 15E with FIX 6 accuracy, after 10 minites, still running. So I guess it's just the nature of e^(x^3) regardless of the calculator, laptop?

Evaluating that integral to that degree of accuracy requires the integrand to be sampled 1023 times by the Romberg integrator in Free42. Depending on implementation details, other calculators may get there in one fewer iteration, which would mean 511 samples.

This is all independent of the speed of the hardware on which you're running the calculation; I'm only talking about how often the function has to be executed.

If you insert 1 STO+ 0 in your function somewhere, you can keep track of how often it is called, and at what rate. More than 1023 points to a buggy integrator; an invocation count that increases very slowly points to a slow calculator.

Counting iterations--Clever! Thanks for the explanation and monitoring tactic.

[rprosperi]

(09-03-2017 08:00 PM)Thomas Okken Wrote:  If you insert 1 STO+ 0 in your function somewhere, you can keep track of how often it is called, and at what rate. More than 1023 points to a buggy integrator; an invocation count that increases very slowly points to a slow calculator.

I was wondering how/where you were getting Fn evaluation counts. Clever! Simple! The best tips always are both. Thanks.