Re: [Bug-apl] Hang in Residue

[Jay Foad]

Thanks. At r1034 I get:

  A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
  A∘.|A
DOMAIN ERROR

And here's one of the cases that fails:

  1e¯200|1e200
DOMAIN ERROR

This still seems wrong to me, since the ISO standard for Residue says
"Implementations should avoid signalling limit-error in residue" with
advice on how to avoid it. (OK, it doesn't mention DOMAIN ERROR, but I
think the same principle applies.)

Jay.


On 6 January 2018 at 11:56, Juergen Sauermann  wrote:

> Hi,
>
> thanks, fixed in *SVN 1029*.
>
> /// Jürgen
>
>
> On 01/05/2018 04:37 PM, Jay Foad wrote:
>
> Yes, that expression hangs on my Linux box too. It gets stuck here:
>
> FloatCell::bif_residue (this=0x55ae13a8, Z=0x55ae24f8,
> A=0x55ae11d8) at FloatCell.cc:643
> 643  while (z < 0.0)z = z + a;
> (gdb) p z
> $1 = -inf
> (gdb) p a
> $2 = 9.9998e-201
>
> Jay.
>
> On 5 January 2018 at 15:24, Xiao-Yong Jin  wrote:
>
>> 1e¯200|1e200 hangs on my mac.
>>
>> > On Jan 5, 2018, at 6:57 AM, Juergen Sauermann <
>> juergen.sauerm...@t-online.de> wrote:
>> >
>> > Hi Jay,
>> >
>> > hmm, interesting. I am getting this:
>> >
>> >   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>> >   A∘.|A
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> > ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> >
>> > I suppose it is one of the A[i] ∣ A[j] which causes the hanging so it
>> would
>> > be interesting to know which one. Probably one with +/- 1E¯200 or
>> 1E¯100.
>> >
>> > Best Regards,
>> > /// Jürgen
>> >
>> >
>> > On 01/05/2018 12:16 PM, Jay Foad wrote:
>> >> At svn r1028 on Linux I get:
>> >>
>> >>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>> >>   A∘.|A
>> >> (hangs)
>> >>
>> >> Jay.
>> >
>>
>>
>
>

Re: [Bug-apl] Hang in Residue

[Juergen Sauermann]

  
  
Hi Jay,
  
  thanks, fixed in SVN 1035.
  
  BTW tryapl.com gives this:

  A←1E¯200 1E200  ¯1E¯200 ¯1E200

  A ∘.∣ A

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0

/// Jürgen
 

  TOn 01/08/2018 10:29 AM, Jay Foad wrote:

  Thanks. At r1034 I get:



        A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
        A∘.|A
  DOMAIN ERROR
  
  

And here's one of the cases that fails:



        1e¯200|1e200
  DOMAIN ERROR



This still seems wrong to me, since the ISO standard for
  Residue says "Implementations should avoid signalling
  limit-error in residue" with advice on how to avoid it. (OK,
  it doesn't mention DOMAIN ERROR, but I think the same
  principle applies.)


Jay.


  
  
On 6 January 2018 at 11:56, Juergen
  Sauermann 
  wrote:
  
 Hi,

thanks, fixed in SVN 1029.

/// Jürgen

  
  

  On
01/05/2018 04:37 PM, Jay Foad wrote:
  
  
Yes, that _expression_ hangs on my
  Linux box too. It gets stuck here:
  
  
  
FloatCell::bif_residue
  (this=0x55ae13a8, Z=0x55ae24f8, 
    A=0x55ae11d8) at FloatCell.cc:643
643              while (z < 0.0)    z =
  z + a;
(gdb) p z
$1 = -inf
(gdb) p a
$2 = 9.9998e-201
  
  
  
  Jay.


  On 5 January 2018 at
15:24, Xiao-Yong Jin 
wrote:
1e¯200|1e200 hangs on
  my mac.
  

  > On Jan 5, 2018, at 6:57 AM, Juergen
  Sauermann 
  wrote:
  >
  > Hi Jay,
  >
  > hmm, interesting. I am getting this:
  >
  >       A←(-⌽A),0,A←1e¯200 1e¯100 1
  1e100 1e200
  >       A∘.|A
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  > ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0
  1E¯200 1E¯100 1 1E100 1E200
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >  0E0    0E0    0  0E0     0E0    0
  0E0    0E0    0 0E0   0E0
  >
  > I suppose it is one of the A[i] ∣
  A[j] which causes the hanging so it would
  > be interesting to know which one.
  Probably one with +/- 1E¯200 or 1E¯100.
  >
  > Best Regards,
  > /// Jürgen
  >
  >
  > On 01/05/2018 12:16 PM, Jay Foad
  wrote:
  >> At svn r1028 on Linux I get:

Re: [Bug-apl] Hang in Residue

[Jay Foad]

