<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Jay et al,<br>
<br>
thanks for the analysis. I hope this problem is fixed in <b>SVN
934</b>.<br>
<br>
For those of you that can reproduce the problem on their machine,
please let me know<br>
if the problem has not disappeared.<br>
<br>
/// Jürgen<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 04/26/2017 10:19 AM, Jay Foad wrote:<br>
</div>
<blockquote
cite="mid:CANd1uZ=***@mail.gmail.com"
type="cite">
<div dir="ltr">I see the wrong result on my machine, just like
Fred. Jürgen, the problem seems to be in this code:
<div><br>
</div>
<div>
<div> // if ⎕CT != 0 and B ÷ A is close to an integer within
⎕CT then return 0.</div>
<div> //</div>
<div> // Note: In that case, the integer to which A ÷ B is
close is either</div> <div>� �// floor(A � B) or ceil(A � B).</div> <div>� �//</div> <div>const APL_Float qct = Workspace::get_CT();</div> <div>� �if (qct != 0)</div> <div>� � � {</div> <div>� � � � const APL_Complex quot = cval() / a;</div> <div>� � � � const APL_Float qfr = floor(quot.real());</div> <div>� � � � const APL_Float qfi = floor(quot.imag());</div> <div>� � � � const APL_Float qcr = ceil(quot.real());</div> <div>� � � � const APL_Float qci = ceil(quot.imag());</div> <div><br> </div> <div> if (quot.real() > (qcr - qct) &&
quot.imag() > (qci - qct)) </div>
<div> return IntCell::z0(Z); // quot is close to
its ceiling</div>
<div><br>
</div>
<div> if (quot.real() < (qfr - qct) &&
quot.imag() < (qfi - qct)) </div>
<div> return IntCell::z0(Z); // quot is close to
its floor</div>
<div> }</div>
</div>
<div><br>
</div>
<div>In this case quot is:</div>
<div><br>
</div>
<div>
<div>(gdb) p quot</div>
<div>$14 = {_M_value = 6.9999999999999991 +
-1.9999999999999998 * I}</div>
</div>
<div><br>
</div>
<div>... 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.</div>
<div><br>
</div>
<div>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/.</div>
<div><br>
</div>
<div>Jay.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 26 April 2017 at 06:44, Frederick
Pitts <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:***@comcast.net" target="_blank">***@comcast.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">To all,<br>
<br>
I have 3 machines running 64-bit Fedora 25
Workstation with g++<br>
(GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) and either gnu-apl
svn version<br>
889 or 933. Two of the machines are about 8 years old and
one less<br>
than a year old.<br>
<br>
On all three platforms, gnu-apl gives:<br>
<span class=""><br>
3J1 | 23J1 25J25<br>
3J1 0<br>
<br>
</span> Juergen and Xtian (on svn 933) report their
setups give the<br>
right answer:<br>
<br>
0 0<br>
<br>
Am I the only one seeing this problem? BTW, I have
about 1500<br>
more examples of the modulo operator failing out of 6765201
tests with<br>
distinct argument values.<br>
<br>
Regards,<br>
<br>
Fred<br>
<br>
<br>
On Tue, 2017-04-25 at 23:01 -0400, Christian Robert wrote:<br>
> Same result as Juergen,<br>
><br>
> Xtian.<br>
><br>
> [***@centos-7:/home/xtian] $ apl<br> <span class="">><br>
> ______ _ __
__ __ ___ ____ __<br>
> / ____// | / // / / / / | /
__ \ / /<br>
> / / __ / |/ // / / / / /| | /
/_/ // /<br>
> / /_/ // /| // /_/ / / ___ | /
____// /___<br>
> \____//_/ |_/
\____/ /_/ |_|/_/ /_____<wbr>/<br>
><br> </span>> Welcome to GNU APL version
1.7 / 933M<br> <span class="">><br>
> Copyright (C) 2008-2016 Dr. Jürgen
Sauermann<br>
> Banner by FIGlet: <a
moz-do-not-send="true" href="http://www.figlet.org"
rel="noreferrer" target="_blank">www.figlet.org</a><br>
><br>
> This program comes with ABSOLUTELY
NO WARRANTY;<br>
> for details run: apl
--gpl.<br>
><br>
> This program is free software, and you are
welcome to<br>
> redistribute it<br>
> according to the GNU Public License (GPL)
version 3 or<br>
> later.<br>
><br> </span>> SAVED 2017-03-30 22:33:13 (GMT-4)<br> <span class="im HOEnZb">> 23J1 25J25 ÷ 3J1<br>
> 7J¯2 10J5<br>
> 3J1 | 23J1 25J25<br>
> 0 0<br>
><br>
><br>
><br> </span> <div class="HOEnZb"> <div class="h5">> On 2017-04-25 21:50, Frederick Pitts
wrote:<br>
> > Juergen,<br>
> ><br>
> > I did a 'make clean' followed by
'make' and 'make<br>
> > install'. I<br>
> > obtained the same result that caused me to
report the problem.<br>
> ><br>
> > The version of gnu-apl I'm using is
svn rev 933. From the<br>
> > banner in your email, I see you're testing
with code from your<br>
> > personal<br>
> > svn. Is it possible the changes you recently
made to<br>
> > (ComplexCell.hh<br>
> > and FloatCell.hh) are not yet in the svn from
which I clone?<br>
> ><br>
> > Regards,<br>
> ><br>
> > Fred<br>
> ><br>
> > On Tue, 2017-04-25 at 22:05 +0200, Juergen
Sauermann wrote:<br>
> > > Hi Fred,<br>
> > > <br>
> > > actually it does on my machine:<br>
> > > <br>
> > > ______ _ __
__ __ ___ ____ __<br>
> > > / ____// | / // / /
/ / | / __ \ / /<br>
> > > / / __ / |/ // / /
/ / /| | / /_/ // /<br>
> > > / /_/ // /| // /_/
/ / ___ | / ____// /___<br>
> > > \____//_/ |_/
\____/ /_/ |_|/_/ /_____<wbr>/<br>
> > > <wbr> <br>
> > > Welcome to GNU APL
version 1.7 / 12784:12785M<br>
> > > <wbr> <br>
> > > Copyright (C)
2008-2016 Dr. Jürgen Sauermann<br>
> > > <wbr>Banner by
FIGlet: <a moz-do-not-send="true"
href="http://www.figlet.org" rel="noreferrer"
target="_blank">www.figlet.org</a><br>
> > > <wbr> <br>
> > > This program comes with
ABSOLUTELY NO WARRANTY;<br>
> > > <wbr>for
details run: apl --gpl.<br>
> > > <wbr> <br>
> > > This program is free software, and
you are welcome to<br>
> > > redistribute it<br>
> > > according to the GNU Public
License (GPL) version 3 or<br>
> > > later.<br>
> > > <wbr> <br>
> > > 23J1 25J25 ÷ 3J1<br>
> > > 7J¯2 10J5<br>
> > > <br>
> > > 3J1 | 23J1 25J25<br>
> > > 0 0<br>
> > > <br>
> > > <br>
> > > However, if I remember correctly then
some of the changes that I<br>
> > > made<br>
> > > lately were in<br>
> > > header files (ComplexCell.hh and
FloatCell.hh). If you did<br>
> > > ./configure without options, then<br>
> > > your build is probably is a 'fast' one,
which may not have<br>
> > > detected<br>
> > > header file changes.<br>
> > > <br>
> > > Please try make clean at the top level
and rebuild GNU APL to see<br>
> > > if<br>
> > > the problem persists.<br>
> > > <br>
> > > Best Regards,<br>
> > > Jürgen Sauermann<br>
> > > <br>
> > > <br>
> > > <br>
> > > On 04/25/2017 09:30 PM, Frederick Pitts
wrote:<br>
> > > > Jeurgen,<br>
> > > > <br>
> > > > A greatest common divisor of
23J1 and 25J25 is 3J1.<br>
> > > > Complex division by of 23J1 and
25J25 by 3J1 yields Gaussian<br>
> > > > integers<br>
> > > > <br>
> > > > 23J1 25J25 ÷ 3J1<br>
> > > > 7J¯2 10J5<br>
> > > > <br>
> > > > but mod 3J1 of the same numbers does
not consistently yield<br>
> > > > zeroes<br>
> > > > <br>
> > > > 3J1 | 23J1 25J25<br>
> > > > 3J1 0<br>
> > > > <br>
> > > > I can provide numerous other
examples of this problem if<br>
> > > > needed.<br>
> > > > <br>
> > > > Regards,<br>
> > > > <br>
> > > > Fred<br>
> > > > <br>
> > > > <br>
> > > > <br>
> > > > <br>
> > ><br>
> > > <br>
><br>
><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>