WP 34S solve an integral

[rprosperi]

(04-24-2015 12:16 PM)Dieter Wrote:  I would recommend a solution like this:

Code:

...
RDP 05    // round to e.g. 5 decimal places
x≠0?      // if result does not round to zero
x<> L     // recall the original unrounded value
RTN

This way the solver always gets the exact function result, and only values below the (here) 5–digit threshold are rounded to zero so that the solver quits.

Dieter

Nice touch Dieter. Clear yet short. Elegant.

[Thomas_Sch]

(04-24-2015 12:16 PM)Dieter Wrote:  I would recommend a solution like this:

Code:

...
RDP 05    // round to e.g. 5 decimal places
x≠0?      // if result does not round to zero
x<> L     // recall the original unrounded value
RTN

This way the solver always gets the exact function result, and only values below the (here) 5–digit threshold are rounded to zero so that the solver quits.
Dieter

A beginners question:
Where in Barry's program

Code:


LBL A
STO 00      //Save target integral result desired
DROP        //Lower stack to get Upper/Lower solve guess bounds
SLV 00
RTN
ERR 20      //If solve fails to find a root show this error
LBL 00
 0
∫ 01      // ∫ from x to 0 = –∫ from 0 to x 
RCL+ 00   // 10 – ∫
RTN
LBL 01
x²
RTN

should I insert your lines ?
Many thanks for the help!
Thomas

[Dieter]

(04-24-2015 06:22 PM)Thomas_Sch Wrote:  A beginners question:
Where in Barry's program (...) should I insert your lines ?

The rounding is done at the very end of the function routine, right before the result is returned to SLV:

Code:

LBL A
STO 00      //Save target integral result desired
DROP        //Lower stack to get Upper/Lower solve guess bounds
SLV 00
RTN
ERR 20      //If solve fails to find a root show this error
LBL 00
 0
∫ 01      // ∫ from x to 0 = –∫ from 0 to x 
RCL+ 00   // 10 – ∫
RDP 05    // round to e.g. 5 decimal places
x≠0?      // if result does not round to zero
x<> L     // recall the original unrounded value
RTN
LBL 01
x²
RTN

However, limiting the execution time of the Integrate function is much more important. Here the number of iterations depends on the display setting. So be sure to set something like SCI 4 or FIX 5. There is not much sense in having the integral calculated to 12 digits when finally 10 – this is rounded to 5 digits. ;-)

Remember: the execution time of Integrate is directly influenced by the display setting. The result is returned as soon as it matches display precision. On the other hand, Solve always tries to return a full-accuracy result, no matter which display format is set. That's why speeding up Solve requires manual rounding.

Addendum: in this particular case it would make sense to have Solve quit at the same accuracy level as Integrate, i.e. as soon as the result rounded to the current display setting becomes zero. This can be done with a simple ROUND command (rounds to display precision, unliike RDP that rounds to the number of specified digits). Or, even more elegant, use the dedicated x≈0? test which directly tests whether the display-rounded value of x is zero:

Code:

...
LBL 00
 0
∫ 01      // ∫ from x to 0 = –∫ from 0 to x 
RCL+ 00   // 10 – ∫
x≈0?      // if result rounds to zero
CLx       // then return zero
RTN
...

Now simply set FIX 4 or FIX 5 and you're done.

Please note that x≈0? is useless in display modes other than FIX. So don't use SCI, ENG or ALL here.

Dieter

[Thomas_Sch]

Hello Dieter,
many thanks for your detailed explanations. The relationships are now clearer.
Thomas

[Dieter]

(04-24-2015 07:07 PM)Thomas_Sch Wrote:  many thanks for your detailed explanations. The relationships are now clearer.

Please also note my update using the x≈0? test. ;-)

Dieter

[Thomas_Sch]

You're faster than light ;-)

Code:

x≈0?

"Every day a new command keeps the doctor away"

[walter b]

(04-24-2015 07:30 PM)Thomas_Sch Wrote:  "Every day a new command keeps the doctor away"

