Re: [Bug-apl] Almost One

[Mike Duvos]

Hi Jürgen,

To reproduce a floating point value exactly when it is read back in after being converted to ASCII, it is necessary to write out one past the maximum number of decimal digits the floating point representation supports.

64 bit IEEE is 17 decimal places, so you have to write out 18.

So a user who sets ⎕PP to 18, and displays or formats a number, should get the exact value of the number displayed, and the floating point representation should be recreated down to the last bit when the number is read back in.  This is important when people use workspaces to perform functions similar to )IN and )OUT, or when they write data to text files, and want to get the same data back in their workspace after reading it back in.

In APL2 this works correctly...      

      ⎕PP←18
      1J1E¯16
1J9.9999999999999998E¯17

In GNU APL it doesn't


      ⎕PP←18
      1J1E¯16
1

The fact that I used 1D45*8 to create a number slightly different from 1.0, and 2

⎕TF to display the number to full 18 digit precision are tangential to the point I am making.

Regards,

Mike

 

 

On Fri, Sep 4, 2015 at 7:19 AM, Juergen Sauermann <address@hidden> wrote:

Hi Mike,

I can't really see what's wrong here. On my platform I get:

      ALMOST_ONE←1D45*8
      2 ⎕TF 'ALMOST_ONE'
ALMOST_ONE←9.999999999999998E¯1J¯2.449293598294707E¯16

2 ⎕TF is independent of ⎕PP and ⎕CT and it prints floating point and complex numbers
with their maximum precision. So this merely shows that 1D45 to the 8th power
slightly differs from its theoretical value 1.0 (due to rounding erros when parsing
1D45 and when computing the 8th power).

/// Jürgen

On 09/03/2015 01:26 AM, Mike Duvos wrote:

       )CLEAR

CLEAR WS
     
      ALMOST_ONE←1D45*8
     
      ⎕CT←0
     
      ⎕PP←18
     
      ALMOST_ONE
1
      1=ALMOST_ONE
0
      2 ⎕TF 'ALMOST_ONE'
ALMOST_ONE←1J¯2.449293598294707E¯16

When I set ⎕PP←18, I would expect the exact values of numbers to be printed.

APL2 prints the number exactly.