Recapping on “Bug Sort”.

Recapping on “Bug Sort”.

[Austin Obyrne]

Several things have been pointed out to me by informed readers that I have taken on board.  I appreciate the good intention and am truly grateful for the advice.

First of all I have been told that the name is unbecoming and I am changing it therefore to “Parallel Sort” because of the way it works in parallel and concurrently with a computer program at run time.

Any number of variables in a computer program may be tracked simultaneously and the changing values are written to dedicated sorting arrays and sorted immediately as they occur in an ongoing process.  This obviates double handling of data that needs to be sorted by the user i.e in not having to collect it retroactively by some other means and then sorting it in a separate secondary operation.

I have been told that my program resembles a known sort program called “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to point out therefore that the salient thing about my “Parallel Sort” is that my implementation is geared to capturing data during any unrelated program run-time and assigning the data in such a way that the separate elements index their own addresses in the sorting arrays.  A similarity with some other existing paper algorithm is simply fortuitous.

I am not on the make for anything like fame or fortune (perish the thought) but in fairness I think that where discrete data is a conditional caveat (i.e. general sorting that would include float data type is not being claimed), I have invented a useful tool in programming and in computer science that previously did not exist. It is acknowledged that this sort program is limited to discrete data types only.

The invention has an attractive “time complexity “ rating.
Tests to date indicate 14250 integers sorted in less that 1 second – much better results are expected later – the development is ongoing.

I would like to thank everybody who has helped me in this matter recently.

-Austin O’Byrne.

Re: Recapping on “Bug Sort”.

[Jeffrey Carter]

On 06/22/2012 12:55 PM, Austin Obyrne wrote:
>
> I have been told that my program resembles a known sort program called
> �Counting Sort�.  I would hate to be guilty of plagiarism and I would like to
> point out therefore that the salient thing about my �Parallel Sort� is that
> my implementation is geared to capturing data during any unrelated program
> run-time and assigning the data in such a way that the separate elements
> index their own addresses in the sorting arrays.  A similarity with some
> other existing paper algorithm is simply fortuitous.

What you have presented is an implementation of counting sort, nothing more. 
There is nothing new or unique about your implementation.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> >
> > I have been told that my program resembles a known sort program called
> > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > point out therefore that the salient thing about my “Parallel Sort” is that
> > my implementation is geared to capturing data during any unrelated program
> > run-time and assigning the data in such a way that the separate elements
> > index their own addresses in the sorting arrays.  A similarity with some
> > other existing paper algorithm is simply fortuitous.
> 
> What you have presented is an implementation of counting sort, nothing more. 
> There is nothing new or unique about your implementation.
> 
> -- 
> Jeff Carter
> "Apart from the sanitation, the medicine, education, wine,
> public order, irrigation, roads, the fresh water system,
> and public health, what have the Romans ever done for us?"
> Monty Python's Life of Brian
> 80
> 
> 
> 
> --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

I am not denying that although I have not inspected "Count Sort" so as to make a comparison.

Is there any working application that you know of or better still, performance figures.

Austin O'Byrne.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> >
> > I have been told that my program resembles a known sort program called
> > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > point out therefore that the salient thing about my “Parallel Sort” is that
> > my implementation is geared to capturing data during any unrelated program
> > run-time and assigning the data in such a way that the separate elements
> > index their own addresses in the sorting arrays.  A similarity with some
> > other existing paper algorithm is simply fortuitous.
> 
> What you have presented is an implementation of counting sort, nothing more. 
> There is nothing new or unique about your implementation.
> 
> -- 
> Jeff Carter
> "Apart from the sanitation, the medicine, education, wine,
> public order, irrigation, roads, the fresh water system,
> and public health, what have the Romans ever done for us?"
> Monty Python's Life of Brian
> 80
> 
> 
> 
> --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---


There is no question of kudos-grabbing by me in this matter - I have already invented a world first in unbreakable cryptography that is here to stay, this is merely a useful adjunct to that so I am not exactly starving for attention.

see "Skew Line Encryptions - The Eventual Cipher"

http://www.adacrypt.com/introduction.html

There is a lot of 'dredging' for links going on these days that often are suspect assertions that have no properly established credence.  Even Wikipedia has to taken with a measured pinch of salt at the end of the day -the low-hanging fruit to many visitors but its usually only a starting point for further study by seriously minded people.

Because it is in print does not make a claim fire proof.

Unless "Count Sort" can deliver then it is not right to say it is an establisheed sort prog - it is derogatory to my invention in fact to make comparisons unless it can be backed up with stronger performance figures otherwise it is nothing more than a static paper sort program. 

In this day and age the onus is on the claimant to deliver fresh claims as a working computerised program since that is how it will be expected to run in reality - this must be demonstrated in lieu of mathemtaical proof which is impossible to do very often.

It doesn't matter to me how highly regarded my invention does become - I am already on the score board for better reasons.

PS - I have just done a test run on my "Parallel Sort" program invention using my very ordinary home computer and the results are:- 

28500 seven-digit positive integers were sorted in less than 1 second. The crucial test part of the program was timed for that test as being the de facto sorting implement.

Can "Count Sort" beat that ?

Dredging for links in the internet is a poor substitute for proper intelligent research.  When these links surface they still need to be demonstrated properly and not accepted simply because they have appeared as link to someone's website and are quotable for that reason. 

Best Wishes.

