▼
Posts: 416
Threads: 78
Joined: Mar 2006
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 HP32SII 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
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Antonio 
Interesting finding!
On my HP32S and HP32SII, I get 0.02000000005 as the estimated error  one order of magnitude smaller than the error estimated by the HP33S (0.21291207886).
When the display mode is changed to "SCI 2", the error is 0.04939691181 on the HP32S/SII, but unchanged on my HP33S (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 HP15C (pages 247248) and for the HP34C (pages 245246).
The method was carried forward to the HP41 Advantage Pac and the HP32S and HP32SII  all of which were RPN calculators that utilized FIX/SCI/ENG for specifying the uncertainty of the input function. The HP42S 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 HP33S. Compare respective pages 87 and 88 in the HP32SII and the HP33S manuals. Both manuals illustrate the same examples, but the calculations of upperbound estimated error are quite different. The HP33S 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 "allHP" calculators:
Using FIX 2, the uncertainty of the integrand is 0.005. This constant "halfribbon", multiplied by the interval (40) = 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.
▼
Posts: 416
Threads: 78
Joined: Mar 2006
Karl wrote:
Quote:
Here's how it used to be done, on the "allHP" calculators:
# Using FIX 2, the uncertainty of the integrand is 0.005. This constant "halfribbon", multiplied by the interval (40) = 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 010; 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 HP15C?
Thanks in advance.
 Antonio
by the way: you seem to define uncertainty as a constant "halfribbon" multiplied by the interval. But different intervals give different ribbons. Am I totally wrong?
 Antonio
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Antonio 
The user's manuals for the HP15C and the HP34C 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 HP15C and the HP34C 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 displaymode settings (FIX, SCI, or ENG). The calculator produces a "worstcase" 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 HP34C, HP15C, HP32S, HP32SII, and HP41 Advantage Pac. (On the HP42S, 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*(ba), 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 10^{n} of the full numerical value, where n is the base10 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.
HP33S estimated error of integration:
Perhaps the different error calculations on the HP33S are "simpler" and more consistent between FIX, SCI, and ENG, but I believe that the user is being poorly served by the unnecessarilycoarse estimates of error. It is quite clear that the HP33S calculated integral of f(x) = x^{2} 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 HP33S 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.
▼
Posts: 416
Threads: 78
Joined: Mar 2006
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 HP33S, 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 HP33S, and nothing on it seems to clear these concepts).
Thanks again.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Antonio 
Quote:
I ask you: is there a way to detect the error estimate of the HP33S, 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 HP33S, and nothing on it seems to clear these concepts).
The HP33S manuals (as well as the HP32SII manuals) in English are no more specific. That's why I pointed out the HP34C and HP15C manuals for a detailed explanation of the implementation of numerical integraion. The subsequent manuals were "decontented" and "dumbeddown", to use several slang phrases.
So, I really don't know how the HP33S 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 HP32SII, 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 RPNbased models with this information.
 KS
Posts: 1,792
Threads: 62
Joined: Jan 2005
Antonio and Kiyoshi 
I state with confidence that I have solved the mystery of the error calculations on the HP33S!
Bottom line: The HP33S uses the same method for specifying the uncertainty of the integrand, and calculating the estimated error of the integral, as does the HP48G (and other RPL models, except the the HP28C/S).
Kiyoshi's recent post contained a clue that led me toward the answer:
Quote:
Integrating x^{2} from 0 to 0.1 in FIX 2 produces 3.33E4 +/ 5.00E4 , 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.33E4 +/ 3.33E6.
I hadn't known how to obtain the estimated error of integration on my 48G, but evidently, it was possible. Pages 206 and 207 of the HP48G 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 HP42S, which uses the variable "ACC" to specify the accuracy factor, and returns the estimated error to the stack.
On the HP48G, 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 HP42S 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 HP34C, HP15C, HP32S, HP32SII, and HP41 Advantage Pac.
The result and error values I obtained for the integral of
f(x) = x^{2}.dx over x = 0 to x = 4, with FIX 2 or "ACC" = 0.01
were identical on the HP33S, HP42S, and the HP48G  namely, 21.333138 and 0.212912 in FIX 6.
Conversely, the HP34C, HP15C, HP32S, HP32SII, and HP41 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 largevalued integrands, but relatively coarser for smallvalued integrands, as Kiyoshi found.
 KS
Edited: 27 July 2006, 11:34 p.m.
▼
Posts: 416
Threads: 78
Joined: Mar 2006
Karl,
if I understand what you say (don't bet I do, anyway!),
1) the HP33S method is suitable for smaller integrals, but not that much for larger ones
2) the HP33S 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 HP33S 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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Antonio 
The HP33S method works like the HP42S method, and is patterned after the HP48 method.
If you want high precision for highvalued 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
▼
Posts: 416
Threads: 78
Joined: Mar 2006
Thanks, Karl, for your patience.
 Antonio
