RPN-PRGM: New Windows console application emulating HP calculators
01-14-2021, 05:47 PM
Post: #1
 Aacini Junior Member Posts: 9 Joined: May 2016
RPN-PRGM: New Windows console application emulating HP calculators
Hi. My name is Antonio. Since many years ago I have been a very loyal user of Hewlett-Packard calculators. I remember that time when a friend of mine show me his brand-new HP-21 calculator he bought the next day it was released! Some time after, I bought my first HP calculator: a brand-new HP-25. Several years ago I started to bought and collect ancient HP calculators. I have now a collection of about 60 Hewlett-Packard calculators that includes some jewels, like a working HP-9810A, a working HP-35 with the 2.02 ln e^x = 2.00 bug, and a never used HP-Xpander new-in-the-box! But this is another story...

I learned IBM-1130 assembly language in 1977, when I was 22 years old. In 1981, after the IBM-PC was released, I bought the first computer of my own: a cheaper Columbia "Transportable" PC-compatible model. I bought Borland Turbo Assembler 1.0, learned Intel 8086 assembly language, and started to write some interesting and unusal programs. I continued writting MASM32 assembly language programs for Windows PC computers since then.

I recently joined the two old loves of my life: HP calculators and Intel assembly language. I wrote a Windows console application that allows to use the PC processor like a HP calculator. It makes possible to directly use the x87 FPU stack as if it were an 8-registers HP calculator (like in the WP 34S) and execute floating point operations in the fastest possible way, using native FPU instructions. This application, called RPN-PRGM, allows any person capable of use an HP calculator to write programs for the PC that run faster than the ones created by standard compilers. It also may serve as a straightforward introduction to Intel MASM32 assembly programming language.

I invite you to test the first version of this application called RPN.exe; you may download it from this site.

Antonio
01-15-2021, 08:13 AM
Post: #2
 Moggul Member Posts: 68 Joined: Jun 2019
RE: RPN-PRGM: New Windows console application emulating HP calculators
Beinvenido Antonio!!!!

Your site is quite an interesint read. It must have been very interesting to explore each technology as they were appearing.

11C 12C 15C 17BII 18C 19BII 21 25 27S 28S 32E 32S 32SII 33C 33S 34S 35S 38C 39gs 39GII 40gs 41C 41CV 41CX 42S 45 48G+ 48GII 49G 49G+ 50 67 71B 97
01-15-2021, 01:27 PM
Post: #3
 Massimo Gnerucci Senior Member Posts: 2,330 Joined: Dec 2013
RE: RPN-PRGM: New Windows console application emulating HP calculators
Hello Antonio, please have a look at Virustotal's results!

Greetings,
Massimo

-+×÷ ↔ left is right and right is wrong
01-15-2021, 01:36 PM
Post: #4
 rprosperi Senior Member Posts: 4,954 Joined: Dec 2013
RE: RPN-PRGM: New Windows console application emulating HP calculators
(01-15-2021 01:27 PM)Massimo Gnerucci Wrote:  Hello Antonio, please have a look at Virustotal's results!

I suspected as much, and decided to wait for feedback.

'Nuf said... I hope.

--Bob Prosperi
01-15-2021, 03:57 PM
Post: #5
 Aacini Junior Member Posts: 9 Joined: May 2016
RE: RPN-PRGM: New Windows console application emulating HP calculators
(01-15-2021 01:27 PM)Massimo Gnerucci Wrote:  Hello Antonio, please have a look at Virustotal's results!

Wow! That is a lot of (false positive) viruses!

Could you give me some advice on what modifications should I made to my code in order to avoid such detections? Thanks!

Antonio
01-15-2021, 10:42 PM (This post was last modified: 01-15-2021 10:50 PM by Massimo Gnerucci.)
Post: #6
 Massimo Gnerucci Senior Member Posts: 2,330 Joined: Dec 2013
RE: RPN-PRGM: New Windows console application emulating HP calculators
(01-15-2021 03:57 PM)Aacini Wrote:
(01-15-2021 01:27 PM)Massimo Gnerucci Wrote:  Hello Antonio, please have a look at Virustotal's results!

