In this case, the c data type is double (ieee 64 bit floating point on intel).
FYI, -- Raul On Wed, Sep 13, 2017 at 11:03 AM, Don Guinn <[email protected]> wrote: > Intel has 32 bit integer division. It now may have 64 bit division. > > On Wed, Sep 13, 2017 at 8:34 AM, Raul Miller <[email protected]> wrote: > >> 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 >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
