03-05-2019, 02:21 PM
I noticed that INTEG on the HP-42S terminates suspiciously quickly when evaluating the integral of SIN, in DEG mode, from 0 to 360. It returns zero, which is correct, but how?
What I find puzzling is that you specify the desired accuracy to the HP-42S integrator through the ACC variable, and ACC is a relative error. The thing with integrals that are exactly zero is that while successive approximations get closer and closer to zero, the absolute error shrinks at roughly the same rate as the estimated integral, and so the relative error doesn't improve. With ACC set to, say, 1e-6, you'd expect INTEG to keep running until it starts to underflow -- which would take forever since each successive iteration takes twice as many evaluations of the integrand than the previous one.
Free42 handles this situation by simply giving up after 20 iterations. That means up to 524,287 evaluations of the integrand, which isn't too bad given how fast PCs and smartphones are nowadays. The HP-42S doesn't seem to have such a hard limit, though: I tried integrating RAN in Emu42, and when I gave up, it had already clocked more than 9 million evaluations, which on a real 42S would presumably have taken hours or even days.
I assume what happens is that INTEG doesn't just check the relative error against ACC, but also checks whether the estimate of the integral just keeps getting smaller. I'm curious what the termination condition would be, though. I can't find any indication of this in the HP-42S Owner's Manual, nor in the Programming Examples and Techniques book.
Does anyone have any insights as to how the HP-42S integrator, or other versions of HP INTEG, deal with relative errors vs. integrals that are zero?
P.S. Because of symmetry, every iteration of the integral of SIN from 0 to 360 could be expected to return zero, but INTEG terminates quickly even when the situation isn't quite so tidy, like
from 0 to 270.
What I find puzzling is that you specify the desired accuracy to the HP-42S integrator through the ACC variable, and ACC is a relative error. The thing with integrals that are exactly zero is that while successive approximations get closer and closer to zero, the absolute error shrinks at roughly the same rate as the estimated integral, and so the relative error doesn't improve. With ACC set to, say, 1e-6, you'd expect INTEG to keep running until it starts to underflow -- which would take forever since each successive iteration takes twice as many evaluations of the integrand than the previous one.
Free42 handles this situation by simply giving up after 20 iterations. That means up to 524,287 evaluations of the integrand, which isn't too bad given how fast PCs and smartphones are nowadays. The HP-42S doesn't seem to have such a hard limit, though: I tried integrating RAN in Emu42, and when I gave up, it had already clocked more than 9 million evaluations, which on a real 42S would presumably have taken hours or even days.
I assume what happens is that INTEG doesn't just check the relative error against ACC, but also checks whether the estimate of the integral just keeps getting smaller. I'm curious what the termination condition would be, though. I can't find any indication of this in the HP-42S Owner's Manual, nor in the Programming Examples and Techniques book.
Does anyone have any insights as to how the HP-42S integrator, or other versions of HP INTEG, deal with relative errors vs. integrals that are zero?
P.S. Because of symmetry, every iteration of the integral of SIN from 0 to 360 could be expected to return zero, but INTEG terminates quickly even when the situation isn't quite so tidy, like
Code:
00 { 33-Byte Prgm }
01▸LBL "S"
02 MVAR "X"
03 180
04 RCL "X"
05 X≤Y?
06 GTO 00
07 2
08 ×
09 180
10 -
11 SIN
12 2
13 ×
14 RTN
15▸LBL 00
16 SIN
17 ENDfrom 0 to 270.