Re: [Bug-apl] 0⍟0

[Juergen Sauermann]

Hi Jay, Kacper, I see, thanks for your explanations. /// Jürgen On 07/14/2016 09:43 AM, Jay Foad wrote: 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