Really nice. The examples suggest to me that a lot of algorithms would be more accessible to people if they could be visually represented in some way. The timing is important -- the slowness of the bubble sort compared to the quickness of the quick sort gives one an immediate sense of why one would generally want the latter over the former.
I'm more interested in the visual aesthetic, but I've built a few sculptures[1] visualizing algorithms. It's something I'm hoping to expand on when I have more time and resources. I'd write a bit more about them, but I'm on my phone getting ready for work.
Despite what that github page says about not having any reason for making these sculptures, I'm currently thinking of them as a way to highlight the kinds of concepts and technology that our computer-saturated world relies on to operate. Of course the obvious audience is people who already have an understanding of computer science, but by making them aesthetically pleasing I hope to expose people who aren't interested in algorithms to some of the algorithms that influence or make up the technology they rely on. They're intended to be shown in a gallery space, but now that I have space to show in they're more than 500 miles away from me; hopefully I'll put a show together later this year.
Often it has to do with speed of implementation and a data set that is small enough for negligible difference. There is also an issue of whether the algorithm keeps duplicate ordering intact.
Radix sort is one of those tricks that doesn't help often, but every once in a while can produce spectacular results. Here it is showing a 4x speedup on a particular operation in git:
Yeah, I am kidding - don't worry I won't, I can imagine that getting pretty irritating :P
I did this as a quick hack on a whim about a year ago (was a visualisation I wanted to see but couldn't find one quite like this), I am pleasantly surprised by the positivity on this (I kinda posted it on a whim), so I think I will probably hack on it again :-)
It's tempting to code up a whole bunch of sorting algorithms, merge and heap sort are definitely high on the list.
I've played with sound as well with sort visualizations - it has been disappointing and more irritating than enlightening, but maybe there's a proper angle on it somebody will find that adds to the understanding of the algorithm.
And as the others have said - your rainbow viz is really nice, in a lot of ways :)
I find this visual+audio version both entertaining and genuinely useful as tracking changes in multiple sounds at the same time that quickly, combined with the visual process gives more tangibility to the algorithm. Plus the punchline was unexpected and fits well to a "credits" part.
I'm seeing waaaay too much stuff happen all at once for quicksort. Frankly, most visualizations give you an inkling as to the logic behind an algorithm, but quicksort just sort of pops the field into the correct order in a blur.
Another classic sorting algorithm to visualize is heapsort.
I looked through the code, I see why quicksort is such a blur now, and I don't see an obvious way to fix it. Since you are in a sense, benchmarking these algorithms.
One way to do it might be to allow the user to set the timeout in your defer function.
Setting the timeout to 1 second lets the user observe each run of your algorithms. You can see the partitioning behaviour a bit better like that.
Side note: this code is pretty. I should learn coffeescript.
I really need to jump back into the code, not looked at it for a while and take a look at improving how 'fairly' it benchmarks the algorithms. That's an interesting suggestion, will experiment with it.
Thanks for your kind comment on the code qual :) personally I only see the faults, for one I am sure I could improve perf... year-old code is often that way however! :)
I tried to implement shell sort in your system. Shell sort is much like quick sort in that it kind of divides and conquers. (you can see my horrid first timer work here: https://github.com/Ghoughpteighbteau/Rainbow-Sort )
My estimation is that you need to refactor the algorithms such that they hold their state inside a closure, and break after a set number of swaps. Say every 300 swaps they break and the canvas updates. This kind of background processing is such a pain in javascript.
Yeah, the problem is it just sort of "happens" without me being able to understand what's going on behind the scenes. For instance, all of a sudden half the screen is slightly more sorted, but I have no clue what went into getting it that way, even though it took more time to do so.
Yeah, I think I need to review this code + make it 'fairer' or at least somewhat smoother. The positive reaction here has motivated me to hack on this project again!
Interestingly, I just migrated my Sorting Visualizer off of GAE this weekend. Its kind of similar - more customizable, much less attractive: http://aarondufour.com/
This is excellent and a great teaching tool. I tried putting something like this together a while back as a Java applet for one of my classes but couldn't get the color ordering function to work correctly. Did you use HSB?
Thanks for the link, you're absolutely right that RGB doesn't work. I modified my original one dimensional sort to make it look like your 2D one, and got this:
