[PD] Vanilla object for "sort"

[Miller Puckette]

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