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