Talk:Merge sort/Archive 1

Standardization
Shouldn't this article be more structurally similar to the Insertion Sort article? --Guugolpl0x (talk) 04:00, 6 September 2010 (UTC)

Defect in Merge Pseudocode
The merge function pseudocode appears to be incorrect. If left is [2, 16] and right is [-18, 1], the result will be [-18, 1, 2]; it should be [-18, 1, 2, 16]. This could be fixed by appending the contents of left or right with a loop rather than incorrectly assuming that only one item will remain. Titaniumdecoy (talk) 00:54, 24 March 2010 (UTC)

sort
On a boring weekend, I sat down with my computer trying to implement some sorting algorithms. Then I started working on a Mergesort implementation. I didn't have internet access, so all the help I had was foggy memories of this page. Everything went fine until I started working on the merge function (I was programming in Java, BTW). I tried to make a merge function that could merge the two ranges without using a temporary array, something like the above merge function in C, but without the v1 and v2 arrays. (I thought that I had seen such a method on this page - came back tonight and saw that I hadn't ;-)

I had limited success in making the function work - is it at all possible?


 * moved from article page -- John Owens 20:48 Apr 21, 2003 (UTC)
 * # (cur) (last) . . 15:33 Apr 21, 2003 . . 217.209.32.132 (The tale of Joe Random Hacker trying to make a merge function without using temporary arrays)


 * I have to ask why you're saying merge sort can't be implemented without temporary arrays. There is a "C code" section below here which shows exactly this -- how to implement merge sort without any temporary arrays.--Manixrock (talk) 12:44, 17 April 2010 (UTC)


 * You mean apart from temp1 and temp2? Oli Filth(talk&#124;contribs) 13:27, 17 April 2010 (UTC)

Replacing the C sample code
I think the current C sample code isn't very useful. The purpose of sample code on an algorithm page has to be to convey how the algorithm works, in a concise and readable manner. The point is not to provide an efficient implementation that users can copy&paste.

I propose replacing the lengthy C sample by the following Python code:

def merge(a, b): # Merging is trivial if one list is empty. if len(a) == 0: return b if len(b) == 0: return a  # Merge non-empty lists by taking the smaller one of the two # head elements, and recursively merging the remaining lists. if a[0] <= b[0]: return a[0:1] + merge(a[1:], b) else:            return b[0:1] + merge(a, b[1:])

def mergesort(a): # Lists of 0 or 1 elements are already sorted. if len(a) <= 1: return a # Split list in half, sort halves separately and merge. m = len(a) // 2 # // is integer division return merge(mergesort(a[0:m]), mergesort(a[m:]))

I think Python is a good choice here because
 * the syntax is uncluttered and fairly easy to read, even if one isn't familiar with the details of Python
 * array slice and append operations make for a much more concise formulation of the algorithm, where the C code has to shuffle around single elements in loops.
 * While the algorithm could probably be expressed even more elegantly in a functional language ike Scheme, I think an imperative formulation will be easier to understand for the majority of readers.

If there are no objections, I will go ahead and make the changes. --K. Sperling 12:45, 17 Jul 2004 (UTC)

The definition given in this article is for a Binary merge sort. Higher orders of merge are possible (e.g. Ternary merge sort, divide unordered list into three lists of approximately equal size, sort those, then merge the three ordered lists). Well-written Mergesort and Heapsort implementations have approximately the same performance (if anything Mergesort usually wins by a whisker).

wait a moment... This code is erraneous!!!

---

I tested the mergesort code in float and int variations in C. The combinations of Sort and Merge functions here on Wikipedia don't work in a simple C compiler. After compilation the results of a run are sorted in the wrong order! -- Glenn.L.Williams@nasa.gov  This paragraph is the opinion of the author only and not that of NASA!!!

MIPS? Miranda?
I removed the MIPS assembly version of the code, because this isn't the 99 Bottles of Beer page, and I don't think anybody is going to be enlightened about how the algorithm works by pages of assembly code.

I also suggest that the Miranda example should be removed. It's almost the same as the Haskell one - it seems to differ only in the syntax for taking the left half and right half of a list - and Haskell is more well known than Miranda, at least based on the one data point that I've never heard of Miranda.

RSpeer 17:29, Apr 21, 2005 (UTC)

Analysis of moves is suspect
The assertion that quicksort's best case behavior is N log N moves must depend on some very specific implementation. If the element in the middle is used as the pivot (not a good idea, but often seen), then input that is already in order will result in 0 moves. I'd favor removing the discussion of best case behavior.

I'm also suspicious about the assertion that merge sort does better on average than quicksort on moves. Merge sort will move all the elements, log N times. On average, quicksort will find half the elements on the proper side of the pivot, so it should only have to move 1/2 the elements, log N times.

Algorithmic analysis is not my field, so I won't attempt to edit the article. But it would be nice to have an expert check out the validity of the analysis. —The preceding unsigned comment was added by Jpl (talk • contribs).


 * It's not talking about the number of moves; it's talking about the number of steps the algorithm has to take. Even if quicksort doesn't actually do any swaps, it still has to inspect elements in the list; and it's been proven that any comparison-based sorting algorithm must take at least O(N log N) time.


 * With respect to your statement "it should only have to move 1/2 the elements, log N times", well, this is O-notation we're talking about, so that's actually equivalent to saying O(N log N), since N/2 log(N) is also O(N log N). --Saforrest 04:26, 11 April 2006 (UTC)


 * The main page says In terms of moves, merge sort's worst case complexity is O(n log n)—the same complexity as quicksort's best case. We've already established that the best case number of compares is O(N log N), so of course the number of steps can be no better than O(N log N).  I don't think we're in disagreement about the behavior, but the article asserts that quicksort best case moves is O(N log N), and that's simply false (and largely irrelevant).  --jpl 22 June 2006

Quicksort can indeed fall in the &theta;(n2) in its worst running cases, but it is generally expected to behave &theta;(n lg n). Also randomizing the algorithm (pivot selection) largely decrease the likelyhood of a worst case. The reason why it is regarded as one of the fastest algorithm is the low hidden constants hidden in the average &theta;(n lg n). I would also remove this discussion from the main page, given the lack of sources agreeing with this section's author opinion. --TheSpooler 02:58, 26 June 2007 (UTC)

Top-down implementation
Example C code for top down merge sort algorithm which uses recursion to divide the list into sublists until sublist size is 1, then merges sublists during returns back up the call chain.

Bottom-up implementation
Example C code for bottom up merge sort algorithm which treats the list as an array of n sublists of size 1, and iteratively merges sub-lists back and forth between two list buffers:

Rcgldr (talk) 00:28, 14 April 2013 (UTC)


 * These routines do not appear to use the conventional notion of list processing. The conventional list is not manifest size + vector of elements (essentially equivalent to processing a vector) but rather a linked list of indeterminate size and scattered element allocations. Glrx (talk) 02:33, 14 April 2013 (UTC)

Algorithm - C++ vector code examples
// this typedef would not need to be included in the code examples

Bottom-up implementation
Rcgldr (talk) 00:31, 14 April 2013 (UTC)

questionable comment in top down implementation, why the change to C#?
This section that was previously written in C so that it would closely match the bottom up implementation, was replaced with a C# example, that isn't as closely matched, and one of the comments is questionable, since it's not clear if the comment is about the recursive call being made or about the list returned from the recursive call.

From Merge_sort in the source fragment

These calls do not do any sorting, they only recursively divide sub-lists until sub-list size is 1. No actual sorting begins until some instance of TopDownMergeSort reaches the line that calls the function Merge. Also the C examples showed that the old list was being freed with a specific call to free. The C# example doesn't make it clear that the input list(s) is/are being discarded after splitting or merging the input list(s) into new list(s). If more comments are wanted for the C examples to match the comments in the C# example, I'd be happy to update the examples. I could change the C code to C++ code with classes if that would be preferred. Rcgldr (talk) 12:34, 11 April 2013 (UTC)


 * I'm not sure I follow your logic a call to TopDownMergeSort definitely sorts the array passed to it. The 'Merge' method is called inside the recursive call. However if this is unclear, we should change it. maju (talk) 01:59, 11 April 2013 (UTC)


 * It's understood that the overall result sorts the data. My issue is that the comments in the code should apply to the lines of code in the current instance of TopDownMergeSort, not to the overall effect of layers of recursion. Those lines of code are just a continuation of the process of dividing a list and recursively calling TopDownMergeSort until the list size is 1. What needs to be made clear is that until some instance of TopDownMergeSort reaches the line that calls Merge, no sorting has taken place, only the splitting of lists, and that no instance of TopDownMergeSort returns until after a call is made to Merge.


 * The only lines of code that contain the logic to actually sort data are contained in Merge, not TopDownMergeSort. Rcgldr (talk) 04:55, 11 April 2013 (UTC)


 * I have changed the c example to c# because the pointer manipulation and passing sizes obscures the logic. I strongly believe that freeing memory is not part of the algorithm. I you dislike c# as the language we could go for Python or other language, but I will strongly argue with 'native' support for arrays, no pointers and 'automatic' memory management. maju (talk) 01:59, 11 April 2013 (UTC)


 * My example did not pass any sizes as parameters. The newlist function sets the structure size when it's called to create a new list. I could change this to C++ and create a class that has size as a member instead of using ->size. I don't dislike c#, but I was trying to make it clear that lists were being created and deleted as part of the process, in order to better compare the differences beween top down (many lists being created and deleted), versus bottom up (one list created to be used as a second list, and one list deleted when the sort is completed (the code can be modified so that the original list always ends up with sorted data, but this is an optimization not required for the examples). The other issue is that without using pointers, I'm not sure how you efficiently (no undeed copying of data) implement the bottom up merge sort which swaps the pointers between input and output buffers after each pass. If a proper bottom up merge sort needs pointers, then to be consistent, the top down merge should also use pointers in order to make comparing the different methods easier. Rcgldr (talk) 05:24, 11 April 2013 (UTC)


 * Lastly, I see a lot of value in the fact that the c# code deals with anything that can be compared whereas the c code deals only with integers. (talk) 01:59, 11 April 2013 (UTC)


 * The data in that structure could be anything that can be compared. I used 64 bit unsigned integers as an example to keep the example simple. Only size needs to be an integer. Rcgldr (talk) 04:55, 11 April 2013 (UTC)


 * To clarify, in the top down example, the only lines of code that do any actual sorting of data are contained in the Merge (or Merge_Pair) function. Rcgldr (talk) 12:34, 11 April 2013 (UTC)


 * It's been suggested that the article could have both the C# and C (or C++) examples. I'm not sure it's needed, but it would be better to have both examples written in the same language. My concern about C# is that readers not familiar with C# may wonder why lists are allocated with new but never freed with delete. In addtion, the bottom up implementation is awkward without the use of pointers and swapping them for each pass, since this would require otherwise uneeded copying of data or nearly duplicate code to handle merging back and forth between two lists (which is why I chose C for examples). Rcgldr (talk) 12:34, 11 April 2013 (UTC)


 * Comment. The article should not emphasize programming details. WP prefers psuedo code, and a good reason for that is the ideas can be stated without getting mired in the details of a programming language. Glrx (talk) 01:51, 13 April 2013 (UTC)


 * Both implementations should be use the same style. This is what I was trying to accomplish with the two C examples, which were very close to wikipedia's C style pseudocode (ignoring the separate header section), so I don't see the problem with what I did. Now the old version is restored, where the top down implementation psuedocode style is very different than the bottom up C example, which what I was trying to resolve. This section should be updated so that both sections use the same style. Rcgldr (talk) 08:28, 13 April 2013 (UTC)


 * Comment. I do not see a valid point in reverting back to C/C++ code. C# version is much better to read and it has nice syntax sugars. I did the last changes on C# code and I decided to add generics (similar to templates in C++) today, but now I see you guys already reverted it back. This is an algorithm page and we should show easy-to-understand codes. — Preceding unsigned comment added by 69.18.50.2 (talk) 14:13, 13 April 2013 (UTC)


 * Look at the history, I didn't revert it back. My last change was to include both examples. I'm waiting to see a good C# example for bottom up merge sort (post it here on the talk page, that way it won't get undone). Note that outside the class room, most merge sorts are bottom up (or hybrid / bottom up). I added a C++ vector code example for top down merge sort on this talk page if you want to see what that looks like. Rcgldr (talk) 18:44, 13 April 2013 (UTC)


 * I was the editor who reverted. I disagree that C# is better to read, and I strongly object to some of that syntactic sugar. WP should not presume that readers are programmers or adept at C or C#. IIRC, there were some edits that replaced explicit variable increments (common in all languages) with the C-family specific ++ idiom / syntactic sugar. I do not see that serving the readers at all. This article is not the place to showcase coding prowess. I also see many of the macro definitions being difficult/opaque for most readers. Glrx (talk) 02:18, 14 April 2013 (UTC)


 * Although the intended readers may not be familiar with a specific language, most of them will have some experience with programming. Currently the psuedocode style for top down is not consistent with the C code example for the bottom up. I'd like to see a similar style for both implementations, using the same or similar variable names as needed. If someone wants to fix this, do you have any other issues with language specific idioms other than "++" for incrementing? Are you OK with the usage of pseudo functions like datacopy instead of for loops and indexing? Rcgldr (talk) 03:35, 14 April 2013 (UTC)


 * there were some edits that replaced explicit variable increments (common in all languages) with the C-family specific ++ idiom. Note that the ++ idiom is used in the current bottom up implementation section:


 * Rcgldr (talk) 08:55, 14 April 2013 (UTC)


 * The notion of an increment is expected in a for loop. The |edit I objected to was the PDP-11 increments where the reader must puzzle out what iL++ and iR++ mean within the body of a loop. The statement model is more common that the side-effect expression. Glrx (talk) 20:48, 21 April 2013 (UTC)


 * If the issue is mostly the post increments, that could have been easily fixed with a simple edit and adding a couple more lines to the examples, rather than reverting to what there is now, one psuedo code example and one C example, which makes it more difficult to compare the two methods. I didn't want to get in to a debate about C# versus C or C++ examples, I just wanted the top down and bottom up merge implementations to be explained in a similar matter. Rcgldr (talk) 04:54, 22 April 2013 (UTC)


 * No, the issue is deeper. The emphasis switched from explaining a simple algorithm to writing concrete executable code. Both additions had that problem. Glrx (talk) 04:00, 23 April 2013 (UTC)


 * Except that the current bottom up algorithm is explained using concrete executable C++ code. The suggested C++ code example from above is "simpler" than the current english oriented psuedo-code description which gets into uneeded details such as copying elements one at at time to split a list into two sub-lists. Rcgldr (talk) 09:32, 27 April 2013 (UTC)


 * A follow up comment to the mess that currently exists in the examples. The top down example psuedo code gets into unneeded detail in some parts, like a verbose description of splitting a list one element at a time, then later glosses over complex operations like removing the first item from a list with the pseudo macros first(list) and rest(list). The top down example completely ignores the more common top down method of manupulating indexes by recursively generating triplets of indices (left, middle, right) where the range is reduced by 1/2 with each level of recursion, as opposed to the current decription of splitting actual arrays. The bottom up example uses the macro min without explaing what it does. The top down and bottom up examples should be written in a similar style. The top down example is too english like, too verbose, inconsistent with the level of detail in describing operators. The bottom up example includes a complex if statement that relies on C's "early out" on conditional operators || and && which could be potentially confusing. Rcgldr (talk) 11:18, 25 August 2013 (UTC)


 * Revised the top down pseudo code example to reflect a realistic implementation. Rcgldr (talk) 20:12, 25 August 2013 (UTC)


 * example of pseudo code for a complex algorithm that uses some high level operators (exponentiation, polynomial multiplication, ..) in an otherwise c like syntax, apparently from a text book: Berlekamp%E2%80%93Massey_algorithm
 * Rcgldr (talk) 11:14, 25 August 2013 (UTC)

Is top down merge sort practical?
Top down merge sort uses recursion and splitting / copying of a list until list size is 1, while a bottom up sort just starts off considering a list as n sub-lists of size 1. The overhead for the top down recursion method to just reach what is the starting point for a bottom up merge is quite a bit, the list is split up n-1 times to create n lists of size 1, and the number of elements copied during the splitting phase is log2(n) · n. A top down merge sort also has to allocate and free all of those intermediate lists created during the splitting and merging phases. The end result is that a top down merge takes about 3 times as long as a bottom up merge in a simple case like sorting an array of integers.

It seems that a top down merge sort is mostly a class room exercise. All the merge sorts that I'm aware of in libraries, C++ standard template library, and commercial products, are based on a bottom up merge sort. Rcgldr (talk) 08:32, 13 April 2013 (UTC)


 * The top down algorithm provides a divide-and-conquer explanation of the algorithm. Glrx (talk) 02:04, 14 April 2013 (UTC)


 * So is a bottom up algorithm, the divide step separates a list of n elements into n lists of 1 element (or n / m lists of m elements). It manages to do this without the overhead of recursion. Rcgldr (talk) 04:08, 14 April 2013 (UTC)


 * A top down merge sort need not do multiple allocate, copy, free steps. Do not use a poor instance of a program to make a general comment about all instances. A top-down can start by allocating size n work array and then start the recursion. Lexically scoped languages (unlike C) can do that elegantly. The fundamental difference is one of expressing control. In top down, the stack is used to keep track of the subarray being processed. In bottom up, there's one stack frame, but an outside loop and some variables keep track of the current subarray. Glrx (talk) 02:04, 14 April 2013 (UTC)


 * Having a secondary work array of n elements doesn't eliminate the extra copy operations. A top down merge sort could use recursion to generate a binary tree of indexes, normally on the stack. Because of the ordering within the binary tree, each merge step has to merge from the orginal array to the work array, then copy the merged output back to the original array, an extra copy step on every merge operation. (Without the copy back after each merge, you'd run into potential situtation where an instance of merge(left, right) would have left on one array and right on the other array, and you'd have to include additional information to keep track of which array each instance of a sub-list was located). I'm not aware of a method to avoid doing this when n is not a power of 2. What is the point of generating a binary tree of indexes and having to do an extra copy step on every merge operation, when these issues are eliminated with an bottom up merge sort? I'm not aware of any standard language library with a merge sort function that uses top down implementation. For example, the HP / Microsoft standard template library for stable_sort splits up an array into n/32 lists, uses insertion sort to sort each list of 32 (or less) elements, then uses a bottom up merge to complete the sort. Rcgldr (talk) 21:25, 17 April 2013 (UTC)


 * Yes, it can eliminate extra copy operations. There is no need for a copy back at each level. Recursive implementations are not common, but that does not mean they are not possible. Which array holds the source depends upon the recursion level parity. Glrx (talk) 21:01, 21 April 2013 (UTC)


 * Trying to avoid the copy back steps makes a top down merge sort even more complicated. Take the case of a 5 element sublist without the copy back, you end up with an instance of a 2 element sublist on one array and a 3 element sublist on the other array, so one of the sub-lists needs to be copied before the merge can be done. Such an algorithm would have to keep track of which array contains which sub-lists, and when the extra copy steps are needed. All of the examples I've seen of top down done with indexes use a copy back step, such as this one: merge.htm. Recursive implementations are clearly possible, but they introduce uneeded overhead, since the recursion process can be eliminated by simply treating a list of n elements as n sublists of 1 element each (or n/m sublists of m elements each) and iterating as shown in the examples here. Rcgldr (talk) 05:09, 22 April 2013 (UTC)


 * Yes, but that means don't try to write efficient code when explaining an algorithm. Keep things simple. If that means extra copies, then use extra copies. This article is not about efficient programming; it's about an algorithm. Glrx (talk) 04:08, 23 April 2013 (UTC)


 * That's not the point of this section. The question here was if a top down merge sort is practical (it it is actually used in compiler libraries or commercial products). As an analogy, factorial can be implemented via recursion, but it's not practical (efficient). What's the point of using recursion to split up a list into n sublists of size 1 when a list can be simply considered as n subists of size 1 as the initial state without executing any code? There is the case when a partial top down merge sort can be used to reduce memory overhead, such as allocating a temp buffer 1/2 the size of the data to be sorted, then merging 1/2 of the data at a time (using bottom up merge sort). For the final merge step, you'd have the first half of the data in the temp buffer, and would merge the temp buffer and second half of data into the original data buffer. Rcgldr (talk) 22:44, 27 April 2013 (UTC)


 * top down merge sort - indices - which array holds the source depends upon the recursion level parity. Solution for this is to alternate between two almost identical recursive functions, to keep the merge direction in sync with recursion level parity. The top down algorithm section has been updated to show this simple solution. The actual merge process for top down and bottom up is the same. For an index based merge sort, the difference is top down uses recursion to generate triplets of indices (left, middle, right), while bottom up uses iteration. The triplets of indices, (left == start of left run, middle == end of left run == start of right run, right == end of right run) are used for the actual merge process. Both top down and bottom up generate the same set of (n/2 + n/4 + n/8 + ... = n-1) triplets, and only the ordering of the sets used for merging is different. The order of merge operations for top down is top down, depth first, left first, and for bottom up, it's bottom up, breadth first, which may affect cache. Iteration is faster than recursion, but most of the time is spent merging (versus generating triplets) and as mentioned, the merge process is the same for both. Rcgldr (talk) 04:11, 27 August 2013 (UTC)

About a possible O(N*Log(N)) time and only O(1) memory merge sort
i think this is just a variant of some idea of mine block inter blocks insert, basically is about first scanning data, merging using mainly some Euclid arrange routine, performing that block inter block insert... its an old idea of mine but idk if really working neither in these days :) — Preceding unsigned comment added by 93.118.212.93 (talk) 10:52, 8 June 2013 (UTC)

lets say we got two sorted partitions to b merged first we set an index on the first element of first partition assuming we want smallest to largest elements sorting if current element of first group is smaller than current element of second group (initialized as first element of second group) we seek for first partitions next elements till find an element that is bigger than second group current element in this case we switch elements then linearly seek for both of the rite positions in the new places. then kinda repeat this kinda cycle until at least one partition is done case in which(thnx to google translate :) ), if the second partition ended only we might need some Euclid arrange involving second partition and the rest remaining from first partition to linearly O(N) time "switching" their positions... Florin Matei 93.118.212.93 (talk) 16:51, 27 April 2013 (UTC)

u'll have to forgive me im under the effect of my last clopixol shot taken last thurstday, i think that evn possible more sophisticate in order that for really working, this idea of mine its creative and its good enough after all 93.118.212.93 (talk) 17:41, 27 April 2013 (UTC) Florin

Top down implementation
I'm trying to update the top down implementation to use indexing and a style similar to the bottom up implementation, but someone that doesn't even have a wiki page reverted the update. I can make a simpler version of the top down merge that uses a copy step, similar to the current copy step in the bottom up example, to avoid having to alternate between two recursive functions. The top down merge function would be identical to the current bottom up merge function. I can post a proposed example here in this section, but is there any point in doing this? Do the others here involved with this article prefer the text explanation versus any C / C++ example that would be similar in style to the bottom up example? Rcgldr (talk) 23:20, 4 September 2013 (UTC)