Posts: 325
Threads: 18
Joined: Jul 2006
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 wellbehaved 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 builtin integrators at FIX 6 to get the same accuracy.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 HP33S 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 HP42S with ACC = 1E8 (equivalent to FIX 8). Comparison with several partial integrals suggests that this answer is quite reasonable.
The HP48G with STD mode (full 12digit accuracy) gave an integral of 0.0019835838188 with an error of 5.204 x 10^{11}.
The HP33S with FIX 8 gave the same answer as the HP42S: 0.0019835837645 with an error of 5.195229 x 10^{8}.
 KS
Edited: 29 July 2006, 4:33 a.m.
▼
Posts: 325
Threads: 18
Joined: Jul 2006
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.54E1 255
FIX 2 0.17830 5.54E2 255
FIX 3 0.17824 5.54E3 511
FIX 4 0.17610 5.38E4 511
FIX 5 0.17610 5.38E5 511
FIX 6 1.98E3 5.20E6 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 builtin 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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Kiyosi 
As I predicted, the HP33S gave the same answers as your HP48GX 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 HP33S implementation of integranduncertainty for integration is the same as that used for the HP48G series. However, neither the method nor the change from the HP32SII 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 highestfrequency 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 zerocrossing?)
 KS
Posts: 325
Threads: 18
Joined: Jul 2006
What does the 33S give for the error estimate when you integrate x^{2} 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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
What does the 33S give for the error estimate when you integrate x2 from 0 to 0.4 ?
FIX 2 on the HP33S: 0.02133 +/ 0.0021
SCI 2 on the HP33S: 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 HP48G and HP33S are using a multiplicative accuracy factor that is specified using the display modes. This is documeted to a certain extent in the HP48G manual, but not in the HP33S manual (which was adapted from the HP32SII manual, although the HP32SII used the "traditional" method of the HP34C, HP15C, and HP41 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, HP15C, and HP41 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 welldocumented in the manuals for the HP15C and HP34C. 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 HP34C, HP15C, and HP41 Advantage).
After all, what might be the calculated integral and uncertainty of sin(x) from x = 0 to x = 2*pi?
 KS
Posts: 325
Threads: 18
Joined: Jul 2006
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.
▼
Posts: 416
Threads: 78
Joined: Mar 2006
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
▼
Posts: 325
Threads: 18
Joined: Jul 2006
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 19digit number.
Clear as mud, right?
▼
Posts: 416
Threads: 78
Joined: Mar 2006
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 HP15C one, and I believe it's the closer to perfection.
Greetings from a warm Italy
 Antonio
▼
Posts: 325
Threads: 18
Joined: Jul 2006
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 x^{2} from 0 to 0.1 in FIX 2 produces 3.33E4 +/ 5.00E4 , 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.33E4 +/ 3.33E6 .
Posts: 325
Threads: 18
Joined: Jul 2006
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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 HP34C and HP15C manauls:
Uncertainty of integrand under FIX N: 0.5 x 10^{N}
Upperbound stimate of the error of integral calculation from a to b under FIX N: (0.5 x 10^{N})*(ba)
I'm updating my article about SOLVE/INTEG on RPNbased models to include this material.
 KS
▼
Posts: 416
Threads: 78
Joined: Mar 2006
Ok, I'm waiting for your article. Seems interesting.
 Antonio
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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.
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/articles.cgi?read=556
 KS
Edited: 2 Aug 2006, 2:11 a.m.
Posts: 1,041
Threads: 15
Joined: Jan 2005
Regarding the RPL models, from information in HP 48
Insights PART II: ProblemSolving 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
userspecified 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
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
PS:
I expect that STD would set the "error tolerance" to
10^{12}.
Regards, James
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
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}.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 recentlyupdated 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 HP33S 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 accuracyfactor variable "IACC" (a la the HP42S) 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
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
Yes, indeed, that's what I believed, and what I had written for my
recentlyupdated 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 HP33S 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 accuracyfactor variable "IACC"
(a la the HP42S) 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 userspecified 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
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 RPNbased models, because SOLVE and INTEG on the RPLbased models are quite different in capabilities and protocol  symbolic solutions, multiple integrals, etc. In fact, the HP28's capabilities and protocol are not the same as that of the HP48 and HP49.
My mention of ALL = FIX 11 and FIX/SCI/ENG are identical referred to the HP33S, with a mention in passing to the HP48:
From the article:
The approach in the HP33S is  somewhat unexpectedly  the same one used for the RPLbased HP48 series. Because displaymode 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 10N 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 HP48 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
Posts: 325
Threads: 18
Joined: Jul 2006
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. :)
Posts: 1,041
Threads: 15
Joined: Jan 2005
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
Posts: 416
Threads: 78
Joined: Mar 2006
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.
