Re: [Bug-apl] Problem with modulo arithmetic on Gaussian integers redux

[Juergen Sauermann]

Hi Jay, thanks again for the explanation. As a matter of fact, older GNU APL versions did use a more common-sense definition of tolerant floor, but then Fred reported problems with the Gaussian integers and I thought that this may be caused by me not strictly following the ISO standard. So I changed the implementation to follow the ISO standard. more and more. Apparently that was the wrong path. It remains interesting why this happens only on some platforms, but I suppose this is due to rounding errors. I will try another approach now, using the distance from the nearest Gaussian integer in tolerant floor. Best Regards, Jürgen Sauermann On 06/15/2017 10:38 AM, Jay Foad wrote: Another example from Fred:       ¯1J11 | ¯12J10 ⍝ should be zero ¯11J¯1 This seems to be a consequence of the ISO standard's curious definition of tolerant-floor. I would naively expect the tolerant floor of A←0.99999999999999989J0.99999999999999989 to be 1J1, but according to the standard (and hence GNU APL) it is 1. So A is not considered a near-integer because it fails the (⌊-A)=-⌊A test. I would humbly suggest ignoring the standard in this case and implementing a more common sense definition of tolerant-floor. Note that in IBM APL2 (the demo version for Windows) I get:       ⌊0.99999999999999989J0.99999999999999989 1J1    ... so they don't seem to follow the ISO standard either. Jay. On 14 June 2017 at 18:05, Frederick Pitts <fred.pi...@comcast.net> wrote: Jürgen, Jay With svn 958, I'm see the following       a ← ¯1J11       b ← ¯12J10       a | b ¯11J¯1       b ÷ a 1J1       1J1 × a ¯12J10       a ← 1J¯11       b ← 12J¯10       a ∣ b 11J1       b ÷ a 1J1       1J1 × a 12J¯10 So the error changed but persists on my platform. Regards, Fred On Wed, 2017-06-14 at 17:20 +0200, Juergen Sauermann wrote: Hi Jay, Fred, thanks a lot, Jay, for figuring this out. Fred, I made the change proposed by Jay. Please let me know if the problem persists. SVN 958. /// Jürgen On 06/14/2017 03:13 PM, Jay Foad wrote: It got broken in r939. The problem is in Cell.icc: //----------------------------------------------------------------------------- inline bool Cell::integral_within(APL_Complex A, APL_Float B) { const APL_Complex C = -A;    return tolerant_floor(C, B) == tolerant_floor(A, B); } //----------------------------------------------------------------------------- You're missing a minus sign before the second "tolerant_floor". Jay. On 14 June 2017 at 13:04, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: Hi Fred, not sure what to do about that. On my machine I am getting:       1J3 ∣ 8J4 0 and your TGI0.apl program seems not to output anything. Best Regqrds, Jürgen Sauermann On 06/14/2017 05:52 AM, Frederick Pitts wrote: Juergen, I'm seeing errors with the mod (∣) operator applied to Gaussian integers again. With svn 896, the mod operator yields a nonzero residual result while the division operator yields an exact Gaussian integer quotient result as follows       1J3 ∣ 8J4 1J3       8J4 ÷ 1J3 2J¯2       1J3 × 2J¯2 8J4 I'm running Fedora 25, 64 bit, on an Intel Core i7-6700 4 core CPU with 16 Gbyte memory. The attached TGI0.apl generates many more failure examples if needed. Regards, Fred