RPN-PRGM: New Windows console application emulating HP calculators

[Aacini]

Albert Chan,

Well, the fact that changing the Precision Control alters the results of the same operations is not a bug, but a well-known fact. As a matter of fact, is the basis of the example about the Forensics Algorithm:

RPN.exe users manual Wrote:This is an example of such an operation based on the Forensics Algorithm:

Code:

RPN FPUPC:0 9 Deg Sin Cos Tan ATan ACos ASin FIX:16

. The exact result of this expression is 9, but the real results are 9.0338335037231445, 9.0000000001046097 and 8.9999999999999130 when the precision is set to 0, 2 and 3, respectively.

Another example:

Code:


RPN: FPUPC:3 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 10.0000000000000000E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN: FPUPC:2 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 99.9999999999999744E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN: FPUPC:0 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999999999999820E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C9BF_03FF_B800

RPN: FPUPC:3 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999916826296320E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C200_0000_0000

Antonio

[Albert Chan]

(02-22-2021 04:40 AM)Aacini Wrote:  Another example:

Code:

RPN: FPUPC:3 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 10.0000000000000000E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN: FPUPC:2 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 99.9999999999999744E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN: FPUPC:0 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999999999999820E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C9BF_03FF_B800

RPN: FPUPC:3 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999916826296320E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C200_0000_0000

We should expect 1e16 = 10.000e15, not 100.00e15 or 9.2234e15
Something is wrong with eng:# conversion.

It seems FPUPC:# does not take effect right the way.
(If it does, first line and last line should produce the same result)

---

I had noticed RPN.exe version 1.0 reduced eng:# to 18 significant digits.
Perhaps we can shift eng conversion code to sprintf ?

Just break up the number into parts, then join them together.
Note: we need to confirm 1 ≤ IP(|mantissa|) < 1000

Example: 1.23e1000 = (12 + .3) * 1e999 → "12.3e999"

[Aacini]

I solved part of the mystery:

Code:


RPN: FPUPC:3
-1.#UND

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 10.0000000000000000E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN: FPUPC:2
4034_8E1B_C9BF_03FF_FFF9

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999999999999820E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C9BF_03FF_B800

RPN: FPUPC:0
4034_8E1B_C9BF_03FF_B800

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999916826296320E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C200_0000_0000

RPN: FPUPC:3
4034_8E1B_C200_0000_0000

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 10.0000000000000000E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN.exe first parses the whole input line (using the current Precision Control). After that, the whole line is executed. This means that when the next line is parsed, the parse routine uses the same Precision Control set by the last executed line. Of course, this introduces differences...

As I said several times, my ENG:p method is not reliable. You should conclude nothing about the FPU/RPN.exe operation based on the results displayed by ENG:p. I am looking for a more reliable method to show an 80-bits floating point number.

Antonio

[compsystems]

Now with manual in Spanish.
"Operaciones Aritméticas en RPN.html"