bug-apl
[Top][All Lists]
Advanced

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

Re: [Bug-apl] number precision in saved workspaces


From: Xiao-Yong Jin
Subject: Re: [Bug-apl] number precision in saved workspaces
Date: Mon, 13 Jun 2016 09:24:42 -0500

Yes, they work.  Thanks.

> On Jun 11, 2016, at 9:29 AM, Juergen Sauermann <address@hidden> wrote:
> 
> Hi Xiao-Yong,
> 
> thanks, fixed in SVN 740. I haven't checked )DUMP and )OUT but I suppose
> they work now since the fault was in the tokenizer (which is also used by
> )LOAD and )IN).
> 
> /// Jürgen
> 
> 
> On 06/10/2016 10:34 PM, Xiao-Yong Jin wrote:
>> Hi Jürgen,
>> 
>> Thanks.  I found more floating point reproduction issues.
>> 
>>       ⎕PP←17
>>       x-y←x←○3 4
>> 0 0
>>       x-⍎⍕x
>> 0 1.7763568394002505E¯15
>>       x-¯14⎕CR 14⎕CR x
>> 0 0
>>       2⎕TF 2⎕TF ‘y'
>> y
>>       y
>> 9.4247779607693793 12.566370614359172
>>       x
>> 9.4247779607693793 12.566370614359172
>>       x-○3 4
>> 0 0
>>       y-○3 4
>> 0 ¯1.7763568394002505E¯15
>>       x-y
>> 0 1.7763568394002505E¯15
>>       9.4247779607693793 12.566370614359172-○3 4
>> 0 ¯1.7763568394002505E¯15
>> 
>> 
>> The exact representation by 14⎕CR works great (as in one of the ISO CF 
>> implementations), but both ⎕TF and ⍎⍕ fail to reproduce the exact number.
>> 
>> Since you last change, the )save )load does keep the exact values, and I 
>> looked at the saved workspace file, the numbers are
>> 146   <Ravel vid="1" cells="⁴9.4247779607693793⁴12.566370614359171"/>
>> 147   <Ravel vid="2" cells="⁴9.4247779607693793⁴12.566370614359172"/>
>> 185     <Symbol name="x" stack-size="1">
>> 186       <Variable vid="2"/>
>> 187     </Symbol>
>> 188 
>> 189     <Symbol name="y" stack-size="1">
>> 190       <Variable vid="1"/>
>> 191     </Symbol>
>> Here, the last digit of y is 1 instead of 2, as shown in the REPL.
>> 
>> So it seems the routine used to format numbers has some problem with the 
>> last digits, even if with ⎕PP=17?  Or it’s just the reader has some problem?
>> 
>> In addition, )dump and )out still changes the floating point number, but 
>> perhaps that is the same issue as in ⎕TF and ⍎⍕?
>> 
>> 
>>> On Jun 7, 2016, at 3:29 PM, Juergen Sauermann <address@hidden>
>>>  wrote:
>>> 
>>> Hi Xiao-Yong,
>>> 
>>> OK - SVN 739.
>>> 
>>> /// Jürgen
>>> 
>>> 
>>> On 06/07/2016 08:16 PM, Xiao-Yong Jin wrote:
>>> 
>>>> Hi Jürgen,
>>>> 
>>>> Thanks, though the current behavior still does not give the exact number 
>>>> bit by bit.  Can you change it to %.17g, or 
>>>> std::numeric_limits<double>::max_digits10?
>>>> 
>>>> In addition, is it OK to raise the maximum allowed ⎕PP to 17?
>>>> 
>>>> Best,
>>>> Xiao-Yong
>>>> 
>>>> 
>>>> 
>>>>> On Jun 7, 2016, at 12:37 PM, Juergen Sauermann <address@hidden>
>>>>> 
>>>>>  wrote:
>>>>> 
>>>>> Hi Xiao-Yong,
>>>>> 
>>>>> thanks, fixed in SVN 738.
>>>>> 
>>>>> /// Jürgen
>>>>> 
>>>>> 
>>>>> On 06/07/2016 08:13 AM, Xiao-Yong Jin wrote:
>>>>> 
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> Is the following behavior intended?  Note the x value after load.
>>>>>> 
>>>>>>       )clear
>>>>>> CLEAR WS
>>>>>>       x←.12345678901234567890
>>>>>>       ⎕pp←16
>>>>>>       x
>>>>>> 0.1234567890123457
>>>>>>       )wsid tmp
>>>>>> WAS CLEAR WS
>>>>>>       )save tmp
>>>>>> 2016-06-07  01:09:15 (GMT-5)
>>>>>>       )clear
>>>>>> CLEAR WS
>>>>>>       )load tmp
>>>>>> SAVED 2016-06-07 01:09:15 (GMT-5)
>>>>>>       x
>>>>>> 0.123457
>>>>>>       ⎕pp
>>>>>> 16
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>> 
> 




reply via email to

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