How does the last step sort an of the sizes? Why even have all the other steps if that one can do it all?
SmoothLiquidation@lemmy.world
on 06 Feb 20:31
nextcollapse
When you merge two sorted lists, you only have to compare the first element of each, since you can trust that all of the other elements are bigger. All the steps before that are there to make sure that is true.
IrateAnteater@sh.itjust.works
on 06 Feb 21:00
collapse
Wait, how do I know that all four of the right half aren’t smaller than all four of the Left half?
SmoothLiquidation@lemmy.world
on 07 Feb 00:24
collapse
It doesn’t matter. You check the first of each group and pick the smallest, then compare the one you didn’t pick with the next one of the other group. In your example, you would pick all of the ones from the right side and once it is empty, just add all the ones on the left.
CaptainBlagbird@lemmy.dbzer0.com
on 07 Feb 08:23
nextcollapse
If you want to zipper two sorted lists, you compare the first element of each list, pick that first, take the next element of that list, rinse & repeat until one list runs out and then just chuck the entire rest of the other list in the remaining space, even if that’s just one element. Since your two initial lists are already sorted, you can trust the combined list to also be sorted.
So the point is that always only exactly 2 elements are compared and so you first have to split everything into groups of 2. Seems very inefficient for larger datasets, since you need to handle every single item over and over again and compare so so often. But not a sorting and comparison expert, so no idea if human sorting logic applies at all.
Tbf, Merge Sort has a Big O of n log (n) in all cases, so it’s a pretty mid sorting algorithm in general, but it’s conceptually straightforward and easy to explain to newbies.
threaded - newest
How does the last step sort an of the sizes? Why even have all the other steps if that one can do it all?
When you merge two sorted lists, you only have to compare the first element of each, since you can trust that all of the other elements are bigger. All the steps before that are there to make sure that is true.
Wait, how do I know that all four of the right half aren’t smaller than all four of the Left half?
You don’t, and they can be.
Watch the animation on Wikipedia: en.wikipedia.org/wiki/Merge_sort
It doesn’t matter. You check the first of each group and pick the smallest, then compare the one you didn’t pick with the next one of the other group. In your example, you would pick all of the ones from the right side and once it is empty, just add all the ones on the left.
youtu.be/es2T6KY45cA
The one and only way to learn sorting algorithms: youtu.be/dENca26N6V4?si=pDZoR0uRiuGoqwkr
I’d watch this if I didn’t know about programming just for the sheer weirdness
If you want to zipper two sorted lists, you compare the first element of each list, pick that first, take the next element of that list, rinse & repeat until one list runs out and then just chuck the entire rest of the other list in the remaining space, even if that’s just one element. Since your two initial lists are already sorted, you can trust the combined list to also be sorted.
So the point is that always only exactly 2 elements are compared and so you first have to split everything into groups of 2. Seems very inefficient for larger datasets, since you need to handle every single item over and over again and compare so so often. But not a sorting and comparison expert, so no idea if human sorting logic applies at all.
Tbf, Merge Sort has a Big O of n log (n) in all cases, so it’s a pretty mid sorting algorithm in general, but it’s conceptually straightforward and easy to explain to newbies.
There’s no better big O sorting method for generic lists. Heap sort has better averages but the big O is the same in the end.
Step 4 seems to do nothing?
Step 4 splits the pair above into single elements, from step 5 on the groups are getting merged.
Oh right, okay.
*Marged
My bad