(34S) Integration (using the double-exponential method)
|
03-24-2017, 02:21 PM
(This post was last modified: 06-15-2017 01:21 PM by Gene.)
Post: #1
|
|||
|
|||
(34S) Integration (using the double-exponential method)
This is my implementation of the double exponential integration method for the wp34s.
As stated in other threads, this method copes with discontinuities of the integrand or its derivatives at the integration interval ends, accepts infinities as interval ends and is, usually, much faster than the Romberg method. There are here 3 versions of this program (the 3 versions are not identical in behaviour):
This is the version suited to be keyed in by hand. Code:
|
|||
03-24-2017, 02:22 PM
(This post was last modified: 03-26-2017 08:01 PM by emece67.)
Post: #2
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
This one is the version to be assembled an put into LIB or RAM. Beware that this version does not exactly reproduce the behavior of the other two.
Code:
|
|||
03-24-2017, 02:23 PM
(This post was last modified: 04-02-2017 01:08 PM by emece67.)
Post: #3
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
And this last one is that aimed to replace the built-in integration program.
Code:
|
|||
03-25-2017, 12:33 AM
Post: #4
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
What do people think about including the last one in the 34S firmware?
Does it do the right thing with the final stack? Pauli |
|||
03-25-2017, 10:21 PM
Post: #5
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
My thumb is up. It could add to the list of WP34s 'uniquenesses'.
BTW, the license and copyright header reads: "M. César". That "M" must stand for marvellous... or may be mathematician... or both in one single letter, by some sort of arcane&syncopated algebraic expression ;O) Saludos Saluti Cordialement Cumprimentos MfG BR + + + + + Luigi Vampa + Free42 '<3' I + + |
|||
03-25-2017, 11:52 PM
(This post was last modified: 03-26-2017 12:12 AM by emece67.)
Post: #6
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-25-2017 12:33 AM)Paul Dale Wrote: What do people think about including the last one in the 34S firmware? Perhaps a little bit more time for people other than me to test the program is advisable. (03-25-2017 12:33 AM)Paul Dale Wrote: Does it do the right thing with the final stack? It does the very same thing, in this respect, that the built in integrator: corrupt all the stack. I was able to write a version (not to be used in XROM) preserving the stack, but I found some trouble when porting it to XROM. Perhaps I need some advice here. My approach was:
I do not want to use xIN/xOUT because it forces DBLON mode and because I'm not sure if XEQUSR/POPUSR can be used inside xIN/xOUT. In any case, I'm still trying to fix this (looking into ->A..D->). (03-25-2017 10:21 PM)Luigi Vampa Wrote: BTW, the license and copyright header reads: "M. César". That "M" must stand for marvellous... or may be mathematician... or both in one single letter, by some sort of arcane&syncopated algebraic expression ;O) Jaja, Luigi, la M solo es de Manuel. |
|||
03-26-2017, 12:25 AM
Post: #7
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-25-2017 11:52 PM)emece67 Wrote: It does the very same thing, in this respect, that the built in integrator: corrupt all the stack. The built in integrator doesn't corrupt the stack. It leaves the integral in X, the error estimate in Y and the original limits of integration in Z & T and also preserves the original X value in L. Refer to the 34C manual page 211. I'm don't remember what it does to A, B, C & D with stack size 8 -- XROM switches to four level stack mode on entry so they won't be directly altered, although the fills before calling user code might. Quote:I do not want to use xIN/xOUT because it forces DBLON mode and because I'm not sure if XEQUSR/POPUSR can be used inside xIN/xOUT. xIN/xOUT cannot nest so they cannot be used in integrate because the user's program might use a function that uses xIN/xOUT. Quote:In any case, I'm still trying to fix this (looking into ->ABCD->). [->]A..D and A..D[->] stash these four registers away in temporary volatile memory. They provided a way to gain some extra working registers before we had locals. It must be assumed that the temporary registers are lost when XEQUSR is called. - Pauli |
|||
03-26-2017, 11:33 AM
Post: #8
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-24-2017 02:23 PM)emece67 Wrote: cut I wish more programs posted here would have exhaustive comments like yours instead of just the program (that in RPN / RPL is unlikely to be "self descriptive") Wikis are great, Contribute :) |
|||
03-26-2017, 11:36 AM
Post: #9
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-24-2017 02:21 PM)emece67 Wrote: This is my implementation of the double exponential integration method for the wp34s. Looks like a nice and carefully coded program. Let me ask a few questions: There is a logic that calculates an epsilon value depending on the display setting. This seems to work fine in FIX mode. But how does this work in SCI/ENG or ALL mode? Note that (unlike RDP) ROUND rounds 1/9 to at most 11 places. Or a certain number of significant digits in SCI/ENG mode. At LBL 40 the program checks if the integration variable is within the integration limits. This is done by calculating the current x and comparing it to tm in R.06. In such cases I always wonder if roundoff errors might not lead to an error here. Suppose tm is 2 and h*j rounds to 2,000000000000001 so that the test returns false. Can this possibly happen? A simple counter would be a safe solution. Very small values of the integral, e.g. 1E–16, may be calculated because the actual value is zero, but just as well the correct value of the true integral. Is the program able to distinguish these two cases? BTW, Pi/2 is directly available as CNST 86. ;-) Dieter |
|||
03-26-2017, 06:34 PM
(This post was last modified: 03-26-2017 07:51 PM by emece67.)
Post: #10
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-26-2017 12:25 AM)Paul Dale Wrote: The built in integrator doesn't corrupt the stack. It leaves the integral in X, the error estimate in Y and the original limits of integration in Z & T and also preserves the original X value in L. Refer to the 34C manual page 211. I'm don't remember what it does to A, B, C & D with stack size 8 -- XROM switches to four level stack mode on entry so they won't be directly altered, although the fills before calling user code might. Surely that's the behavior of the 34C, but the 34s:
Thus, I've modified my program to behave more or less in the same way, so it now (v1.1r and v1.1x):
(03-26-2017 11:36 AM)Dieter Wrote: There is a logic that calculates an epsilon value depending on the display setting. This seems to work fine in FIX mode. But how does this work in SCI/ENG or ALL mode? Note that (unlike RDP) ROUND rounds 1/9 to at most 11 places. Or a certain number of significant digits in SCI/ENG mode. Later, epsilon (eps) is mainly used to compute some other values (thr & tm). Such values depend on the number of significant digits displayed thus, epsilon is not an absolute threshold for anything, but a number carrying information about the number of significant digits displayed. This way, eps is more meaningful here in ALL/SCI/ENG modes than in FIX mode. There was also an absolute comparison with eps that allows the program not to iterate (mainly when both integration ends are infinite) through a big number of abscissas whose weights are so small than they do not contribute to the final result. This was only an heuristic to speed-up computation, not the main convergence test. In any case, thanks to your comment, I've found that such test interferes with cases where the integrand is always very small, so I have changed such test and now all tests are relative. (03-26-2017 11:36 AM)Dieter Wrote: At LBL 40 the program checks if the integration variable is within the integration limits. This is done by calculating the current x and comparing it to tm in R.06. In such cases I always wonder if roundoff errors might not lead to an error here. Suppose tm is 2 and h*j rounds to 2,000000000000001 so that the test returns false. Can this possibly happen? A simple counter would be a safe solution. j is a small integer only updated with INC. h is an integer power of 2 from 2 to 1/256 updated by continued division by 2, all these powers have an exact decimal representation in the wp34s. Thus, h*j is always exactly representable in the machine, so no concerns about roundoff here. (03-26-2017 11:36 AM)Dieter Wrote: Very small values of the integral, e.g. 1E–16, may be calculated because the actual value is zero, but just as well the correct value of the true integral. Is the program able to distinguish these two cases? Being now all tests relative, integrands that are always small do not pose any special problem. But the program does not distinguish if the true integral is zero and the computed, small, result is due to round-off, or the computed, small, result is a nice approximation of a small but not zero integral. (03-26-2017 11:36 AM)Dieter Wrote: BTW, Pi/2 is directly available as CNST 86. ;-) In my local builds that's not true, cause I have a modified CONST menu, so I try to avoid such constructs. |
|||
03-26-2017, 08:19 PM
Post: #11
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-26-2017 06:34 PM)emece67 Wrote: Surely that's the behavior of the 34C, but the 34s: AFAIR one of the final steps of the integration routine was a STO–Y so that Y does not hold the previous approximation but the difference compared to the last one. The content of the other lower stack registers are just as they are supposed to. (03-26-2017 06:34 PM)emece67 Wrote: 5. Corrupts ABCD with some unknown data (no matter if the user is in SSIZE4 or SSIZE8, ABCD are always corrupted) A, B, C and D may be corrupted, yes. (03-26-2017 06:34 PM)emece67 Wrote: Thus, I've modified my program to behave more or less in the same way, so it now (v1.1r and v1.1x): I would prefer an error estimate in Y, as it is returned by the 34C and 15C. And I think this also is the way the 34s integration routine is supposed to work. Pauli? Dieter |
|||
03-27-2017, 12:09 AM
Post: #12
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method) | |||
03-27-2017, 12:10 AM
Post: #13
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method) | |||
03-27-2017, 06:41 AM
(This post was last modified: 03-27-2017 07:33 AM by Dieter.)
Post: #14
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-27-2017 12:10 AM)Paul Dale Wrote: That's how I thought it worked. Seems I was wrong or something got lost somewhere. The current integration code can be examined on sourceforge.net. The exit routine at int_done starts with the last two approximations in X and Y, then recalls the two limits and rearranges the stack so that the limits are in Z and T and the last two approximations in X and Y. And indeed there is no final STO–Y that would leave an error estimate in Y. Edit: The switch from Gauss-Kronrod to Romberg was somewhere between v2240 and v2260. If you compare the integration code of v2240 with that of v2260 you will notice that the former indeed calculated an error estimate from the last two approximations... Code: /* Set up the stack for our output */ ...while already the earliest Romberg versions didn't: Code: /* Three matches in a row is goodness. */ ...and this obviously has never been corrected. Since the 34s manual says the user interface is "as in the HP-15C" I think this should be done, e.g. like this: Code: int_done:: RCL- Y This way (last approx. – prev. approx.) is returned in Y. Dieter |
|||
03-27-2017, 07:53 AM
Post: #15
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
I'll change my program to return an error estimation in Y.
I've found that, after the change I made cause of Dieter's comment about epsilon, there's now a way to discern when a small result is due to roundoff when evaluating an integral that is zero or a small result due to an integral that is truly small, but different from 0. I'll try to add an heuristic to return 0 when the integral seems to be zero. Regards. |
|||
03-27-2017, 05:42 PM
(This post was last modified: 03-28-2017 08:19 AM by emece67.)
Post: #16
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
Changes done (v1.2r and v1.2x).
Now the program:
There's also a check around the estimated error used to distinguish between integrals that evaluate to 0 and those that evaluate to small numbers. Now, integrals suspected to be equal to 0 are reported as such, thus \(\int_{-\pi}^\pi \cos(x)dx\) will be evaluated to 0, but \(\int_{-\pi/2}^{\pi/2} 10^{-100}\cos(x)dx\) will be evaluated to \(2·10^{-100}\). Both computations will return and estimated error different from 0. Regards. Edited: removing the comment about ABCD remaining untouched. |
|||
03-28-2017, 03:30 AM
Post: #17
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
(03-27-2017 05:42 PM)emece67 Wrote: Keeps ABCD untouched It is not possible to use A..D-> and ->A..D to preserve the A-D registers across a call to user code. These commands stash the register values at a fixed location in volatile RAM which will be lost under some circumstances. It will also break with nested integrals or with mixed solve and integrate. The only way to preserve the A-D registers is to allocate four additional local registers for the purpose. The A..D-> and ->A..D commands are left from when I implemented solve without the benefit of local registers and had to squeeze everything into a very limited number of special XROM registers. I needed more temporary space so I added these two commands. Like several other specials for XROM, they are extremely specific to my purpose at the time and come with major caveats. - Pauli |
|||
03-28-2017, 08:20 AM
Post: #18
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
Program description modified removing the statement about ABCD remaining untouched.
|
|||
03-28-2017, 09:03 AM
Post: #19
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
It would be prudent to also remove the ->A..D and A..D-> commands as well.
Pauli |
|||
03-28-2017, 08:40 PM
Post: #20
|
|||
|
|||
RE: (WP-34S) Integration (using the double-exponential method)
As you insisted, I've commented out such lines.
Regards, |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 8 Guest(s)