On an old complaint about the 15C integration

[J-F Garnier]

Is there a bug when trying to integrate x! between 69 and 70 on a 15c LE/CE ?
This old thread suggests it: thread-238657-post-238723
But a closer look doesn't confirm it.

Quote:I evaluated your integral [x!] from 69 to 70 in fix 4 display (runtime error *expected*):
These runs did not terminate automatically.

Machine               Result after R/S at 400 seconds
HP-15C                5.1602E98 blinking display
HP 15C-LE            2.0638E98 then "running" blinking alternately
DM-15CC (48 MHz) 5.2069E98 blinking display

So, there is a difference between HP 15C-LE results and those of the HP-15C and the more accurately emulated DM-15CC.
I think it can be called a bug in the sense that it does not reflect the response of the original HP-15C.

First misconception: an overflow is not a run-time error on the 15C and doesn't halt a program.
What will be calculated is the integral of min(x!,9.999999999e99).
The result will be blinking to indicate an overflow during the calculation, this is a normal 15C behaviour.

Second mistake: it's a bad idea to use FIX 4 to integrate a function with an expected result in the range of 1e99, this is asking to compute the integral with a 0.0001 absolute accuracy. In this case, a SCI setting is mandatory to specify a relative accuracy of e.g. 1e-4 with SCI 4.

With this setting, the 15c LE, 15c CE and DM15L all give the same result in a short time: 2.7358 e99
Even the venerable original HP-15C can compute the integral, using SCI 2 to limit the execution time.

What is interesting in this use case is the different way the 'running' message is handled on the 15c LE, 15c CE and DM15L.
Actually, even the original 15C is not so nice, since the display is sometimes completely blank during the calculation.
If there is a bug, it is in the original code that manages the display during the integration.

Personally, I like the 15c CE display, with a very fast blinking 'running' display.

J-F

[brouhaha]

(11-15-2024 08:28 AM)J-F Garnier Wrote:  What is interesting in this use case is the different way the 'running' message is handled on the 15c LE, 15c CE and DM15L.
Actually, even the original 15C is not so nice, since the display is sometimes completely blank during the calculation.
If there is a bug, it is in the original code that manages the display during the integration.

While it is true that the original 15C integration didn't manage the display as well as one would like, the differences in the later ARM-based models are all due to bugs in the way the flashing display is implmented, related to the various PSE bugs, etc. I have repeatedly explained how the original Voyager blinking hardware worked, in the hope that the firmware developer for the ARM-based models would put in a correct implementation instead of a bunch of kludgy hacks for individual symptoms, but it has never happened.

Quote:Personally, I like the 15c CE display, with a very fast blinking 'running' display.

It would be better to fix the underlying bug, then modify the 15C Nut microcode to get your desired display handling, than to get a somewhat better behavior purely accidentally. Sigh.