Re: [Bug-apl] Hang in Residue

[Xiao-Yong Jin]

It's a waste of time to make modulo exact for inexact floating point numbers.  
People should expect round off errors in those cases.  Until GNU APL have 
multi-precision numbers, it is pointless to make modulo exact for inexact 
numbers.

Asking for exact result with something like

      (1E200+⍳10)|¯1

seems useless.

> On Jan 8, 2018, at 3:49 PM, Juergen Sauermann <address@hidden> wrote:
> 
> Hi Elias,
> 
> the ISO APL standard says:
> 
> "Note: The implementation-algorithm P modulo Q provides an exact modulo 
> operation for realnumbers
> P and Q. It evaluates R←B-(×B)×|A×⌊|B÷A and return R if (×A)=×B or R+A 
> otherwise.
> The definition of “mod” in the IEEE standard for Binary Floating-Point 
> Arithmetic (754) provides
> an example of this exact evaluation."
> 
> If I do the same computation then for some arguments I am getting strange 
> results, probably caused by
> rounding errors. The only non-trivial function in the computation is above is 
> floor(). Some of the numbers
> in Jay's example (e.g. 1E200) are notexact in a 64 bit float so that may as 
> well be the cause of the problems.
> 
> I anyhow wonder what can be expected from, say, 1E200 modulo 9 if there are 
> many numbers around 1E200 that all
> have the same floating point representation. Maybe the old way of throwing a 
> DOMAIN ERROR when the result
> becomes obscure wasn't that bad, despite of what the ISO standard asks for.
> 
> Best Regards,
> /// Jürgen
> 
> 
> On 01/08/2018 10:17 PM, Elias Mårtenson wrote:
>> I can't easily find the document online without having to pay for it, but 
>> doesn't the Wikipedia page contain all the information you need? 
>> https://en.m.wikipedia.org/wiki/IEEE_754
>> 
>> On 9 Jan 2018 12:14 am, "Juergen Sauermann" <address@hidden> wrote:
>> Hi Jay,
>> 
>> I am still puzzled by the ISO description (and can't find the "IEEE standard 
>> for Binary Floating-Point Arithmetic (754)"
>> referenced in the standard.
>> 
>> Would you be able to provide the expected expected output of your example 
>> below?
>> 
>> If I follow the ISO description of mod in the ISO APL standard word by word 
>> then I am getting pretty odd values at times.
>> 
>> Best Regards,
>> /// Jürgen
>> 
>> 
>> On 01/08/2018 02:19 PM, Jay Foad wrote:
>>> Yes, thanks! Now, when ⎕CT=0 there are some odd results:
>>> 
>>>       ⎕CT←0
>>>       A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>       A∘.|A
>>>  0E0   ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 0E0    0E0    ¯1E200 0E0   0E0
>>>  0E0    0E0   ¯1E0   ¯1E¯100 ¯1E¯200 0 0E0    0E0    ¯1E100 0E0   0E0
>>>  0E0    0E0    0E0   ¯1E¯100 ¯1E¯200 0 0E0    0E0     0E0   0E0   0E0
>>>  0E0    0E0    0E0    0E0    ¯1E¯200 0 0E0    0E0     0E0   0E0   0E0
>>>  0E0    0E0    0E0    0E0     0E0    0 0E0    0E0     0E0   0E0   0E0
>>> ¯1E200 ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100  1E0   1E100 1E200
>>>  0E0    0E0    0E0    0E0     0E0    0 0E0    0E0     0E0   0E0   0E0
>>>  0E0    0E0    0E0    0E0     0E0    0 1E¯200 0E0     0E0   0E0   0E0
>>>  0E0    0E0    0E0    0E0     0E0    0 1E¯200 1E¯100  0E0   0E0   0E0
>>>  0E0    0E0    1E100  0E0     0E0    0 1E¯200 1E¯100  1E0   0E0   0E0
>>>  0E0    0E0    1E200  0E0     0E0    0 1E¯200 1E¯100  1E0   1E100 0E0
>>>       1e200|¯1
>>> 1E200
>>> 
>>> The standard explicitly says that the result should never be the same as 
>>> the (non-zero) left argument: "If Z is A , return zero."
>>> 
>>> Jay.
>>> 
>>> On 8 January 2018 at 12:26, Juergen Sauermann <address@hidden> wrote:
>>> Hi Jay,
>>> 
>>> maybe SVN 1036 works better.
>>> 
>>> /// Jürgen
>>> 
>>> 
>>> On 01/08/2018 01:02 PM, Jay Foad wrote:
>>>> Thanks. With r1035 I get:
>>>> 
>>>>       A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>>       A∘.|A
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>> ¯1E200  0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>> ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>> 
>>>> One result stands out:
>>>> 
>>>>       ¯1E¯200|¯1E200
>>>> ¯1E200
>>>> 
>>>> The result of A|B (with A non-zero) should be strictly smaller in 
>>>> magnitude than A, so this seems very wrong.
>>>> 
>>>> Jay.
>>>> 
>>>> 
>>>> On 8 January 2018 at 11:49, Juergen Sauermann <address@hidden> wrote:
>>>> Hi Jay,
>>>> 
>>>> thanks, fixed in SVN 1035.
>>>> 
>>>> BTW tryapl.com gives this:
>>>> 
>>>>       A←1E¯200 1E200  ¯1E¯200 ¯1E200
>>>>       A ∘.∣ A
>>>> 0 0 0 0
>>>> 0 0 0 0
>>>> 0 0 0 0
>>>> 0 0 0 0
>>>> 
>>>> 
>>>> /// Jürgen
>>>>  
>>>> 
>>>> 
>>>> TOn 01/08/2018 10:29 AM, Jay Foad wrote:
>>>>> Thanks. At r1034 I get:
>>>>> 
>>>>>       A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>>>       A∘.|A
>>>>> DOMAIN ERROR
>>>>> 
>>>>> And here's one of the cases that fails:
>>>>> 
>>>>>       1e¯200|1e200
>>>>> DOMAIN ERROR
>>>>> 
>>>>> This still seems wrong to me, since the ISO standard for Residue says 
>>>>> "Implementations should avoid signalling limit-error in residue" with 
>>>>> advice on how to avoid it. (OK, it doesn't mention DOMAIN ERROR, but I 
>>>>> think the same principle applies.)
>>>>> 
>>>>> Jay.
>>>>> 
>>>>> 
>>>>> On 6 January 2018 at 11:56, Juergen Sauermann <address@hidden> wrote:
>>>>> Hi,
>>>>> 
>>>>> thanks, fixed in SVN 1029.
>>>>> 
>>>>> /// Jürgen
>>>>> 
>>>>> 
>>>>> On 01/05/2018 04:37 PM, Jay Foad wrote:
>>>>>> Yes, that expression hangs on my Linux box too. It gets stuck here:
>>>>>> 
>>>>>> FloatCell::bif_residue (this=0x555555ae13a8, Z=0x555555ae24f8, 
>>>>>>     A=0x555555ae11d8) at FloatCell.cc:643
>>>>>> 643              while (z < 0.0)    z = z + a;
>>>>>> (gdb) p z
>>>>>> $1 = -inf
>>>>>> (gdb) p a
>>>>>> $2 = 9.9999999999999998e-201
>>>>>> 
>>>>>> Jay.
>>>>>> 
>>>>>> On 5 January 2018 at 15:24, Xiao-Yong Jin <address@hidden> wrote:
>>>>>> 1e¯200|1e200 hangs on my mac.
>>>>>> 
>>>>>> > On Jan 5, 2018, at 6:57 AM, Juergen Sauermann <address@hidden> wrote:
>>>>>> >
>>>>>> > Hi Jay,
>>>>>> >
>>>>>> > hmm, interesting. I am getting this:
>>>>>> >
>>>>>> >       A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>>>> >       A∘.|A
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> > ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >  0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0   0E0
>>>>>> >
>>>>>> > I suppose it is one of the A[i] ∣ A[j] which causes the hanging so it 
>>>>>> > would
>>>>>> > be interesting to know which one. Probably one with +/- 1E¯200 or 
>>>>>> > 1E¯100.
>>>>>> >
>>>>>> > Best Regards,
>>>>>> > /// Jürgen
>>>>>> >
>>>>>> >
>>>>>> > On 01/05/2018 12:16 PM, Jay Foad wrote:
>>>>>> >> At svn r1028 on Linux I get:
>>>>>> >>
>>>>>> >>       A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>>>> >>       A∘.|A
>>>>>> >> (hangs)
>>>>>> >>
>>>>>> >> Jay.
>>>>>> >
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>