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 <jay.f...@gmail.com> wrote:

> I get:
>
>       ¯1J11 | ¯12J10
> computing (-12,10) modulo (-1,11)
> ⎕CT is: 1e-13
> the quotient B ÷ A is: (0.9999999999999999,0.9999999999999999)
> the quotient rounded down is: (1,0)
> ¯11J¯1
>
> On 15 June 2017 at 13:47, Juergen Sauermann <juergen.sauerm...@t-online.de
> > wrote:
>
>> 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 version is *SVN 961*.
>>
>> If it still does not work then attached is a more verbose variant of the
>> *bif_residue()*
>> implementation that prints the intermediate results of the computation
>> (so that we can
>> nail down where things go wrong).
>>
>> On my machine I get, for example,  this:
>>
>> *      a ← ¯1J11*
>> *      b ← ¯12J10*
>> *      a | b*
>> *computing (-12,10) modulo (-1,11)*
>> *⎕CT is: 1e-13*
>> *the quotient B ÷ A is: (1,1)*
>> *result is 0 because the quotient is integral within ⎕CT*
>> *0*
>>
>> Just replace your *ComplexCell.cc* with the attached one.
>>
>> Thanks,
>> Jürgen
>>
>>
>> On 06/15/2017 10:38 AM, Jay Foad wrote:
>>
>> 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