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 <
[email protected]> 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.
>
>
>
>
