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