Re: [Bug-apl] Hang in Residue

Juergen Sauermann Mon, 08 Jan 2018 13:50:42 -0800

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" <juergen.sauerm...@t-online.de> 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 <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

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 <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=0x555555ae13a8, Z=0x555555ae24f8,

A=0x555555ae11d8) at FloatCell.cc:643

643 while (z < 0.0) z = z + a;

(gdb) p z

$1 = -inf

(gdb) p a

$2 = 9.9999999999999998e-201

Jay.

On 5 January 2018 at 15:24, Xiao-Yong Jin <jinxiaoy...@gmail.com> 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
> 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
>> A∘.|A
>> (hangs)
>>
>> Jay.
>

Re: [Bug-apl] Hang in Residue

Reply via email to