: [Bug-apl] Problem with modulo arithmetic on
Gaussian integers redux
Sorry,
please ignore that. I had not done an
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 wrote:
> I get:
>
> ¯1J11 | ¯12J10
> computing (-12,10) modulo (-1,11)
> ⎕CT is: 1e-13
> the quotient B ÷ A is: (0.
I get:
¯1J11 | ¯12J10
computing (-12,10) modulo (-1,11)
⎕CT is: 1e-13
the quotient B ÷ A is: (0.,0.)
the quotient rounded down is: (1,0)
¯11J¯1
On 15 June 2017 at 13:47, Juergen Sauermann
wrote:
> Hi,
>
> I have changed the implementation of *ComplexCell::b
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 ver
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
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.99989J0.99989 to be 1J1, but according to the
standard (and h
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
> Jürgen, Jay, Kacper,
The last time this error occurred on my platform, you could
not reproduce it on yours. However, Jay Foad and Kacper Gutowski were
able to reproduce the error. Hopefully one or both of them or someone
else on the Bug-apl list will be able to do so again.
Regards,
F
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);
}
//-
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 P
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
Hi Jürgen:
I just want to express my personal thanks to you for your responsiveness in
making GNU APL better.
Your dedication is exemplary and inspiring.
respect….
Peter
> On Apr 27, 2017, at 12:28 PM, Juergen Sauermann
> wrote:
>
> Hi again,
>
> I have changed the implementation of A∣B for
Hi again,
I have changed the implementation of A∣B for complex
numbers so that it follows exactly
the wording of the ISO standard, SVN 938.
I do not think that this changes the result, but it may simplify
the troubleshooting
of this primi
Hi Frederick,
thanks, I will study the paper below in detail.
GNU APL uses the Euclidean algorithm in the form optimized by
Gabriel Lame.
You will find the implementation of it at ComplexCell.cc
lines 299 ff in function
ComplexCell::bif_resi
Jürgen,
SVN 937 works for me.
Out of curiosity, is the Euclidean division algorithm described
starting at the bottom of page 6 of http://www.math.uconn.edu/~kconrad/
blurbs/ugradnumthy/Zinotes.pdf relevant to how you are performing the
modulo function on Gaussian integers? The de
Hi,
thanks a lot. I believe I found it now.
The check for near-int in the complex modulo was still incorrect
(and interestingy correct in the non-complex case). SVN 937.
/// Jürgen
On 04/26/2017 09:08 PM, Peter Teeson
wrote:
In which header is cval() defined?
> On Apr 26, 2017, at 3:00 PM, Kacper Gutowski wrote:
>
> On Wed, Apr 26, 2017 at 06:30:34PM +0200, Juergen Sauermann wrote:
>> For those of you that can reproduce the problem on their machine, please let
>> me
>> know if the problem has not disappeared.
>
On Wed, Apr 26, 2017 at 06:30:34PM +0200, Juergen Sauermann wrote:
> For those of you that can reproduce the problem on their machine, please let
> me
> know if the problem has not disappeared.
I just compiled 934 and 3J1|23J1 gives 3J1 for me too.
My g++ version is 6.3.0 20170415 on debian sid.
Of course….. I 100% agree.
It was just a suggestion for a differential diagnosis (in medical terms not
calculus ones).
Once log ago I had to track down an IBM Fortran 77 Floating point bug… which I
was able to do and send a PTF to them.
Never had to deal with the assembly for complex numbers so i
Hi Jay et al,
thanks for the analysis. I hope this problem is fixed in SVN
934.
For those of you that can reproduce the problem on their machine,
please let me know
if the problem has not disappeared.
/// Jürgen
O
Hi Peter et al,
I believe the proper way to fix this is to find the root cause of
it, not to find a compiler
under which the problem does not occur. I am currently following
Jays advice, but the
work on it is still ongoing.
// Jürgen
what is his processor?
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
On Wed, 26 Apr 2017 11:28:00 -0400
Peter Teeson wrote:
> Works OK on my Early 2009 Mac Pro running macOS 10.10.5 Yosemite and APL
> #svn927
>
> You have different HW but same OS & toolchain?
> So how about trying a differe
Works OK on my Early 2009 Mac Pro running macOS 10.10.5 Yosemite and APL #svn927
You have different HW but same OS & toolchain?
So how about trying a different toolchain to see if it is the compiler etc?
Or what about trying to disassemble the coded at the point of execution?
Could it be somethin
I see the wrong result on my machine, just like Fred. Jürgen, the problem
seems to be in this code:
// if ⎕CT != 0 and B ÷ A is close to an integer within ⎕CT then return 0.
//
// Note: In that case, the integer to which A ÷ B is close is either
// floor(A ÷ B) or ceil(A ÷ B).
//
co
To all,
I have 3 machines running 64-bit Fedora 25 Workstation with g++
(GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) and either gnu-apl svn version
889 or 933. Two of the machines are about 8 years old and one less
than a year old.
On all three platforms, gnu-apl gives:
3J1 |
Juergen,
I did a 'make clean' followed by 'make' and 'make install'. I
obtained the same result that caused me to report the problem.
The version of gnu-apl I'm using is svn rev 933. From the
banner in your email, I see you're testing with code from your personal
svn. Is it pos
Hi Fred,
actually it does on my machine:
__ _ __ __ __ ___ __
/ // | / // / / / / | / __ \ / /
/ / __ / |/ // / / / / /| | / /_/
Jeurgen,
A greatest common divisor of 23J1 and 25J25 is 3J1.
Complex division by of 23J1 and 25J25 by 3J1 yields Gaussian integers
23J1 25J25 ÷ 3J1
7J¯2 10J5
but mod 3J1 of the same numbers does not consistently yield zeroes
3J1 | 23J1 25J25
3J1 0
I can provide numerous other ex
28 matches
Mail list logo
