The lt keyword for issorted and sort! is defying my intuition. From reading the source code, I understand why I get the following results, but I am finding it counterintuitive. From the documentation for sort!: the lt keyword allows providing a custom “less than” function Let’s try it: julia> …

[image] goretkin: By design, isless and isequal is more “fundamental” than the <= that you are advocating for. But what’s the relevance of that? The question I’m struggling with is “what does it mean for a sequence to be sorted according to some comparison operator?” This switching of order …

[image] goretkin: We are lucky when outcomes of careful design for generic programming aligns with the expectations of every user, and we appear not to be lucky this time. So I don’t don’t know if I’m in the minority here, but what happens if the design confounds the expectations of (say, for…

[image] DNF: But what’s the relevance of that? The question I’m struggling with is “what does it mean for a sequence to be sorted according to some comparison operator?” It sounds like you are willing to accept the claim that isless and isequal is more fundamental than <=. So, then your next …

[image] goretkin: It sounds like you are willing to accept the claim that isless and isequal is more fundamental than <= . I don’t object to that. But why must sort be implemented in terms of the most fundamental function?

The definition Julia uses is that a list is sorted iff for every pair of elements, either: The elements are equal The first element is less than the second The reason for this design is it only relies on users to define ==(a::T,b::T) and <(a::T,b::T). The reason to define sort in terms of the mo…

[image] Oscar_Smith: The elements are equal The first element is less than the second Then it would help a lot if the first clause was made very explicit. And that the lt input is subject to very strict requirements.

Yeah. The docs probably should say something along the lines of “lt should be a function that forms a total order when combined with isequal”

[image] Oscar_Smith: The reason for this design is it only relies on users to define ==(a::T,b::T) and <(a::T,b::T) . That is not correct. All you need is < / isless. Take for example julia> mutable struct Wrap _::Int end julia> Base.isless(a::Wrap, b::Wrap) = isless(a._, b._…

[image] Jean_Michel: and that is much more than 1% of users. The number was for the sake of argument. But how big do you think that number is? And as I said, the docs don’t even mention “total order” (or do they), so why would I expect that to be relevant?

Understanding issorted's lt keyword

New to Julia

Jean_Michel May 12, 2021, 6:41pm 65

The design perfectly fits the expectation of users who know the mathematical definition of a total order, and that is much more than 1% of users.

Topic		Replies	Views
Meaning of `isless`, `<`, `cmp`, `isequal`, `==`, total order, partial order, unordered Internals & Design	24	2463	January 7, 2018
Sortperm with keyword lt = !isless throws BoundsError General Usage	9	582	January 8, 2023
Behavior of == when isless or < is defined General Usage	22	2272	April 4, 2018
What should `issorted` return when an order isn't defined for the elements, but a comparison works? General Usage sort	4	272	July 10, 2023
Why is there no isless(::Int64, ::UnitRange{Int64})? General Usage range , unitrange	45	1237	April 9, 2025

Understanding issorted's lt keyword

Related topics