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 <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