Quicksort vs Mergesort in 35 Seconds
HTML-код
- Опубликовано: 10 сен 2024
- Sort 200 different colors in under 30 seconds #shorts
Quick sort and Merge sort are used. We see that quicksort takes fewer operations here, but some of that could be how I counted the operations. Quicksort is known for being the fastest though.
Quicksort work by selecting a pivot value and putting everything less than (or equal to) that pivot to the left of it in the array, and everything greater than the pivot to the right of it.
Merge sort works by recursively splitting the list until it has two lists with only one element in them, and then merging them together in the correct order.
Both of these are n log n time. My quicksort implementation doesn't use extra storage, my merge sort implementation does make slices of the list when it is splitting.
This was done using python & pygame
All code
Copyright 2021 Google LLC
SPDX-License-Identifier: Apache-2.0
www.apache.org...
The inspiration for this code was this github repo
github.com/Luc...
I used this algorithm to turn a wavelength into an RGB color
www.noah.org/wi...
Thumbnail Background image (Thunderstorm) by FelixMittermeier
pixabay.com/ph...
I mean, Quick Sort depends on your pivot but Merge Sort will always be consistent
Merge sort sucks. It only works with randomised data.
@@vwlz8637it can be hugely parallelized though
@@vwlz8637isn’t randomised data the data you’ll mainly be working with?
@@vwlz8637 isnt that the point? why would you need to sort non random data? unless you mean put new data in the right place but that's literally not its job
@@vwlz8637 gotta be kidding 😂
Oh hell yeah finally RUclips is recommending me good shit
Yeah, I think the recommendation algorithm is based on Bubble sort, so it takes while :)
@@dubiouscode4802 great humour right there
@@dubiouscode4802No it's based on bogosort cause everything is random😂
@@dubiouscode4802nah nah it's selection sort 😂
@@shaurryabaheti its stupid sort lol
One thing a lot of people forget when comparing these two is that quick sort can be implemented as an in-place sort with less memory allocation required. That's one of the main reasons it ends up being faster in practice despite having a higher worst-case complexity.
Nobody talk about parallelization. Merge sort is the default implementation for modern language because it can be parallelized, and, therefore, faster
This. Divide and conquer.
**Multiply and surrender.**
Quicksort can be parallelized
And it can better use cpu caches
> I bet on Merge Sort
> I lost my money
To who?
@@Hi-Im-Noob-uwu MERGE SORT, HE LOST, I BET $1M ON THAT (joking)
@@marble17i bet 10 bucks on quick sort and won 20 bucks
bro did not go big
@@lenoobxd go big or go home
I go home
Mergesort is always O(n*log(n)) but and Quicksort is mostly O(n*log(n)) in worst case it can go to O(n^2).
However if both run in their ideal time complexity of O(n*log(n)) then Mergesort just has a bigger constant hence the slowness.
Merge is also more space costly
@@simohayha6031 depends on your data structure.
i am a simple man. i see computer video, i click
Quick sort is fast but the worst case is O(n²). Mergesort is just more consistent.
Quicksort is also O(nlogn) if you use a function to find the median for your pivot. But in practice it's much faster to get a random pivot or a median of medians.
@@Vzduch2 what about uniform data?
rip n log n
@@bitonic589 O(nlogn)
quick sort is O(n^2) for particularly unlucky input data. it basically turns into insertion sort
Especially already sorted data.
That's why we live it for the random gods.
You can't be unlucky hundreds of times in a row so its always nlogn.
I think it's safe to bet you won't come across a case of true n² in your life.
@@darknight3613 not every data you sort is randomly shuffled, n² can happen for A-shape, V-shape or data that is already sorted (depending on quick sort pivot implementation) and these data orders aren't that rare when you measure some real-life properties; heck if you sort something twice by accident and take your pivot at a wrong spot you'll get n²;
so I don't think it's just a theoretical, it's something to keep in mind; but fortunately vast majority of programers can rely on built-in sorting functions and have other people worry about low-level implementation
unlike mergesort, quicksort isn't stable
unlike quicksort, mergesort requires o(n) additional storage to work
quick sort also is nice if you might need to get the list in whatever order it is before finishing, like the list ends up mostly finished soon and just perfects it
Quicksort is rarely used in its pure form, it resorts to other algorithms when it detects its performance is degrading, or when the set size is just so small that the asymptotic behavior favors another algo.
I feel like ive entered a side of the internet that I'll never comprehend any thing more than the tickle sorting algorithms give my brain when you hear and see the lines being organized. Reminds me off arcades as a kid.
One of the solutions I've seen to both algorithms' struggles with nearly-sorted data is to quickly shuffle the list.
Bro doing RUclips Sorts
at first i misread this and was wondering what the joke was aside from the ytber doing youtube shorts. you got me, gj
😆
I will always like merge sort more than quick sort. It seems more elegant even though it is the slower of the two
in the avarage case they are both the same. But quicksort can somteimes be quicker
@@thomasko0947 QuickSort would be slower in the worst case
merge sort also uses more memory because it has to make a lot of extra copies of the data but quick sort is purely done in place
@@flazerrazer2992 memory needed is just one more array with the size of the array you already have.
@@thomasko0947 not entirely true. the constant factors go away when you do big-o analysis, so they're both O(n*log(n)) in the average case, but the constant factors for quicksort are smaller so its average case is mathematically faster.
I only trust Bogo sort
all hail bogo sort superiority
O(n) best case, no other sorting algo can beat it
@@gr.4380 Stalin sort is O(n) in all cases.
Well, O(initial n) in all cases.
@@gr.4380 almost every distribution sort is O(n) in almost all cases
I still love the orderliness of Radix Sort.
Really helpful comparison, thank you!
The quickness of quicksort or any sorting algorithm depends on the order of the initial list; it might be quicker for a completely randomly shuffled list, but and other scenarios it might not be as quick. That's why a completely randomly sorted list is not a comprehensive demonstration or comparison.
Quick sort CAN be faster, but merge has more consistency among n objects, quick could get all in one, it could get only 2, the pivot is RANDOM, higher his lower lows.
Interesting, it should be obvious that algorithms with the same time complexity don't necessarily run in the same amount of time, but it's nice to be reminded.
Reminds me how for a class we had an assignment that checked if our code was linear time complexity by just timing it to see if it was fast enough. My code was linear time complexity but still not fast enough. Rather frustrating but it pushed me to come up with an even better solution!
"algorithms with the same time complexity don't necessarily run in the same amount of time"
Could this be because of the different amount of times for constants (C1, C2, etc)?
Virgin Big-O purist vs Chad clock cycle counting.
Try edge cases
Depends on the imput size.....Merge sort has an O(N Log(N)) timpe comexity, which is constant.....whereas Quicksort is not doing this in a constant time....and it is dependant on the imput size
quick sort is also O(nlogn) provided that the pivot is the median, which is obtainable. neither is constant
@reedoken6143 According to Harvard, Merge Sort has a constant time in the best case and worst-case scenario. Therefore, the Merge Sort algorithm runtime is considered constant. If it wouldn't be like this, everyone would use Quick Sort instead of Merge Sort.
@@TyTy-gm8yb yes, merge sorts best and worst case are both O(nlogn), but O(nlogn) isn't constant. They're both dependent on their input size, that's what the n is inside O(...), n is the input size. Provided you find the median value of your list prior to sorting, quick sort also performs in O(nlogn) and can even perform in O(n). the reality is that they perform the same in 99% of situations, and the decision can be made on other factors like parallelization or memory limitations.
@@reedoken6143 Is constant in relation to the input size....because the time complexity is calculated in relation with the input size
@@TyTy-gm8yb That's not how big O notation works... f(x) = x is only constant if x is constant and is not a variable. Same thing applies to O(n). Considering the input size of the list is variable, we aren't working with just one size of list, then O(n) or O(nlogn) is not constant because n is not constant.
If constant was in relation to the input size, then quick sort would be constant also. Again, for the average case both merge sort and quick sort are O(nlogn). Quick sort simply has more variability as it is best case O(n) and worst case O(n^2), but for the majority of real world cases is O(nlogn), the same as merge sort
Really cool demonstration. I personally think merge sort animations look a bit cooler when it's done in a breadth-first ordering instead of the depth-first ordering you showed here. It still looks cool, though.
Quick sort is tail recursive (i.e the last statement in the recursive function is the recursive call) maybe that's the reason for it being faster than merge sort.
What? I thought tail recursion was to reduce memory usage?
@ooo8188 yeah I dont think it has anything to do with it but in general they're both O(nlogn) so it doesn't really matter anyway
You can write merge sort in tail recursion too btw
Its also faster@@ooo8188
Quick sort is quick sort for a reason
yeah because its trash
"Yeah operational complexity is important when it comes to scalability but we shouldn't forget about the coefficients, or any adversarial cases for that manner"
In the real world, we often know some things about our data or its existing potential orderings, influencing our choice of sorting algorithm, sometimes surprisingly so
now do a 3 way comparison of a bunch of nlogn sorting algorithms. Mergesort, quicksort, heapsort, etc.
It's like my mom always said when I was cleaning my room, only pick things up once and put them in their place so you don't have to do it again.
Unfortunately for her the place I would be putting some things was also a mess so I would have to set stuff down to clean the other area in order to be able to have room to put the item that was out of place in place 😂
Try doing both sorts on data sets that cannot fit in memory.
Actually quicksort and mergesort are basically the same algorithm. Try running an ideal mergesort on a 2^n permutation, then run stable quicksort on the same permutation inverse and look at the decision tree. Exactly the same set of comparisons and moves, but in opposite time.
2 good sorts: the best short
Quick sort is soooo much easier to write code for. It is naturally recursive and the code is short and beautiful 😍
The disadvantage is that a large list can cause the program stack to overflow 😢
Merge sort seems more intuitive and easier to understand for me
Great video!
Nice!
Thanks! Welcome to the channel
@@dubiouscode4802 Hi
@@AkmalZaini-po3bh Hello!
very interesting :)
quicksort worst case performance is O(n²), while mergesort is O(n*log n), which is less.
Try doing this with Bubble Sort vs Stooge Sort
(Stooge sort = sort top 2/3 of the list, then the bottom 2/3, then the top 2/3. Named after how the Three Stooges would hit each other back and forth)
*than
But thx for your comment 😌
But quick sort can go upto n² in worst case but not the merge sort
Thanks
How about quickscramble and mergescramble
Quick sort of nice because it's also human based too.
Quicksort has its weaknesses. Merge sort also has the ability to combine arrays- which is pretty unique
Interesting idea:
Which array is ~more sorted after N steps in the sorting? Quick sort, for sure.
I mean, that's where the name mergesort comes from. It merges arrays. It being slower on average and taking up more space needs to be taken into consideration when using it, it being stable and having a const runtime on an array of size n has its benefits. When more specific requirements are known neither standard implementations of quick- or mergesort will perform as good as optimized variations of those or other sorting algorithms
Now try them on a sorted array 😁
“finally, some good fucking content”
"Written in Python3" runtime -> O(n³)
Sort lore
Quick sort will be faster a lot of times. Merge sort will be fast all of the time
Why tho?
Mergesort =always nlogn time complexity
Quicksort = could be (and most of the time is) nlogn time complexity but could also be O(n^2) in the worst case.
How come quicksort is better?
should specify that nlogn refers to average case, to avoid confusions
is it me but... THE FIRST FRAME TEMINDS ME OF BAD APPLE
Bead and cycle?
He should have use stalin sort
Gravity sort:
gravity sort: i'm faster
Marge Sort
👌
However, quick's worst case is worse than merge's.
Heap sort vs quicksort?
now do heap sort
O(n log n)
bruh youtube keeps recommending ts to me 💀
How to get into google sir?
Freakysort
👏🏼
Gravity sort solos unfortunately
Quicksort is quick
but merge sort is faster in worst case than quick sort
I hate doing quicksort on paper; too many wrong answers.
Why
Good
Wheres bogo sort
Bogosort faster
Coool
Quicksort is controversial bc the worst time is n^2, but the vast majority of the time its nlogn
C'mon, you should know by now that the names don't mean anything.
no sound 0/10
Gaysort :v
And here you can see that Quick Sort is faster, however there ain't no way you're programming that, so just use Merge Sort
Ok maybe AI will replace you
@@Alguem387 Bold of you to assume I have a job /j
gay sort
So professionally, you work for google,
and non professionally also you work for google. (via RUclips) 😄
merge sort is soo gay
? How can a sorting algorithm be "gay"?
@@Eutropios I think he means the rainbow patterns you see with MergeSort early on.