Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!unc!mcnc!decvax!cca!g-rh
From: g-rh@cca.UUCP (Richard Harter)
Newsgroups: net.math
Subject: Re: YASMP (Yet Another Sorting Methods Posting)
Message-ID: <3130@cca.UUCP>
Date: Sun, 30-Jun-85 04:04:30 EDT
Article-I.D.: cca.3130
Posted: Sun Jun 30 04:04:30 1985
Date-Received: Wed, 3-Jul-85 09:22:29 EDT
References: <3070@cca.UUCP> <>
Reply-To: g-rh@cca-unix.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge
Lines: 73
Summary: 


Me:

>> 	Finally, radix sorting is O(n log n), at best.  The
>> reason is that the keys must be at least log n bits long to
>> represent n distinct keys.

Wayne Throop:

>Not quite.  Radix sorting is O(n * m), where n is the number of records,
>and m is some muliplier derived from the length of the key.  However,
>the multiplier m is NOT related to the number of records, but to the way
>the instance of the radix sort algorithm chooses to view the keys.
>While it is true that the keys must be at least log n bits long to get
>unique keys, this does not limit the speed of the radix sort, since a)
>more than one bit is processed "at a time", and b) the keys need not be
>unique.
>
>Again, *comparison sorting* is limited to O(n log n), because of the
>fundamental nature of sorting by comparing keys.  Other forms of sorting
>are *not* limited to O(n log n), but they *cannot* depend (totally) on
>comparison.  Radix sorting does not in any way depend on comparing keys,
>in the same sense that a person processing mail doesn't need to compare
>the zip codes on one of the letters to the zip codes on the others.
>
>[Also, read Knuth's "Sorting and Searching"... it contains
> all of the above, and a lot more.  It explicitly states these
> properties of radix sort.]
>
>[As a trivial example to show that the m in the O(n * m) radix sort
> can be smaller than log n, with more than n possible keys, consider
> sorting keys which are integers from 0 to 3.  There are (log2 4) bits
> in these keys, but clearly a radix sort in this case still takes only n
> operations, not 2n.]

You are quite correct in pointing out that the coefficient of n in the
lower bound for the radix sort depends on the number of unique keys 
rather than the size of n.  However the point about processing more
than one bit at a time is not well taken.  Suppose that we have M
distinct keys and that m is the number of bits needed to express the
M keys.  m is bounded below by log2(M) but may be greater.  Suppose
that we process p bits at a time.  Then the sort requires O(n * m / p)
operations which is still O (n * m). [n and m are the variables for
the O operator; p is a constant.]  Changing the base of the log in
an O(n log n) algorithm does not change the order of the algorithm,
even though it may speed it up by a magnificent constant factor.

It is also, I think, a little misleading to say that radix sorting
does not use comparison.  In effect, each key in the list is compared
with a test value in each pass.  (This is concealed in the usual
low end to high end implementation of a radix sort; however it is
explicit if you use the equivalent high end to low end implementation
with sublists.)  Quicksort also compares each key against a test value;
the difference is that the quicksort test values are always members
of the set of keys.

The interesting thing about the radix sort is that it permits us to
do multiple comparisons in a single operation.  (This can be done
either sorting low end to high end or high end to low end.)  In
practice radix sorts win (where applicable) for this reason.  For
example, I can sort a list of 32 bit integers using 4 passes with
a radix sort which processes 8 bits at a time.  Using quicksort it
would take me 10 passes (on average) to sort 1024 keys.  Note also
that it would take 32 passes with the radix sort if I processed one
bit at a time.  The fundamental reason that one can 'batch' comparisons
in an operation is that the radix sort uses data-independent test
values rather than test values drawn from data as is done in
'comparison' sorts.  The data-independent test values used by the
radix sort are such that the intrinsic parallelism (at the bit
level within a word) of the CPU can be exploited.

			Richard Harter
			g-rh@cca.UUCP