Wow! That is a lot of (false positive) viruses!

Could you give me some advice on what modifications should I made to my code in order to avoid such detections? Thanks!

Antonio

Probably a false positive due to some code sequences, heuristically associated with malware infections.
This is what I found on Microsoft site (no further explanation).

Similar problems elsewhere.

Greetings,
Massimo

-+×÷ ↔ left is right and right is wrong
01-20-2021, 08:56 PM (This post was last modified: 01-20-2021 11:15 PM by Aacini.)
Post: #7
 Aacini Junior Member Posts: 9 Joined: May 2016
RE: RPN-PRGM: New Windows console application emulating HP calculators
Mmmm... This is unpleasant and frustrating...

I sent an email to the virus detection companies that gave a false positive report on my RPN.exe file. This is a copy of such an email:

Aacini email Wrote:Good morning. I have written a program for Windows in assembly language that the Virus Total page results reported as "malicious" by several virus detecting engines, including the yours. You may review the Virus Total results page at:

https://www.virustotal.com/gui/file/c733.../detection

This is a summary of such a report:

SecureAge APEX: Malicious
Cybereason: Malicious.989425
Cylance: Unsafe
Elastic: Malicious (high Confidence)
Sangfor Engine Zero: Malware
BitDefender Theta: Genn:NN.ZefaxF.34760.amW@aGWL7Uf
Cynet: Malicious (score: 100)
Microsoft: Program:Win32/Wacapew.C!ml

The people at Virus Total gave me your email and indicated me that I ask you to include my RPN.exe file in your virus exclusion list, so the false positive report of my program be eliminated. However, I think there is a simpler and better solution of this problem for both you and me.

If you indicate me wich segment of my code is the one that your engine detects as possible threat, I could modify it, because the source code is written in assembly language. In this way, you have not to modify your list for this program nor for any other future program I could write.

I really appreciate any action you may take in order to solve this problem.

Antonio Perez

So I have to wait until such companies answer my request... However, as one people at VirusTotal said: "1/60 and even 5/60 doesn’t automatically mean “Bad”, and 0/60 doesn't always mean good". You may use my RPN.exe program anyway if you trust me. If you want a reason to trust me, I could give you a pair:

- I invite you to read my history at https://apaacini.com
- I have written many auxiliary .EXE programs for Windows written in assembly language and published them at https://www.dostips.com/forum/viewtopic.php?f=3&t=3428 and other sites since 8 years ago at least. There are about 20 .EXE files in that site that have been downloaded at least 3250 times. No one of the users of that site have reported a single problem with my .exe programs...

Antonio
01-20-2021, 11:48 PM
Post: #8
 rprosperi Senior Member Posts: 4,954 Joined: Dec 2013
RE: RPN-PRGM: New Windows console application emulating HP calculators
Antonio,

Your files likely were flagged as 'bad' by a few of the scanners precisely because it was written in assembler, something very rarely done these days in general, however much more frequently found in malware in general and viruses in particular.

So, thanks for checking with the scanner publishers and posting notes here clarifying the issue and your findings.

--Bob Prosperi
01-21-2021, 01:21 AM
Post: #9
 mfleming Senior Member Posts: 735 Joined: Jul 2015
RE: RPN-PRGM: New Windows console application emulating HP calculators
This has happened to a few other programs of note including Free42 I think. Very frustrating for the developer since the virus scan company is unlikely to reveal their signature method. Throw in some nops and dead code to change the signature?

Remember kids, "In a democracy, you get the government you deserve."
01-21-2021, 02:35 PM
Post: #10
 Nigel (UK) Senior Member Posts: 398 Joined: Dec 2013
RE: RPN-PRGM: New Windows console application emulating HP calculators
I downloaded your program several days ago. My computer uses Windows' built-in anti-virus software (Defender?) and currently has a free version of Malwarebytes installed.