@Thomas: Reimen ist eine Kunst.

@Dieter: Thanks for your comprehensible explanations!

d:-)

[Thomas_Sch]

(04-24-2015 10:12 PM)walter b Wrote:  ..
@Thomas: Reimen ist eine Kunst.

http://de.wikipedia.org/wiki/Reim_dich_o...fress_dich ;-)

[Dieter]

(04-24-2015 06:37 PM)I Wrote:  Please note that x≈0? is useless in display modes other than FIX. So don't use SCI,

Well, here's a solution using x≈? Y which will work in all display modes. FIX is only required if the value in R00 or the integral is zero.

Code:

LBL 00
 0
x<> Y
∫ 01      // ∫ from 0 to x
RCL 00    // compare with value in R00
x≈? Y     // if both are approximately equal
ENTER     // then set Y = X so that...
 -        //  ...the following subtraction yields zero
RTN       // else return ∫ - R00
LBL 01
 x²
RTN

10 STO 00
SCI 3
2 ENTER 4   SLV 00
=> 3,107 E+0   in < 8 s, |error| < 1E–7

Dieter

[BarryMead]

(04-25-2015 10:48 AM)Dieter Wrote:  

(04-24-2015 06:37 PM)I Wrote:  Please note that x≈0? is useless in display modes other than FIX. So don't use SCI,

Well, here's a solution using x≈? Y which will work in all display modes. FIX is only required if the value in R00 or the integral is zero.

Code:

LBL 00
 0
x<> Y
∫ 01      // ∫ from 0 to x
RCL 00    // compare with value in R00
x≈? Y     // if both are approximately equal
ENTER     // then set Y = X so that...
 -        //  ...the following subtraction yields zero
RTN       // else return ∫ - R00
LBL 01
 x²
RTN

10 STO 00
SCI 3
2 ENTER 4   SLV 00
=> 3,107 E+0   in < 8 s, |error| < 1E–7

Dieter

Thanks Dieter: By testing convergence precision far away from zero you were able to preserve the relationship between displayed digits and error significance. Normally as a number approaches zero Scientific Notation display modes just reduce the power of 10 and keep the number of significant digits constant. So typically in these modes rounding near zero doesn't help. But by comparing the target value with the integral away from zero you were able to still use rounding to shorten the run time even in SCI, ENG, and ALL display modes. Nice work!

[Dieter]

(04-25-2015 06:59 PM)BarryMead Wrote:  Thanks Dieter: By testing convergence precision far away from zero you were able to preserve the relationship between displayed digits and error significance. Normally as a number approaches zero Scientific Notation display modes just reduce the power of 10 and keep the number of significant digits constant. So typically in these modes rounding near zero doesn't help. But by comparing the target value with the integral away from zero you were able to still use rounding to shorten the run time even in SCI, ENG, and ALL display modes. Nice work!

All this works with up to 12 digits – both ROUND and the x≈? commands are limited by the number of displayable digits. Which is perfectly fine for cases like this one where 4 or 5 digits will do since we want to get a fast result.

BTW the Integrate routine uses the same x≈? test, so again 12 safe digits is the best we can get. OK, the actual result usually is more precise since convergence is better than linear and the "exit logic" may add one more iteration "just to be sure". But let's not forget there is another similar test that allows comparing two values in 14, 24 or even 32 digits: the CNVG? test. It's especially useful in DP mode. For instance, replacing x≈? Y with CNVG? 01 would check whether X and Y agree in 24 significant digits.

BTW2: I would love to have a CNVG? test where the number of compared digits can be specified by the user instead of being limited to the three mentioned cases. So that e.g. CNVG? 20 would compare 20 significant digits. Yes, I know the current CNVG? can do a bit more (compare the absolute or relative error, handle NaNs etc), but still...

Dieter

[lrdheat]

Fascinating material! Neat to see the program mature through your work on this question, and neat to see the capabilities of the WP 34S, the range of tools available to a programmer!