HP-71B internal summation weakness in Math ROM

[Valentin Albillo]

.
Hi, J-F:

(06-03-2020 06:35 PM)J-F Garnier Wrote:  The Math ROM 1A has a weakness related to the internal 15-digit summation operation used in matrix operations. [...] I'm particularly pleased to have solved the issue in the latest version of the new "Math Pac 2", now giving *exactly* the same results than the HP-28S and 42S, and moreover very happy to know what was the source of the discrepancy.

My most sincere congratulation and heartfelt thanks and also thanks a lot for mentioning and kindly praising my article, much appreciated.

Let me assure you that I would join you in improving the already-awesome Math ROM with both ideas and code if I were able to run it in my current hardware/OS combination but alas, I can't as your Emu71 doesn't run in Windows 64-bit and I have no other options available right now.

Now a few questions if you don't mind:

1) I know that the HP-71B uses 15 digits for internal computations but I've noticed since ever that something as this evaluation in the command line (and in a running program, of course):

1/3 + 1/3 +1/3

gives .999999999999. Same thing with 3*1/3 which also gives the 9's.

Why is this ? Why aren't all expressions internally evaluated to full 15-digit internal precision, then rounded to 12 digit for output to the user (or storage in some variable) ?

I can't understand the rationale for evaluating internally the temporary result of 1/3 with 15 digits, then instead of continuing using this value in the still internal computation, it actually gets rounded to 12-digit and the computation continues, still internally. Thus you get 3 unnecessary, precision-losing roundings while computing the expression, plus a 4th rounding to 12 decimals when performing the sum of the 3 intermediate results and reporting the rounded result to the user.

I've seen lots of discussion over the years whether the (HP-41C, say) 10-digit of precision with no guard digitst of HP was preferable or not to the 12-13 digits with 2-3 guard digits of TI. Frankly, I much prefer the TI approach as it can be exploited to get additional accuracy in many cases while HP does the precision-losing nonsense just described.

2) This has nothing to do with your Emu71 as I can't test it but I'd be interested in your personal opinion:

I've noticed that go71b, another (very buggy and unreliable, unlike your excellent, reliable Emu71) HP-71B emulator using actual HP-71B ROM code is more than 60 times slower than Free42 for the very same program (BASIC and RPN, respectively) and running in the very same hardware.

Might the reason be that simulated RPN code is that much faster than emulated HP-71B BASIC/Assembler code ? 60 times ?. What do you think ?

As a side note, go71B lies downright with the timing. It outputs times (using the TIME function) that are 2.5x faster than real time (i.e.: it says something took 1 min. but it actually took 2.5 min. of actual, real time).

Again, thanks and best regards.
V.