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.99999999999999989J0.99999999999999989 to be 1J1, but according to the
standard (and hence GNU APL) it is 1. So A is not considered a near-integer
because it fails the (⌊-A)=-⌊A test.

I would humbly suggest ignoring the standard in this case and implementing
a more common sense definition of tolerant-floor. Note that in IBM APL2
(the demo version for Windows) I get:

      ⌊0.99999999999999989J0.99999999999999989
1J1

... so they don't seem to follow the ISO standard either.

Jay.

On 14 June 2017 at 18:05, Frederick Pitts <fred.pi...@comcast.net> wrote:

> Jürgen, Jay
>
>
> With svn 958, I'm see the following
>       a ← ¯1J11
>       b ← ¯12J10
>       a | b
> ¯11J¯1
>       b ÷ a
> 1J1
>       1J1 × a
> ¯12J10
>       a ← 1J¯11
>       b ← 12J¯10
>       a ∣ b
> 11J1
>       b ÷ a
> 1J1
>       1J1 × a
> 12J¯10
>
> So the error changed but persists on my platform.
>
> Regards,
>
> Fred
>
> On Wed, 2017-06-14 at 17:20 +0200, Juergen Sauermann wrote:
>
> 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 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);
> }
> //----------------------------------------------------------
> -------------------
>
> You're missing a minus sign before the second "tolerant_floor".
>
> Jay.
>
> On 14 June 2017 at 13:04, Juergen Sauermann <juergen.sauerm...@t-online.de
> > wrote:
>
> 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 Pitts wrote:
>
> 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
>       1J3 × 2J¯2
> 8J4
>
>       I'm running Fedora 25, 64 bit, on an Intel Core i7-6700 4 core
> CPU with 16 Gbyte memory.
>
>       The attached TGI0.apl generates many more failure examples if
> needed.
>
> Regards,
>
> Fred
>
>
>
>
>
>

Reply via email to