bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jay Foad
Subject: Re: [Bug-apl] Problem with modulo arithmetic on Gaussian integers redux
Date: Thu, 15 Jun 2017 13:50:52 +0100

I get:

      ¯1J11 | ¯12J10
computing (-12,10) modulo (-1,11)
⎕CT is: 1e-13
the quotient B ÷ A is: (0.9999999999999999,0.9999999999999999)
the quotient rounded down is: (1,0)
¯11J¯1

On 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.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 <address@hidden> 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 <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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]