Re: [Bug-apl] 0⍟0

[Jay Foad]

In practice I think the "if A and B are equal" case is only there to handle 0⍟0. For all other cases of A=B the result of 1 falls out naturally from the general definition (as long as you support complex numbers). And for testing 0=0, ⎕CT is irrelevant; comparisons with zero are never tolerant. And as Kacper pointed out, if A and B are very close but not exactly equal you'll get a result which is very close but not exactly equal to 1, which is just what you want for a continuous function.

Jay.

On 13 July 2016 at 17:42, Juergen Sauermann <address@hidden> wrote:

Hi,

yes, I meant ⎕CT of course.

I have fixed this without using ⎕CT, SVN 780.

My point was that for integer arguments ⎕CT makes no difference, but for real and
complex numbers as soon as you do computations with them they tend to quickly catch
rounding errors and the comparisons A=B and A=1 are then very likely to fail even if
the numbers are almost equal or close to 1.

So using ⎕CT would have made more sense to me.

/// Jürgen

On 07/13/2016 01:36 PM, Kacper Gutowski wrote:

On 13 July 2016 at 13:21, Juergen Sauermann wrote:

I see. Which leaves the question if "equal" shall be strict or within ⎕IO.

Since we are dealing with real numbers (and therefore often rounding errors)
within ⎕IO
makes more sense to me but the standard does not mention ⎕IO for ⍟.

I think you mean ⎕CT?  The word “equal” is bolded there which means
it's supposed to be defined earlier and in §5.2.5 you'll find that
“A equals B” when they are the same number.  There is a different
phrase “A is tolerantly-equal to B within” for tolerant equality.

The ⎕CT is not needed here anyway because, as with 0÷0, this is a
continuous extension for {⍵⍟⍵}. When A≠1 and B≠0, A⍟B→1 as A-B→0
and your implementation defined logarithm algorithm shall give
appropriate, close to one, results for A close to B.

-k