Since then I have had absolutely no problems. Upon reading previous posts I have re-scanned my computer both with Malwarebytes and with the Windows anti-virus software; neither has given any warnings at all.

I am as sure as I can be that this software is safe. It is also interesting and very well documented!

Nigel (UK)
01-28-2021, 04:16 PM
Post: #11
 Aacini Junior Member Posts: 9 Joined: May 2016
RE: RPN-PRGM: New Windows console application emulating HP calculators
Nigel,

Thanks a lot for share your first experience with RPN.exe program.

Did you read the (extensive) manual? I invite you to pay attention to two features unique to this application:
• The management of the IEEE-754 special values described in the user's manual, like Infinites, the NotANumber entity, negative zero, etc. This means that RPN.exe expressions will never produce an error! For example, this calculation:
Code:
 rpn 4 0 / 1/x
that is equal to inverse of Infinite, gives zero as result, that is the right answer! Isn't it?
• The management of 80-bits floating point numbers, that allows to enter and display numbers with 19 decimal digits and an exponent of ten above 4000.

Antonio
01-29-2021, 01:50 PM
Post: #12
 Albert Chan Senior Member Posts: 1,598 Joined: Jul 2018
RE: RPN-PRGM: New Windows console application emulating HP calculators
(01-28-2021 04:16 PM)Aacini Wrote:  [*] The management of 80-bits floating point numbers, that allows to enter and display numbers with 19 decimal digits and an exponent of ten above 4000.

Hi, Aacini

It may be better if display numbers extended to 21.
Minimum digits d that will round-trip b bits: d = ceil(b*(log(2)/log(10))) + 1

53 bits → d = ceil(15.9546) + 1 = 17 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ // double precision
64 bits → d = ceil(19.2659) + 1 = 21 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ // extended precision

Better yet, have an option to enter/display hex-float.

---

Is this a RPN.exe bug ?

I use 1e16 + 2.9999 to test for rounding behavior (note: 1e16 slightly bigger than 2^53)

With double precision, 2.9999 get rounded-down, sum = 1e16 + 2
With extended precision, 2.9999 get rounded-up, sum = 1e16 + 3
If extended precision then round-back to double, sum = 1e16 + 4

But, this is not what observed:

> RPN.exe 1e16 2.9999 + eng:19 ﻿ ﻿ ﻿ ; note: eng:19 is 19 digits, not 20
10.00000000000000300E+0015

> RPN.exe 1e16 2.9999 + fix:0 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ; should hit with double-rounding errors, returning 1e16+4
10000000000000002

For some strange reason, the flip occurs much higher:

>RPN.exe 1e16 3.00634 + fix:0
10000000000000002

>RPN.exe 1e16 3.00635 + fix:0
10000000000000004

---

A minor issue, numbers starting with decimal point are not recognized:

RPN: .123
Invalid operator: .

RPN: -.123
Wrong number: -.
02-01-2021, 03:33 AM (This post was last modified: 02-01-2021 03:38 AM by Aacini.)
Post: #13
 Aacini Junior Member Posts: 9 Joined: May 2016
RE: RPN-PRGM: New Windows console application emulating HP calculators
Ok, there are several points involved here:

(01-29-2021 01:50 PM)Albert Chan Wrote:
(01-28-2021 04:16 PM)Aacini Wrote:  [*] The management of 80-bits floating point numbers, that allows to enter and display numbers with 19 decimal digits and an exponent of ten above 4000.

Hi, Aacini

It may be better if display numbers extended to 21.
Minimum digits d that will round-trip b bits: d = ceil(b*(log(2)/log(10))) + 1

53 bits → d = ceil(15.9546) + 1 = 17 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ // double precision
64 bits → d = ceil(19.2659) + 1 = 21 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ // extended precision

The number of bits vs. decimal digits described in the "Exploring Binary" article is a theoretical approach. In a practical implementation, the 80-bits floating point number (the 64-bits mantissa, really) must be converted into a 64-bits integer number that can contain a maximum of 19 decimal digits:

RPN.exe users manual Wrote:The X register have an internal 80-bits precision of 19 decimal digits and an exponent of ten of ±4932; however, printf function can only display a 64-bits precision value with 16 digits and an exponent of ten of ±308. Any value outside this range is shown as +Infinite or zero. However, if ENG:p format is given then an attempt to show the X register with its full precision is done.

...

In a similar case is printf, the function that converts the X floating point register into an ASCII string in order to show it... Note: the precision of the 80-bits FPU registers is 19 decimal digits with an exponent of ten of ±4932, but printf function can display X register just as a 64-bits "double" value with 16 digits of precision and an exponent of ten of ±308. As far as I know, there is not any Win-32 API function that convert a full 80-bits floating point value into an ASCII string.

...

When ENG:p format is given, the X register is split in mantissa and exponent parts as integers, so the mantissa can be displayed with its full 19 decimal digits (although last digits may lost some precision) and the exponent with its ±4932 range... However, the method used in this Binary-to-Decimal conversion is a simple one that lacks detailed tests, so it may fail with certain values...

The method I used to display the 80-bits floating point number as a 19 decimal digits may introduce some rounding errors in the least significand digit(s). This means that you can NOT trust in the precision of the number displayed with ENG:p format. The central part of my conversion method is this:

Code:
         ;If current format is ENG: show mantissa and exponent as Int64EInt32 numbers         ;When enter this code, X register contain the number to show         ;                               ;stack: X         fldlg2                          ;stack: X Log10(2)                ;+1         fld     ST(1)                   ;stack: X Log10(2) X              ;+2         fyl2x                           ;stack: X Log10(X)         ;         fisttp  dVariable2              ;var2 = Floor(Log(x)), stack: X         fild    dVariable2              ;stack: X Exponent         fild    dNumber18               ;stack: X Exponent adjustment         fsub                            ;stack: X Exp-adj         ;         fldl2t                          ;stack: X Exp Log2(10)         fmul                            ;stack: X Exp*Log2(10)         call    f2powX                  ;stack: X 10^Exp         ;         fdiv                            ;X = mantissa aligned to 19 integer digits         fadd    pointFive               ;plus 0.5 for rounding         fisttp  qVariable               ;var = mantissa as 64-bits integer

I am open to any suggestion of a more precise method to perform this conversion.

(01-29-2021 01:50 PM)Albert Chan Wrote:  Better yet, have an option to enter/display hex-float.

Well, this can be done in an easier way, but the problem then is to read the hex format (by us) as a direct copy of the FPU ST(0) register with no conversion. I will add the HEX output format in the next RPN.exe version.

----

(01-29-2021 01:50 PM)Albert Chan Wrote:  Is this a RPN.exe bug ?

I use 1e16 + 2.9999 to test for rounding behavior (note: 1e16 slightly bigger than 2^53)

With double precision, 2.9999 get rounded-down, sum = 1e16 + 2
With extended precision, 2.9999 get rounded-up, sum = 1e16 + 3
If extended precision then round-back to double, sum = 1e16 + 4

But, this is not what observed:

> RPN.exe 1e16 2.9999 + eng:19 ﻿ ﻿ ﻿ ; note: eng:19 is 19 digits, not 20
10.00000000000000300E+0015

> RPN.exe 1e16 2.9999 + fix:0 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ; should hit with double-rounding errors, returning 1e16+4
10000000000000002

For some strange reason, the flip occurs much higher:

>RPN.exe 1e16 3.00634 + fix:0
10000000000000002

>RPN.exe 1e16 3.00635 + fix:0
10000000000000004

RPN.exe users manual Wrote:RPN.exe is a Windows console application designed to evaluate floating-point arithmetic operations based on an entirely different philosophy that allow the user to have access to FPU operations in a way as direct as possible with just the minimum indispensable additional code. To do that, the operations given by the user are directly translated to native machine code and then executed.

The operations you enter are exactly the same operations that the FPU executes, so the result you get is the way the FPU works.

I invite you to review the FPURM (FPU Rounding Mode) and FPUPC (FPU Precision Control) operations in chapter 7 "System operations" in the user's manual.

