WP 34S solve an integral

04242015, 05:53 PM
Post: #21




RE: WP 34S solve an integral
(04242015 12:16 PM)Dieter Wrote: I would recommend a solution like this: Nice touch Dieter. Clear yet short. Elegant. Bob Prosperi 

04242015, 06:22 PM
Post: #22




RE: WP 34S solve an integral
(04242015 12:16 PM)Dieter Wrote: I would recommend a solution like this:A beginners question: Where in Barry's program Code:
Many thanks for the help! Thomas 

04242015, 06:37 PM
(This post was last modified: 04242015 07:20 PM by Dieter.)
Post: #23




RE: WP 34S solve an integral
(04242015 06:22 PM)Thomas_Sch Wrote: A beginners question: The rounding is done at the very end of the function routine, right before the result is returned to SLV: Code: LBL A 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 fullaccuracy 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 displayrounded value of x is zero: Code: ... 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 

04242015, 07:07 PM
(This post was last modified: 04242015 07:10 PM by Thomas_Sch.)
Post: #24




RE: WP 34S solve an integral
Hello Dieter,
many thanks for your detailed explanations. The relationships are now clearer. Thomas 

04242015, 07:17 PM
Post: #25




RE: WP 34S solve an integral  
04242015, 07:30 PM
(This post was last modified: 04242015 07:30 PM by Thomas_Sch.)
Post: #26




RE: WP 34S solve an integral
You're faster than light ;)
Code: x≈0? 

04242015, 10:12 PM
Post: #27




RE: WP 34S solve an integral  
04242015, 10:27 PM
Post: #28




RE: WP 34S solve an integral
(04242015 10:12 PM)walter b Wrote: ..http://de.wikipedia.org/wiki/Reim_dich_o...fress_dich ;) 

04252015, 10:48 AM
Post: #29




RE: WP 34S solve an integral
(04242015 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 10 STO 00 SCI 3 2 ENTER 4 SLV 00 => 3,107 E+0 in < 8 s, error < 1E–7 Dieter 

04252015, 06:59 PM
(This post was last modified: 04252015 07:35 PM by BarryMead.)
Post: #30




RE: WP 34S solve an integral
(04252015 10:48 AM)Dieter 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!(04242015 06:37 PM)I Wrote: Please note that x≈0? is useless in display modes other than FIX. So don't use SCI, 

04252015, 08:54 PM
Post: #31




RE: WP 34S solve an integral
(04252015 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 

04252015, 09:09 PM
Post: #32




RE: WP 34S solve an integral
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!


« Next Oldest  Next Newest »

User(s) browsing this thread: