Understanding issorted's lt keyword

goretkin · May 12, 2021, 6:05pm

That means that the default lt = isless would be wrong, since it would give issorted([1, 1]) == false.

You could then suggest the default be lt = <=, but note that the fallback for <= is defined in terms of <:

JuliaLang/julia/blob/d6c092d6d73be9b41b5b8fef30d882fdb63a8d20/base/operators.jl#L401


      
          julia> 7 ≤ 7 ≤ 9
          true
          
          julia> "abc" ≤ "abc"
          true
          
          julia> 5 <= 3
          false
          ```
          """
          <=(x, y) = (x < y) | (x == y)
          const ≤ = <=
          
          """
              >=(x, y)
              ≥(x,y)
          
          Greater-than-or-equals comparison operator. Falls back to `y <= x`.
          
          # Examples
          ```jldoctest

And < is defined in terms of isless:

github.com

JuliaLang/julia/blob/d6c092d6d73be9b41b5b8fef30d882fdb63a8d20/base/operators.jl#L352


      
          julia> 'a' < 'b'
          true
          
          julia> "abc" < "abd"
          true
          
          julia> 5 < 3
          false
          ```
          """
          <(x, y) = isless(x, y)
          
          """
              >(x, y)
          
          Greater-than comparison operator. Falls back to `y < x`.
          
          # Implementation
          Generally, new types should implement [`<`](@ref) instead of this function,
          and rely on the fallback definition `>(x, y) = y < x`.

If you simply define isless and == (EDIT: not isequal), you get the desired (probably) definitions of the other operators. I’d say that this is nothing more than a design choice, but it’s one that works pretty well in my opinion. And indeed you can write issorted in terms of isless: instead of checking that every consecutive element satisfies a property, you instead check that no consecutive element violates a property.

I understand that this extra negation and swapping of the arguments is not the first definition of issorted that some people are thinking of. But the definition that is in Base is self-consistent. That’s not to say that this can’t be better documented.

I’ll add that there might be cases where it’s better to define isless on your type (possible a wrapper type) than it is to pass in a function for lt. I asked about these two choices once upon a time: Designing APIs. defining new methods versus passing in functions