On Sat, May 09, 2015 at 05:30:14PM -0400, Jonathan Wilkes via Pd-list wrote:
On 05/09/2015 11:29 AM, Frank Barknecht wrote:
Hi,
the list-sort.pd abstraction in the [list]-abs is Pd vanilla and uses data structures to do the sorting. The actual sorting is fast, but first the list is copied into a data structure [struct f float x] and into a subpatch, which takes a moment. Then you just sort the subpatch with the message "sort" to it.
In my benchmarks four yers ago it was faster than the other sorting algorithms available at the time, which are also included in the collection.
That's probably because the other sorting algorithms spend a significant amount of time copying lists.
To get anything close to the speed of the canvas "sort" method you'd have to have an object that manipulates an incoming list in place. However, that'd have serious side effects, which is why I suppose no objects do that kind of thing.
-Jonathan
But I believe Frank's method (which is, by the way, ingenious!) also requires copying the objects to be sorted. So I think one could do just as well some other way.
Here are three things I could imagine doing for some future release:
a [list sort] built-in that outputs two lists, one the sorted numbers or symbols, and the other giving the indices of the items in order
an [array sort] object - I guess that should write its outputs into two other arrays, yuck
a [text sort] object that would act like unix "sort": just sort all the lines of the text object.
I don't know which of these would be the most useful. The only use case that I've run into personally is my desire to do triage on sigmund~ outputs to find, say, the peaks best fitting a user-defied criterion about freqency and amplitude (example: Fletcher-Munson loudness; or other example: the peaks that best continue a collection of pre-existing tracks). For that, the [list sort] solution would be best I think.
cheers Miller