Austin O'Byrne.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> > On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> > >
> > > I have been told that my program resembles a known sort program called
> > > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > > point out therefore that the salient thing about my “Parallel Sort” is that
> > > my implementation is geared to capturing data during any unrelated program
> > > run-time and assigning the data in such a way that the separate elements
> > > index their own addresses in the sorting arrays.  A similarity with some
> > > other existing paper algorithm is simply fortuitous.
> > 
> > What you have presented is an implementation of counting sort, nothing more. 
> > There is nothing new or unique about your implementation.
> > 
> > -- 
> > Jeff Carter
> > "Apart from the sanitation, the medicine, education, wine,
> > public order, irrigation, roads, the fresh water system,
> > and public health, what have the Romans ever done for us?"
> > Monty Python's Life of Brian
> > 80
> > 
> > 
> > 
> > --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
> 
> 
> There is no question of kudos-grabbing by me in this matter - I have already invented a world first in unbreakable cryptography that is here to stay, this is merely a useful adjunct to that so I am not exactly starving for attention.
> 
> see "Skew Line Encryptions - The Eventual Cipher"
> 
> http://www.adacrypt.com/introduction.html
> 
> There is a lot of 'dredging' for links going on these days that often are suspect assertions that have no properly established credence.  Even Wikipedia has to taken with a measured pinch of salt at the end of the day -the low-hanging fruit to many visitors but its usually only a starting point for further study by seriously minded people.
> 
> Because it is in print does not make a claim fire proof.
> 
> Unless "Count Sort" can deliver then it is not right to say it is an establisheed sort prog - it is derogatory to my invention in fact to make comparisons unless it can be backed up with stronger performance figures otherwise it is nothing more than a static paper sort program. 
> 
> In this day and age the onus is on the claimant to deliver fresh claims as a working computerised program since that is how it will be expected to run in reality - this must be demonstrated in lieu of mathemtaical proof which is impossible to do very often.
> 
> It doesn't matter to me how highly regarded my invention does become - I am already on the score board for better reasons.
> 
> PS - I have just done a test run on my "Parallel Sort" program invention using my very ordinary home computer and the results are:- 
> 
> 28500 seven-digit positive integers were sorted in less than 1 second. The crucial test part of the program was timed for that test as being the de facto sorting implement.
> 
> Can "Count Sort" beat that ?
> 
> Dredging for links in the internet is a poor substitute for proper intelligent research.  When these links surface they still need to be demonstrated properly and not accepted simply because they have appeared as link to someone's website and are quotable for that reason. 
> 
> Best Wishes.
> 
> Austin O'Byrne.

Update on performance.

42750 seven-digit positive integers were sorted in between 1 and 2 seconds.

Waiting to hear regarding "Count Sort".

- adacrypt

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 11:20:10 AM UTC+1, Austin Obyrne wrote:
> On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> > On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> > > On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> > > >
> > > > I have been told that my program resembles a known sort program called
> > > > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > > > point out therefore that the salient thing about my “Parallel Sort” is that
> > > > my implementation is geared to capturing data during any unrelated program
> > > > run-time and assigning the data in such a way that the separate elements
> > > > index their own addresses in the sorting arrays.  A similarity with some
> > > > other existing paper algorithm is simply fortuitous.
> > > 
> > > What you have presented is an implementation of counting sort, nothing more. 
> > > There is nothing new or unique about your implementation.
> > > 
> > > -- 
> > > Jeff Carter
> > > "Apart from the sanitation, the medicine, education, wine,
> > > public order, irrigation, roads, the fresh water system,
> > > and public health, what have the Romans ever done for us?"
> > > Monty Python's Life of Brian
> > > 80
> > > 
> > > 
> > > 
> > > --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
> > 
> > 
> > There is no question of kudos-grabbing by me in this matter - I have already invented a world first in unbreakable cryptography that is here to stay, this is merely a useful adjunct to that so I am not exactly starving for attention.
> > 
> > see "Skew Line Encryptions - The Eventual Cipher"
> > 
> > http://www.adacrypt.com/introduction.html
> > 
> > There is a lot of 'dredging' for links going on these days that often are suspect assertions that have no properly established credence.  Even Wikipedia has to taken with a measured pinch of salt at the end of the day -the low-hanging fruit to many visitors but its usually only a starting point for further study by seriously minded people.
> > 
> > Because it is in print does not make a claim fire proof.
> > 
> > Unless "Count Sort" can deliver then it is not right to say it is an establisheed sort prog - it is derogatory to my invention in fact to make comparisons unless it can be backed up with stronger performance figures otherwise it is nothing more than a static paper sort program. 
> > 
> > In this day and age the onus is on the claimant to deliver fresh claims as a working computerised program since that is how it will be expected to run in reality - this must be demonstrated in lieu of mathemtaical proof which is impossible to do very often.
> > 
> > It doesn't matter to me how highly regarded my invention does become - I am already on the score board for better reasons.
> > 
> > PS - I have just done a test run on my "Parallel Sort" program invention using my very ordinary home computer and the results are:- 
> > 
> > 28500 seven-digit positive integers were sorted in less than 1 second. The crucial test part of the program was timed for that test as being the de facto sorting implement.
> > 
> > Can "Count Sort" beat that ?
> > 
> > Dredging for links in the internet is a poor substitute for proper intelligent research.  When these links surface they still need to be demonstrated properly and not accepted simply because they have appeared as link to someone's website and are quotable for that reason. 
> > 
> > Best Wishes.
> > 
> > Austin O'Byrne.
> 
> Update on performance.
> 
> 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
> 
> Waiting to hear regarding "Count Sort".
> 
> - adacrypt

Update on performance.

This time takes into account: 

Collecting the data. sorting the data and reading back the data.

85,550 seven-digit positive integers took 12 seconds.

In a real world program one could say that 7000 values per second can be sorted as they are assigned in parallel to a particular variable in a hosting program.

Austin O'Byrne.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 2:08:58 PM UTC+1, Austin Obyrne wrote:
> On Saturday, June 23, 2012 11:20:10 AM UTC+1, Austin Obyrne wrote:
> > On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> > > On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> > > > On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> > > > >
> > > > > I have been told that my program resembles a known sort program called
> > > > > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > > > > point out therefore that the salient thing about my “Parallel Sort” is that
> > > > > my implementation is geared to capturing data during any unrelated program
> > > > > run-time and assigning the data in such a way that the separate elements
> > > > > index their own addresses in the sorting arrays.  A similarity with some
> > > > > other existing paper algorithm is simply fortuitous.
> > > > 
> > > > What you have presented is an implementation of counting sort, nothing more. 
> > > > There is nothing new or unique about your implementation.
> > > > 
> > > > -- 
> > > > Jeff Carter
> > > > "Apart from the sanitation, the medicine, education, wine,
> > > > public order, irrigation, roads, the fresh water system,
> > > > and public health, what have the Romans ever done for us?"
> > > > Monty Python's Life of Brian
> > > > 80
> > > > 
> > > > 
> > > > 
> > > > --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
> > > 
> > > 
> > > There is no question of kudos-grabbing by me in this matter - I have already invented a world first in unbreakable cryptography that is here to stay, this is merely a useful adjunct to that so I am not exactly starving for attention.
> > > 
> > > see "Skew Line Encryptions - The Eventual Cipher"
> > > 
> > > http://www.adacrypt.com/introduction.html
> > > 
> > > There is a lot of 'dredging' for links going on these days that often are suspect assertions that have no properly established credence.  Even Wikipedia has to taken with a measured pinch of salt at the end of the day -the low-hanging fruit to many visitors but its usually only a starting point for further study by seriously minded people.
> > > 
> > > Because it is in print does not make a claim fire proof.
> > > 
> > > Unless "Count Sort" can deliver then it is not right to say it is an establisheed sort prog - it is derogatory to my invention in fact to make comparisons unless it can be backed up with stronger performance figures otherwise it is nothing more than a static paper sort program. 
> > > 
> > > In this day and age the onus is on the claimant to deliver fresh claims as a working computerised program since that is how it will be expected to run in reality - this must be demonstrated in lieu of mathemtaical proof which is impossible to do very often.
> > > 
> > > It doesn't matter to me how highly regarded my invention does become - I am already on the score board for better reasons.
> > > 
> > > PS - I have just done a test run on my "Parallel Sort" program invention using my very ordinary home computer and the results are:- 
> > > 
> > > 28500 seven-digit positive integers were sorted in less than 1 second. The crucial test part of the program was timed for that test as being the de facto sorting implement.
> > > 
> > > Can "Count Sort" beat that ?
> > > 
> > > Dredging for links in the internet is a poor substitute for proper intelligent research.  When these links surface they still need to be demonstrated properly and not accepted simply because they have appeared as link to someone's website and are quotable for that reason. 
> > > 
> > > Best Wishes.
> > > 
> > > Austin O'Byrne.
> > 
> > Update on performance.
> > 
> > 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
> > 
> > Waiting to hear regarding "Count Sort".
> > 
> > - adacrypt
> 
> Update on performance.
> 
> This time takes into account: 
> 
> Collecting the data. sorting the data and reading back the data.
> 
> 85,550 seven-digit positive integers took 12 seconds.
> 
> In a real world program one could say that 7000 values per second can be sorted as they are assigned in parallel to a particular variable in a hosting program.
> 
> Austin O'Byrne.

