Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site spuxll.UUCP Path: utzoo!linus!vaxine!wjh12!genrad!decvax!ucbvax!ucbcad!tektronix!hplabs!hao!seismo!cmcl2!floyd!whuxle!spuxll!ech From: ech@spuxll.UUCP Newsgroups: net.lang Subject: Re: Merge Sort Message-ID: <501@spuxll.UUCP> Date: Fri, 15-Jun-84 16:35:07 EDT Article-I.D.: spuxll.501 Posted: Fri Jun 15 16:35:07 1984 Date-Received: Thu, 21-Jun-84 01:40:20 EDT References: <2126@mit-eddie.UUCP> Organization: AT&T Information Systems, South Plainfield NJ Lines: 17 Yes, a merge sort is *always* O(n log n). However, one has to go to heroic measures to do a merge that is both O(n) time and *in-place*. Quicksort, bubble sort, and others of that ilk are in-place and USUALLY O(n log n); heapsort is ALWAYS O(n log n) but has (at least according to Knuth) a higher proportionality constant. An in-place linear merge is possible, but also has an impossible constant: there is one by Kronrod, recounted in the exercises of Knuth v. 3 (I don't remember exactly -- check the index for Kronrod). If there is any more interest in this particular dead end :-) let me know. I have a particularly nifty O(n log n) merge (results in a O(n (log n)^2) sort) which is in-place and has some other neat properties. think of it as a puzzle, and yes it is a divide-and-conquer algorithm... =Ned=