----

(01-29-2021 01:50 PM)Albert Chan Wrote:  A minor issue, numbers starting with decimal point are not recognized:

RPN: .123
Invalid operator: .

RPN: -.123
Wrong number: -.

RPN.exe users manual Wrote:The correct number formats are these:
Decimal: [-]digits[.digits][{e|E}[sign]exponent]
with 18 total digits and a (normalized) exponent up to 4932.

Yes. The digits part before the decimal point is the only mandatory part of a number. Note that you can't enter a number with positive sign either.

Antonio
02-01-2021, 05:07 PM
Post: #14
 Albert Chan Senior Member Posts: 1,598 Joined: Jul 2018
RE: RPN-PRGM: New Windows console application emulating HP calculators
(02-01-2021 03:33 AM)Aacini Wrote:  I am open to any suggestion of a more precise method to perform this conversion.

1. since Exp is integer, scaling factor can be improved to give more precisions

S = 10^Exp = 2^(Log2(10)*Exp) = 2^(Log2(1.25)*Exp) * 2^(3*Exp)

First term is more accurate, because of more precise constant, and smaller exponent.
Second term is just a shift of binary exponents, thus exact.

lua> log2 = require'mathx'.log2
lua> Exp = 99
lua> 2^(log2(10)*Exp)
9.999999999999729e+098
lua> 2^(log2(1.25)*Exp) * 2^(3*Exp)
1e+099

2. ASM code hard-coded rounding mantissa to 19 digits, but ENG:﻿P should round to P digits.

RPN: 92 eng:2
91.E+0000

RPN: 92 eng:6
91.9999E+0000

