The Museum of HP Calculators

HP Forum Archive 16

 About HP-33S integrationMessage #1 Posted by Antonio Maschio (Italy) on 24 July 2006, 9:32 a.m. Hi, I noticed that 33S integration is good, but... Try it yourself. Put x^2 into EQN or as a program (in this case define FN= as the label you used). Integrate in FIX 2 from 0 to 4. It should yield 64/3 (21.33). The result is correct (even if you extend the FIX to 9 or to ALL), but the uncertainty on the Y stack register is 0.21. I cannot remember exactly what the HP-32SII yields, but I guess it's at least 100 times smaller. Isn't 0.21 too big for such a calculator? Is there something wrong in assuming that even in FIX 2 the uncertainty should be 0.0021 (or something), that is lesser than the last useful decimal digit fixed in FIX? Thanks is advance for your advice. -- Antonio

 Re: About HP-33S integrationMessage #2 Posted by Karl Schneider on 24 July 2006, 2:50 p.m.,in response to message #1 by Antonio Maschio (Italy) Hi, Antonio -- Interesting finding! On my HP-32S and HP-32SII, I get 0.02000000005 as the estimated error -- one order of magnitude smaller than the error estimated by the HP-33S (0.21291207886). When the display mode is changed to "SCI 2", the error is 0.04939691181 on the HP-32S/SII, but unchanged on my HP-33S (S/N CNA413nnnnn). The forumlae for estimating the the upper bound of the error in the result were originally specified in the manual for the HP-15C (pages 247-248) and for the HP-34C (pages 245-246). The method was carried forward to the HP-41 Advantage Pac and the HP-32S and HP-32SII -- all of which were RPN calculators that utilized FIX/SCI/ENG for specifying the uncertainty of the input function. The HP-42S does it a bit differently (and better), with an accuracy factor variable "ACC" that is a fixed multiplier of the value of the integrand. Diferent formulae were apparently used in the HP-33S. Compare respective pages 8-7 and 8-8 in the HP-32SII and the HP-33S manuals. Both manuals illustrate the same examples, but the calculations of upper-bound estimated error are quite different. The HP-33S estimate of the error is very coarse -- seemingly just a multiplier of the result, which actually was quite a bit closer to the actual answer than the error estimate suggested. Here's how it used to be done, on the "all-HP" calculators: Using FIX 2, the uncertainty of the integrand is 0.005. This constant "half-ribbon", multiplied by the interval (4-0) = 0.020. Easy enough. Using SCI 2, the ribbon becomes an order of magnitude wider when the value of the integrand exceeds 10.0 when x > sqrt(10) ~= 3.162. Thus, the caclulated error should be higher than with FIX 2. -- KS Edited: 25 July 2006, 2:34 a.m.

 Re: About HP-33S integrationMessage #3 Posted by Antonio Maschio (Italy) on 25 July 2006, 2:44 a.m.,in response to message #2 by Karl Schneider Karl wrote: Quote: Here's how it used to be done, on the "all-HP" calculators: # Using FIX 2, the uncertainty of the integrand is 0.005. This constant "half-ribbon", multiplied by the interval (4-0) = 0.020. Easy enough. # Using SCI 2, the ribbon becomes an order of magnitude wider when the value of the integrand exceeds 10.0 when x > sqrt(10) ~= 3.162. Thus, the caclulated error should be higher than with FIX 2. -- KS But why the uncertainty shouldn't be expressed as itself? I mean, I ask for 2 correct decimal digits of the integral; I expect the error being confined to the third digit. Or not? I tried even the interval 0-10; the result is 333.33 and the uncertainty is 3.33! Maybe I didn't understand what "uncertainty" means. Can you tell me a simple way to obtain a simple error estimate, just like on the old dear HP-15C? Thanks in advance. -- Antonio by the way: you seem to define uncertainty as a constant "half-ribbon" multiplied by the interval. But different intervals give different ribbons. Am I totally wrong? -- Antonio

 Re: About HP-33S integrationMessage #4 Posted by Karl Schneider on 26 July 2006, 3:06 a.m.,in response to message #3 by Antonio Maschio (Italy) Antonio -- The user's manuals for the HP-15C and the HP-34C explain the philosophy and implementation of numerical integration on those models. This formed the basis of the approach used on subsequent RPN models, for which the numerical integration function is not nearly as well documented. I'm not sure how accessible (or even available) the manuals for the HP-15C and the HP-34C are, in Italian. The idea is this: It is not reasonable for a user to directly specify a required maximum error for the result of a numerical integration, because the exact answer is not known. Instead, the user specifies the accuracy (or tolerance) of the integrand function by using the display-mode settings (FIX, SCI, or ENG). The calculator produces a "worst-case" estimated error by integrating the tolerance of the integrand function over the range of integration. Assuming that the integral is calculated accurately, the estimated error will likely exceed the actual error by a significant percentage amount. Original method of estimating error of integration: This original method is implemented as described on the HP-34C, HP-15C, HP-32S, HP-32SII, and HP-41 Advantage Pac. (On the HP-42S, the uncertainly is entered as an "accuracy factor" multiplier variable, without using FIX/SCI/ENG.) If FIX 2 is set, the displayed value of the integrand function will be within +/- 0.005 of the full numerical value, so the "actual" value (whatever it is) will be assumed to be within the same tolerance. This absolute uncertainty can be visualized as a ribbon or band of fixed width. Thus, the estimated maximum error will be 0.005*(b-a), where a and b are the limits of integration. SCI and ENG are a bit trickier. If SCI 2 is set, the displayed value of the integrand function will be within 0.005 x 10n of the full numerical value, where n is the base-10 exponent displayed. This is a stepwise relative uncertainty. The estimated error must be calculated by integration, and the tolerance "band" widens by an order of magnitude when the integrand function increases beyond an integer power of 10. HP-33S estimated error of integration: Perhaps the different error calculations on the HP-33S are "simpler" and more consistent between FIX, SCI, and ENG, but I believe that the user is being poorly served by the unnecessarily-coarse estimates of error. It is quite clear that the HP-33S calculated integral of f(x) = x2 between x = 0 and x = 4 is much closer to the actual answer of 21 1/3 than the displayed error of 0.21 would indicate. If the HP-33S is estimating integration error using FIX N, SCI N, ENG N as follows: ```Estimated_error = Calculated_integral * 10-N ``` Well... that's just not very good. -- KS Edited: 26 July 2006, 3:14 a.m.

 Re: About HP-33S integrationMessage #5 Posted by Antonio Maschio (Italy) on 26 July 2006, 5:04 a.m.,in response to message #4 by Karl Schneider Thanks, Karl, you've been very clear and kind (and patient!). I assume you are mathematically more involved than me (I'm a civil engineer with some rust on my math memories). I ask you: is there a way to detect the error estimate of the HP-33S, basing on the data it yields? I guess no, if "error estimate" is the result multiplied by 10^N. -- Antonio (P.S. I got the Italian manual of the HP-33S, and nothing on it seems to clear these concepts). Thanks again.

 Re: About HP-33S integrationMessage #6 Posted by Karl Schneider on 26 July 2006, 9:52 p.m.,in response to message #5 by Antonio Maschio (Italy) Antonio -- Quote: I ask you: is there a way to detect the error estimate of the HP-33S, basing on the data it yields? I guess no, if "error estimate" is the result multiplied by 10^N. -- Antonio (P.S. I got the Italian manual of the HP-33S, and nothing on it seems to clear these concepts). The HP-33S manuals (as well as the HP-32SII manuals) in English are no more specific. That's why I pointed out the HP-34C and HP-15C manuals for a detailed explanation of the implementation of numerical integraion. The subsequent manuals were "de-contented" and "dumbed-down", to use several slang phrases. So, I really don't know how the HP-33S calculates its estimate of error, but it doesn't seem very accurate. In your example, it's not exactly a multiplication by 10-N (where N is the number of decimal places, as stated in the manual), but it's very close. It was also a "sneaky" change from the HP-32SII, as I mentioned. The two examples using SCI are exactly the same, except for the value of the error estimate. I ought to augment my article regarding use of SOLVE/INTEG on RPN-based models with this information. -- KS

 HP-33S estimated error of integration: mystery solved!Message #7 Posted by Karl Schneider on 27 July 2006, 3:21 p.m.,in response to message #5 by Antonio Maschio (Italy) Antonio and Kiyoshi -- I state with confidence that I have solved the mystery of the error calculations on the HP-33S! Bottom line: The HP-33S uses the same method for specifying the uncertainty of the integrand, and calculating the estimated error of the integral, as does the HP-48G (and other RPL models, except the the HP-28C/S). Kiyoshi's recent post contained a clue that led me toward the answer: Quote: Integrating x2 from 0 to 0.1 in FIX 2 produces 3.33E-4 +/- 5.00E-4 , where the uncertainty is larger than the answer. This is on a 15C, I don't have a 33S. My 48GX does better, producing 3.33E-4 +/- 3.33E-6. I hadn't known how to obtain the estimated error of integration on my 48G, but evidently, it was possible. Pages 20-6 and 20-7 of the HP-48G manual revealed that "FIX 2" specified an accuracy factor of 0.01, from which the error was estimated accordingly, and stored as the variable "IERR". This computational method is the one employed in the HP-42S, which uses the variable "ACC" to specify the accuracy factor, and returns the estimated error to the stack. On the HP-48G, however, the FIX/SCI/ENG/ALL (or "standard") display modes are used instead of a variable to specify the accuracy factor. This has several drawbacks: It's not very intuitive, whereas the HP-42S procedure is much more so. Only a few different values can be specified. It's not the same way FIX/SCI/ENG/ALL were used for integration in the HP-34C, HP-15C, HP-32S, HP-32SII, and HP-41 Advantage Pac. The result and error values I obtained for the integral of f(x) = x2.dx over x = 0 to x = 4, with FIX 2 or "ACC" = 0.01 were identical on the HP-33S, HP-42S, and the HP-48G -- namely, 21.333138 and 0.212912 in FIX 6. Conversely, the HP-34C, HP-15C, HP-32S, HP-32SII, and HP-41 Advantage Pac use the FIX setting to define an absolute uncertainty. This will tend to give results and error estimates that are more precise for large-valued integrands, but relatively coarser for small-valued integrands, as Kiyoshi found. -- KS Edited: 27 July 2006, 11:34 p.m.

 Re: HP-33S estimated error of integration: mystery solved!Message #8 Posted by Antonio Maschio (Italy) on 28 July 2006, 4:36 a.m.,in response to message #7 by Karl Schneider Karl, if I understand what you say (don't bet I do, anyway!), 1) the HP-33S method is suitable for smaller integrals, but not that much for larger ones 2) the HP-33S method gives a relative uncertainty, depending on the "n" of FIX "n", being 10^(-n) the factor. Q: Is there a way to retrieve the absolute uncertainty basing on the values HP-33S returns? Suppose you want to integrate for 0 to 1000; the result in FIX 2 is 333330281.58, and the uncertainty is 3326751.23; surely too much, if I asked a precision till the second decimal. In any case, good work! -- Antonio Edited: 28 July 2006, 6:15 a.m.

 Re: HP-33S estimated error of integration: mystery solved!Message #9 Posted by Karl Schneider on 28 July 2006, 11:25 a.m.,in response to message #8 by Antonio Maschio (Italy) Antonio -- The HP-33S method works like the HP-42S method, and is patterned after the HP-48 method. If you want high precision for high-valued integrands, specify more decimal places, e.g., FIX 6. ALL should give the highest preceision (and take more time). There is no way to specify an absolute uncertainty. -- KS

 Re: HP-33S estimated error of integration: mystery solved!Message #10 Posted by Antonio Maschio (Italy) on 28 July 2006, 12:00 p.m.,in response to message #9 by Karl Schneider Thanks, Karl, for your patience. -- Antonio

 Re: HP-33S estimated error of integration: mystery solved!Message #11 Posted by Kiyoshi Akima on 28 July 2006, 1:04 p.m.,in response to message #7 by Karl Schneider I'm not so convinced we've got it solved. Try integrating ``` /2pi | ln(1+x) sin(1001x) dx /0 ``` for FIX 0,1,2,4,6 at the least. On the 48GX, the estimated error for FIX 0 is nearly an order of magnitude larger than the estimated integral, while at FIX 1 the error estimate is three times the estimated integral. In both cases the answer is wrong by two orders of magnitude and has the wrong sign. In FIX 4 the answer is off by two orders of magnitude and still has the wrong sign, though at least the error is less than the answer. In FIX 6 the machine finally comes close. The results are comparable though not identical on the 15C and 34C. A quick look at the function shows why it's so troublesome, even though it's well-behaved with no singularities: It's very oscillatory. I'll keep playing with this over the weekend and I'll tabulate/post my results next week. If someone wants to send me the results from the 33S, I'll be happy to include them. Just click on my name at the top of this message to get my email address. I'll also post a program to efficiently numerically evaluate this type of function, getting five significant digits with as few as three function evaluations as opposed to the 8191 evaluations used by the built-in integrators at FIX 6 to get the same accuracy.

 HP-33S integration: oscillating integrandMessage #12 Posted by Karl Schneider on 29 July 2006, 12:47 a.m.,in response to message #11 by Kiyoshi Akima Quote: I'm not so convinced we've got it solved. Try integrating ``` /2pi | ln(1+x) sin(1001x) dx /0 ``` Well, all I claimed to solve was to determine which method the HP-33S was using to calculate its estimated maximum error of integration, and I'm standing by my assertion... :-) As for the integral, it does oscillate rapidly, causing computational difficulties. The integrand has exactly 1001 complete cycles, with each one having a slight negative net area, due to the slowly but monotonically increasing LN function. I got an answer of -0.00198 (rounded) with a maximum estimated error of 5.195 x 10-8 on the HP-42S with ACC = 1E-8 (equivalent to FIX 8). Comparison with several partial integrals suggests that this answer is quite reasonable. The HP-48G with STD mode (full 12-digit accuracy) gave an integral of -0.0019835838188 with an error of 5.204 x 10-11. The HP-33S with FIX 8 gave the same answer as the HP-42S: -0.0019835837645 with an error of 5.195229 x 10-8. -- KS Edited: 29 July 2006, 4:33 a.m.

 Re: HP-33S integration: oscillating integrandMessage #13 Posted by Kiyoshi Akima on 31 July 2006, 12:54 p.m.,in response to message #12 by Karl Schneider We're getting a little off topic here, aren't we? :-) Just for fun, try it using a lower display setting. On my 48GX: ```display result error evals FIX 0 0.52396 4.39 7 FIX 1 0.17830 5.54E-1 255 FIX 2 0.17830 5.54E-2 255 FIX 3 0.17824 5.54E-3 511 FIX 4 0.17610 5.38E-4 511 FIX 5 0.17610 5.38E-5 511 FIX 6 -1.98E-3 5.20E-6 8191 ``` The error estimate goes down by an order of magnitude for each additional display digit, as we would expect. But the answers aren't even in the right ballpark until we get to FIX 6. At FIX 2 through FIX 5, the error range doesn't even include the correct result. The reason is obvious. As you've pointed out, the integrand oscillates through 1001 cycles. It isn't until you get to FIX 6 that the integrator samples enough points. At FIX 5 it only samples every other cycle. Is it any wonder it's so far off? It isn't until it samples each cycle twice (the Nyquist frequency for any EEs out there) that it starts to come close. The built-in integrator goes until three successive estimates agree to within the specified error tolerance. The results above tell me that 2K, 4K, and 8K (minus 1) points were needed to get the required consensus. There are special integration schemes for such functions. Using Filon's method, I got the following results. ```points result 2 -1.9835847 3 -1.9835844 5 -1.9836308 9 -1.9836045 17 -1.9835824 33 -1.9835848 65 -1.9835837 129 -1.9835837 ``` But then, Filon's method is expressly designed for integrating functions of the form g(x)sin(kx). In effect it factors out the oscillations and reduces the problem to that of integrating ln(1+x), a much easier task as shown by the results above. We now return you to your regularly scheduled programming.

 Re: HP-33S integration: oscillating integrandMessage #14 Posted by Karl Schneider on 31 July 2006, 9:29 p.m.,in response to message #13 by Kiyoshi Akima Kiyosi -- As I predicted, the HP-33S gave the same answers as your HP-48GX for FIX 0, FIX 1, and FIX 5. I didn't see the need to try the other settings. It's further evidence that the HP-33S implementation of integrand-uncertainty for integration is the same as that used for the HP-48G series. However, neither the method nor the change from the HP-32SII was not documented in words. Good application of the Nyquist Sampling Criterion, which requires that a waveform be sampled at greater than twice the rate of its highest-frequency component in order to be accurately represented digitally. (Exactly twice the rate is not enough. Otherwise, what if a pure periodic waveform was sampled at every zero-crossing?) -- KS

 Re: HP-33S estimated error of integration: mystery solved!Message #15 Posted by Kiyoshi Akima on 31 July 2006, 12:26 p.m.,in response to message #7 by Karl Schneider What does the 33S give for the error estimate when you integrate x2 from 0 to 0.4 ? The correct result is exactly three orders of magnitude smaller than integrating from 0 to 4. On the 48 in all modes, or on the 15C and 41C/AdvantagePac in SCI mode, the error estimate is indeed three orders of magnitude smaller. But in FIX mode, the error estimate is only one order of magnitude smaller. This leads me to believe that in SCI mode we're getting relative error. I really don't know what we're getting in FIX mode, however, at least on the 15C and the 41C/AdvantagePac.

 Re: HP-33S estimated error of integration: mystery solved!Message #16 Posted by Karl Schneider on 31 July 2006, 10:14 p.m.,in response to message #15 by Kiyoshi Akima Quote: What does the 33S give for the error estimate when you integrate x2 from 0 to 0.4 ? FIX 2 on the HP-33S: 0.02133 +/- 0.0021 SCI 2 on the HP-33S: 0.02133 +/- 0.0021 In fact, it doesn't seem to matter whether FIX, SCI, or ENG is used for problem with a given number of places N. The HP-48G and HP-33S are using a multiplicative accuracy factor that is specified using the display modes. This is documeted to a certain extent in the HP-48G manual, but not in the HP-33S manual (which was adapted from the HP-32SII manual, although the HP-32SII used the "traditional" method of the HP-34C, HP-15C, and HP-41 Advantage). Quote:This leads me to believe that in SCI mode we're getting relative error. I really don't know what we're getting in FIX mode, however, at least on the 15C and the 41C/AdvantagePac. Yes, the HP34C, HP-15C, and HP-41 Advantage define a "stepwise" relative uncertainty of the integrand when using SCI or ENG. (The relative uncertainty abpurptly increases by an order of magnitude then the integrand surpasses 10, 100, 1000, etc.) FIX defines an absolute uncertainty; e.g. "FIX 2" specifies an uncertainty of 0.005. This is well-documented in the manuals for the HP-15C and HP-34C. There is an unspecific statement of p. 83 of the Advantage Pac manual regarding uncertainty in the integrand function using FIX vs. using SCI or ENG. BTW, there's nothing inherently wrong with an error estimate that exceeds the value of the integral by orders of magnitude, particularly when: The integrand changes sign; An absolute uncertainty that exceeds the value of the integrand is specified (using FIX on the HP-34C, HP-15C, and HP-41 Advantage). After all, what might be the calculated integral and uncertainty of sin(x) from x = 0 to x = 2*pi? -- KS

 Re: About HP-33S integrationMessage #17 Posted by Kiyoshi Akima on 24 July 2006, 4:46 p.m.,in response to message #1 by Antonio Maschio (Italy) You're getting exactly what you asked for. The FIX 2 setting specifies two decimal digits, not two digits after the decimal point. The machine's giving you an answer of 21.33 with an error of two units in the third digit of the answer. Do it in FIX 3 and you'll get an error that's an order of magnitude smaller at 0.02. In FIX 2, integrate the same function from 0 to 0.4. You should get an answer of 0.02133 with an error of 0.000213, which again estimates the error at two units in the third digit.

 Re: About HP-33S integrationMessage #18 Posted by Antonio Maschio (Italy) on 25 July 2006, 2:20 a.m.,in response to message #17 by Kiyoshi Akima Hi, K.A., you wrote Quote: The FIX 2 setting specifies two decimal digits, not two digits after the decimal point. Can you tell me the difference? Assume I'm dumb and stupid. -- Antonio

 Re: About HP-33S integrationMessage #19 Posted by Kiyoshi Akima on 25 July 2006, 1:20 p.m.,in response to message #18 by Antonio Maschio (Italy) Simple. In the number 21.33, the first two decimal (base ten) digits are the "21" to the left of the decimal (radix) point (the first two digits in the number). The first two digits after the point are the "33" on the right. Consider doing an integral that comes out in the neighborhood of 1E8. You might be able to get ten digits, but you won't get ten digits after the decimal point, since that would require an 18- or 19-digit number. Clear as mud, right?

 Re: About HP-33S integrationMessage #20 Posted by Antonio Maschio (Italy) on 26 July 2006, 3:15 a.m.,in response to message #19 by Kiyoshi Akima Hi KA, In lines of principle you are right about big numbers. But FIX, as of my experience, governs the decimals "after" the dot. ```4500 in FIX 2 is displayed as 4500.0000; its square root is displayed as 67.0820; the third power is displayed as 301869.1770 the third power again is displayed as 2.7508E16. ``` I agree that big numbers deserve their own treatment, but I feel that what a simple user like me expects from an integration algorithm (which, as stated in the manual, is as precise in decimals as the decimals fixed with FIX/SCI) is that integrating a tiny x^2 from 0 to 4 yields 21.33 in FIX 2 with an uncertainty of 0.00x, which, of course, shouldn't alter in any way the result (i.e. 'x' must not be, say, 9, which could alter the result in 21.34). This behaviour is the notorius HP-15C one, and I believe it's the closer to perfection. Greetings from a warm Italy -- Antonio

 Re: About HP-33S integrationMessage #21 Posted by Kiyoshi Akima on 26 July 2006, 4:52 p.m.,in response to message #20 by Antonio Maschio (Italy) I certainly agree with you. I think FIX 4 should give four digits accuracy after the decimal point. But for integrals whose magnitudes are greater than 10 , the calculator appears to be counting the digits to the left of the radix point. If the result is big enough, some digits to the left of the radix point could be wrong. It's a different case for results whose magnitudes are less than 0.1 . In that case the FIX setting specifies an absolute error, so FIX 2 gives an uncertainty less than 0.01 but potentially larger than 0.005 , even when the integral is much smaller. Integrating x2 from 0 to 0.1 in FIX 2 produces 3.33E-4 +/- 5.00E-4 , where the uncertainty is larger than the answer. This is on a 15C, I don't have a 33S. My 48GX does better, producing 3.33E-4 +/- 3.33E-6 .

 Re: About HP-33S integrationMessage #22 Posted by Kiyoshi Akima on 31 July 2006, 12:31 p.m.,in response to message #20 by Antonio Maschio (Italy) Yes, the FIX setting governs the number of displayed digits after the decimal point (assuming the number isn't too big). But when integrating, just what does it determine concerning the accuracy? It doesn't appear to specify either the number of correct significant digits (relative error) nor the number of correct digits after the decimal point (absolute error). At least not on the HP15C or HP41C/AdvantagePac. On the RPL machines it does seem to determine the relative error, which is different from the number of digits after the decimal point.

 FIX for integration on HP15/34/41+AdvantageMessage #23 Posted by Karl Schneider on 31 July 2006, 10:25 p.m.,in response to message #22 by Kiyoshi Akima Quote: But when integrating, just what does it determine concerning the accuracy? It doesn't appear to specify either the number of correct significant digits (relative error) nor the number of correct digits after the decimal point (absolute error). At least not on the HP15C or HP41C/Advantage Pac. As documented in the HP-34C and HP-15C manauls: Uncertainty of integrand under FIX N: 0.5 x 10-N Upper-bound stimate of the error of integral calculation from a to b under FIX N: (0.5 x 10-N)*(b-a) I'm updating my article about SOLVE/INTEG on RPN-based models to include this material. -- KS

 Re: FIX for integration on HP15/34/41+AdvantageMessage #24 Posted by Antonio Maschio (Italy) on 1 Aug 2006, 8:27 a.m.,in response to message #23 by Karl Schneider Ok, I'm waiting for your article. Seems interesting. -- Antonio

 Updated Article #556 for SOLVE/INTEG is now postedMessage #25 Posted by Karl Schneider on 2 Aug 2006, 2:06 a.m.,in response to message #24 by Antonio Maschio (Italy) Antonio and all other readers -- I have updated the article I wrote last year regarding SOLVE/INTEG on RPN calc's. It now includes a section on uncertainty of integrand and error of integration, along with a section on references. -- KS Edited: 2 Aug 2006, 2:11 a.m.

 RPL FIX effect on numerical integrationMessage #26 Posted by James M. Prange (Michigan) on 1 Aug 2006, 11:44 p.m.,in response to message #22 by Kiyoshi Akima Regarding the RPL models, from information in HP 48 Insights PART II: Problem-Solving Resources (available on the current Museum DVD / CD ROM set), for numerical integration, n FIX (or SCI or ENG) sets an "error tolerance" E = 10-n. The iterations (each using halved sampling intervals) terminate when three successive estimates differ by amounts less than the user-specified error tolerance, or after a maximum of sixteen iterations have produced no apparent convergence. A number is also stored in the reserved variable IERR. For the case of three successive estimates differing by less than the specified error tolerance, this is a positive value, and is the error tolerance times the absolute value of the last estimate of the integral. The idea is that the probable error is less than or equal to IERR. If the process terminates because sixteen successive iterations have produced no apparent convergence, -1 is stored in IERR. Of course, having three successive estimates differ by less than the specified error tolerance doesn't guarantee that the last estimate is correct within the error tolerance. To avoid misleading results, the user should have some knowledge of the behaviour of the function to be integrated. FIX, SCI, and ENG also have their usual results. FIX and SCI set the number of displayed digits to the right of the decimal point, and ENG sets the display to n+1 significant digits, with the exponent a multiple of 3. Note that these have no effect on the actual values of the numbers on the stack, just on how they're displayed. To change the actual value, use functions such as the RND, TRNC, FLOOR, CEIL, IP, or FP. Regards,James Edited: 2 Aug 2006, 5:51 a.m. after one or more responses were posted

 Re: RPL FIX effect on numerical integrationMessage #27 Posted by James M. Prange (Michigan) on 2 Aug 2006, 12:05 a.m.,in response to message #26 by James M. Prange (Michigan) PS: I expect that STD would set the "error tolerance" to 10-12. Regards,James

 Re: RPL FIX effect on numerical integrationMessage #28 Posted by James M. Prange (Michigan) on 2 Aug 2006, 5:47 a.m.,in response to message #27 by James M. Prange (Michigan) PPS: On second thought, STD results in the same estimate (and IERR) as 11 FIX (or SCI or ENG), so STD must set the error tolerance to 10-11.

 Re: RPL FIX effect on numerical integrationMessage #29 Posted by Karl Schneider on 2 Aug 2006, 12:37 p.m.,in response to message #28 by James M. Prange (Michigan) Quote: STD results in the same estimate (and IERR) as 11 FIX (or SCI or ENG), so STD must set the error tolerance to 10-11. James -- Yes, indeed, that's what I believed, and what I had written for my recently-updated Article #556 (see earlier post in this thread). The reason is that no number will be displayed with 12 digits after the decimal point. A zero before the point will always be displayed if the mantissa is less than one. My results on the HP-33S have yet to show any difference between SCI or ENG vs. FIX. If a multiplicative accuracy factor is defined by a display mode, then it's difficult to make any definite distinction just by using different modes. This is why I believe an accuracy-factor variable "IACC" (a la the HP-42S) would have made more sense than FIX/SCI/ENG/ALL. Thank you for providing information that corroborates what I have inferred from tests and the manuals. -- KS

 Re: RPL FIX effect on numerical integrationMessage #30 Posted by James M. Prange (Michigan) on 6 Aug 2006, 5:27 a.m.,in response to message #29 by Karl Schneider Quote: Yes, indeed, that's what I believed, and what I had written for my recently-updated Article #556 (see earlier post in this thread). I did read your article, but it makes only a brief reference to RPL models. Quote: The reason is that no number will be displayed with 12 digits after the decimal point. A zero before the point will always be displayed if the mantissa is less than one. I'll take your word for it that that's true for "Classic RPN" models, but for RPL models, in STD display mode, a number less than one that can be displayed with 12 or less digits (without using scientific notation) is displayed without a zero to the left of the decimal point. For example, 10-12 is displayed as .000000000001, that is, with 12 digits after the decimal point, which is what (mis)led me to at first expect that STD display mode would result in an "error tolerance" of 10-12. Quote: My results on the HP-33S have yet to show any difference between SCI or ENG vs. FIX. If a multiplicative accuracy factor is defined by a display mode, then it's difficult to make any definite distinction just by using different modes. For the RPL models too, as far as I've noticed, using FIX, SCI, or ENG have exactly the same affect on the error tolerance for integration, with STD having the same effect as 11 FIX. Quote: This is why I believe an accuracy-factor variable "IACC" (a la the HP-42S) would have made more sense than FIX/SCI/ENG/ALL. I don't like using the display mode for setting the error tolerance either, but storing it in a reserved variable would have the disadvantage that a user may well forget to set it. I'd rather have it as an argument, and after all, there's no shortage of stack levels on an RPL model. I still wonder exactly how IERR is calculated on the RPL models. It seems to be approximately the user-specified error tolerance times the absolute value of the estimated integral (assuming successful convergence). For that matter, storing the probable maximum error in the reserved variable IERR can be viewed as a disadvantage, as a user may well neglect to check it, especially if IERR doesn't appear in the current menu. But any RPL function must return exactly one result to the stack. Something that I wish for is a way to check how many samples were used, which is something that I don't know of any way to check. Come to think of it, it might be useful to be able to specify how many samples to use, as an alternative to the iterative process of checking until three successive estimates agree within the error tolerance. Quote: Thank you for providing information that corroborates what I have inferred from tests and the manuals. You're welcome. Regards,James

 Re: RPL FIX effect on numerical integrationMessage #31 Posted by Karl Schneider on 6 Aug 2006, 2:59 p.m.,in response to message #30 by James M. Prange (Michigan) James -- Good comments. Quote: I did read your article, but it makes only a brief reference to RPL models. True; that was my intent to limit the scope of my article to the RPN-based models, because SOLVE and INTEG on the RPL-based models are quite different in capabilities and protocol -- symbolic solutions, multiple integrals, etc. In fact, the HP-28's capabilities and protocol are not the same as that of the HP-48 and HP-49. My mention of ALL = FIX 11 and FIX/SCI/ENG are identical referred to the HP-33S, with a mention in passing to the HP-48: From the article: The approach in the HP-33S is -- somewhat unexpectedly -- the same one used for the RPL-based HP-48 series. Because display-mode settings must be used, the only permitted values of accuracy factor are of the form 10-N. Thus, the maximum estimated error of integration is about 10-N times the integral of the absolute value of the integrand, where N is the parameter provided to FIX, SCI, or ENG. (ALL corresponds to N = 11.) FIX, SCI, or ENG will typically yield identical results for a given value of N. Good point about the HP-48 not showing the leading integer zero -- even for numbers of absolute value less than unity, having less than 12 significant digits. I'd forgotten about that. (I wonder if that's a settable flag option). Quote: I don't like using the display mode for setting the error tolerance either, but storing it in a reserved variable would have the disadvantage that a user may well forget to set it. I'd rather have it as an argument, and after all, there's no shortage of stack levels on an RPL model. Yes, you're probably right. A disadvatage: the accuracy factor would have to be specified every time, unless it were an optional argument on the bottom of the stack, and a default value were used if omitted. E.g., ```4: '2*X + SIN(X)' 3: 'X' 3: '2*X + SIN(X)' 2: {0.00 2.00} 2: 'X' 1: 0.003 1: {0.00 2.00} ``` This to me is an intuitive approach to integration: function, variable, limits in an ordered list, and special accuracy factor if desired. On the left, 0.003 would be the multiplicative accuracy factor; on the right, the default value would be used. -- KS

 Re: RPL FIX effect on numerical integrationMessage #32 Posted by Kiyoshi Akima on 7 Aug 2006, 12:38 p.m.,in response to message #30 by James M. Prange (Michigan) Quote: Something that I wish for is a way to check how many samples were used, which is something that I don't know of any way to check. Simple. Put the following into the function being integrated: ```'C' INCR DROP ``` and create a global variable 'C' with the value 0. Make sure you zero it out before integrating again. If you use a driver program to automate repeated integrations, you can make the driver zero out the counter. Of course, the name can be anything you want, if you already have something named 'C'. I tend to use a compiled variable ('<-c') in my driver program. There's a marginal performance degradation and increased memory usage, but I can usually live with it. :-)

 Re: RPL FIX effect on numerical integrationMessage #33 Posted by James M. Prange (Michigan) on 2 Aug 2006, 6:30 a.m.,in response to message #26 by James M. Prange (Michigan) Another PS: The value stored in IERR isn't exactly the error tolerance times the absolute value of the estimate of the integrand, but is typically slightly less than that. I don't know for certain, but perhaps it's based on the variation of the estimates in the last few iterations? Regards,James

 Re: About HP-33S integrationMessage #34 Posted by Antonio Maschio (Italy) on 26 July 2006, 12:27 p.m.,in response to message #1 by Antonio Maschio (Italy) I discovered the following: ```1) Let's take the following functions: x^2 x^3 x^4 whose integral is well known. 2) Let's calculate two integrals of these functions from any starting point to any end point (let's say from 0 to 4 and from 0 to 8) 3) Let's calculate apart the real value and, subtracting to this value the result, we obtain the real error (let's call it Er) 4) Let's obtain the Error estimate given by the machine, contained into Y stack register (let's call it E) 5) Let's divide E by Er; we obtain a constant value for each function: x^2 -> 1090.11 x^3 -> 543.98 x^4 -> 247.20 ``` Anyone knows why? If we could calculate these values, we could obtain the real error! Thanks again -- Antonio P.S. I didn't think about it much, so excuse me if you find mistakes. -- A.

Go back to the main exhibit hall