RPN-PRGM: New Windows console application emulating HP calculators

[Aacini]

I am working on a more accurate method to convert an 80-bits floating point number into a 19-digits decimal ASCII string. It will be ready in the next version of RPN.exe, besides HPSTACK mode that emulates the HP 4-registers stack management and some other minor changes.

(02-03-2021 06:54 AM)pavel nemec cz Wrote:  Your RPN.exe is very interesting and I played a little bit with it. I have to say I was very surprised and did not get reasoning that all the stack items get lost and "erased" to -1.#FLW when the stack underflows. I understand that with RPNPRGM you can use the switch but it might be useful to be able to change operation of the stack during interactive operation as well.

Well, you should realize that the Overflow/Underflow condition is a state of the whole stack, not just of one register! I am pretty sure you'll appreciate the next RPN.exe version with the HPSTACK operation implemented...

(02-03-2021 06:54 AM)pavel nemec cz Wrote:  Could you explain why I got different results for SIN COS TAN forensic test?

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

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

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

RPN.exe users manual Wrote: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.0338315963745117, 9.0000000001046061 and 9.0000000000002736 when the precision is set to 0, 2 and 3, respectively.

The result of this particular expression is affected by the multiple (6) conversions of the angular mode between the FPU native Radians to the requested Degrees. If the mode is keep in Radians and just two conversions are performed at beginning and end of the expression (RPN FPUPC:0 9 D->R Rad Sin Cos Tan ATan ACos ASin R->D FIX:16), then the precision of the results improves: 9.0000047683715820, 9.0000000000000071 and 9.0000000000000000. If you have an intensive trigonometric operations program you should perform all operations in Radians and just convert the final result to Degrees, if required; the results will be both better and faster.

For RAD I have the same result as you stated in the manual. I have an Intel CPU.

This was my fault! It seems I copied the results of the forensic test and, after that, I slightly modified the Floating-Point to Decimal conversion method, so I forgot to run again the test and copy the new results...

I fixed the results in the user's manual; this will be reflected in the new version...

Antonio