HP-71B internal summation weakness in Math ROM

[J-F Garnier]

(06-03-2020 11:51 PM)Valentin Albillo Wrote:  Hi, J-F:
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.

Hi Valentin !

Valentin, I strongly encourage you to use DOSBox to continue to use Emu71/DOS !
DOSBox is easy to install and use, and it nicely shares the host OS file system, contrary to other solutions like VirtualBox.
Even if the performance is reduced due to the two emulation layers, Emu71 still runs at about x8 speed on my quite old core-i3 machine (Win10-64).
So it's enough for short tests or to quickly try new ideas. I'm using it very often, and go to VirtualBox (or my very old 32-bit W2K system) when I really need speed.

Quote: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) ?

The reason is that each elementary math operation is made on 15 digits and rounded to 12 digits, so the process is
1/3= .333333333333333 (15-dig). rounded to .333333333333
then .333333333333 +.333333333333 is computed as .333333333333000 + .333333333333000 and rounded again
and so on.

Keeping the 15-digit value all along the expression evaluation will create consistency issues, for instance doing A=1/3 @ A+A+A would return a different result, since variables are holding the packed 12-digit forms only.

I believe the HP-71B math core system was designed with this principle in mind: each elementary math operation must provide the best result (that is the closest approximation to the exact value). This was probably inspired by Prof. Kahan (who was involved in the HP-15C and HP-71B Math ROM developments). This explains the use of "infinite precision" 15-digit truncating then 12-digit rounding.

It is possible to compute expressions on 15 digits for a few cases with the resources of the Math ROM such as complex numbers or matrices.
For instance the product of two complex numbers (x1,y1)*(x2,y2) provides (x1*x2-y1*y2,x1*y2+x2*y1) each part completely evaluated on 15 digits. It can be combining with the DOT function to sum several terms.

Quote: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 ?

An emulator adds the overhead of the CPU/hardware simulation; Free42 is a native application. All depends on the performance of the emulation engine, I can't really judge the x60 ratio but it's the order of magnitude we can expect.
As a comparison, Emu71/DOS runs at about x300 speed natively on my W2K 32-bit system, and at x8 speed in DOSbox on my W10 64-bit system, so a ratio of 40 due to the DOSbox emulation layer.

J-F