heinrichmartin <
martin....@frequentis.com> wrote:
> puts "lsort -stride: [time {set s1 [lsort -stride 2 [lsort -stride 2 -index 1 $u]]}]"
> puts "lsort -command: [time {set s2 [lsort -stride 2 -command {apply {{a b} {lassign $a a1 a2; lassign $b b1 b2; if {$a1==$b1} then {return [string compare $a2 $b2]} else {return [expr {$a1-$b1}]}}}} $u]}]"
> if {$s1 != $s2} {
> puts stderr "ERROR: The results differ!"
> }
> ERROR: The results differ!
> CAUTION: The implementation with -command is not supported! -stride always
> defauts -index to 0 even if -command is given. Afaik there is no way to
> multi-sort with -command.
This differ is also explained by the different sorting criteria:
the first one sorts both elements in ascii order, thus placing "2"
after "10", whereas the command-variant would (even if it weren't
for the implied "-index 0") use integer comparison for the first
element.
This is however irrelevant to the OP (Alexandru), who wrote that
his list has really pairs of real numbers, thus he most likely
already has his relevant sort-order option in use.
Given that the command actually gets two single elements rather than
sublists, then of course the two "lassign"s in the command cause some
extra shimmering and thus even further worsen the performance.
Removing the lassign and just pretending that the respective
elements are each repeated for index 1, will drop the performance
quotient (msecs(command) / msecs(two sorts)) from above 10 to
about 7.
> It looks like an extension to lsort like "-multisort {0 1}" would be a
> nice feature. If -multisort and -command are used, then the command
> shall accept more arguments, namely {a0 a1 b0 b1} in this case.
I don't really see much value in the -multisort option. It seems to make
sense only where -command and -stride appear together, otherwise the
command already sees the complete sublist to compare. I think, there
must be another solution/fix to get these two options working together
even at the extra cost of preparing a pair of sublists for each comparison.