Thanks. With r1035 I get:

  A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
  A∘.|A
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
¯1E200  0E00  0E0 0E00 0E00E00 0E0   0E0
¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0
 0E00E00  0E0 0E00 0E00E00 0E0   0E0

One result stands out:

  ¯1E¯200|¯1E200
¯1E200

The result of A|B (with A non-zero) should be strictly smaller in magnitude
than A, so this seems very wrong.

Jay.


On 8 January 2018 at 11:49, Juergen Sauermann  wrote:

> Hi Jay,
>
> thanks, fixed in *SVN 1035*.
>
> BTW tryapl.com gives this:
>
> *  A←1E¯200 1E200  ¯1E¯200 ¯1E200*
>
> *  A ∘.∣ A*
>
> *0 0 0 0
> 0 0 0 0
> 0 0 0 0
> 0 0 0 0*
> /// Jürgen
>
>
>
> TOn 01/08/2018 10:29 AM, Jay Foad wrote:
>
> Thanks. At r1034 I get:
>
>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>   A∘.|A
> DOMAIN ERROR
>
> And here's one of the cases that fails:
>
>   1e¯200|1e200
> DOMAIN ERROR
>
> This still seems wrong to me, since the ISO standard for Residue says
> "Implementations should avoid signalling limit-error in residue" with
> advice on how to avoid it. (OK, it doesn't mention DOMAIN ERROR, but I
> think the same principle applies.)
>
> Jay.
>
>
> On 6 January 2018 at 11:56, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
>
>> Hi,
>>
>> thanks, fixed in *SVN 1029*.
>>
>> /// Jürgen
>>
>>
>> On 01/05/2018 04:37 PM, Jay Foad wrote:
>>
>> Yes, that expression hangs on my Linux box too. It gets stuck here:
>>
>> FloatCell::bif_residue (this=0x55ae13a8, Z=0x55ae24f8,
>> A=0x55ae11d8) at FloatCell.cc:643
>> 643  while (z < 0.0)z = z + a;
>> (gdb) p z
>> $1 = -inf
>> (gdb) p a
>> $2 = 9.9998e-201
>>
>> Jay.
>>
>> On 5 January 2018 at 15:24, Xiao-Yong Jin  wrote:
>>
>>> 1e¯200|1e200 hangs on my mac.
>>>
>>> > On Jan 5, 2018, at 6:57 AM, Juergen Sauermann <
>>> juergen.sauerm...@t-online.de> wrote:
>>> >
>>> > Hi Jay,
>>> >
>>> > hmm, interesting. I am getting this:
>>> >
>>> >   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>> >   A∘.|A
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> > ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>> >
>>> > I suppose it is one of the A[i] ∣ A[j] which causes the hanging so it
>>> would
>>> > be interesting to know which one. Probably one with +/- 1E¯200 or
>>> 1E¯100.
>>> >
>>> > Best Regards,
>>> > /// Jürgen
>>> >
>>> >
>>> > On 01/05/2018 12:16 PM, Jay Foad wrote:
>>> >> At svn r1028 on Linux I get:
>>> >>
>>> >>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>> >>   A∘.|A
>>> >> (hangs)
>>> >>
>>> >> Jay.
>>> >
>>>
>>>
>>
>>
>
>

Re: [Bug-apl] Hang in Residue

[Juergen Sauermann]

  
  
Hi Jay,
  
  maybe SVN 1036 works better.
  
  /// Jürgen
  

On 01/08/2018 01:02 PM, Jay Foad wrote:


  Thanks. With r1035 I get:



        A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
        A∘.|A
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
  ¯1E200  0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
  ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100
1E200
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0
   0E0    0E0    0  0E0     0E0    0 0E0    0E0    0 0E0  
0E0



One result stands out:



        ¯1E¯200|¯1E200
  ¯1E200



The result of A|B (with A non-zero) should be strictly
  smaller in magnitude than A, so this seems very wrong.


Jay.


  
  
On 8 January 2018 at 11:49, Juergen
  Sauermann 
  wrote:
  
 Hi Jay,

thanks, fixed in SVN 1035.

BTW tryapl.com gives this:
  
A←1E¯200 1E200  ¯1E¯200 ¯1E200

A ∘.∣ A

  0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0

/// Jürgen
 
  
 
TOn 01/08/2018 10:29 AM, Jay Foad wrote:
  
Thanks. At r1034 I get:
  
  
  
      A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100
  1e200
      A∘.|A
DOMAIN ERROR


  
  And here's one of the cases that fails:
  
  
  
      1e¯200|1e200
DOMAIN ERROR
  
  
  
  This still seems wrong to me, since the ISO
standard for Residue says "Implementations
should avoid signalling limit-error in residue"
with advice on how to avoid it. (OK, it doesn't
mention DOMAIN ERROR, but I think the same
principle applies.)
  
  
  Jay.
  
  


  On 6 January 2018 at
