Re: table.sort: invalid order function for sorting

Francisco Olarte <[email protected]> Fri, 24 Apr 2026 19:56:18 +0200
Newsgroups gmane.comp.lang.lua.general
Message-ID <CA+bJJbwKqzNd_QhAPgg0=8_Gfxz7nJfwNVq-9AxKoEgwYut6hg@mail.gmail.com>
On Fri, 24 Apr 2026 at 18:16, 'Martin Eden' via lua-l <
[email protected]> wrote:

> That's right. Came to that after 40 seconds since I sent email.
>
I did not see this before I wrote the first one.

>
> But we can't say it's obvious, right? Besides, in real life there will
> be several lines of code instead of "a, b".
>

It really is obvious. You do the same thing with three valued comparators
for generality. cmp(b,a) works if cmp returns -/0/+ or true-nil-false or
2,"",-3.14. Not cmp will not work in many cases ( the usual is -/0/+ for
C/asm convenience and tradition , and when you sort a lot you have
"-cmp(a,b)" chiseled in a corner of your brain, but this mixes numeric and
comparisons in an ackward way.



> Time spent in comparator is not limited. So sorting time may consist
> mostly of time in that function. Imagine we're doing web request for
> each comparison.. Imagine two times longer line of people in every
> shop you visit..
>

This is why algorithms are coded to not test three ways. You do your web
request but do not swap on not out of order. If you test a<b and get true,
you put a before b, if false, b before a. No harm done if they are equal (
this is in a swapping/partitioning sort , if you are doing, say, an stable
merge sort, you can do similar reasoning, but is too long to write )

 > I think having comparators be boolean "less than" functions makes some

> > sense though.
> > I want to be able to just write something like table.sort(t,
> > function(a, b) return a > b end).
> >
> > Introducing a kind of "spaceship operator" seems like too much for a
> > simple scripting language like Lua.
> > What would the type of the result be? You could make it a number, of
> > course, but that's really a hack.
>

Everybody ( well, C/C++, perl and others ) settles normally for -/0/+, as I
said, it has tradition.
...

Boolean "less than" is perfectly fine. Problem that comparisons are costly.
> So we spent like 24800 microseconds just to get data. And then
> compare numbers and return 0 or 1. Which takes like 20 micros.
>
Ideally comparator should provide as much information about relation of
> given items as it can. At least three output values if there is linear
> order.
> What sorting algorithm will do with them is his own business.
>

Boolean less than is fine, but if comparison is costly 3-way returns makes
them costlier, and handling three-values results also makes control loops
costlier.

Read the source of some good quick / insertion / heap / merge sort
implementations are you will probably find why binary comparators are
preferred in a lot of places.

Francisco Olarte.

-- 
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/CA%2BbJJbwKqzNd_QhAPgg0%3D8_Gfxz7nJfwNVq-9AxKoEgwYut6hg%40mail.gmail.com.