[VA] HP-15C CE et al.: Some questions about INTEG

[Valentin Albillo]

  
Hi, all,

Re the HP-15C/LE/CE built-in Integration functionality (INTEG for short,) I've noticed that neither the Owner's Handbook nor the Advanced Functions Handbook ever says a word about what happens when INTEG can't achieve the user-specified accuracy.

They say it uses a modified Romberg method which keeps on doubling the number of samples to try and achieve the user-specified accuracy, but how long does it keep doing this ? Up to 16,383 samples ? 32,767 ? 65,535 ? And what happens if it reaches that limit without ever achieving the user-specified accuracy ? How does it report failure to the caller ? Or can INTEG run indefinitely in that case ?

The HP-71B's Math ROM's INTEGRAL keyword (which I understand uses essentially the same Romberg-based method taken from the HP-15C/34C,) goes up to 65,535 samples, then reports failure by making IBOUND negative upon returning to the caller, which means: "I'm sorry but I couldn't achieve the accuracy you specified."

So, does the HP-15C/LE/CE's INTEG do the same ? If called from a program, does it skip the next step, as SOLVE does ? Nothing of this seems to be even mentioned (let alone discussed) in any HP-15C or HP-34C manuals. It also goes unmentioned in the HP-41C Advantage manual, or even in the classic HP Journal article (pp.23-32) about this functionality (then just newly introduced in the HP-34C,) which was written by Kahan himself.

I've searched extensively but I've been unable to find any references, though I seem to remember I saw one such in the very distant past. Can any of you post some ?

In the meantime I've conducted an experiment using my brand-new HP-15C CE, namely I've run this small program I wrote for the purpose, which tries to make INTEG actually reach its limit and if so, see what happens next, e.g.:

a) Does it actually reach some built-in limit for its Romberg-based method, or does it run indefinitely ?

b) If it reaches a limit for the number of function evaluations, what's that limit ? How many evaluations max. ?

c) And what does it do next if executed in a program ? Does it skip the next program step to indicate failure as SOLVE does ? Does it also make the computed uncertainty negative to alert the caller, as the Math ROM does with IBOUND ?

The commented 17-step, 19-byte program listing is:

  01  LBL A         begin program            13  LBL E    f(x) definition
  02   0                                     14  DSE I    increase neg.# of evals
  03  STO I         reset counter to 0       15  LBL 01   place-holder
  04  FIX 9         specify max. accuracy    16  RAN#     random value for f(x)
  05   1            limits will be 0..1      17  RTN      returns to caller (INTEG)
  06  INTEG E       compute the integral
  07  GTO 0         "if successful", branch
  08  PI            if not, show Pi ...
  09  RTN           ... and end program
  10  LBL 0         "if successful" ...
  11  RCL I         ... display neg.# of evals
  12  RTN           end program

Note: should you interrupt the program (e.g. because it doesn't end after a long while,) execute RTN from the keyboard to completely terminate program execution and most important, to recover the 23 registers automatically allocated for the integration. You can check they were properly recovered by executing MEM before and after executing the RTN
.
LBL E defines the function to be integrated, which obviously must execute as fast as possible because it'll be called many thousand times by INTEG, while also ensuring the integral's approximations don't converge to a final result meeting the (maximum) required accuracy. Both goals are met by using RAN# as the function's value regardless of the arguments passed to it. The HP-15C CE's INTEG instruction can evaluate this function 121 times per second.

Unfortunately, upon running it with GSB A it went on flashing running at a very fast rate (at least 4-5 times per second !) for more than 15 min., when I stopped it by pressing a key. Recalling the value of register I, which kept count of the (negative) number of evaluations of f(x), it came out as -108,980, which is almost twice the max. number of evaluations INTEGRAL would do (65,535) so my conclusion is:

Either INTEG has a built-in limit higher that 65,535 function evaluations (say 131,071 or more,) or it has no built-in limit and might simply run indefinitely till some (presumably handled) error happens in the microcode, perhaps when the 23 registers allocated for this task prove to be insufficient.

Furthermore, I'd offer a little bit of reasoned speculation: perhaps the overall lack of documentation for this case is due to the fact that computing such difficult (non-converging) integrals on the original devices (34C, 15C, Advantage) would've taken some 45 hours to do what the CE did in 15 min., yet still didn't converge.

That many hours (at the very minimum, as this is such a simple, fast-to-evaluate function) would've probably flattened out the batteries before getting any result so it was likely considered quite impossible to reach and execute any ad-hoc microcode to deal with this case and, as ROM space was extremely scarce, none was put in place (unlike the 71B Math ROM, where they did put code to deal with cases deemed impossible to produce, but then they had 5 Kb to spare.) Just saying ...

Well, that's all. If any of you are willing to let your LE/CE run for longer than 15 min. (say 30 min. or a full hour, which would be equivalent to ~one week on the original devices) to try and check if this program eventually stops by itself and if so, what the outcome is, I sure would appreciate it.

On the other hand, if some of the renowned 15C gurus (Eric Smith, Jean-François Garnier, you know who you are) can have a look at the 15C ROM and find out for good what it does in this case, it would be the ultimate answer.

Thanks in advance and regards.
V.