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