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 <juergen.sauerm...@t-online.de>
> 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" <juergen.sauerm...@t-online.de>
>> 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
>>> <juergen.sauerm...@t-online.de> 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
>>>> <juergen.sauerm...@t-online.de> 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
>>>>> <juergen.sauerm...@t-online.de> 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 <jinxiaoy...@gmail.com> wrote:
>>>>>> 1e¯200|1e200 hangs on my mac.
>>>>>>
>>>>>> > On Jan 5, 2018, at 6:57 AM, Juergen Sauermann
>>>>>> > <juergen.sauerm...@t-online.de> 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.
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
