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

Juergen Sauermann Thu, 15 Jun 2017 06:29:08 -0700

Hi Leslie,

no, it seems like SVN 961 is working.

Best Regards,
Jürgen

On 06/15/2017 03:07 PM, Leslie S Satenstein wrote:

is svn 961 recinded?

Regards

Leslie

Leslie Satenstein

Montréal Québec, Canada
From: Jay Foad <jay.f...@gmail.com>
To: Juergen Sauermann <juergen.sauerm...@t-online.de>
Cc: "bug-apl@gnu.org" <bug-apl@gnu.org>
Sent: Thursday, June 15, 2017 8:54 AM
Subject: Re: [Bug-apl] Problem with modulo arithmetic on Gaussian integers redux
Sorry, please ignore that. I had not done an svn update.

With the latest svn I get:

¯1J11 | ¯12J10

0

... so it's looking good!
On 15 June 2017 at 13:50, Jay Foad <jay.f...@gmail.com> wrote:
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 <juergen.sauerm...@t-online.de > 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 <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_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 <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

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

Reply via email to