Talk:Merge algorithm

message: I would like to know if it is standard nomenclature to call "merge algorithms" the ones that follow.
* given a set of current account balances and a set of transactions, both sorted by account number, produce the set of new account balances after the transactions are applied; this requires always advancing the "new transactions" pointer in preference to the "account number" pointer when the two have equal keys, and adding all the numbers on either tape with the same account number to produce the new balance.
* produce a sorted list of records with keys present in all the lists (equijoin); this requires outputting a record whenever the keys of all the p0..n are equal.
* similarly for finding the largest number on one tape smaller than each number on another tape (e.g. to figure out what tax bracket each person is in).
* similarly for computing set differences: all the records in one list with no corresponding records in another.
I checked several books on algorithms and in all of them "merge algorithm" is taking two or more ordered lists and producing one ordered list in linear time. Maybe the above algorithms could be in another article.
Pablo.cl 02:04, 24 May 2004 (UTC)
thread_title:  Nomenclature issue 

message: I removed the comments about the STL merge implementation being more efficient than the presented source code because there's no guarantee of the STL's implementation performance, or approachability, for any specific task. The assertion I removed doesn't apply in all cases, and can't be presented as fact without much more context and discussion.
Meanwhile, I am wondering why the examples don't implement the pseudo code presented at the beginning of the article. The examples have no comments and don't explain what their parameters are. The C and C++ versions don't bother to check the length of the target array.
Should I add comments, and rewrite the samples to more closely match the pseudocode?
Mikeblas 21:48, 28 December 2005 (UTC)
thread_title:  about the examples 

message: I intend to remove the sample implementations section if and when :Wikipedia:Articles for deletion/Insertion sort implementations is successful.  It may be worthwhile to transwiki them to WikiBooks, WikiSource, or the Literate Programming wiki if anyone feels strongly about them.  —donhalcon╤ 06:09, 5 March 2006 (UTC)
replies: text: That AFD was successful, but there are still a couple of sample implementations. What's going on with requiring references for sample code in articles? -- Mikeblas 15:43, 5 September 2007 (UTC)
thread_title: Sample code

message: I would like to know which is the fastest of knowns merge algorithms, I've read a lot... but I didn't find an answer. Trying to find an optimal sorting algorithm, I came to the conclusion that the optimal merge is a generalization of the binary search algorithm. Someone thinks that may be true, or even already known?
I've writen in ADA this algorithm and if someone finds the best known merge algorithm, I will benchmark my proof of concept against. Meanwhile, I would try to compare it to clasic merge.--Azrael60 18:55, 26 September 2007 (UTC)
thread_title: BEST KNOWN MERGE ALGORITHM

message: This section includes the statement: A k-way in-memory merge sort can also be constructed from a k-way merge algorithm, but his provides no benefits over the ordinary binary merge sort. On a processor with 16 registers, such as a PC in 64 bit mode, a 4-way merge sort using 10 or so pointers that a compiler optimizes by using registers for all those pointers will result in a 4-way merge sort being somewhat faster than a binary merge sort, and about as fast as quick sort. PC based benchmarks showed the 4-way merge sort was about 15% faster than binary merge sort. Rcgldr (talk) 19:19, 29 November 2015 (UTC)
replies: text: I made the statement more precise by specifying that the number of comparisons is being counted. QVVERTYVS (hm?) 19:55, 29 November 2015 (UTC)
replies: text: I would recommend just removing the statement. A 4 way merge averages 3 compares for every move, versus 2 way merge averaging 1 compare for every move, but the 4 way does 1/2 the moves. So the number of compares of 4 way is 1.5 times the number of compares for 2 way, while the number of moves for 4 way is 1/2 the number of moves for 2 way. This is probably too much detail for the main article, which is about merge algorithms as opposed to sort algorithms. Rcgldr (talk) 22:26, 3 December 2015 (UTC)
replies: text: Removed it. We might want to add a section about this to merge sort later. QVVERTYVS (hm?) 09:49, 4 December 2015 (UTC)