11:56, Juergen Sauermann 
wrote:

   Hi,
  
  thanks, fixed in SVN 1029.
  
  /// Jürgen
  


  
On
  01/05/2018 04:37 PM, Jay Foad wrote:


  Yes, that _expression_
hangs on my Linux box too. It gets
stuck here:



  FloatCell::bif_residue
(this=0x55ae13a8,
Z=0x55ae24f8, 
      A=0x55ae11d8) at
FloatCell.cc:643
  643              while (z
< 0.0)    z = z + a;
  (gdb) p z
  $1 = -inf
  (gdb) p a
  $2 = 9.9998e-201

Re: [Bug-apl] Hang in Residue

[Jay Foad]

Yes, thanks! Now, when ⎕CT=0 there are some odd results:

  ⎕CT←0
  A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
  A∘.|A
 0E0   ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 0E00E0¯1E200 0E0   0E0
 0E00E0   ¯1E0   ¯1E¯100 ¯1E¯200 0 0E00E0¯1E100 0E0   0E0
 0E00E00E0   ¯1E¯100 ¯1E¯200 0 0E00E0 0E0   0E0   0E0
 0E00E00E00E0¯1E¯200 0 0E00E0 0E0   0E0   0E0
 0E00E00E00E0 0E00 0E00E0 0E0   0E0   0E0
¯1E200 ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100  1E0   1E100 1E200
 0E00E00E00E0 0E00 0E00E0 0E0   0E0   0E0
 0E00E00E00E0 0E00 1E¯200 0E0 0E0   0E0   0E0
 0E00E00E00E0 0E00 1E¯200 1E¯100  0E0   0E0   0E0
 0E00E01E100  0E0 0E00 1E¯200 1E¯100  1E0   0E0   0E0
 0E00E01E200  0E0 0E00 1E¯200 1E¯100  1E0   1E100 0E0
  1e200|¯1
1E200

The standard explicitly says that the result should never be the same as
the (non-zero) left argument: "If Z is A , return zero."

Jay.

On 8 January 2018 at 12:26, Juergen Sauermann  wrote:

> Hi Jay,
>
> maybe *SVN 1036* works better.
>
> /// Jürgen
>
>
> On 01/08/2018 01:02 PM, Jay Foad wrote:
>
> Thanks. With r1035 I get:
>
>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>   A∘.|A
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
> ¯1E200  0E00  0E0 0E00 0E00E00 0E0   0E0
> ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>
> One result stands out:
>
>   ¯1E¯200|¯1E200
> ¯1E200
>
> The result of A|B (with A non-zero) should be strictly smaller in
> magnitude than A, so this seems very wrong.
>
> Jay.
>
>
> On 8 January 2018 at 11:49, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
>
>> Hi Jay,
>>
>> thanks, fixed in *SVN 1035*.
>>
>> BTW tryapl.com gives this:
>>
>> *  A←1E¯200 1E200  ¯1E¯200 ¯1E200*
>>
>> *  A ∘.∣ A*
>>
>> *0 0 0 0
>> 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0*
>> /// Jürgen
>>
>>
>>
>> TOn 01/08/2018 10:29 AM, Jay Foad wrote:
>>
>> Thanks. At r1034 I get:
>>
>>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>   A∘.|A
>> DOMAIN ERROR
>>
>> And here's one of the cases that fails:
>>
>>   1e¯200|1e200
>> DOMAIN ERROR
>>
>> This still seems wrong to me, since the ISO standard for Residue says
>> "Implementations should avoid signalling limit-error in residue" with
>> advice on how to avoid it. (OK, it doesn't mention DOMAIN ERROR, but I
>> think the same principle applies.)
>>
>> Jay.
>>
>>
>> On 6 January 2018 at 11:56, Juergen Sauermann <
>> juergen.sauerm...@t-online.de> wrote:
>>
>>> Hi,
>>>
>>> thanks, fixed in *SVN 1029*.
>>>
>>> /// Jürgen
>>>
>>>
>>> On 01/05/2018 04:37 PM, Jay Foad wrote:
>>>
>>> Yes, that expression hangs on my Linux box too. It gets stuck here:
>>>
>>> FloatCell::bif_residue (this=0x55ae13a8, Z=0x55ae24f8,
>>> A=0x55ae11d8) at FloatCell.cc:643
>>> 643  while (z < 0.0)z = z + a;
>>> (gdb) p z
>>> $1 = -inf
>>> (gdb) p a
>>> $2 = 9.9998e-201
>>>
>>> Jay.
>>>
>>> On 5 January 2018 at 15:24, Xiao-Yong Jin  wrote:
>>>
 1e¯200|1e200 hangs on my mac.

 > On Jan 5, 2018, at 6:57 AM, Juergen Sauermann <
 juergen.sauerm...@t-online.de> wrote:
 >
 > Hi Jay,
 >
 > hmm, interesting. I am getting this:
 >
 >   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
 >   A∘.|A
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 > ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 >
 > I suppose it is one of the A[i] ∣ A[j] which causes the hanging so it
 would
 > be interesting to know which one. Probably one with +/- 1E¯200 or
 1E¯100.
 >
 > Best Regards,
 > /// Jürgen
 >
 >
 > On 01/05/2018 12:16 PM, Jay Foad wrote:
 >> At svn r1028 on Linux I get

