My Invention of "Bug Sort".

Copyright © 2012 Austin O'Byrne.

Let us say that “NextNum” is a variable in a program output string thatthe user wants to sort at the end of the program run.

How it works.

Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.

Q := NextNum(I);
I_NUM(Q):= I_NUM(Q)+1;

(This is the bug)

The bug ‘gets’ (captures) the instantaneous value of NextNum as it materializes and then immediately writes this instantaneous value to a dedicated array in order of *magnitude and returns for the next i.e. each value indexes its own place in the array ( *not in sequential order where the entries would be contiguous and remain unsorted – this is the most salient point for the reader to note).

*This is defacto sorting per se.

It only needs to read back from the array to see the sorted string which can be anything up to 1 million or more elements sorted in a split second, tocomplete the task.

Discussion.

Although I do not yet have performance figures to hand I think I can safelysay that this is super quick, super efficient sorting.

The method is hugely intrinsic to Ada and should be considered as a permanent part of the language mathematical library like say the ‘vector cross product’, trig functions, and calculus. I am proposing that idea here andnow if any reader wants to get behind it with me to promote the idea further to the powers that be in Ada. I am retaining the copyright meanwhile.

I cannot see any of the synthetic algorithms like ‘quick sort’, ‘treesort’ etc, coming even close to it. I think this blows them all right out of the water.

I am developing the demonstration pilot programs (half way there) that I will be uploading to my site later for your perusal.

There will be,

1) An interactive real-time, separate numerical and alphanumerical working program.

2) Batch working in numerical and alphanumerical – i.e. reading in from external unsorted files and out-putting to other sorted external files.

A full description document will accompany the four uploaded programs in Ada that will have the compiler with them and are for free downloading.

I would like to corner this invention as being fundamentally an Ada feature– you guys should get behind it now if you know how to contact the Ada people who have the power to make changes to the language – I don’t.

With both feet firmly on the ground I say this ‘sort’ method could become ubiquitous in the future and /or a bench mark for all other sort programs if they still exist.

Enjoy,

Austin O’Byrne ( aka - adacrypt).

On 2012-06-19 03:13, Austin Obyrne wrote:

> Copyright © 2012 Austin O'Byrne.
>
> Let us say that “NextNum” is a variable in a program output string that the user wants to sort at the end of the program run.
>
> How it works.
>
> Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.
>
> Q := NextNum(I);
> I_NUM(Q):= I_NUM(Q)+1;
>
> (This is the bug)
>
> The bug ‘gets’ (captures) the instantaneous value of NextNum as it materializes and then immediately writes this instantaneous value to a dedicated array in order of *magnitude and returns for the next i.e. each value indexes its own place in the array ( *not in sequential order where the entries would be contiguous and remain unsorted – this is the most salient point for the reader to note).
>
> *This is defacto sorting per se.
>
> It only needs to read back from the array to see the sorted string which can be anything up to 1 million or more elements sorted in a split second, to complete the task.

I find your style of writing difficult to understand. However, if I
follow what you are saying, you are talking about Radix Sort. That
sorting method is O(n) instead of O(n log(n)) (which is the best
attainable running time for a comparison sort). However in general it
can have huge memory requirements and is really only practical in
special cases.

Peter

On Tuesday, June 19, 2012 12:55:12 PM UTC+1, Peter C. Chapin wrote:
> On 2012-06-19 03:13, Austin Obyrne wrote:
>
> > Copyright � 2012 Austin O'Byrne.
> >
> > Let us say that �NextNum� is a variable in a program output string that the user wants to sort at the end of the program run.
> >
> > How it works.
> >
> > Each change in �NextNum� is trapped as it is computed by a �bug� strategically placed in the lines of source code.
> >
> > Q := NextNum(I);
> > I_NUM(Q):= I_NUM(Q)+1;
> >
> > (This is the bug)
> >
> > The bug �gets� (captures) the instantaneous value of NextNum as it materializes and then immediately writes this instantaneous value to a dedicated array in order of *magnitude and returns for the next i.e. each value indexes its own place in the array ( *not in sequential orderwhere the entries would be contiguous and remain unsorted � this is the most salient point for the reader to note).
> >
> > *This is defacto sorting per se.
> >
> > It only needs to read back from the array to see the sorted string which can be anything up to 1 million or more elements sorted in a split second, to complete the task.
>
> I find your style of writing difficult to understand. However, if I
> follow what you are saying, you are talking about Radix Sort. That
> sorting method is O(n) instead of O(n log(n)) (which is the best
> attainable running time for a comparison sort). However in general it
> can have huge memory requirements and is really only practical in
> special cases.
>
> Peter

