Hmm... actually... no...
The relevant implementation here is in ve.c:
static D jtremdd(J jt,D a,D b){D q,x,y;
if(!a)R b;
ASSERT(!INF(b),EVNAN);
if(a==inf )R 0<=b?b:a;
if(a==infm)R 0>=b?b:a;
q=b/a; x=tfloor(q); y=tceil(q); R teq(x,y)?0:b-a*x;
}
No hint of fmod here (though it does get used elsewhere).
FYI,
--
Raul
On Wed, Sep 13, 2017 at 10:28 AM, Raul Miller <[email protected]> wrote:
> I took a look at the core j implementation, and it looks like it's
> using the c fmod() mechanism.
>
> So this is really a bug inherited from c.
>
> I think.
>
> FYI,
>
> --
> Raul
>
>
> On Wed, Sep 13, 2017 at 10:06 AM, Erling Hellenäs
> <[email protected]> wrote:
>> 196x|57290824867848391x
>> 99
>>
>> I wonder how they manage to handle this in Nial:
>>
>> 57290824867848391 - ( 196 * floor ( 57290824867848391 / 196 ) )
>> 99
>>
>> Floor creates an integer, but the precision should be lost in the division
>> if they represent their floats as IEEE double. So, maybe they have another
>> representation or they change it when needed. The division does create a
>> floating point number.
>>
>> Cheers,
>>
>> Erling
>>
>>
>>
>> Den 2017-09-13 kl. 15:44, skrev Erling Hellenäs:
>>>
>>> Yes.
>>>
>>> (14^2)|!.0 [ 5729082486784839
>>>
>>> 147
>>>
>>>
>>> /Erling
>>>
>>>
>>> Den 2017-09-13 kl. 15:25, skrev Don Guinn:
>>>>
>>>> That is true, but the problem is not in J, but in IEEE as it cannot
>>>> represent that number exactly in float double. Before 64 bit integers
>>>> came
>>>> out all integers were included exactly in float double. So converting
>>>> integer to float never caused a loss in precision. Now it does.
>>>>
>>>> 2^.57290824867848391
>>>>
>>>> 55.6692
>>>>
>>>> 0j0":{.57290824867848391 0.5
>>>>
>>>> 57290824867848392
>>>>
>>>>
>>>> When things are pushed to their limits and possibly beyond, strange
>>>> things
>>>> happen. Comparison tolerance address many problems that bite other
>>>> programming languages, but it's not perfect. That decimal numbers with
>>>> fractional values cannot be represented exactly in binary computers
>>>> causes
>>>> a lot of grief in all programming languages.
>>>>
>>>>
>>>> I'm just relieved to understand the problem and that it is easy to get
>>>> around up to the limits of IEEE float double.
>>>>
>>>> On Wed, Sep 13, 2017 at 7:06 AM, Erling Hellenäs
>>>> <[email protected]>
>>>> wrote:
>>>>
>>>>> So, the perceived problem is related to comparison tolerance. The
>>>>> question
>>>>> is then how it is used and if this use is rational?
>>>>>
>>>>> With comparison tolerance at 0, when we add another digit, we get a new
>>>>> incorrect result, now related to lost precision?
>>>>>
>>>>> 9!:19]0
>>>>> 196x|57290824867848391x
>>>>> 99
>>>>> ({.196 0.5)|57290824867848391
>>>>> 104
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Erling
>>>>>
>>>>>
>>>>> Den 2017-09-13 kl. 14:38, skrev Don Guinn:
>>>>>
>>>>>> I think I found the culprit.
>>>>>>
>>>>>> ({.196 0.5)|5729082486784839
>>>>>> 0
>>>>>> 9!:18''
>>>>>> 5.68434e_14
>>>>>> 2^.9!:18''
>>>>>> _44
>>>>>> 9!:19]0
>>>>>>
>>>>>> ({.196 0.5)|5729082486784839
>>>>>> 147
>>>>>> 9!:19]5.68434e_15
>>>>>>
>>>>>> ({.196 0.5)|5729082486784839
>>>>>> 147
>>>>>> ({.196 0.5)|57290824867848391
>>>>>> 0
>>>>>> 9!:19]5.68434e_16
>>>>>>
>>>>>> ({.196 0.5)|57290824867848391
>>>>>> 104
>>>>>>
>>>>>> On Tue, Sep 12, 2017 at 4:57 PM, Raul Miller <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>> R2=: |
>>>>>>>
>>>>>>> R1=: (] - [ * [: <.!.0 ] % [)"0
>>>>>>> R0=: (|&x:)"0
>>>>>>>
>>>>>>> (14^2) R1 5729082486784839
>>>>>>> 147
>>>>>>> (14^2) R2 5729082486784839
>>>>>>> 0
>>>>>>>
>>>>>>> X=: (0.1-0.1)+i.1000
>>>>>>> Y=: 5729082486784839+i:1000
>>>>>>>
>>>>>>> datatype X
>>>>>>> floating
>>>>>>>
>>>>>>> +/,X (R0/ ~: R2/) Y
>>>>>>> 1845046
>>>>>>> +/,X (R0/ ~: R1/) Y
>>>>>>> 0
>>>>>>>
>>>>>>> Good question.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --
>>>>>>> Raul
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 12, 2017 at 4:26 AM, Erling Hellenäs
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>>> Residue1=: ] - [ * [: <.!.0 ] % [
>>>>>>>>
>>>>>>>> Residue2=: |
>>>>>>>>
>>>>>>>> (14^2) Residue1 5729082486784839
>>>>>>>>
>>>>>>>> 147
>>>>>>>>
>>>>>>>> (14^2) Residue2 5729082486784839
>>>>>>>>
>>>>>>>> 0
>>>>>>>>
>>>>>>>> Why is Residue2 losing precision when Residue1 is not?
>>>>>>>>
>>>>>>>> /Erling
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Den 2017-09-12 kl. 02:04, skrev Don Kelly:
>>>>>>>>
>>>>>>>>> I believe that Raul has hit it on the head. 14^2 will be floating
>>>>>>>>> as
>>>>>>>>>
>>>>>>>> will
>>>>>>>> generally be the case with % so it is possible that errors add or
>>>>>>>> subtract
>>>>>>>> to give an erroneous result. Note that
>>>>>>>>>
>>>>>>>>> (14^2) (] - [ * [: <. ] % [)5729082486784839x
>>>>>>>>>
>>>>>>>>> 147
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (14^2x) (] - [ * [: <. ] % [)5729082486784839
>>>>>>>>>
>>>>>>>>> 147
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> (14^2x)|5729082486784839
>>>>>>>>>
>>>>>>>>> 147
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> does it more simply
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Don
>>>>>>>>>
>>>>>>>>> On 2017-09-11 6:50 AM, Erling Hellenäs wrote:
>>>>>>>>>
>>>>>>>>>> (14^2x) (] - [ * [: <. ] % [)5729082486784839x
>>>>>>>>>>
>>>>>>>>>> 147
>>>>>>>>>>
>>>>>>>>>> (14^2) (] - [ * [: <. ] % [)5729082486784839
>>>>>>>>>>
>>>>>>>>>> _49
>>>>>>>>>>
>>>>>>>>>> (14^2) (] - [ * _1 + [: <. ] % [)5729082486784839
>>>>>>>>>>
>>>>>>>>>> 147
>>>>>>>>>>
>>>>>>>>>> /Erling
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Den 2017-09-11 kl. 15:40, skrev Erling Hellenäs:
>>>>>>>>>>
>>>>>>>>>>> From what I see, floor gives an incorrect result which I correct
>>>>>>>>>>> with
>>>>>>>>>>> the " _1 + " There is not other problem. No loss of precision.
>>>>>>>>>>> /Erling
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Den 2017-09-11 kl. 15:27, skrev Raul Miller:
>>>>>>>>>>>
>>>>>>>>>>>> I do not know what you are thinking, and you have not illustrated
>>>>>>>>>>>>
>>>>>>>>>>> your
>>>>>>>>
>>>>>>>> thoughts sufficiently for me to grasp them.
>>>>>>>>>>>>
>>>>>>>>>>>> So, I thought I'd work through this:
>>>>>>>>>>>>
>>>>>>>>>>>> (14^2) (] - [ * _1 + [: <. ] % [)5729082486784839
>>>>>>>>>>>> 147
>>>>>>>>>>>> (14^2x) (] - [ * _1 + [: <. ] % [)5729082486784839x
>>>>>>>>>>>> 343
>>>>>>>>>>>>
>>>>>>>>>>>> Clearly, the exact answer is different from the quick answer.
>>>>>>>>>>>>
>>>>>>>>>>>> If we compare
>>>>>>>>>>>> load'debug/dissect'
>>>>>>>>>>>> dissect '(14^2) (] - [ * _1 + [: <. ] % [)5729082486784839'
>>>>>>>>>>>> dissect '(14^2x) (] - [ * _1 + [: <. ] %
>>>>>>>>>>>> [)5729082486784839x'
>>>>>>>>>>>>
>>>>>>>>>>>> We can see the initial off-by-one errors, but the big difference
>>>>>>>>>>>>
>>>>>>>>>>> shows
>>>>>>>>
>>>>>>>> up at the end (where we subtract from 5729082486784839)
>>>>>>>>>>>>
>>>>>>>>>>>> The value we are subtracting is:
>>>>>>>>>>>>
>>>>>>>>>>>> (14^2x) ([ * _1 + [: <. ] % [)5729082486784839x
>>>>>>>>>>>> 5729082486784496
>>>>>>>>>>>> (14^2) ([ * _1 + [: <. ] % [)5729082486784839
>>>>>>>>>>>> 5.72908e15
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the bits needed to represent that as an integer:
>>>>>>>>>>>>
>>>>>>>>>>>> 2^.(14^2) ([ * _1 + [: <. ] % [)5729082486784839
>>>>>>>>>>>> 52.3472
>>>>>>>>>>>>
>>>>>>>>>>>> we can see that that's right on the edge of being the number of
>>>>>>>>>>>> representable digits in a 64 bit float.
>>>>>>>>>>>>
>>>>>>>>>>>> But, also, it's the result of multiplying
>>>>>>>>>>>>
>>>>>>>>>>>> 14^2
>>>>>>>>>>>> 196
>>>>>>>>>>>>
>>>>>>>>>>>> by an off-by-one amount. And...
>>>>>>>>>>>>
>>>>>>>>>>>> 343-196
>>>>>>>>>>>> 147
>>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> Anyways, I'm not sure what you were thinking, but I guess we can
>>>>>>>>>>>> take
>>>>>>>>>>>> this as a good example of the idea that errors can actually
>>>>>>>>>>>> accumulate.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> ----------
>>>>>>>>
>>>>>>>> For information about J forums see http://www.jsoftware.com/
>>>>>>>>>>
>>>>>>>>>> forums.htm
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>> ----------
>>>>>>>>>> For information about J forums see http://www.jsoftware.com/forum
>>>>>>>>>> s.htm
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> For information about J forums see
>>>>>>>>> http://www.jsoftware.com/forums.htm
>>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------------
>>>>>>>> For information about J forums see
>>>>>>>> http://www.jsoftware.com/forums.htm
>>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>>>
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