text: What the original source cares about (and what I sloppily summarized as "no benefit") is the exact expected number of comparisons, not the big-O complexity. QVVERTYVS (hm?) 15:22, 7 December 2015 (UTC)
replies: text: The number of moves is also a factor, but the total number of operations remains the same, k=2, n log2(n) compares + n log2(n) moves = 2 n log2(n) total operations. k=4, 1 1/2 n log2(n) compares + 1/2 n log2(n) moves = 2 n log2(n) total operations. On my system, Intel 2600K 3.4ghz, in 64 bit mode (16 registers), a 4 way merge sort of psuedo random 64 bit unsigned integers is about 12% to 15% depending on the number of integers (12% for 4 million, 15% for 64 million). The 4 way merge sort on integers is about as fast as quick sort. The relative performance is affected by the overhead of compares versus the overhead of moves. Rcgldr (talk) 18:28, 7 December 2015 (UTC)

text: As mentioned above, the issue with the removed statement was how it was worded no benefit as opposed to same time complexity, and it probably belongs in sort algorithms and/or merge sort, not merge algorithms. Rcgldr (talk) 02:31, 12 December 2015 (UTC)
thread_title: Applications - statement about k-way sorts in memory 

message: A source code for merge_int_dac routine (consequently, for merge_int_dac_mp, too), added in this revision by Mia0303 under the Merge algorithm#Parallel merge section is incorrect. It would not even compile due to at least two major errors, let alone running and producing reasonable results!
Even when fixed, it will also be dramatically ineffective. Additionally it lacks description of the parameters, so it's hard to tell how it should be invoked. One can try to guess the parameters meaning, but that would mean reinventing the algorithm rather than learning it, which strongly contradicts an encyclopedic style. --CiaPan (talk) 08:52, 9 February 2016 (UTC)
replies: text: I've replaced the whole section by a summary of CLRS's parallel merge. QVVERTYVS (hm?) 10:59, 9 February 2016 (UTC)
thread_title:  Fake algorithms 

message: The article K-way merge algorithm largely duplicates content in the K-way merging section in this article, so I think it should be merged (this is not just a pun, I promise). I also suspect that the topic is not notable enough to merit its own article. — PCB 21:59, 9 December 2017 (UTC)
replies: text: I agree, the two articles have far too much overlap to be separate. Possibly if this article were expanded in a different direction the topics could be separately notable, but with the current content they are not. —David Eppstein (talk) 22:13, 9 December 2017 (UTC)
replies: text: Closing, given the uncontested policy-based argument. Klbrain (talk) 13:23, 23 June 2019 (UTC)
thread_title:  Merge K-way merge algorithm article into this one 

message: What is the difference between the merge algorithm and merge sort? The article says that the merge algorithm plays a critical role in the merge sort algorithm, but according to how the article describes the merge algorithm, it seems to me that it is the same thing as merge sort. So, what is the difference between the two algorithms, if there is a difference? I think this should be clarified early on in the article. —Kri (talk) 17:52, 23 August 2023 (UTC)
replies: text: The merge algorithm takes two sorted chains (lists, sequences, arrays, ...) of data and creates a new chain (sometimes by copying the items of source data, sometimes by interleaving them, depending on the data structure in use), containing all items of both source chains in the proper order. Merge sort takes unsorted chain of data, decomposes it into multiple chains and successively merges them to construct a finał sorted chain of all source data. --CiaPan (talk) 20:14, 23 August 2023 (UTC)
replies: text: Yes. The merge algorithm is a subroutine in merge sort, not the whole merge sort. It is also used as a subroutine in some other algorithms unrelated to sorting. —David Eppstein (talk) 01:14, 24 August 2023 (UTC)
replies: text:  Thank you for clarification.  CiaPan (talk) 10:33, 29 August 2023 (UTC)
replies: text: Thank you for the answers; that makes sense! I have updated the text under the image in the article to reflect that. —Kri (talk) 19:42, 29 August 2023 (UTC)

text: What David said about a 𝄪subroutine𝄪 above applies to words 𝄪successively merges them𝄪 in my answer. --CiaPan (talk) 10:33, 29 August 2023 (UTC)
thread_title:  Difference between the merge algorithm and merge sort?