Hi Peter,

I have never heard of Radix Sort unitl you mention it now so I have checkedit out on Wikipedia just to get an impression of how it works when compared to my Bug Sort.

That's a truly tortuous algorithm and I can see where the memory goes.

I only deal with whole numbers - integers and alphanumeric characters and the memory consumption is very much smaller - 10 megabytes does an awful lotof sorting i.e in normal situations this is quite little.

My interest is largely in cryptography which never uses anything but integers so you can see why my pre-occupation is with integers.

There is no comparison as far as I can see between Radix Sort and Bug Sort but I take your point that something taht sorts float values on a basis of signicficant values must require a lot of memory.

If I had that problem I would look for a better solution beforehand.

Many thanks for your useful pointer.

Regards - Austin O'Byrne

On Tuesday, June 19, 2012 12:13:28 AM UTC-7, Austin Obyrne wrote:
>
> Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.

"Bug" in engineering is a euphemism for "error"; this usage goes back at least to the 19th century. You might want to choose another name.

> Q := NextNum(I);
> I_NUM(Q):= I_NUM(Q)+1;

This is straightforward, and probably very good for your specific needs. Specialized sorting algorithms like this can do much better than general ones.. Like all specialized algorithms, this one has a number of shortcomings asa general sorting algorithm, not least of which is its restriction to sorting values of discrete types only.

It is hardly instantaneous. A complexity analysis is interesting:

Most sorting algorithms' complexity analyses are based only on N, the number of values (the number of times Q gets a value in the example). This algorithm must also take into account the number of possible values Q may have. If Q is of type T, this is T'Pos (T'Last) - T'Pos (T'First) + 1. I'll call this value M. M may be less than, equal to, or greater than N. For convenience, I'll define

B = Max (M, N)

First, time complexity: The algorithm must initialize the array I_Num to all zeros; this is O(M). It then increments the corresponding value of I_Num for each value of Q encountered; this is O(N). Finally, it must traverse I_Num to do something with the resulting values; this is O(M). So the overalltime complexity is O(B). Linear time complexity, which is very good. No general sorting algorithm is linear.

Now space complexity: The algorithm needs the space for I_Num, which is O(M). Depending on what you do with the results, you may need to transform I_Num into the corresponding sorted sequence. For example, if you're sorting the values (3, 7, 1), you often want to end up with an array (1 => 1, 2 => 3, 3 => 7). Such a sequence is O(N). So the space complexity is at least O(M), and may be O(N) (if that's larger). To be safe for all cases we must call it O(B). Several sorting algorithms have O(N) space requirements,so that's not necessarily a problem.

For the following discussions, I'll presume the following declarations:

Q : TQ;
I_Num : array (TQ) of TI;

An implementation of this must take into account a number of factors specific to the problem being solved. TI must be large enough to hold the maximumnumber of times a given value of Q may occur, but small enough that I_Num can be declared. If a component of I_Num overflows, you'll either get incorrect results (TI is a modular integer type) or and exception (TI is a signed integer type).

I_Num'Size will be 2 ** (TQ'Size + TI'Size); that must fit in memory. If parts of I_Num have to be swapped to disk, this could result in absolute times slower than a general, in-place algorithm.

This could also be slower if M >> N.

This is a form of insertion sort, in which values are sorted as they are encountered. In this it is similar to an ordered-tree insertion sort, in which values are inserted into an ordered, balanced, binary tree (or equivalentstructure) as they are encountered. This is another general sorting algorithm that is O(N log N).

An interesting approach, and probably well suited to your specific problem area, but I doubt it will replace general sort algorithms.

On 06/19/2012 09:13 AM, Austin Obyrne wrote:
> Copyright © 2012 Austin O'Byrne.
>
> Let us say that “NextNum” is a variable in a program output string that the user wants to sort at the end of the program run.
>
> How it works.
>
> Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.
>
> Q := NextNum(I);
> I_NUM(Q):= I_NUM(Q)+1;
>
> (This is the bug)
>
> The bug ‘gets’ (captures) the instantaneous value of NextNum as it materializes and then immediately writes this instantaneous value to a dedicated array in order of *magnitude and returns for the next i.e. each value indexes its own place in the array ( *not in sequential order where the entries would be contiguous and remain unsorted – this is the most salient point for the reader to note).
>
> *This is defacto sorting per se.
>
> It only needs to read back from the array to see the sorted string which can be anything up to 1 million or more elements sorted in a split second, to complete the task.
>
> Discussion.
>
> Although I do not yet have performance figures to hand I think I can safely say that this is super quick, super efficient sorting.
>
> The method is hugely intrinsic to Ada and should be considered as a permanent part of the language mathematical library like say the ‘vector cross product’, trig functions, and calculus. I am proposing that idea here and now if any reader wants to get behind it with me to promote the idea further to the powers that be in Ada. I am retaining the copyright meanwhile.
>
> I cannot see any of the synthetic algorithms like ‘quick sort’, ‘tree sort’ etc, coming even close to it. I think this blows them all right out of the water.
>
> I am developing the demonstration pilot programs (half way there) that I will be uploading to my site later for your perusal.
>
> There will be,
>
> 1) An interactive real-time, separate numerical and alphanumerical working program.
>
> 2) Batch working in numerical and alphanumerical – i.e. reading in from external unsorted files and out-putting to other sorted external files.
>
> A full description document will accompany the four uploaded programs in Ada that will have the compiler with them and are for free downloading.
>
> I would like to corner this invention as being fundamentally an Ada feature – you guys should get behind it now if you know how to contact the Ada people who have the power to make changes to the language – I don’t.
>
> With both feet firmly on the ground I say this ‘sort’ method could become ubiquitous in the future and /or a bench mark for all other sort programs if they still exist.
>
> Enjoy,
>
> Austin O’Byrne ( aka - adacrypt).