X = 92
P = 6
S = 10^(P-1 - floor(log10(X)) = 10^(5-1) = 1E4
round(X*S)/S = 920000E-0004 = 92.0000E+0000

3. this is a BUG.

RPN: 93 eng:6
92.2337E+0000
02-02-2021, 03:19 AM
Post: #15
 Albert Chan Senior Member Posts: 1,598 Joined: Jul 2018
RE: RPN-PRGM: New Windows console application emulating HP calculators
We can produce more accurate 10^Exp with more bits for log2(10):

log2(10) = 0x3.5269e12f346e2bf924afdbfd36bf6d ...

Code:
-- k1 + k2 = rounded 95-bits of log2(10) k1 = 0x3.5269e12f34 k2 = 0x0.00000000006e2bf924afdc function pow10(n)   -- assume integer n     local m = k1*n     local e = floor(m + 0.5)     return 2^(m-e+k2*n) * 2^e end

lua> for i=-300,300,100 do print(i, pow10(i)) end
-300﻿ ﻿ ﻿ ﻿ ﻿ 1e-300
-200﻿ ﻿ ﻿ ﻿ ﻿ 1e-200
-100﻿ ﻿ ﻿ ﻿ ﻿ 1e-100
0﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ 1
100﻿ ﻿ ﻿ ﻿ ﻿ ﻿ 1e+100
200﻿ ﻿ ﻿ ﻿ ﻿ ﻿ 1e+200
300﻿ ﻿ ﻿ ﻿ ﻿ ﻿ 1e+300
02-03-2021, 06:54 AM
Post: #16
 pavel nemec cz Junior Member Posts: 6 Joined: May 2014
RE: RPN-PRGM: New Windows console application emulating HP calculators
(01-20-2021 08:56 PM)Aacini Wrote:  So I have to wait until such companies answer my request... However, as one people at VirusTotal said: "1/60 and even 5/60 doesn’t automatically mean “Bad”, and 0/60 doesn't always mean good". You may use my RPN.exe program anyway if you trust me.

Antonio

Hallo Antonio,

I also trusted your RPN program and went for installation. (You are better than the programmer of TI59 simulator, who's program was blocked by my computer already during download - you can compare virus check results by yourself http://www.breatharian.eu/Petr/program/d.../TI-59.zip).

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.

I know nothing about X86 assembly language and your tool is a nice bridge to it and more interestingly into FPU world as well.

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.

I decided to donate \$10 and I admire your skills and effort. Thank you for sharing this program.

KR
Pavel
02-04-2021, 12:32 PM
Post: #17
 Albert Chan Senior Member Posts: 1,598 Joined: Jul 2018
RE: RPN-PRGM: New Windows console application emulating HP calculators
RPN.exe users manual Wrote:The result of [forensic test] 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.

This is not the main reason for round-trip accuracy improvement.
Errors mostly comes from cosine of tiny number (in radian), giving result close to 1
(similarly, for arc-cosine of number close to 1, to recover tiny angle)

Even without unit conversion errors, we still hit with it.

lua> u = pi/180 ﻿ ﻿ ﻿ ﻿ -- 180 u = pi radian. In other words u = degree.
lua> asin(acos(atan(tan(cos(sin(9*u)*u)*u))/u)/u)/u
8.999999999832568

lua> u = 1/64 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ -- 64 u = 1 radian. Conversion, u ⇄ radian, is exact
lua> asin(acos(atan(tan(cos(sin(9*u)*u)*u))/u)/u)/u
9.000000000229626
02-09-2021, 05:45 AM
Post: #18
 Aacini Junior Member Posts: 9 Joined: May 2016
RE: RPN-PRGM: New Windows console application emulating HP calculators
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
02-18-2021, 08:29 PM (This post was last modified: 02-19-2021 12:30 AM by Aacini.)
Post: #19
 Aacini Junior Member Posts: 9 Joined: May 2016
RE: RPN-PRGM: New Windows console application emulating HP calculators
RPN.exe version 1.0 is ready! This new version includes several changes, some minor, some larger...

I revised the method I used to convert the 80-bits X register into an ASCII string when ENG:p format is given. Although there was an obvious error in the former method, the corrected version is still not completely exact because it lacks additional tests to keep it simple and small. You may read about the difficulties involved in the Floating Point Binary-to-Decimal conversion at Ryû: Fast Float-to-String Conversion article. I still have to test the other modifications suggested by Albert Chan to improve the conversion method. Also, in this note: "eng:19 is 19 digits, not 20" you are right. This have been fixed. ENG:17 now show 18 total digits.

- I realized that Stack Overflow condition is shown as "-1.#FLW" (the same as Stack Underflow). I fixed this error, so Stack Overflow is show now as "+1.#FLW".
- A help screen is now displayed when /? or -? parameter is given.
- STO and RCL operations with no parameters now access LASTx register.
- HMS and HR (HH.MMSSCC to/from decimal hours) conversions have been added.
- I added HEX:# hexadecimal output format to compensate for the errors in ENG:p format. This operation is interesting because it allows to review the internal representation of the value in X register, including Infinities, NaN's and subnormal numbers.
- HPSTACK operation now enables/disables the HP stack emulation mode so just 4 stack registers are managed, the X register is saved in LASTx before all operations, and the T register is duplicated after operations over 2 registers. This is the larger modification completed in this version. I suggest you to read again the chapter 1- "RPN.exe vs. Stack-based calculators" in the new manual where the HP emulation mode is described.

You may download the new RPN.exe version 1.0 from the same link of the first version. There is also a new RPN_SP.exe program with a Spanish language messages version.

Antonio
02-20-2021, 02:52 PM
Post: #20
 Albert Chan Senior Member Posts: 1,598 Joined: Jul 2018
RE: RPN-PRGM: New Windows console application emulating HP calculators
Some bugs I discovered playing with RPN.exe version 1.0

RPN: hpstack fpupc:2 sci:16 1e16
1.0000000000000000E+016

RPN\HP: eng:17
99.9999999999999744E+0015

RPN\HP: hex:2
4341_C379_37E0_8000

RPN\HP: sci:16 1e16 ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ ﻿ // repeat of previous commands, different results.
9.9999999999999820E+015

RPN\HP: eng:17
9.22337203685477580E+0015

RPN\HP: hex:2
4341_C379_37E0_7FF7
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)