[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Almost One

From: Mike Duvos
Subject: Re: [Bug-apl] Almost One
Date: Fri, 4 Sep 2015 07:58:55 -0700

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...      



In GNU APL it doesn't



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.





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:

      2 ⎕TF 'ALMOST_ONE'

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:
      2 ⎕TF 'ALMOST_ONE'

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

APL2 prints the number exactly.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]