Re: [Bug-apl] Hang in Residue

[Juergen Sauermann]

  
  
Hi Jay,
  
  I am still puzzled by the ISO description (and can't find the
  "IEEE standard for Binary Floating-Point Arithmetic (754)"
  referenced in the standard.
  
  Would you be able to provide the expected expected output of your
  example below?
  
  If I follow the ISO description of mod in the ISO APL standard
  word by word then I am getting pretty odd values at times.
  
  Best Regards,
  /// Jürgen
  

On 01/08/2018 02:19 PM, Jay Foad wrote:


  Yes, thanks! Now, when ⎕CT=0 there are some odd
results:



        ⎕CT←0
        A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
        A∘.|A
   0E0   ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 0E0    0E0  
 ¯1E200 0E0   0E0
   0E0    0E0   ¯1E0   ¯1E¯100 ¯1E¯200 0 0E0    0E0  
 ¯1E100 0E0   0E0
   0E0    0E0    0E0   ¯1E¯100 ¯1E¯200 0 0E0    0E0     0E0
  0E0   0E0
   0E0    0E0    0E0    0E0    ¯1E¯200 0 0E0    0E0     0E0
  0E0   0E0
   0E0    0E0    0E0    0E0     0E0    0 0E0    0E0     0E0
  0E0   0E0
  ¯1E200 ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100  1E0
  1E100 1E200
   0E0    0E0    0E0    0E0     0E0    0 0E0    0E0     0E0
  0E0   0E0
   0E0    0E0    0E0    0E0     0E0    0 1E¯200 0E0     0E0
  0E0   0E0
   0E0    0E0    0E0    0E0     0E0    0 1E¯200 1E¯100  0E0
  0E0   0E0
   0E0    0E0    1E100  0E0     0E0    0 1E¯200 1E¯100  1E0
  0E0   0E0
   0E0    0E0    1E200  0E0     0E0    0 1E¯200 1E¯100  1E0
  1E100 0E0


        1e200|¯1
  1E200



The standard explicitly says that the result should never
  be the same as the (non-zero) left argument: "If Z is A ,
  return zero."


Jay.
  
  
On 8 January 2018 at 12:26, Juergen
  Sauermann 
  wrote:
  
 Hi Jay,

maybe SVN 1036 works better.

/// Jürgen

  
  

  On
01/08/2018 01:02 PM, Jay Foad wrote:
  
  
Thanks. With r1035 I get:
  
  
  
      A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100
  1e200
      A∘.|A
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
¯1E200  0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200
  1E¯100 1 1E100 1E200
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
 0E0    0E0    0  0E0     0E0    0 0E0  
   0E0    0 0E0   0E0
  
  
  
  One result stands out:
  
  
  
      ¯1E¯200|¯1E200
¯1E200
  
  
  
  The result of A|B (with A non-zero) should be
strictly smaller in magnitude than A, so this
seems very wrong.
  
  
  Jay.
  
  


  On 8 January 2018 at
11:49, Juergen Sauermann 
wrote:

   Hi
  Jay,
  
  thanks, fixed in SVN 1035.
  

Re: [Bug-apl] Hang in Residue

[Elias Mårtenson]

I can't easily find the document online without having to pay for it, but
doesn't the Wikipedia page contain all the information you need?
https://en.m.wikipedia.org/wiki/IEEE_754

On 9 Jan 2018 12:14 am, "Juergen Sauermann" 
wrote:

> Hi Jay,
>
> I am still puzzled by the ISO description (and can't find the "IEEE
> standard for Binary Floating-Point Arithmetic (754)"
> referenced in the standard.
>
> Would you be able to provide the expected expected output of your example
> below?
>
> If I follow the ISO description of mod in the ISO APL standard word by
> word then I am getting pretty odd values at times.
>
> Best Regards,
> /// Jürgen
>
>
> On 01/08/2018 02:19 PM, Jay Foad wrote:
>
> Yes, thanks! Now, when ⎕CT=0 there are some odd results:
>
>   ⎕CT←0
>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>   A∘.|A
>  0E0   ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 0E00E0¯1E200 0E0   0E0
>  0E00E0   ¯1E0   ¯1E¯100 ¯1E¯200 0 0E00E0¯1E100 0E0   0E0
>  0E00E00E0   ¯1E¯100 ¯1E¯200 0 0E00E0 0E0   0E0   0E0
>  0E00E00E00E0¯1E¯200 0 0E00E0 0E0   0E0   0E0
>  0E00E00E00E0 0E00 0E00E0 0E0   0E0   0E0
> ¯1E200 ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100  1E0   1E100 1E200
>  0E00E00E00E0 0E00 0E00E0 0E0   0E0   0E0
>  0E00E00E00E0 0E00 1E¯200 0E0 0E0   0E0   0E0
>  0E00E00E00E0 0E00 1E¯200 1E¯100  0E0   0E0   0E0
>  0E00E01E100  0E0 0E00 1E¯200 1E¯100  1E0   0E0   0E0
>  0E00E01E200  0E0 0E00 1E¯200 1E¯100  1E0   1E100 0E0
>   1e200|¯1
> 1E200
>
> The standard explicitly says that the result should never be the same as
> the (non-zero) left argument: "If Z is A , return zero."
>
> Jay.
>
> On 8 January 2018 at 12:26, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
>
>> Hi Jay,
>>
>> maybe *SVN 1036* works better.
>>
>> /// Jürgen
>>
>>
>> On 01/08/2018 01:02 PM, Jay Foad wrote:
>>
>> Thanks. With r1035 I get:
>>
>>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>   A∘.|A
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>> ¯1E200  0E00  0E0 0E00 0E00E00 0E0   0E0
>> ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>  0E00E00  0E0 0E00 0E00E00 0E0   0E0
>>
>> One result stands out:
>>
>>   ¯1E¯200|¯1E200
>> ¯1E200
>>
>> The result of A|B (with A non-zero) should be strictly smaller in
>> magnitude than A, so this seems very wrong.
>>
>> Jay.
>>
>>
>> On 8 January 2018 at 11:49, Juergen Sauermann <
>> juergen.sauerm...@t-online.de> wrote:
>>
>>> Hi Jay,
>>>
>>> thanks, fixed in *SVN 1035*.
>>>
>>> BTW tryapl.com gives this:
>>>
>>> *  A←1E¯200 1E200  ¯1E¯200 ¯1E200*
>>>
>>> *  A ∘.∣ A*
>>>
>>> *0 0 0 0
>>> 0 0 0 0
>>> 0 0 0 0
>>> 0 0 0 0*
>>> /// Jürgen
>>>
>>>
>>>
>>> TOn 01/08/2018 10:29 AM, Jay Foad wrote:
>>>
>>> Thanks. At r1034 I get:
>>>
>>>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>   A∘.|A
>>> DOMAIN ERROR
>>>
>>> And here's one of the cases that fails:
>>>
>>>   1e¯200|1e200
>>> DOMAIN ERROR
>>>
>>> This still seems wrong to me, since the ISO standard for Residue says
>>> "Implementations should avoid signalling limit-error in residue" with
>>> advice on how to avoid it. (OK, it doesn't mention DOMAIN ERROR, but I
>>> think the same principle applies.)
>>>
>>> Jay.
>>>
>>>
>>> On 6 January 2018 at 11:56, Juergen Sauermann <
>>> juergen.sauerm...@t-online.de> wrote:
>>>
 Hi,

 thanks, fixed in *SVN 1029*.

 /// Jürgen


 On 01/05/2018 04:37 PM, Jay Foad wrote:

 Yes, that expression hangs on my Linux box too. It gets stuck here:

 FloatCell::bif_residue (this=0x55ae13a8, Z=0x55ae24f8,
 A=0x55ae11d8) at FloatCell.cc:643
 643  while (z < 0.0)z = z + a;
 (gdb) p z
 $1 = -inf
 (gdb) p a
 $2 = 9.9998e-201

 Jay.

 On 5 January 2018 at 15:24, Xiao-Yong Jin 
 wrote:

> 1e¯200|1e200 hangs on my mac.
>
> > On Jan 5, 2018, at 6:57 AM, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
> >
> > Hi Jay,
> >
> > hmm, interesting. I am getting this:
> >
> >   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
> >   A∘.|A
> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
> >  0E00E00  0E0 0E00 0E00E00 0E0   0E0
> >  0E00E00  0E0 0E0  

Re: [Bug-apl] Hang in Residue

[Juergen Sauermann]

  
  
Hi Elias,
  
  the ISO APL standard says:
  
  "Note: The implementation-algorithm P modulo Q provides an
exact modulo operation for realnumbers
  P and Q. It evaluates R←B-(×B)×|A×⌊|B÷A and return
R if (×A)=×B or R+A otherwise.
  The definition of “mod” in the IEEE standard for Binary
Floating-Point Arithmetic (754) provides
  an example of this exact evaluation."
  
  If I do the same computation then for some arguments I am getting
  strange results, probably caused by
  rounding errors. The only non-trivial function in the computation
  is above is floor(). Some of the numbers
  in Jay's example (e.g. 1E200) are notexact in a 64 bit float so
  that may as well be the cause of the problems.
  
  I anyhow wonder what can be expected from, say, 1E200 modulo 9 if there are many numbers around 1E200 that all
have the same floating point representation. Maybe the old
way of throwing a DOMAIN ERROR when the result
becomes obscure wasn't that bad, despite of what the ISO
standard asks for.

Best Regards,
/// Jürgen


  
On 01/08/2018 10:17 PM, Elias Mårtenson
  wrote:


  I can't easily find the document online without
having to pay for it, but doesn't the Wikipedia page contain all
the information you need? https://en.m.wikipedia.org/wiki/IEEE_754
  
On 9 Jan 2018 12:14 am, "Juergen
  Sauermann" 
  wrote:
  
 Hi Jay,

I am still puzzled by the ISO description (and can't
find the "IEEE standard for Binary Floating-Point
Arithmetic (754)"
referenced in the standard.

Would you be able to provide the expected expected
output of your example below?

If I follow the ISO description of mod in the ISO APL
standard word by word then I am getting pretty odd
values at times.

Best Regards,
/// Jürgen

  
  On
01/08/2018 02:19 PM, Jay Foad wrote:
  
  
Yes, thanks! Now, when ⎕CT=0 there are
  some odd results:
  
  
  
      ⎕CT←0
      A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
      A∘.|A
 0E0   ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 0E0  
   0E0    ¯1E200 0E0   0E0
 0E0    0E0   ¯1E0   ¯1E¯100 ¯1E¯200 0 0E0  
   0E0    ¯1E100 0E0   0E0
 0E0    0E0    0E0   ¯1E¯100 ¯1E¯200 0 0E0  
   0E0     0E0   0E0   0E0
 0E0    0E0    0E0    0E0    ¯1E¯200 0 0E0  
   0E0     0E0   0E0   0E0
 0E0    0E0    0E0    0E0     0E0    0 0E0  
   0E0     0E0   0E0   0E0
¯1E200 ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 1E¯200
  1E¯100  1E0   1E100 1E200
 0E0    0E0    0E0    0E0     0E0    0 0E0  
   0E0     0E0   0E0   0E0
 0E0    0E0    0E0    0E0     0E0    0 1E¯200
  0E0     0E0   0E0   0E0
 0E0    0E0    0E0    0E0     0E0    0 1E¯200
  1E¯100  0E0   0E0   0E0
 0E0    0E0    1E100  0E0     0E0    0 1E¯200
  1E¯100  1E0   0E0   0E0
 0E0    0E0    1E200  0E0     0E0    0 1E¯200
  1E¯100  1E0   1E100 0E0
  
  
      1e200|¯1
1E200
  
  
  
  The standard explicitly says that the result
should never be the same as the (non-zero) left
argument: "If Z is A , return zero."
  
  
  Jay.


  On 8 January 2018 at 12:26,
Juergen Sauermann 
wrote:

   Hi Jay,
  
  maybe SVN 1036 works better.
  
  /// Jürgen
  


  
On
  01/08/2018 01:02 PM, Jay Foad wrote:

Re: [Bug-apl] Hang in Residue

[Alexey Veretennikov]

Hi,

Probably this could be of help:
http://www.softelectro.ru/ieee754_en.html


Elias Mårtenson  writes:

> I can't easily find the document online without having to pay for it, but 
> doesn't the Wikipedia
> page contain all the information you need? 
> https://en.m.wikipedia.org/wiki/IEEE_754
>
> On 9 Jan 2018 12:14 am, "Juergen Sauermann"  
> wrote:
>
>  Hi Jay,
>
>  I am still puzzled by the ISO description (and can't find the "IEEE standard 
> for Binary
>  Floating-Point Arithmetic (754)"
>  referenced in the standard.
>
>  Would you be able to provide the expected expected output of your example 
> below?
>
>  If I follow the ISO description of mod in the ISO APL standard word by word 
> then I am
>  getting pretty odd values at times.
>
>  Best Regards,
>  /// Jürgen
>
>  On 01/08/2018 02:19 PM, Jay Foad wrote:
>
>  Yes, thanks! Now, when ⎕CT=0 there are some odd results: 
>
>  ⎕CT←0
>  A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>  A∘.|A
>  0E0 ¯1E100 ¯1E0 ¯1E¯100 ¯1E¯200 0 0E0 0E0 ¯1E200 0E0 0E0
>  0E0 0E0 ¯1E0 ¯1E¯100 ¯1E¯200 0 0E0 0E0 ¯1E100 0E0 0E0
>  0E0 0E0 0E0 ¯1E¯100 ¯1E¯200 0 0E0 0E0 0E0 0E0 0E0
>  0E0 0E0 0E0 0E0 ¯1E¯200 0 0E0 0E0 0E0 0E0 0E0
>  0E0 0E0 0E0 0E0 0E0 0 0E0 0E0 0E0 0E0 0E0
>  ¯1E200 ¯1E100 ¯1E0 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1E0 1E100 1E200
>  0E0 0E0 0E0 0E0 0E0 0 0E0 0E0 0E0 0E0 0E0
>  0E0 0E0 0E0 0E0 0E0 0 1E¯200 0E0 0E0 0E0 0E0
>  0E0 0E0 0E0 0E0 0E0 0 1E¯200 1E¯100 0E0 0E0 0E0
>  0E0 0E0 1E100 0E0 0E0 0 1E¯200 1E¯100 1E0 0E0 0E0
>  0E0 0E0 1E200 0E0 0E0 0 1E¯200 1E¯100 1E0 1E100 0E0
>  1e200|¯1
>  1E200
>
>  The standard explicitly says that the result should never be the same as the
>  (non-zero) left argument: "If Z is A , return zero."
>
>  Jay.
>
>  On 8 January 2018 at 12:26, Juergen Sauermann 
>  wrote:
>
>  Hi Jay,
>
>  maybe SVN 1036 works better.
>
>  /// Jürgen
>
>  On 01/08/2018 01:02 PM, Jay Foad wrote:
>
>  Thanks. With r1035 I get: 
>
>  A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>  A∘.|A
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  ¯1E200 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>
>  One result stands out:
>
>  ¯1E¯200|¯1E200
>  ¯1E200
>
>  The result of A|B (with A non-zero) should be strictly smaller in magnitude
>  than A, so this seems very wrong.
>
>  Jay.
>
>  On 8 January 2018 at 11:49, Juergen Sauermann
>   wrote:
>
>  Hi Jay,
>
>  thanks, fixed in SVN 1035.
>
>  BTW tryapl.com gives this:
>
>   A←1E¯200 1E200  ¯1E¯200 ¯1E200
>   A ∘.∣ A
> 0 0 0 0
> 0 0 0 0
> 0 0 0 0
> 0 0 0 0
>
> /// Jürgen
>  
>
>  TOn 01/08/2018 10:29 AM, Jay Foad wrote:
>
>  Thanks. At r1034 I get: 
>
>  A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>  A∘.|A
>  DOMAIN ERROR
>
>  And here's one of the cases that fails:
>
>  1e¯200|1e200
>  DOMAIN ERROR
>
>  This still seems wrong to me, since the ISO standard for Residue
>  says "Implementations should avoid signalling limit-error in
>  residue" with advice on how to avoid it. (OK, it doesn't mention
>  DOMAIN ERROR, but I think the same principle applies.)
>
>  Jay.
>
>  On 6 January 2018 at 11:56, Juergen Sauermann
>   wrote:
>
>  Hi,
>
>  thanks, fixed in SVN 1029.
>
>  /// Jürgen
>
>  On 01/05/2018 04:37 PM, Jay Foad wrote:
>
>  Yes, that expression hangs on my Linux box too. It gets
>  stuck here: 
>
>  FloatCell::bif_residue (this=0x55ae13a8,
>  Z=0x55ae24f8, 
>  A=0x55ae11d8) at FloatCell.cc:643
>  643 while (z < 0.0) z = z + a;
>  (gdb) p z
>  $1 = -inf
>  (gdb) p a
>  $2 = 9.9998e-201
>
>  Jay.
>
>  On 5 January 2018 at 15:24, Xiao-Yong Jin
>   wrote:
>
>  1e¯200|1e200 hangs on my mac.
>
>  > On Jan 5, 2018, at 6:57 AM, Juergen
>  Sauermann 
>  wrote:
>  >
>  > Hi Jay,
>  >
>  > hmm, interesting. I am getting this:
>  >
>  > A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>  > A∘.|A
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200
>  1E¯100 1 1E100 1E200
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  > 0E0 0E0 0 0E0 0E0 0 0E0 0E0 0 0E0 0E0
>  >
>  > I suppose it is one of the A[i] ∣ A[j] which causes
>  the hanging so it would
>  > be interesting to know which one. Probably one
>  with +/- 1E¯200 or 1E¯100.
>  >
>  > Best Regards,
>  > /// Jürgen
>  >
>  >
>  > On 01/05/2018 12:16 PM, Jay Foad wrote:
>  >> At svn r1028 on Linux I get:
>  >>
>  >> A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>  >> 

Re: [Bug-apl] Hang in Residue

[Xiao-Yong Jin]

It's a waste of time to make modulo exact for inexact floating point numbers.  
People should expect round off errors in those cases.  Until GNU APL have 
multi-precision numbers, it is pointless to make modulo exact for inexact 
numbers.

Asking for exact result with something like

  (1E200+⍳10)|¯1

seems useless.

> On Jan 8, 2018, at 3:49 PM, Juergen Sauermann  
> wrote:
> 
> Hi Elias,
> 
> the ISO APL standard says:
> 
> "Note: The implementation-algorithm P modulo Q provides an exact modulo 
> operation for realnumbers
> P and Q. It evaluates R←B-(×B)×|A×⌊|B÷A and return R if (×A)=×B or R+A 
> otherwise.
> The definition of “mod” in the IEEE standard for Binary Floating-Point 
> Arithmetic (754) provides
> an example of this exact evaluation."
> 
> If I do the same computation then for some arguments I am getting strange 
> results, probably caused by
> rounding errors. The only non-trivial function in the computation is above is 
> floor(). Some of the numbers
> in Jay's example (e.g. 1E200) are notexact in a 64 bit float so that may as 
> well be the cause of the problems.
> 
> I anyhow wonder what can be expected from, say, 1E200 modulo 9 if there are 
> many numbers around 1E200 that all
> have the same floating point representation. Maybe the old way of throwing a 
> DOMAIN ERROR when the result
> becomes obscure wasn't that bad, despite of what the ISO standard asks for.
> 
> Best Regards,
> /// Jürgen
> 
> 
> On 01/08/2018 10:17 PM, Elias Mårtenson wrote:
>> I can't easily find the document online without having to pay for it, but 
>> doesn't the Wikipedia page contain all the information you need? 
>> https://en.m.wikipedia.org/wiki/IEEE_754
>> 
>> On 9 Jan 2018 12:14 am, "Juergen Sauermann"  
>> wrote:
>> Hi Jay,
>> 
>> I am still puzzled by the ISO description (and can't find the "IEEE standard 
>> for Binary Floating-Point Arithmetic (754)"
>> referenced in the standard.
>> 
>> Would you be able to provide the expected expected output of your example 
>> below?
>> 
>> If I follow the ISO description of mod in the ISO APL standard word by word 
>> then I am getting pretty odd values at times.
>> 
>> Best Regards,
>> /// Jürgen
>> 
>> 
>> On 01/08/2018 02:19 PM, Jay Foad wrote:
>>> Yes, thanks! Now, when ⎕CT=0 there are some odd results:
>>> 
>>>   ⎕CT←0
>>>   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
>>>   A∘.|A
>>>  0E0   ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 0E00E0¯1E200 0E0   0E0
>>>  0E00E0   ¯1E0   ¯1E¯100 ¯1E¯200 0 0E00E0¯1E100 0E0   0E0
>>>  0E00E00E0   ¯1E¯100 ¯1E¯200 0 0E00E0 0E0   0E0   0E0
>>>  0E00E00E00E0¯1E¯200 0 0E00E0 0E0   0E0   0E0
>>>  0E00E00E00E0 0E00 0E00E0 0E0   0E0   0E0
>>> ¯1E200 ¯1E100 ¯1E0   ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100  1E0   1E100 1E200
>>>  0E00E00E00E0 0E00 0E00E0 0E0   0E0   0E0
>>>  0E00E00E00E0 0E00 1E¯200 0E0 0E0   0E0   0E0
>>>  0E00E00E00E0 0E00 1E¯200 1E¯100  0E0   0E0   0E0
>>>  0E00E01E100  0E0 0E00 1E¯200 1E¯100  1E0   0E0   0E0
>>>  0E00E01E200  0E0 0E00 1E¯200 1E¯100  1E0   1E100 0E0
>>>   1e200|¯1
>>> 1E200
>>> 
>>> The standard explicitly says that the result should never be the same as 
>>> the (non-zero) left argument: "If Z is A , return zero."
>>> 
>>> Jay.
>>> 
>>> On 8 January 2018 at 12:26, Juergen Sauermann 
>>>  wrote:
>>> Hi Jay,
>>> 
>>> maybe SVN 1036 works better.
>>> 
>>> /// Jürgen
>>> 
>>> 
>>> On 01/08/2018 01:02 PM, Jay Foad wrote:
 Thanks. With r1035 I get:
 
   A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
   A∘.|A
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 ¯1E200  0E00  0E0 0E00 0E00E00 0E0   0E0
 ¯1E200 ¯1E100 ¯1 ¯1E¯100 ¯1E¯200 0 1E¯200 1E¯100 1 1E100 1E200
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
  0E00E00  0E0 0E00 0E00E00 0E0   0E0
 
 One result stands out:
 
   ¯1E¯200|¯1E200
 ¯1E200
 
 The result of A|B (with A non-zero) should be strictly smaller in 
 magnitude than A, so this seems very wrong.
 
 Jay.
 
 
 On 8 January 2018 at 11:49, Juergen Sauermann 
  wrote:
 Hi Jay,
 
 thanks, fixed in SVN 1035.
 
 BTW tryapl.com gives this:
 
   A←1E¯200 1E200  ¯1E¯200 ¯1E200
   A ∘.∣ A
 0 0 0 0
 0 0 0 0
 0 0 0 0
 0 0 0 0
 
 
 /// Jürgen
  
 
 
 TOn 01/08/2018 10:29 AM, Jay