No idea what this is. It keeps crashing Firefox for me. And unfortunately, restarting Firefox only restores the same window, sending me into a loop of crashing.
Crashed on Firefox for me too, saw two - the diagrams looked pretty.
Illustrated Sorting Algorithms
31–39 of 39 posts
Re: Illustrated Sorting Algorithms
#32Earlier quoted context omitted.
Despite that no real-world quicksort implementations have that worst case (due to fallbacks to other sorts), it seems like it's useful to see the pathological case of pure quicksort anyway.
At which case: why bother using quicksort?
Because in the real world, where all our code must actually run, quicksort beats practically every other algorithm on the vast majority of inputs. Its cache behavior is better than heap sort, its memory usage is lower than merge sort, and even its O(log n) memory usage is efficiently allocated on the stack as opposed to hitting a slow system allocator.
"Engineering a Sort Function"[0] covers this quite well.
In some experiments of my own, I've found that even Smoothsort[1] (an algorithm specifically designed to have a smooth transition from linear to linearithmic behavior on nearly-sorted input) can't beat the C++ system's introsort (a quicksort variation with a fallback to heapsort) in already-sorted inputs.
[0] http://www.skidmore.edu/~meckmann/2009Spring/cs206/papers/sp...
Re: Illustrated Sorting Algorithms
#33Points deducted for incorrect O's. Quick Sort is not O(n log n), and merge sort is not O(n^2)
Re: Illustrated Sorting Algorithms
#34Points deducted for incorrect O's. Quick Sort is not O(n log n), and merge sort is not O(n^2)
Well, Quick Sort is O(n log n) on average, but you know that. Also, anything that's O(n log n) is also O(n^2), which means that the author is the worst kind of correct -- but you knew that too :)
Re: Illustrated Sorting Algorithms
#35No idea what this is. It keeps crashing Firefox for me. And unfortunately, restarting Firefox only restores the same window, sending me into a loop of crashing.
Are you sure you have updated Firefox? My firefox ALWAYS asks me if I want to restore the previous session. It also allows me to choose which tabs/windows I want to restore.
It also doesn't crash on this page either.
Re: Illustrated Sorting Algorithms
#36It's tough to be Sorting out Sorting, although I grant that it doesn't have all the newfangled algorithms that this page has.
Really, you need to watch this if you haven't. https://www.youtube.com/watch?v=SJwEwA5gOkM
Re: Illustrated Sorting Algorithms
#37Too bad it's missing Timsort, which is the fastest stable sort and the standard for some standard libraries.
Calling it fastest is not fair. Timsort appears to be very fast because most real world data we operate it on is somewhat sorted, but requires O(n) extra memory. It simply depends on the situation and data.
Re: Illustrated Sorting Algorithms
#38Very pretty indeed! I did a similar thing in JavaScript but inspired by the "sound of sorting" http://webcloud.se/Assortment/
Re: Illustrated Sorting Algorithms
#39No idea what this is. It keeps crashing Firefox for me. And unfortunately, restarting Firefox only restores the same window, sending me into a loop of crashing.
I have no idea if it's FireFox's fault that it crashes, but you'd hope the developer would test on the major browsers.
> I have no idea if it's FireFox's fault that it crashes,
It almost certainly is. It could be an OS or graphics driver problem, but these options are far less likely.
It certainly isn't the site's problem: in the ideal world we don't live in (where browsers, drives and OSs have no faults) it is not be possible for any browser hosted code to take down the whole browser or worse, even if deliberatey trying to do so. The site may be doing something that highlights a problem elsewhere, that the site's designer may be able to work around, but that problem is not their fault.
If the crash is repeatable it would be useful to report it to the Firefox team as that may help them find the bug and therefor either fix it or report it further upstream if it isn't in their code.
> but you'd hope the developer would test on the major browsers.
The developer probably did, if by "major browsers" you mean "the latest of the two of the big three that are available cross platform, and maybe a mobile browser or two" as they were at the time of the site/app's last major update. But testing on all common browsers can be a time consuming process that demands significant resources (a Windows instance for each IE version considered, a Windows, Linux, and OSX instance for each version of Firefox or Chrome considered (as they sometimes hit different problems on different platforms), oh and don't forget that there are several common Linux arragements that you'll see actively used by many people, 8 Windows variants (excluding service packs as variants, 7 if you exclude XP), and a few OSX ones, and that is before you consider 32-bit and 64-bit variations and I've not even touched mobile platforms yet, ..., ..., ...).
Multi-browser testing can be a painful process and even if you either stick to a limited number of combinations (that covers for example 80% of your audience) and/or have the testing automated by some means, the results of tests that you run now might not be relevant tomorrow after a browser maker releases an update or an OS maker releases an update that somehow triggers a latent bug in a browser.
tl;dr: if the browser crashes that is never the site/app's developer's fault. If the site/app fails to work correctly in a given (recent and relatively standards compliant) browser than it probably is but there are practical limitations on what we can do to try acheive 100% correctness.