Hi Kacper, I am aware of the non-transitivity of = when ⎕CT ≠ 0. However, the algorithm used in GNU APL is essentially the same as in the ISO standard. The result is sometimes puzzling.
The difference between GNU APL and ISO is that the ISO algorithm has, in the worst case, quadratic runtime, while GNU APL first sorts the items, which brings down the execution time to n log(n). However, sorting takes only place when number of items is large (20 or more). That's why you see a difference (only) between 19 and 20: the underlying algorithm are then different (and due to the non-transitivity of = give the observed different results. I could lower the split point of the two algorithms from 20 to 2 but that would result in a somewhat lower performance for short vectors. IMHO, given the non-transitivity of = (which is the root cause for the observed behaviour), is the performance penalty for maintaining the exact order of almost identical values not worth its effort. Best regards, Jürgen Sauermann On 1/28/20 6:10 PM, Kacper Gutowski wrote: > Actually, while the algorithm used for 20≥⍴ works well with characters > or integers (once you fix the direction of inequality), I don't think > it's actually correct at all for non-zero ⎕CT because tolerant > equality is not transitive. > Consider this: > X←1+0 1 2 5 4 3×(⎕CT←1E¯9)÷2 > ∪19↑X > 1 1.000000001 1.000000002 0 > ∪20↑X > 1.000000001 1.000000002 0 > > Both expressions should give the same result. > -k > >
