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).
//
const APL_Float qct = Workspace::get_CT();
if (qct != 0)
{
const APL_Complex quot = cval() / a;
const APL_Float qfr = floor(quot.real());
const APL_Float qfi = floor(quot.imag());
const APL_Float qcr = ceil(quot.real());
const APL_Float qci = ceil(quot.imag());
if (quot.real() > (qcr - qct) && quot.imag() > (qci - qct))
return IntCell::z0(Z); // quot is close to its ceiling
if (quot.real() < (qfr - qct) && quot.imag() < (qfi - qct))
return IntCell::z0(Z); // quot is close to its floor
}
In this case quot is:
(gdb) p quot
$14 = {_M_value = 6.9999999999999991 + -1.9999999999999998 * I}
... which is close to the Gaussian integer 7J¯2. But you only check for it
being close to 7J¯1 and 6J¯2, both of which tests fail.
As for why Fred and I see this problem and you don't: I guess on your
machine the expression cval() / a probably returns an exact (Gaussian)
integer result? If so, I guess it's down to some small change in the
compiler version, or glibc, or whatever provides the implementation of
std::complex<double>::operator/.
Jay.
On 26 April 2017 at 06:44, Frederick Pitts <fred.pi...@comcast.net> wrote:
> 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 | 23J1 25J25
> 3J1 0
>
> Juergen and Xtian (on svn 933) report their setups give the
> right answer:
>
> 0 0
>
> Am I the only one seeing this problem? BTW, I have about 1500
> more examples of the modulo operator failing out of 6765201 tests with
> distinct argument values.
>
> Regards,
>
> Fred
>
>
> On Tue, 2017-04-25 at 23:01 -0400, Christian Robert wrote:
> > Same result as Juergen,
> >
> > Xtian.
> >
> > [xtian@centos-7:/home/xtian] $ apl
> >
> > ______ _ __ __ __ ___ ____ __
> > / ____// | / // / / / / | / __ \ / /
> > / / __ / |/ // / / / / /| | / /_/ // /
> > / /_/ // /| // /_/ / / ___ | / ____// /___
> > \____//_/ |_/ \____/ /_/ |_|/_/ /_____/
> >
> > Welcome to GNU APL version 1.7 / 933M
> >
> > Copyright (C) 2008-2016 Dr. Jürgen Sauermann
> > Banner by FIGlet: www.figlet.org
> >
> > This program comes with ABSOLUTELY NO WARRANTY;
> > for details run: apl --gpl.
> >
> > This program is free software, and you are welcome to
> > redistribute it
> > according to the GNU Public License (GPL) version 3 or
> > later.
> >
> > SAVED 2017-03-30 22:33:13 (GMT-4)
> > 23J1 25J25 ÷ 3J1
> > 7J¯2 10J5
> > 3J1 | 23J1 25J25
> > 0 0
> >
> >
> >
> > On 2017-04-25 21:50, Frederick Pitts wrote:
> > > 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 possible the changes you recently made to
> > > (ComplexCell.hh
> > > and FloatCell.hh) are not yet in the svn from which I clone?
> > >
> > > Regards,
> > >
> > > Fred
> > >
> > > On Tue, 2017-04-25 at 22:05 +0200, Juergen Sauermann wrote:
> > > > Hi Fred,
> > > >
> > > > actually it does on my machine:
> > > >
> > > > ______ _ __ __ __ ___ ____ __
> > > > / ____// | / // / / / / | / __ \ / /
> > > > / / __ / |/ // / / / / /| | / /_/ // /
> > > > / /_/ // /| // /_/ / / ___ | / ____// /___
> > > > \____//_/ |_/ \____/ /_/ |_|/_/ /_____/
> > > >
> > > > Welcome to GNU APL version 1.7 / 12784:12785M
> > > >
> > > > Copyright (C) 2008-2016 Dr. Jürgen Sauermann
> > > > Banner by FIGlet: www.figlet.org
> > > >
> > > > This program comes with ABSOLUTELY NO WARRANTY;
> > > > for details run: apl --gpl.
> > > >
> > > > This program is free software, and you are welcome to
> > > > redistribute it
> > > > according to the GNU Public License (GPL) version 3 or
> > > > later.
> > > >
> > > > 23J1 25J25 ÷ 3J1
> > > > 7J¯2 10J5
> > > >
> > > > 3J1 | 23J1 25J25
> > > > 0 0
> > > >
> > > >
> > > > However, if I remember correctly then some of the changes that I
> > > > made
> > > > lately were in
> > > > header files (ComplexCell.hh and FloatCell.hh). If you did
> > > > ./configure without options, then
> > > > your build is probably is a 'fast' one, which may not have
> > > > detected
> > > > header file changes.
> > > >
> > > > Please try make clean at the top level and rebuild GNU APL to see
> > > > if
> > > > the problem persists.
> > > >
> > > > Best Regards,
> > > > Jürgen Sauermann
> > > >
> > > >
> > > >
> > > > On 04/25/2017 09:30 PM, Frederick Pitts wrote:
> > > > > 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 examples of this problem if
> > > > > needed.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Fred
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >
>
>
