Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mnetor.UUCP
Path: utzoo!utcs!mnetor!george
From: george@mnetor.UUCP (George Hart)
Newsgroups: net.lang
Subject: Re: Efficiency of Languages ?
Message-ID: <2511@mnetor.UUCP>
Date: Fri, 1-Nov-85 09:11:46 EST
Article-I.D.: mnetor.2511
Posted: Fri Nov  1 09:11:46 1985
Date-Received: Fri, 1-Nov-85 10:32:18 EST
References: <15100004@ada-uts.UUCP> <15100007@ada-uts.UUCP>
Reply-To: george@mnetor.UUCP (George Hart)
Organization: Computer X (CANADA) Ltd., Toronto, Ontario, Canada
Lines: 47

In article <15100007@ada-uts.UUCP> richw@ada-uts.UUCP writes:
>YES, expensive features can be done in hardware.  The proof
>that I know of that no sort can run faster than O(n log n)
>is based on an analysis of possible decision trees (i.e. any
>comparison-based sort will have a decision tree with n! leaves,
>so must be O(n log n) depth, or something like that -- check
>some algorithms text for the details).  The important point
>is that this proof relies on assumptions about ARCHITECTURE.
>It assumes that more than one comparison will NOT be done at
>the same time.  Next time you come across an algorithms text,
>think twice why they talk so much about RAM (random-access machines).
>
>I believe that one can find the N-th highest number in an
>unsorted list in less than O(n log n) time (I'd have to check
>my algorithms books to make sure, but...)  Throw n different
>processors at an unsorted array, one looking for the first
>highest, the second looking for the second highest, etc.
>Have these processors work concurrently.  Voila!

I, too, should probably consult an algorithms book but assuming
concurrent Von Neumann processors:

Seems like the nth processor would still have to sort the first n
numbers from a list of N and at least look at the remaining N-n numbers
(they can be discarded if they are higher than the current nth number).

The first and last processors are special cases because looking for the
min and max numbers in a list is a O(N) operation (I think).  They only
need to look at each list item once. But the 2 to N-1th processors
still have to work in something close to O(n log n) time.

Wouldn't it be faster to partition the list, have each processor work
on a sublist and merge the results?  Given m processors and a list of N
numbers, this would be a O(N/m log N/m + K) operation where K is the
time required to merge m sorted lists of N/m numbers.


Where is Knuth when you need him......:-)

-- 


Regards,

George Hart, Computer X Canada Ltd.
UUCP: {allegra|decvax|duke|floyd|linus|ihnp4}!utzoo!mnetor!george
BELL: (416)475-8980