Re: [Bug-apl] Modulo or residue function is not generating consistent complete residue systems for some arguments

[Frederick Pitts]

Jürgen,

The proposed change to DIVJ does not work because 'q1' is a complex number, so the '×' in '× q1' is the complex complement function, not the sign function. I tried the proposed change and every test fails.

I will try to hack DIVJ to use a floor towards zero instead of towards minus infinity for the real and imaginary

parts of the quotient and see what happens.

Correct me if I am wrong, but my mind set is that the APL residue function has to satisfy the following invariants:

1) The order of the complete residue system (residue count) for a given modulo 'n' has to equal the norm of 'n'.

2) And as Jay Foad so succinctly expressed it, the residue function has to be idempotent with respect to its right argument,

e.g., ( n | m ) = n | n | m .

regardless of the implementation of the residue function.

Later,

Fred

On Wed, 2017-06-21 at 19:46 +0200, Juergen Sauermann wrote:

Hi Fred,

I have a question about the MOD_test.apl that you kindly provided.

In function DIVJ on line 57 ff it says:

z ← q , a - b × q ← CMPLX ⌊ ( 9 11 ) ○ a ÷ b

so the quotient is rounded down towards minus infinity.

I wonder if that should be something like

z ← q , (× q1) × a - b × q ← CMPLX ⌊ ∣ 9 11 ○ q1 ← a ÷ b

so that the quotient is rounded towards 0? Interestingly IBM and ISO
give different definitions for the residue in terms of APL:

IBM (language reference, page 227):
Z←L∣R
Z is R-L×⌊ R÷L+L=0

ISO (chapter 7.2.9 Residue):
R←Q∣P
R←P-(×P)×|Q×⌊|P÷Q
and return R if (×R)=×Q, or R+Q
otherwise.

That suggest that IBM rounds the quotient down towards minus infinity while ISO rounds
 towards 0.

My naive view on remainder is that the nearest integer quotient shall be smaller in
magnitude and not smaller in value. Regarding your proposal (which is different from
both IBM and ISO) my concern is that may lead to different results for modulo N and
modulo N×1J0

Best Regards,
Jürgen Sauermann

On 06/21/2017 03:08 AM, Frederick Pitts wrote:

Jürgen,

This message is being resent because last minute changes I made to CRS0.apl and CRS1.apl do not output the

data I intended.  This message has corrected versions of those files attached.  Please discard the old CRS0.apl and CRS1.apl files.  The first line of output is the modulo basis, the second line is the calculated complete residue system values and the third line is the number of residues in the CRS on the previous line.

CRSOTST0.apl and CRSOTST1.apl are unchanged.

Also please find attached MOD_TEST.apl which compares the residues calculated by MODJ and the builtin residue function and reports discrepancies.  The first column of output is the modulo basis, the second column the right argument to the functions, the third column the MODJ result and the fourth column is the builtin residue function result.

Regards

Fred

Hello Jürgen,

	SVN 964 moved us in the right direction but not completely out of the

woods.  SVN 964 still exhibits errors.  For instance

      2J6 | 5J5

¯1J7

      2J6 | ¯1J7

¯3J1

      2J6 | ¯3J1

¯3J1

	I found this and previous residue function errors using the attached APL

code files.  The files with base name ending in '0' use the builtin residue

function.  Those with base name ending in '1' use a residue function implemented

in APL.  The files with base name beginning with 'CRSOTST' test if the order of

the complete residue system (CRS) equals the norm of the modulo basis.  That

test fails for several modulo bases, 2J6 being one of them, using the builtin

residue function. No errors are detected with the APL implementation.  The other files

can be used to plot the CRS for a given modulo basis where 'a' and 'b' in

'a + b * i' are limited to +15 to -15 range.  A full screen terminal window is

needed to see the plot.

	My APL implementation of the residue function is very close to what you

described in your previous email.  Maybe comparing the two implementations will

give insight into why the builtin residue function fails for some modulo bases.

	I make no assertion that my implementation is correct in all

aspects.

Regards,

Fred

On Tue, 2017-06-20 at 14:14 +0200, Juergen Sauermann wrote:

Hi Frederick,

the algorithm for A ∣ B used in GNU APL is this:

- compute the quotient Q←B÷A,
- "round down" Q to the next (complex) integer Q1,
- return B - Q1×A

Now the problem seems to be what is meant by "round down". There are two candidates:

  Q1 ← ⌊ Q                                          i.e. use APL floor to round down Q
  Q1 ← Complex( floor(Q.real(), floor(Q.imag()) )   i,e, use C/C++ floor() to round down Q.

In your  5J3 ∣ 14J5 example, the quotient is 2.5J¯0.5, which gives different results for the APL floor ⌊ and the C/C++ floor().

The APL floor ⌊2.5J¯0.5 is 3J¯1 (a somewhat dubious invention in the ISO standard on page 19, which I used up to
including SVN 963), while the C/C++ floor() is 2J¯1. The difference between the APL floor and the C/C++ floor is 1.0 which,
multiplied by the divisor, explains the differences that we see.

As of SVN 964 I have changed the residue function (∣) to use the C/C++ floor instead of the APL floor. The APL floor and
Ceiling functions (⌊ and ⌈) are still using the apparently broken definition in the ISO standard.

I hope this works better for you. At least I am getting this in SVN 964:

      5J3 | 14J5
1J4
      5J3 | 1J4
1J4

whereas SVN 963 was giving:

      5J3 | 14J5
¯4J1
      5J3 | 1J4
¯4J1


Best Regards,
/// Jürgen

On 06/19/2017 07:03 PM, Frederick Pitts wrote:

Jürgen,

	With gnu apl (svn 961 on Fedora 25, Intel(R) Core(TM) i7-6700
CPU), the residue function (∣) yields the following:

      5J3 ∣ 14J5
1J4
      5J3 | 1J4
¯4J1
      5J3 | ¯4J1
¯4J1
The above result means that two elements in the complete residue system
(CSR) for mod 5J3 are equal, i.e. 1J4 = ¯4J1 mod 5J3, which is not
allowed.  None of the elements of a CSR can be equal modulo the CSR's
basis.

Regards,

Fred