|
From: | Leslie S Satenstein |
Subject: | Re: [Bug-apl] Problem with modulo arithmetic on Gaussian integers redux |
Date: | Thu, 15 Jun 2017 13:07:04 +0000 (UTC) |
I get:¯1J11 | ¯12J10computing (-12,10) modulo (-1,11)⎕CT is: 1e-13the quotient B ÷ A is: (0.9999999999999999,0. 9999999999999999)the quotient rounded down is: (1,0)¯11J¯1On 15 June 2017 at 13:47, Juergen Sauermann <address@hidden > wrote:Hi,
I have changed the implementation of ComplexCell::bif_residue() to use a more
intuitive implementation of integral_within(). (the old one used tolerant_floor() with
the dubious half-plane definition from the ISO standard).
The new version is SVN 961.
If it still does not work then attached is a more verbose variant of the bif_residue()
implementation that prints the intermediate results of the computation (so that we can
nail down where things go wrong).
On my machine I get, for example, this:
a ← ¯1J11
b ← ¯12J10
a | b
computing (-12,10) modulo (-1,11)
⎕CT is: 1e-13
the quotient B ÷ A is: (1,1)
result is 0 because the quotient is integral within ⎕CT
0
Just replace your ComplexCell.cc with the attached one.
Thanks,
Jürgen
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.999999 99999999989 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.9 9999999999999989
1J1
... so they don't seem to follow the ISO standard either.
Jay.
On 14 June 2017 at 18:05, Frederick Pitts <address@hidden> wrote:
Jürgen, Jay
With svn 958, I'm see the followinga ← ¯1J11b ← ¯12J10a | b¯11J¯1b ÷ a1J11J1 × a¯12J10a ← 1J¯11b ← 12J¯10a ∣ b11J1b ÷ a1J11J1 × a12J¯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 boolCell::integral_within(APL_Comp lex 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 <address@hidden > 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
[Prev in Thread] | Current Thread | [Next in Thread] |