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

Excuse me, I am jumping in the conversation after 46 posts, but I see immediately what is wrong. The Julia manual just uses the mathematical definition for what is a total order. A total order is given by a function < such that for any a,b we have either a<b or b<a or a==b (but only one of them) …

[image] Jean_Michel: The operator <= does not satisfy the axioms of a total order so should not be used with sort or issorted . But then it becomes impossible to sort non-unique vectors, since they cannot obey a total ordering, so it doesn’t seem very useful. Also, the docs don’t say you can…

[image] DNF: But then it becomes impossible to sort non-unique vectors, since they cannot obey a total ordering, so it doesn’t seem very useful. Not at all. When sorting a non-unique vector the equal elements will become consecutive. The algorithm in Julia for sort uses the definition I gave …

But how can it be sorted if each element isn’t < than the next? Each element is, however, <= than the next, so <= is the correct ordering. What am I missing? This is really frustrating.

Given a total order <, you can define a “less than or equal” relation <= which is: a<=b if a<b or a=b But this relation is not a total order. A sequence a_1,…,a_n is sorted if a_i<a_{i+1} or a_i=a_{i+1}, or in other terms a_i<=a_{i+1}. The function you give to sort must be a total order, otherwi…

I still don’t understand. I’ll quote my recent question: [image] DNF: But how can it be sorted if each element isn’t < than the next? Each element is, however, <= than the next, so <= is the correct ordering.

The way I see it, should-wise: issorted should simply check whether lt holds for each consecutive pair. sort should have an output for which issorted is true, if possible. The default lt should be <=. sort([1, 1, 2]; lt=isless) should error out, because it can’t be done, just like sort([1, im]; lt=i…

The point of issorted is to check whether calling sort is useful or necessary. Think of it as asking “If I call sort with this value for its lt parameter, will it return the array unchanged?” You shouldn’t expect any more or less of it.

[image] gustaphe: The way I see it, should -wise: issorted should simply check whether lt holds for each consecutive pair. 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 f…

[image] goretkin: instead of checking that every consecutive element satisfies a property, you instead check that no consecutive element violates a property. Actually, it seems that the current implementation checks whether the reverse order does not satisfy the property, and those are not eq…

Understanding issorted's lt keyword

New to Julia

DNF May 12, 2021, 5:32pm 52

I still don’t understand. I’ll quote my recent question:

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