HP49-HP50 : when {list of repeated solutions} —> {list with no rep. sol}

[Werner]

(12-22-2022 02:48 PM)David Hayden Wrote:  I didn't know that SORT is slow. Do you know why it's slow? What makes LSORT faster?

Do you have an hour or two? ;-)
SORT is written in SysRPL, and LSORT is almost pure Saturn machine language.
As SysRPL goes, SORT is as good as it gets (insertion sort with binary search, where the insertion, usually the bottleneck, is a stack UNROLL statement that is very fast). LSORT uses median-of-three quicksort with selection sort for small subarrays.
I made LSORT to be as fast as I could make it, and also as compatible with SORT as possible. The current (and by the looks of it, final) version 0.6b does everything SORT does, apart from units, and lists with both real and decimal integer elements (on the 49 and up). I have no solution to incorporate either of these.

You mention that my LUNQ program is O(n^2). Technically, yes. But the built-in SORT is so slow your version will never outperform mine, I think. But with LSORT, it will.
(probably again not in this case as you have to turn the array elements into strings, which is also a costly operation)
Some run times: LSORT vs. (SORT):
[48] 50 random reals: 0.0657_s (1.7_s)
[48] 1024 random reals: 1.8_s (104_s)
[48] 744 strings (49G command list) : 1.4_s (70_s)
[48] 1024 lists of 2 random reals: 2.34_s (Not Enough Memory..)
[49] 1024 decimal integers created with RAND 1.E10 * CEIL R\->I: 1.8_s (217_s)
[49] 2048 strings length between 11. and 19. : 3.97_s ()
[49] 1024 binary integers : 1.8_s (114_s)

.. or more than 50 times faster.

Cheers, Werner