Unfortunately, there are limits which computers give "right" answers. Here is a case where the wrong answer is given:
(14^2) |!.0] 57290824867848391 104 196 | 57290824867848391 99 Because the number on the right has no exact representation in float double. x:57290824867848391 0.5 57290824867848392 1r2 So, it's a hardware restriction. Either mod only accept integer arguments or we have to deal with it. The fuzz is applied to the result, which is within fuzz. One thing I have thought might help is that fuzz be applied to the arguments and if they are both integral values, convert them to integer before applying mod. On Fri, Sep 15, 2017 at 12:49 PM, Erling Hellenäs <[email protected]> wrote: > Even if we take care of the zero case, a fuzzy residue will deliver random > errors much higher than the small errors which naturally affects real > numbers? Multiplied with a big number and then the lost precision of the > subtraction can make these errors very significant? /Erling > > > On 2017-09-15 17:25, Erling Hellenäs wrote: > >> Hi all! >> >> OK. I guess there is some way to implement this so that both Floor and >> Residue are fuzzy without having the circular dependency. It seems to >> basically be the implementation we have. >> It seems Floor gives the closest integer within comparison tolerance in >> the way it is specified then. >> 9!:19 [ 5.68434e_14 >> >> >> 25j5": (9!:18'') * 5729082486784839 % 196 >> >> 1.66153 >> >> 25j5":a=: 5729082486784839 % 196 >> >> 29230012687677.75000 >> >> 25j5": <. a >> >> 29230012687678.00000 >> >> It means that this result, which we find strange, is according to >> specification? >> >> (14^2) | 5729082486784839 >> >> 0 >> >> It also means that this result, which we find correct, is not according >> to specification? >> >> 196 | 5729082486784839 >> >> 147 >> >> >> So, now there is a question about if we should live with this >> inconsistency or change the specification or the part of the implementation >> that is not according to this specification? >> >> I think the efforts to create a consistent algebra is good. However, in >> my practical experience I found it important that functions give correct >> results. Incorrect results without any fault indication could mean that the >> patient dies, the bridge collapses or the company gets insolvent. Could the >> zero result really be considered correct? If not, is there a way in which >> we could deliver a fault indication instead of the zero result? This means >> we should have an error in the integer case and a NaN in the real case? >> >> Cheers, >> >> Erling Hellenäs >> >> Den 2017-09-15 kl. 14:13, skrev Raul Miller: >> >>> Eugene's work should be thought of as specification, rather than >>> implementation. >>> >>> That said, chasing through the various implementations of floor for >>> the various C data types can be an interesting exercise. >>> >>> Thanks, >>> >>> >> ---------------------------------------------------------------------- >> 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
