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> …

And I do understand that this is the case. It just seems completely bizarre. Why is it done like this? Why not then supply a “greater than” comparison? I realize this won’t change, and is probably ‘correct’. It’s just so mind-bendingly, brain-explodingly counterintuitive. I wish I could ‘get it’.

[image] DNF: I get a bit of a headache trying to grasp the ‘inverse’ definition of the concepts, that you are advocating. Note that I am justifying the definition of issorted by discussing the function isless. Julia (Base and software ecosystem) is unlike any other in my experience in how wel…

[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…

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.

[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”

Understanding issorted's lt keyword

New to Julia

DNF May 12, 2021, 6:39pm 63

I don’t object to that. But why must sort be implemented in terms of the most fundamental function?

Topic		Replies	Views
Meaning of `isless`, `<`, `cmp`, `isequal`, `==`, total order, partial order, unordered Internals & Design	24	2466	January 7, 2018
Sortperm with keyword lt = !isless throws BoundsError General Usage	9	587	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	1239	April 9, 2025

Understanding issorted's lt keyword

Related topics