RPN-PRGM: New Windows console application emulating HP calculators

[Aacini]

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