I think your approach is known as Bitmap Sort, which was originally
described by John Bentley in his famous book "Programming Pearls".

Try a Google search for it or just check out my first two hits:

http://designingefficientsoftware.wo...1/bitmap-sort/
http://www.stoimen.com/blog/2010/06/...han-quicksort/

Kind regards,
Martin Trenkmann

On Tuesday, 19 June 2012 17:13:28 UTC+10, Austin Obyrne wrote:
> Copyright © 2012 Austin O'Byrne.
>
> Let us say that “NextNum” is a variable in a program output string that the user wants to sort at the end of the program run.
>
> How it works.
>
> Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.
>
> Q := NextNum(I);
> I_NUM(Q):= I_NUM(Q)+1;

How large is Q?

On Tuesday, June 19, 2012 11:39:07 PM UTC+1, (unknown) wrote:
> On Tuesday, June 19, 2012 12:13:28 AM UTC-7, Austin Obyrne wrote:
> >
> > Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.
>
> "Bug" in engineering is a euphemism for "error"; this usage goes back at least to the 19th century. You might want to choose another name.
>
> > Q := NextNum(I);
> > I_NUM(Q):= I_NUM(Q)+1;
>
> This is straightforward, and probably very good for your specific needs. Specialized sorting algorithms like this can do much better than general ones. Like all specialized algorithms, this one has a number of shortcomings as a general sorting algorithm, not least of which is its restriction to sorting values of discrete types only.
>
> It is hardly instantaneous. A complexity analysis is interesting:
>
> Most sorting algorithms' complexity analyses are based only on N, the number of values (the number of times Q gets a value in the example). This algorithm must also take into account the number of possible values Q may have.. If Q is of type T, this is T'Pos (T'Last) - T'Pos (T'First) + 1. I'll call this value M. M may be less than, equal to, or greater than N. For convenience, I'll define
>
> B = Max (M, N)
>
> First, time complexity: The algorithm must initialize the array I_Num to all zeros; this is O(M). It then increments the corresponding value of I_Num for each value of Q encountered; this is O(N). Finally, it must traverse I_Num to do something with the resulting values; this is O(M). So the overall time complexity is O(B). Linear time complexity, which is very good. No general sorting algorithm is linear.
>
> Now space complexity: The algorithm needs the space for I_Num, which is O(M). Depending on what you do with the results, you may need to transform I_Num into the corresponding sorted sequence. For example, if you're sortingthe values (3, 7, 1), you often want to end up with an array (1 => 1, 2 => 3, 3 => 7). Such a sequence is O(N). So the space complexity is at least O(M), and may be O(N) (if that's larger). To be safe for all cases we must call it O(B). Several sorting algorithms have O(N) space requirements,so that's not necessarily a problem.
>
> For the following discussions, I'll presume the following declarations:
>
> Q : TQ;
> I_Num : array (TQ) of TI;
>
> An implementation of this must take into account a number of factors specific to the problem being solved. TI must be large enough to hold the maximum number of times a given value of Q may occur, but small enough that I_Num can be declared. If a component of I_Num overflows, you'll either get incorrect results (TI is a modular integer type) or and exception (TI is a signed integer type).
>
> I_Num'Size will be 2 ** (TQ'Size + TI'Size); that must fit in memory. If parts of I_Num have to be swapped to disk, this could result in absolute times slower than a general, in-place algorithm.
>
> This could also be slower if M >> N.
>
> This is a form of insertion sort, in which values are sorted as they are encountered. In this it is similar to an ordered-tree insertion sort, in which values are inserted into an ordered, balanced, binary tree (or equivalent structure) as they are encountered. This is another general sorting algorithm that is O(N log N).
>
> An interesting approach, and probably well suited to your specific problem area, but I doubt it will replace general sort algorithms.



<< This is straightforward, and probably very good for your specific needs.

I think this sums it up completely. I realise now that this is a can of worms when taken as general sort program and probably no better than any other..

I think the fact that it works concurrently with the main program amd requires no extra handling of data after it has been computed is a plus?.

Question: In a real world situation could this sort mechanism be done by a 'tasking' package in Ada.

Many thanks for your excellent and informed analysis.

Austin O'Byrne

Many thanks for your excellent analysis

On Wednesday, June 20, 2012 1:11:27 AM UTC+1, (unknown) wrote:
> On Tuesday, 19 June 2012 17:13:28 UTC+10, Austin Obyrne wrote:
> > Copyright © 2012 Austin O'Byrne.
> >
> > Let us say that “NextNum” is a variable in a program output string that the user wants to sort at the end of the program run.
> >
> > How it works.
> >
> > Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.
> >
> > Q := NextNum(I);
> > I_NUM(Q):= I_NUM(Q)+1;
>
> How large is Q?

I am treating this sort program more as 'tool' for specific needs now rather than a general sort program following the analysis given me by the previous reader.

In answer to your question, Q is limited only by the computer capacity to provide memory as far as I can see.

I have written some new "Theoretically Unbreakable" cryptography that is well proven and I was lookin at this as an enhancement which it still is of course but that is as far as it goes. It may not compete (it might if it comes to that) with other sort programs when it is extended to the broader field of sorting all data types.

See "Skew Line Encryptions - The Eventual Cipher" on
http://www.adacrypt.com/introduction.html

This is downloadable and comes with the original compiler (older but perfectly ok)

Thanks for your interest.

Austin.

On Tuesday, June 19, 2012 11:39:07 PM UTC+1, (unknown) wrote:
> On Tuesday, June 19, 2012 12:13:28 AM UTC-7, Austin Obyrne wrote:
> >
> > Each change in ‘NextNum’ is trapped as it is computed by a ‘bug’ strategically placed in the lines of source code.
>
> "Bug" in engineering is a euphemism for "error"; this usage goes back at least to the 19th century. You might want to choose another name.
>
> > Q := NextNum(I);
> > I_NUM(Q):= I_NUM(Q)+1;
>
> This is straightforward, and probably very good for your specific needs. Specialized sorting algorithms like this can do much better than general ones. Like all specialized algorithms, this one has a number of shortcomings as a general sorting algorithm, not least of which is its restriction to sorting values of discrete types only.
>
> It is hardly instantaneous. A complexity analysis is interesting:
>
> Most sorting algorithms' complexity analyses are based only on N, the number of values (the number of times Q gets a value in the example). This algorithm must also take into account the number of possible values Q may have.. If Q is of type T, this is T'Pos (T'Last) - T'Pos (T'First) + 1. I'll call this value M. M may be less than, equal to, or greater than N. For convenience, I'll define
>
> B = Max (M, N)
>
> First, time complexity: The algorithm must initialize the array I_Num to all zeros; this is O(M). It then increments the corresponding value of I_Num for each value of Q encountered; this is O(N). Finally, it must traverse I_Num to do something with the resulting values; this is O(M). So the overall time complexity is O(B). Linear time complexity, which is very good. No general sorting algorithm is linear.
>
> Now space complexity: The algorithm needs the space for I_Num, which is O(M). Depending on what you do with the results, you may need to transform I_Num into the corresponding sorted sequence. For example, if you're sortingthe values (3, 7, 1), you often want to end up with an array (1 => 1, 2 => 3, 3 => 7). Such a sequence is O(N). So the space complexity is at least O(M), and may be O(N) (if that's larger). To be safe for all cases we must call it O(B). Several sorting algorithms have O(N) space requirements,so that's not necessarily a problem.
>
> For the following discussions, I'll presume the following declarations:
>
> Q : TQ;
> I_Num : array (TQ) of TI;
>
> An implementation of this must take into account a number of factors specific to the problem being solved. TI must be large enough to hold the maximum number of times a given value of Q may occur, but small enough that I_Num can be declared. If a component of I_Num overflows, you'll either get incorrect results (TI is a modular integer type) or and exception (TI is a signed integer type).
>
> I_Num'Size will be 2 ** (TQ'Size + TI'Size); that must fit in memory. If parts of I_Num have to be swapped to disk, this could result in absolute times slower than a general, in-place algorithm.
>
> This could also be slower if M >> N.
>
> This is a form of insertion sort, in which values are sorted as they are encountered. In this it is similar to an ordered-tree insertion sort, in which values are inserted into an ordered, balanced, binary tree (or equivalent structure) as they are encountered. This is another general sorting algorithm that is O(N log N).
>
> An interesting approach, and probably well suited to your specific problem area, but I doubt it will replace general sort algorithms.



Re Your suggestion: "Bug" in engineering is a euphemism for "error";

I agree this needs to be changed.

I originally thought of "Tag Sort" but this clashes with 'tag' in Ada terminology.

I'm considering "Cell Sort" (<= elements of an array),"Trap Sort" (<= data is systematically trapped), "Abstraction Sort" (<= data is abstractedfrom the stream of data being assigned to the variable during runtime of the host program.

Would any of these clash with other sort program tiles known to you?

Your suggestion on one of these names would be greatly appreciated.

I am treating my invention now as more of an application (a tool)to specific problems rather than a general method in all of mathematics.

I still see it as a tool specific to each language in programming while notbeing acceptable as an infinite principle or theorem in mathematics
..

I sincerely hope you take the time to reply to this.


Austin O'Byrne.

El 20/06/2012 12:57, Austin Obyrne escribió:
> ...
> Re Your suggestion: "Bug" in engineering is a euphemism for
> "error";
>
> I agree this needs to be changed.
>
> I originally thought of "Tag Sort" but this clashes with 'tag' in Ada
> terminology.
>
> I'm considering "Cell Sort" (<= elements of an array),"Trap Sort" (<=
> data is systematically trapped), "Abstraction Sort" (<= data is
> abstracted from the stream of data being assigned to the variable
> during runtime of the host program.
>
> Would any of these clash with other sort program tiles known to you?
>
> Your suggestion on one of these names would be greatly appreciated.

http://en.wikipedia.org/wiki/Bucket_sort

--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

El 20/06/2012 14:47, Manuel Collado escribió:
> El 20/06/2012 12:57, Austin Obyrne escribió:
>> ...
>> Re Your suggestion: "Bug" in engineering is a euphemism for
>> "error";
>>
>> I agree this needs to be changed.
>>
>> I originally thought of "Tag Sort" but this clashes with 'tag' in Ada
>> terminology.
>>
>> I'm considering "Cell Sort" (<= elements of an array),"Trap Sort" (<=
>> data is systematically trapped), "Abstraction Sort" (<= data is
>> abstracted from the stream of data being assigned to the variable
>> during runtime of the host program.
>>
>> Would any of these clash with other sort program tiles known to you?
>>
>> Your suggestion on one of these names would be greatly appreciated.
>
> http://en.wikipedia.org/wiki/Bucket_sort
>

More precisely:

http://en.wikipedia.org/wiki/Pigeonhole_sort

--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

El 20/06/2012 14:51, Manuel Collado escribió:
> El 20/06/2012 14:47, Manuel Collado escribió:
>> El 20/06/2012 12:57, Austin Obyrne escribió:
>>> ...
>>> Re Your suggestion: "Bug" in engineering is a euphemism for
>>> "error";
>>>
>>> I agree this needs to be changed.
>>>
>>> I originally thought of "Tag Sort" but this clashes with 'tag' in Ada
>>> terminology.
>>>
>>> I'm considering "Cell Sort" (<= elements of an array),"Trap Sort" (<=
>>> data is systematically trapped), "Abstraction Sort" (<= data is
>>> abstracted from the stream of data being assigned to the variable
>>> during runtime of the host program.
>>>
>>> Would any of these clash with other sort program tiles known to you?
>>>
>>> Your suggestion on one of these names would be greatly appreciated.
>>
>> http://en.wikipedia.org/wiki/Bucket_sort
>>
>
> More precisely:
>
> http://en.wikipedia.org/wiki/Pigeonhole_sort

Ooops!. Should be:

http://en.wikipedia.org/wiki/Counting_sort

The original algorithm dates back to 1954. See ref. 8.

--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

On Wednesday, June 20, 2012 1:51:10 PM UTC+1, Manuel Collado wrote:
> El 20/06/2012 14:47, Manuel Collado escribió:
> > El 20/06/2012 12:57, Austin Obyrne escribió:
> >> ...
> >> Re Your suggestion: "Bug" in engineering is a euphemism for
> >> "error";
> >>
> >> I agree this needs to be changed.
> >>
> >> I originally thought of "Tag Sort" but this clashes with 'tag' in Ada
> >> terminology.
> >>
> >> I'm considering "Cell Sort" (<= elements of an array),"Trap Sort" (<=
> >> data is systematically trapped), "Abstraction Sort" (<= data is
> >> abstracted from the stream of data being assigned to the variable
> >> during runtime of the host program.
> >>
> >> Would any of these clash with other sort program tiles known to you?
> >>
> >> Your suggestion on one of these names would be greatly appreciated.
> >
> > http://en.wikipedia.org/wiki/Bucket_sort
> >
>
> More precisely:
>
> http://en.wikipedia.org/wiki/Pigeonhole_sort
>
> --
> Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Many thanks for this.

I think there is much of a muchness in all of these fine programs. I guesswe all want to be able to say we have invented the best program but this is more an elite group of similar programs from what I can see.

I am claiming that the only restriction to my version of this sort program type is the data type is discrete.

Many thanks for your contibution to my education of sort programs.

Regards - Austin.

On Wed, 20 Jun 2012 03:57:55 -0700 (PDT), Austin Obyrne
<austin.obyrne@hotmail.com> declaimed the following in comp.lang.ada:


> I originally thought of "Tag Sort" but this clashes with 'tag' in Ada terminology.
>
It also competes with "tag sort" as was taught in my CS classes,
late 70s.

In this case, "tag" meant an array of indices into the actual data
array. Rather than swapping the actual data (which may have been large
records, possibly even stored on direct access disk), one swapped the
indices (tags) pointing /to/ the data.

When done, one had an array of just indices that would produce the
sorted order of data when retrieved: data(tag(i))
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/

On Wednesday, June 20, 2012 3:57:55 AM UTC-7, Austin Obyrne wrote:
>
> Your suggestion on one of these names would be greatly appreciated.

As Collado pointed out, this is an implementation of Counting Sort.

The extension of sorting algorithms to arrays indexed by non-numeric discrete types (in languages that support them) is obvious and well established. I first encountered it in Pascal in the late 1970s.

--
Jeff Carter
jrcarter commercial-at-sign acm (period | full stop) org