Example top down implementation using indices. The copy back can be avoided if the recursion alternates between two functions so that the direction of the merge corresponds with the level of recursion, but this optimization is not required to show how top down merge sort works.

Rcgldr (talk) 03:19, 5 September 2013 (UTC)


 * Oppose switch from lists to arrays. The current version uses lists rather than arrays, so it illustrates a feature of merge sort is that it can be used with sequential sources. I also oppose the use of C idioms such as  outside of for loops. Articles are encouraged to use psuedo code rather than provide detailed implementations. The algorithms should also be simple rather than employing tricks to avoid copying. The goal is to illustrate the basic algorithm. Subtle tricks can be mentioned, but putting them in early obscures the basic algorithm. Glrx (talk) 23:22, 5 September 2013 (UTC)


 * lists versus arrays. The same argument could be made for bottom up merge sort as well. Top down merge sort is very inefficient for linked lists since it requires scanning lists to find the mid points, while bottom up implementations avoid this. sequential sources - top down merge sort can not be implemented for true sequential sources such as the classic case of 4 tapes drives (bottom up or polyphase merge sort would be used instead). Perhaps the example posted in this thread could be included between the current top down and bottom up examples, to get an "apples" to "apples" comparason of top down versus bottom algorithms (both using indices on arrays to implement the merge sort). Rcgldr (talk) 01:06, 6 September 2013 (UTC)


 * I also oppose the use of C idioms such as  The current bottom up example is using the post increment idiom, apparently a change made by someone else. I don't have an issue with it either way. Rcgldr (talk) 00:48, 6 September 2013 (UTC)


 * The code here should just be simple pseudocode that illustrates the basic idea well with no tricks. We should have citations in the sections with code in to books or properly checked and supported free software source where readers can find more optimised code - which besides will be more trustworthy than something that is dumped into the free encyclopaedia that anyone can edit. Dmcq (talk) 07:33, 6 September 2013 (UTC)


 * The simplest description in the article is the 4 statements in Merge_sort. Perhaps that simple description should be moved further up in the article before the top down and bottom up code examples. I'd like to see top down and bottom up code examples implemented in a similar manner so that they can be properly compared. Rcgldr (talk) 01:59, 7 September 2013 (UTC)

bottom up implementation
Some comments about the current bottom up implementation. The parameters "array A[]", and "array B[]" imply that A and B are arrays of arrays. It's ok to note that A[] and B[] are arrays in the comments, but type field could be left blank in the function declarations or use something else to indicate A and B can be of any type. If this was done with a template, you could declare something like template ... BottomUpMergeSort(int n, element A[], element B[]), but that would probably be more confusing to people not familiar with templates. In the example functions, the ordering of parameters isn't consistent, BottomUpMergeSort has the size first, source array second, and work array third. BottomUpMerge has the source array first, 3 indexes next and the destination array last. CopyArray has the destination array first, the source array second, and the size last. Rcgldr (talk) 02:56, 5 September 2013 (UTC)


 * The type issue is well taken, so I will change it to . Templates should not be used. Arg order could be tweaked. Glrx (talk) 23:25, 5 September 2013 (UTC)