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=