Final update on performance.

These are the results: 

14250 seven-digit positive integers 1 - 2 secs 

28500 "" "" "" "" 1 - 2 secs 

42750 "" "" "" "" 1 - 2 secs 

85500 "" "" "" "" 2 - 3 secs 

Austin O'Byrne.
Clearly, these are extraordinary times for a sort program. 
(the measuring method isn't sensitive enough to give more exact times.) 

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 3:21:26 PM UTC+1, Austin Obyrne wrote:
> On Saturday, June 23, 2012 2:08:58 PM UTC+1, Austin Obyrne wrote:
> > On Saturday, June 23, 2012 11:20:10 AM UTC+1, Austin Obyrne wrote:
> > > On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> > > > On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> > > > > On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> > > > > >
> > > > > > I have been told that my program resembles a known sort program called
> > > > > > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > > > > > point out therefore that the salient thing about my “Parallel Sort” is that
> > > > > > my implementation is geared to capturing data during any unrelated program
> > > > > > run-time and assigning the data in such a way that the separate elements
> > > > > > index their own addresses in the sorting arrays.  A similarity with some
> > > > > > other existing paper algorithm is simply fortuitous.
> > > > > 
> > > > > What you have presented is an implementation of counting sort, nothing more. 
> > > > > There is nothing new or unique about your implementation.
> > > > > 
> > > > > -- 
> > > > > Jeff Carter
> > > > > "Apart from the sanitation, the medicine, education, wine,
> > > > > public order, irrigation, roads, the fresh water system,
> > > > > and public health, what have the Romans ever done for us?"
> > > > > Monty Python's Life of Brian
> > > > > 80
> > > > > 
> > > > > 
> > > > > 
> > > > > --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
> > > > 
> > > > 
> > > > There is no question of kudos-grabbing by me in this matter - I have already invented a world first in unbreakable cryptography that is here to stay, this is merely a useful adjunct to that so I am not exactly starving for attention.
> > > > 
> > > > see "Skew Line Encryptions - The Eventual Cipher"
> > > > 
> > > > http://www.adacrypt.com/introduction.html
> > > > 
> > > > There is a lot of 'dredging' for links going on these days that often are suspect assertions that have no properly established credence.  Even Wikipedia has to taken with a measured pinch of salt at the end of the day -the low-hanging fruit to many visitors but its usually only a starting point for further study by seriously minded people.
> > > > 
> > > > Because it is in print does not make a claim fire proof.
> > > > 
> > > > Unless "Count Sort" can deliver then it is not right to say it is an establisheed sort prog - it is derogatory to my invention in fact to make comparisons unless it can be backed up with stronger performance figures otherwise it is nothing more than a static paper sort program. 
> > > > 
> > > > In this day and age the onus is on the claimant to deliver fresh claims as a working computerised program since that is how it will be expected to run in reality - this must be demonstrated in lieu of mathemtaical proof which is impossible to do very often.
> > > > 
> > > > It doesn't matter to me how highly regarded my invention does become - I am already on the score board for better reasons.
> > > > 
> > > > PS - I have just done a test run on my "Parallel Sort" program invention using my very ordinary home computer and the results are:- 
> > > > 
> > > > 28500 seven-digit positive integers were sorted in less than 1 second. The crucial test part of the program was timed for that test as being the de facto sorting implement.
> > > > 
> > > > Can "Count Sort" beat that ?
> > > > 
> > > > Dredging for links in the internet is a poor substitute for proper intelligent research.  When these links surface they still need to be demonstrated properly and not accepted simply because they have appeared as link to someone's website and are quotable for that reason. 
> > > > 
> > > > Best Wishes.
> > > > 
> > > > Austin O'Byrne.
> > > 
> > > Update on performance.
> > > 
> > > 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
> > > 
> > > Waiting to hear regarding "Count Sort".
> > > 
> > > - adacrypt
> > 
> > Update on performance.
> > 
> > This time takes into account: 
> > 
> > Collecting the data. sorting the data and reading back the data.
> > 
> > 85,550 seven-digit positive integers took 12 seconds.
> > 
> > In a real world program one could say that 7000 values per second can be sorted as they are assigned in parallel to a particular variable in a hosting program.
> > 
> > Austin O'Byrne.
> 
> Final update on performance.
> 
> These are the results: 
> 
> 14250 seven-digit positive integers 1 - 2 secs 
> 
> 28500 "" "" "" "" 1 - 2 secs 
> 
> 42750 "" "" "" "" 1 - 2 secs 
> 
> 85500 "" "" "" "" 2 - 3 secs 
> 
> Austin O'Byrne.
> Clearly, these are extraordinary times for a sort program. 
> (the measuring method isn't sensitive enough to give more exact times.)

My earlier prediction might yet become true i.e. this implementation of "Parallel Sort" in Ada could well become a benchmark for future sort programs.

Austin O'Byrne

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 3:57:15 PM UTC+1, Austin Obyrne wrote:
> On Saturday, June 23, 2012 3:21:26 PM UTC+1, Austin Obyrne wrote:
> > On Saturday, June 23, 2012 2:08:58 PM UTC+1, Austin Obyrne wrote:
> > > On Saturday, June 23, 2012 11:20:10 AM UTC+1, Austin Obyrne wrote:
> > > > On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> > > > > On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> > > > > > On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> > > > > > >
> > > > > > > I have been told that my program resembles a known sort program called
> > > > > > > “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > > > > > > point out therefore that the salient thing about my “Parallel Sort” is that
> > > > > > > my implementation is geared to capturing data during any unrelated program
> > > > > > > run-time and assigning the data in such a way that the separate elements
> > > > > > > index their own addresses in the sorting arrays.  A similarity with some
> > > > > > > other existing paper algorithm is simply fortuitous.
> > > > > > 
> > > > > > What you have presented is an implementation of counting sort, nothing more. 
> > > > > > There is nothing new or unique about your implementation.
> > > > > > 
> > > > > > -- 
> > > > > > Jeff Carter
> > > > > > "Apart from the sanitation, the medicine, education, wine,
> > > > > > public order, irrigation, roads, the fresh water system,
> > > > > > and public health, what have the Romans ever done for us?"
> > > > > > Monty Python's Life of Brian
> > > > > > 80
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
> > > > > 
> > > > > 
> > > > > There is no question of kudos-grabbing by me in this matter - I have already invented a world first in unbreakable cryptography that is here to stay, this is merely a useful adjunct to that so I am not exactly starving for attention.
> > > > > 
> > > > > see "Skew Line Encryptions - The Eventual Cipher"
> > > > > 
> > > > > http://www.adacrypt.com/introduction.html
> > > > > 
> > > > > There is a lot of 'dredging' for links going on these days that often are suspect assertions that have no properly established credence.  Even Wikipedia has to taken with a measured pinch of salt at the end of the day -the low-hanging fruit to many visitors but its usually only a starting point for further study by seriously minded people.
> > > > > 
> > > > > Because it is in print does not make a claim fire proof.
> > > > > 
> > > > > Unless "Count Sort" can deliver then it is not right to say it is an establisheed sort prog - it is derogatory to my invention in fact to make comparisons unless it can be backed up with stronger performance figures otherwise it is nothing more than a static paper sort program. 
> > > > > 
> > > > > In this day and age the onus is on the claimant to deliver fresh claims as a working computerised program since that is how it will be expected to run in reality - this must be demonstrated in lieu of mathemtaical proof which is impossible to do very often.
> > > > > 
> > > > > It doesn't matter to me how highly regarded my invention does become - I am already on the score board for better reasons.
> > > > > 
> > > > > PS - I have just done a test run on my "Parallel Sort" program invention using my very ordinary home computer and the results are:- 
> > > > > 
> > > > > 28500 seven-digit positive integers were sorted in less than 1 second. The crucial test part of the program was timed for that test as being the de facto sorting implement.
> > > > > 
> > > > > Can "Count Sort" beat that ?
> > > > > 
> > > > > Dredging for links in the internet is a poor substitute for proper intelligent research.  When these links surface they still need to be demonstrated properly and not accepted simply because they have appeared as link to someone's website and are quotable for that reason. 
> > > > > 
> > > > > Best Wishes.
> > > > > 
> > > > > Austin O'Byrne.
> > > > 
> > > > Update on performance.
> > > > 
> > > > 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
> > > > 
> > > > Waiting to hear regarding "Count Sort".
> > > > 
> > > > - adacrypt
> > > 
> > > Update on performance.
> > > 
> > > This time takes into account: 
> > > 
> > > Collecting the data. sorting the data and reading back the data.
> > > 
> > > 85,550 seven-digit positive integers took 12 seconds.
> > > 
> > > In a real world program one could say that 7000 values per second can be sorted as they are assigned in parallel to a particular variable in a hosting program.
> > > 
> > > Austin O'Byrne.
> > 
> > Final update on performance.
> > 
> > These are the results: 
> > 
> > 14250 seven-digit positive integers 1 - 2 secs 
> > 
> > 28500 "" "" "" "" 1 - 2 secs 
> > 
> > 42750 "" "" "" "" 1 - 2 secs 
> > 
> > 85500 "" "" "" "" 2 - 3 secs 
> > 
> > Austin O'Byrne.
> > Clearly, these are extraordinary times for a sort program. 
> > (the measuring method isn't sensitive enough to give more exact times.)
> 
> My earlier prediction might yet become true i.e. this implementation of "Parallel Sort" in Ada could well become a benchmark for future sort programs.
> 
> Austin O'Byrne

Re: Recapping on “Bug Sort”.

[Pascal Obry]

Austin,

>> These are the results: 
>>
>> 14250 seven-digit positive integers 1 - 2 secs 
>>
>> 28500 "" "" "" "" 1 - 2 secs 
>>
>> 42750 "" "" "" "" 1 - 2 secs 
>>
>> 85500 "" "" "" "" 2 - 3 secs 

What are the timing on the *same machine* for a *quick sort*? Without
this I just cannot guess how fast those timing are!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 5:07:54 PM UTC+1, Pascal Obry wrote:
> Austin,
> 
> >> These are the results: 
> >>
> >> 14250 seven-digit positive integers 1 - 2 secs 
> >>
> >> 28500 "" "" "" "" 1 - 2 secs 
> >>
> >> 42750 "" "" "" "" 1 - 2 secs 
> >>
> >> 85500 "" "" "" "" 2 - 3 secs 
> 
> What are the timing on the *same machine* for a *quick sort*? Without
> this I just cannot guess how fast those timing are!
> 
> Pascal.
> 
> -- 
> 
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|    http://www.obry.net  -  http://v2p.fr.eu.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

No idea I'm afraid.

Austin.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 5:07:54 PM UTC+1, Pascal Obry wrote:
> Austin,
> 
> >> These are the results: 
> >>
> >> 14250 seven-digit positive integers 1 - 2 secs 
> >>
> >> 28500 "" "" "" "" 1 - 2 secs 
> >>
> >> 42750 "" "" "" "" 1 - 2 secs 
> >>
> >> 85500 "" "" "" "" 2 - 3 secs 
> 
> What are the timing on the *same machine* for a *quick sort*? Without
> this I just cannot guess how fast those timing are!
> 
> Pascal.
> 
> -- 
> 
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|    http://www.obry.net  -  http://v2p.fr.eu.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

I'd imagine running a quick sort program would mean collecting the data as part of the test operation - this where my program gets the advantage of running in parallel with the program variables being sorted - it happens in parallel with the program during runtime and requires no extra time spent on collection.

Austin O'Byrne.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 5:07:54 PM UTC+1, Pascal Obry wrote:
> Austin,
> 
> >> These are the results: 
> >>
> >> 14250 seven-digit positive integers 1 - 2 secs 
> >>
> >> 28500 "" "" "" "" 1 - 2 secs 
> >>
> >> 42750 "" "" "" "" 1 - 2 secs 
> >>
> >> 85500 "" "" "" "" 2 - 3 secs 
> 
> What are the timing on the *same machine* for a *quick sort*? Without
> this I just cannot guess how fast those timing are!
> 
> Pascal.
> 
> -- 
> 
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|    http://www.obry.net  -  http://v2p.fr.eu.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

I doubt that I could adapt "Quick sort" to read from variables in another program - the whole idea is counter productive without materially changing "quick sort " to do that.  Only then could the comparison begin and frankly I do't see "Quick Sort" being quicker than "Parallel Sort" in the resulting hybrid program.

Austin.

Re: Recapping on “Bug Sort”.

[Niklas Holsti]

On 12-06-23 13:20 , Austin Obyrne wrote:
> On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
>> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
>>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
>>>>
>>>> I have been told that my program resembles a known sort program called
>>>> �Counting Sort�.  I would hate to be guilty of plagiarism and I would like to
>>>> point out therefore that the salient thing about my �Parallel Sort� is that
>>>> my implementation is geared to capturing data during any unrelated program
>>>> run-time and assigning the data in such a way that the separate elements
>>>> index their own addresses in the sorting arrays.  A similarity with some
>>>> other existing paper algorithm is simply fortuitous.
>>>
>>> What you have presented is an implementation of counting sort, nothing more.
>>> There is nothing new or unique about your implementation.

Austin,

While I agree with Jeff that you have rediscovered Counting Sort, this 
does not mean that you are being accused of plagiarism. It is common for 
programmers to rediscover algorithms that are basically simple, but very 
good for some special cases -- and perhaps for just these reasons are 
not very well known.

I could imagine posing this sorting problem (sorting a dense set of 
numbers in a known, not too wide range) in a class on programming (not 
an advanced class, either) and would expect some of the students to use 
this method (i.e. Counting Sort) in their solutions.

> Update on performance.
>
> 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
>
> Waiting to hear regarding "Count Sort".

Since your method is an implementation of Counting Sort, you are 
actually measuring "Counting Sort", at least in one implementation.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Recapping on “Bug Sort”.

[Niklas Holsti]

On 12-06-23 17:21 , Austin Obyrne wrote:
> On Saturday, June 23, 2012 2:08:58 PM UTC+1, Austin Obyrne wrote:
>> On Saturday, June 23, 2012 11:20:10 AM UTC+1, Austin Obyrne wrote:
>>> On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
>>>> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
>>>>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
>>>>>>
>>>>>> I have been told that my program resembles a known sort program called
>>>>>> �Counting Sort�.  I would hate to be guilty of plagiarism and I would like to
>>>>>> point out therefore that the salient thing about my �Parallel Sort� is that
>>>>>> my implementation is geared to capturing data during any unrelated program
>>>>>> run-time and assigning the data in such a way that the separate elements
>>>>>> index their own addresses in the sorting arrays.  A similarity with some
>>>>>> other existing paper algorithm is simply fortuitous.
>>>>>
>>>>> What you have presented is an implementation of counting sort, nothing more.
>>>>> There is nothing new or unique about your implementation.
 > ...
>
> Final update on performance.
>
> These are the results:
>
> 14250 seven-digit positive integers 1 - 2 secs
>
> 28500 "" "" "" "" 1 - 2 secs
>
> 42750 "" "" "" "" 1 - 2 secs
>
> 85500 "" "" "" "" 2 - 3 secs
>
> Austin O'Byrne.
> Clearly, these are extraordinary times for a sort program.
> (the measuring method isn't sensitive enough to give more exact times.)

The times are not so good. I ran the following command on my MacBook Air 
(old model, not a superfast machine); this command generates a text file 
with 85500 7-digit numbers in a more or less mixed order and sorts it 
into descdending order with the Unix "sort" program:

yes | head -85500 | pr -n:7 -t | cut -d: -f1 | tr ' 0123456789' 
'09472601583' | (time sort -n -r >sorted)

The output from the "time" command that measures the "sort" process is:

real	0m0.133s
user	0m0.068s
sys	0m0.011s

This means that even the elapsed time, including all the I/O, is only 
0.133 seconds. Note that the "sort" program is a very general one, so it 
should have lots of overhead compared to a program written to sort only 
a set of integers.

If your program handles 7-digit integers, your "count" array will have 
10 million elements. Most of the time taken by your program will be 
spent in initializing the array to "all zero" and in scanning the array 
from start to end to pick up and output the 85500 numbers, which fill 
less than 1% of the array. This is the drawback of the Counting Sort 
method: if the data is sparse in its range, there is lots of overhead 
both in time and memory usage.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 7:05:56 PM UTC+1, Niklas Holsti wrote:
> On 12-06-23 13:20 , Austin Obyrne wrote:
> > On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> >> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> >>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> >>>>
> >>>> I have been told that my program resembles a known sort program called
> >>>> “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> >>>> point out therefore that the salient thing about my “Parallel Sort” is that
> >>>> my implementation is geared to capturing data during any unrelated program
> >>>> run-time and assigning the data in such a way that the separate elements
> >>>> index their own addresses in the sorting arrays.  A similarity with some
> >>>> other existing paper algorithm is simply fortuitous.
> >>>
> >>> What you have presented is an implementation of counting sort, nothing more.
> >>> There is nothing new or unique about your implementation.
> 
> Austin,
> 
> While I agree with Jeff that you have rediscovered Counting Sort, this 
> does not mean that you are being accused of plagiarism. It is common for 
> programmers to rediscover algorithms that are basically simple, but very 
> good for some special cases -- and perhaps for just these reasons are 
> not very well known.
> 
> I could imagine posing this sorting problem (sorting a dense set of 
> numbers in a known, not too wide range) in a class on programming (not 
> an advanced class, either) and would expect some of the students to use 
> this method (i.e. Counting Sort) in their solutions.
> 
> > Update on performance.
> >
> > 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
> >
> > Waiting to hear regarding "Count Sort".
> 
> Since your method is an implementation of Counting Sort, you are 
> actually measuring "Counting Sort", at least in one implementation.
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Thanks for that.

The very salient thing that everybody is missing is the way the data is collected and sorted simultaneously in "Parallel Sort" compared to Count Sort.  Parallel Sort is more a piece of computer science being implemeted in the Ada programming language.

Frankly I am not familiar with Count Sort in practise (being a comparison program puts it beyond the pale to me ) but can I ask you one question that will make my point more clearly.

If I asked you to demonstrate "Count Sort" being used to sort a specimen set of data how would you go about making the data available to the program.

Somewhere along the line you would have to prepare an external batch file for reading in or you would key in the data interactively - it has to be like that all the time with Count Sort - herein lies the difference - my program captures the data in parallel at the very origin ie as it is computed - no double handling => huge time and labour saving.

The counting part is trivial.  It is the capturing concept that is the important difference between what I am calling Parallel Sort and what anyone else may call Count Sort .  The counting is almost benign when the elements of data index their own addresses in an array in both cases.  

There is only a very tenuous connection in this fact however, plus that both sort programs eschew all comparisom methods and simply count the data according to magnitude as the means of sorting it. This common factor is not sufficient in itself however in my view to be grounds for any one to say that they are largely related versions of the same program.  They have only a very small amount in common. It is a huge leap from my parallel program to the count sort program in doing this - they have far too little in common to be lumped together like this.

I await your answer on how is the data introduced to a sort program that you  would use at home say.

Regards,

Austin.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 7:17:24 PM UTC+1, Niklas Holsti wrote:
> On 12-06-23 17:21 , Austin Obyrne wrote:
> > On Saturday, June 23, 2012 2:08:58 PM UTC+1, Austin Obyrne wrote:
> >> On Saturday, June 23, 2012 11:20:10 AM UTC+1, Austin Obyrne wrote:
> >>> On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> >>>> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> >>>>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> >>>>>>
> >>>>>> I have been told that my program resembles a known sort program called
> >>>>>> “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> >>>>>> point out therefore that the salient thing about my “Parallel Sort” is that
> >>>>>> my implementation is geared to capturing data during any unrelated program
> >>>>>> run-time and assigning the data in such a way that the separate elements
> >>>>>> index their own addresses in the sorting arrays.  A similarity with some
> >>>>>> other existing paper algorithm is simply fortuitous.
> >>>>>
> >>>>> What you have presented is an implementation of counting sort, nothing more.
> >>>>> There is nothing new or unique about your implementation.
>  > ...
> >
> > Final update on performance.
> >
> > These are the results:
> >
> > 14250 seven-digit positive integers 1 - 2 secs
> >
> > 28500 "" "" "" "" 1 - 2 secs
> >
> > 42750 "" "" "" "" 1 - 2 secs
> >
> > 85500 "" "" "" "" 2 - 3 secs
> >
> > Austin O'Byrne.
> > Clearly, these are extraordinary times for a sort program.
> > (the measuring method isn't sensitive enough to give more exact times.)
> 
> The times are not so good. I ran the following command on my MacBook Air 
> (old model, not a superfast machine); this command generates a text file 
> with 85500 7-digit numbers in a more or less mixed order and sorts it 
> into descdending order with the Unix "sort" program:
> 
> yes | head -85500 | pr -n:7 -t | cut -d: -f1 | tr ' 0123456789' 
> '09472601583' | (time sort -n -r >sorted)
> 
> The output from the "time" command that measures the "sort" process is:
> 
> real	0m0.133s
> user	0m0.068s
> sys	0m0.011s
> 
> This means that even the elapsed time, including all the I/O, is only 
> 0.133 seconds. Note that the "sort" program is a very general one, so it 
> should have lots of overhead compared to a program written to sort only 
> a set of integers.
> 
> If your program handles 7-digit integers, your "count" array will have 
> 10 million elements. Most of the time taken by your program will be 
> spent in initializing the array to "all zero" and in scanning the array 
> from start to end to pick up and output the 85500 numbers, which fill 
> less than 1% of the array. This is the drawback of the Counting Sort 
> method: if the data is sparse in its range, there is lots of overhead 
> both in time and memory usage.
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Sorry, I missed half your message before I started writing - it is still substantially true I believe - *you were able to generate a test program quickly in order to test the run time but how in the real world would you input the data from another source i.e. beyond your control, to your 'Count Sort' program. It would have to be keyed in somewhere by a human operator?? 

Cheers. 

Austin.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 8:07:58 PM UTC+1, Austin Obyrne wrote:
> On Saturday, June 23, 2012 7:05:56 PM UTC+1, Niklas Holsti wrote:
> > On 12-06-23 13:20 , Austin Obyrne wrote:
> > > On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne wrote:
> > >> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter wrote:
> > >>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> > >>>>
> > >>>> I have been told that my program resembles a known sort program called
> > >>>> “Counting Sort”.  I would hate to be guilty of plagiarism and I would like to
> > >>>> point out therefore that the salient thing about my “Parallel Sort” is that
> > >>>> my implementation is geared to capturing data during any unrelated program
> > >>>> run-time and assigning the data in such a way that the separate elements
> > >>>> index their own addresses in the sorting arrays.  A similarity with some
> > >>>> other existing paper algorithm is simply fortuitous.
> > >>>
> > >>> What you have presented is an implementation of counting sort, nothing more.
> > >>> There is nothing new or unique about your implementation.
> > 
> > Austin,
> > 
> > While I agree with Jeff that you have rediscovered Counting Sort, this 
> > does not mean that you are being accused of plagiarism. It is common for 
> > programmers to rediscover algorithms that are basically simple, but very 
> > good for some special cases -- and perhaps for just these reasons are 
> > not very well known.
> > 
> > I could imagine posing this sorting problem (sorting a dense set of 
> > numbers in a known, not too wide range) in a class on programming (not 
> > an advanced class, either) and would expect some of the students to use 
> > this method (i.e. Counting Sort) in their solutions.
> > 
> > > Update on performance.
> > >
> > > 42750 seven-digit positive integers were sorted in between 1 and 2 seconds.
> > >
> > > Waiting to hear regarding "Count Sort".
> > 
> > Since your method is an implementation of Counting Sort, you are 
> > actually measuring "Counting Sort", at least in one implementation.
> > 
> > -- 
> > Niklas Holsti
> > Tidorum Ltd
> > niklas holsti tidorum fi
> >        .      @       .
> 
> Thanks for that.
> 
> The very salient thing that everybody is missing is the way the data is collected and sorted simultaneously in "Parallel Sort" compared to Count Sort.  Parallel Sort is more a piece of computer science being implemeted in the Ada programming language.
> 
> Frankly I am not familiar with Count Sort in practise (being a comparison program puts it beyond the pale to me ) but can I ask you one question that will make my point more clearly.
> 
> If I asked you to demonstrate "Count Sort" being used to sort a specimen set of data how would you go about making the data available to the program.
> 
> Somewhere along the line you would have to prepare an external batch file for reading in or you would key in the data interactively - it has to be like that all the time with Count Sort - herein lies the difference - my program captures the data in parallel at the very origin ie as it is computed - no double handling => huge time and labour saving.
> 
> The counting part is trivial.  It is the capturing concept that is the important difference between what I am calling Parallel Sort and what anyone else may call Count Sort .  The counting is almost benign when the elements of data index their own addresses in an array in both cases.  
> 
> There is only a very tenuous connection in this fact however, plus that both sort programs eschew all comparisom methods and simply count the data according to magnitude as the means of sorting it. This common factor is not sufficient in itself however in my view to be grounds for any one to say that they are largely related versions of the same program.  They have only a very small amount in common. It is a huge leap from my parallel program to the count sort program in doing this - they have far too little in common to be lumped together like this.
> 
> I await your answer on how is the data introduced to a sort program that you  would use at home say.
> 
> Regards,
> 
> Austin.

Correction : Count Sort is not a comparison based sort program - I got mixed up with "Quick Sort".

Re: Recapping on “Bug Sort”.

[Jeffrey Carter]

On 06/23/2012 12:07 PM, Austin Obyrne wrote:
>
> The very salient thing that everybody is missing is the way the data is
> collected and sorted simultaneously in "Parallel Sort" compared to Count
> Sort.

What you are missing is that you have seen 2 implementations of Counting Sort. 
The one in Wikipedia is presented as a standalone subprogram that gets an input 
array of values and sorts it into an output array. This is how a reusable 
implementation would look. Since Counting Sort is not a general sorting 
algorithm, few real implementations will look like this. Instead, they will look 
like:

Your implementation, which is not a standalone subprogram nor reusable, that has 
the operations of the algorithm scattered through the program that is 
collecting/generating the data to be sorted.

-- 
Jeff Carter
"Ah, go away or I'll kill ya."
Never Give a Sucker an Even Break
100



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Recapping on “Bug Sort”.

[Niklas Holsti]

On 12-06-23 22:07 , Austin Obyrne wrote:
> On Saturday, June 23, 2012 7:05:56 PM UTC+1, Niklas Holsti wrote:
>> On 12-06-23 13:20 , Austin Obyrne wrote:
>>> On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne
>>> wrote:
>>>> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter
>>>> wrote:
>>>>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
>>>>>>
>>>>>> I have been told that my program resembles a known sort
>>>>>> program called �Counting Sort�.  I would hate to be guilty
>>>>>> of plagiarism and I would like to point out therefore that
>>>>>> the salient thing about my �Parallel Sort� is that my
>>>>>> implementation is geared to capturing data during any
>>>>>> unrelated program run-time and assigning the data in such a
>>>>>> way that the separate elements index their own addresses in
>>>>>> the sorting arrays.  A similarity with some other existing
>>>>>> paper algorithm is simply fortuitous.
>>>>>
>>>>> What you have presented is an implementation of counting
>>>>> sort, nothing more. There is nothing new or unique about your
>>>>> implementation.
>>
>> Austin,
>>
>> While I agree with Jeff that you have rediscovered Counting Sort,
>> this does not mean that you are being accused of plagiarism. It is
>> common for programmers to rediscover algorithms that are basically
>> simple, but very good for some special cases -- and perhaps for
>> just these reasons are not very well known.
>
> Thanks for that.
>
> The very salient thing that everybody is missing is the way the data
> is collected and sorted simultaneously in "Parallel Sort" compared to
> Count Sort.

Yes, it is a neat feature of Counting Sort that the first step of the 
sort -- adding the values to the "count" array -- can be done for each 
new value separately, independently of the other values (since it is not 
a comparison sort). Only the second step, the final scan of the "count" 
array and output of the values in sorted order, must be delayed until 
all values are present.

This means, as you say, that the program can do the first step (add to 
"count" array) immediately when a new value is generated; it is not 
necessary to first collect all the values in some list, say, and then 
sort them.

But I don't think that the group is "missing" this fact; rather, we see 
that it does not change the order of complexity (big-oh) of the 
algorithm, so it is not very interesting.

In fact, I'm not at all sure that adding the new values to the "count" 
array immediately is faster than first collecting them in a dense, 
unordered structure (array or list) and then sorting them. The frequent 
scattered references to the large "count" array can stress the data 
cache and virtual memory system, perhaps causing more data-cache misses 
and page faults which could make the program run slower.

> If I asked you to demonstrate "Count Sort" being used to sort a
> specimen set of data how would you go about making the data available
> to the program.

This is not an interesting question, again because the complexity of 
writing out and reading in a list of N integers is linear, O(N), in the 
number of integers.

> Somewhere along the line you would have to prepare an external batch
> file for reading in or you would key in the data interactively

I can't make head or tail of that. You seem not to know how one can pass 
data from one part of a program to another, or from one program to 
another, without human intervention.

> The counting part is trivial.  It is the capturing concept that is
> the important difference between what I am calling Parallel Sort and
> what anyone else may call Count Sort .  The counting is almost benign
> when the elements of data index their own addresses in an array in
> both cases.

My view is the opposite. The "capturing" is just normal programming, 
passing data from here to there within a program. Adding the data to the 
"count" array at once may or may not be an advantage for speed, see 
above. From the point of view of the sorting problem, the central point 
in Counting Sort is the "count" array that is indexed directly by the 
values to be sorted. *When* then values are added to the array is not 
imporant, IMO.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Recapping on “Bug Sort”.

[Ludovic Brenta]

Austin Obyrne writes on comp.lang.ada:
> how in the real world would you input the data from another source
> i.e. beyond your control, to your 'Count Sort' program. It would have
> to be keyed in somewhere by a human operator??

Or multiple human operators.  Or automatic radar plots.  Or some
temperature, pressure, position, wavelength or whatever, sampled by
automatic sensors, 1000 samples per second.  Really, generating data is
not a problem.

Note that the Unix "sort" program reads from standard input, which may
be a file on a local disk, a file on a remote array of disks, or a pipe
fed by some arbitrarily complex combination of programs.  The "problem"
when reading from standard input is that you can't rewind or push back
into standard input.  Once you have read a byte from it, you can't read
it again, you *must* process it immediately or store it in memory.

-- 
Ludovic Brenta.

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 9:00:48 PM UTC+1, Jeffrey Carter wrote:
> On 06/23/2012 12:07 PM, Austin Obyrne wrote:
> >
> > The very salient thing that everybody is missing is the way the data is
> > collected and sorted simultaneously in "Parallel Sort" compared to Count
> > Sort.
> 
> What you are missing is that you have seen 2 implementations of Counting Sort. 
> The one in Wikipedia is presented as a standalone subprogram that gets an input 
> array of values and sorts it into an output array. This is how a reusable 
> implementation would look. Since Counting Sort is not a general sorting 
> algorithm, few real implementations will look like this. Instead, they will look 
> like:
> 
> Your implementation, which is not a standalone subprogram nor reusable, that has 
> the operations of the algorithm scattered through the program that is 
> collecting/generating the data to be sorted.
> 
> -- 
> Jeff Carter
> "Ah, go away or I'll kill ya."
> Never Give a Sucker an Even Break
> 100
> 
> 
> 
> --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Nope,

I haven't seen anything at all in Wikipedia . 

What I have is an embedded program that collects and sorts data with the minimum of handling, it happens to share a very small common feature with "Count Sort" in the way that sorting is done according to magnitude.  This does not justify saying that it is a clone or even a strong resemblance of "Count Sort" however. 

It is quite wrong and really stretching a weak connection to say that my "Parallel Sort" is a rediscovery of "Count Sort" - the comparison is too tenuous by a long way. 

"Parallel Sort" studiously obviates the need fo any user assistance by way of keyboard operators or externally prepared batch files. *This is the nub of the matter.

The shared sorting method is almost trivial.


Regards - Austin O'Byrne

Re: Recapping on “Bug Sort”.

[Austin Obyrne]

On Saturday, June 23, 2012 9:12:59 PM UTC+1, Niklas Holsti wrote:
> On 12-06-23 22:07 , Austin Obyrne wrote:
> > On Saturday, June 23, 2012 7:05:56 PM UTC+1, Niklas Holsti wrote:
> >> On 12-06-23 13:20 , Austin Obyrne wrote:
> >>> On Saturday, June 23, 2012 8:54:52 AM UTC+1, Austin Obyrne
> >>> wrote:
> >>>> On Friday, June 22, 2012 9:45:53 PM UTC+1, Jeffrey Carter
> >>>> wrote:
> >>>>> On 06/22/2012 12:55 PM, Austin Obyrne wrote:
> >>>>>>
> >>>>>> I have been told that my program resembles a known sort
> >>>>>> program called “Counting Sort”.  I would hate to be guilty
> >>>>>> of plagiarism and I would like to point out therefore that
> >>>>>> the salient thing about my “Parallel Sort” is that my
> >>>>>> implementation is geared to capturing data during any
> >>>>>> unrelated program run-time and assigning the data in such a
> >>>>>> way that the separate elements index their own addresses in
> >>>>>> the sorting arrays.  A similarity with some other existing
> >>>>>> paper algorithm is simply fortuitous.
> >>>>>
> >>>>> What you have presented is an implementation of counting
> >>>>> sort, nothing more. There is nothing new or unique about your
> >>>>> implementation.
> >>
> >> Austin,
> >>
> >> While I agree with Jeff that you have rediscovered Counting Sort,
> >> this does not mean that you are being accused of plagiarism. It is
> >> common for programmers to rediscover algorithms that are basically
> >> simple, but very good for some special cases -- and perhaps for
> >> just these reasons are not very well known.
> >
> > Thanks for that.
> >
> > The very salient thing that everybody is missing is the way the data
> > is collected and sorted simultaneously in "Parallel Sort" compared to
> > Count Sort.
> 
> Yes, it is a neat feature of Counting Sort that the first step of the 
> sort -- adding the values to the "count" array -- can be done for each 
> new value separately, independently of the other values (since it is not 
> a comparison sort). Only the second step, the final scan of the "count" 
> array and output of the values in sorted order, must be delayed until 
> all values are present.
> 
> This means, as you say, that the program can do the first step (add to 
> "count" array) immediately when a new value is generated; it is not 
> necessary to first collect all the values in some list, say, and then 
> sort them.
> 
> But I don't think that the group is "missing" this fact; rather, we see 
> that it does not change the order of complexity (big-oh) of the 
> algorithm, so it is not very interesting.
> 
> In fact, I'm not at all sure that adding the new values to the "count" 
> array immediately is faster than first collecting them in a dense, 
> unordered structure (array or list) and then sorting them. The frequent 
> scattered references to the large "count" array can stress the data 
> cache and virtual memory system, perhaps causing more data-cache misses 
> and page faults which could make the program run slower.
> 
> > If I asked you to demonstrate "Count Sort" being used to sort a
> > specimen set of data how would you go about making the data available
> > to the program.
> 
> This is not an interesting question, again because the complexity of 
> writing out and reading in a list of N integers is linear, O(N), in the 
> number of integers.
> 
> > Somewhere along the line you would have to prepare an external batch
> > file for reading in or you would key in the data interactively
> 
> I can't make head or tail of that. You seem not to know how one can pass 
> data from one part of a program to another, or from one program to 
> another, without human intervention.
> 
> > The counting part is trivial.  It is the capturing concept that is
> > the important difference between what I am calling Parallel Sort and
> > what anyone else may call Count Sort .  The counting is almost benign
> > when the elements of data index their own addresses in an array in
> > both cases.
> 
> My view is the opposite. The "capturing" is just normal programming, 
> passing data from here to there within a program. Adding the data to the 
> "count" array at once may or may not be an advantage for speed, see 
> above. From the point of view of the sorting problem, the central point 
> in Counting Sort is the "count" array that is indexed directly by the 
> values to be sorted. *When* then values are added to the array is not 
> imporant, IMO.
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Many thanks for all the contributions.  I am drawing a line under this topic now. I gather from your last communique that Count Sort is also an embedded sort program identical to the use I envisaged for my Parallel Sort.  I had decided that this was generally not the case and Count Sort was used interactively only in say academia (with full respect to academia).  Apparently I was wrong there.

Many thanks again for your help in this entire matter.

Austin.