Do you keep a master reference of topics and links? Or are you getting this list by searching. One of the above links has references by you to the bottom two as well...
I do a search, open all the items in new tabs, check briefly that they really are the same thing, then copy the links in. It's faster than it sounds, faster than you might think.
Also, every now and again I run into something I haven't seen before and which is of value. I use this, then, as a means of adding value by cross-referencing, but also of gaining value to me by a directed random search.
I have a real static visualization. I should put some pictures online. My visualization does not rely on in-place algorithms: There's a square of pixels n x n, if two items are compared by the algorithm the corresponding pixel turns black, otherwise it stays white.
The traces of mergesort, quicksort and so on are quit distinctive.
Sounds much simpler than these ones. I've never really found it useful to see the unordered set transform into an ordered one - the point should be in how the algorithm does divide&conquer.
I'd prefer to see these where each step in the algorithm was a fixed width that is the same across all of the images. As-is the step width is dependent on the number of steps. This fails to show the speed of convergence.
This is excellent. In my opinion, this is the way algorithm information should be presented. No abundant scientific formulations. Python works well as a pseudo-code substitute and visualizations are clear and intuitive.
Intuitive? I have no idea what's going on! Why are those two elements being compared? Why was an element tossed to the end (or beginning) of the list, and then it bounces right back to where it came from? This doesn't at all give me a sense of big-O time, or if the sort is stable, or what its characteristics are for best and worst cases.
Pretty patterns do indeed emerge from these visualizations, and it's definitely a nice piece of work from the author/artist. But let's not pretend it's a useful algorithm teaching tool.
I'm just very pissed off for how such technical information gets represented. People either give you a long academic text with abbreviations and symbols, or they try to explain some very simple things... in Haskell. Or in Java for that matter. What you get is an overabundant chunk of information that contains more of the ritual language-specific circlejerk, than the info you're actually looking for.
This situation is all over the undergrad academia. For a math major, numerical method algorithms described in advanced notation is ok, as long as you are fluent in it. But when I take CS courses and see the same presentation, I get very confused. For god's sake, these people are going to spend more time on Novell manuals, than on the graph theory. I could have learnt all these algorithms, if I didn't need to chew through all that theoretical packaging and generalization. Instead I spend all my time to dig through precise definitions just to get one or two concepts, when I could have gotten them all, if representation was good enough.
I don't think that CS undergrads don't need precision offered by scientific approach. I think there comes a time when you feel the need for precision. But this time won't come when you only know quicksort in java. You have to gain a broad specter of examples before you can set off to learn about big O analysis. Because this kind of analysis is about comparison. Learning is ineffective when you compare one algorithm with a blurred idea of another.
I might sound like a confused student, but what I'm trying to say is that there should be one unified, simple and consistent source of algorithms in understandable languages. I have the large algorithm encyclopedia from Springer Verlag, and it polluted with all uncertainties of the modern CS studies. It shows us the perspective fields of study, but it's too abundant to explain simple ideas. Same thing is about Wikipedia. It tries to be both precise (because experts write articles) and simple (because people like me read them) - but this is like running in opposite directions simultaneously.
Somewhat related: I am quite fond of Chris Okasaki's "Purely Functional Data Structures" and "Concrete Math" by R. Graham, D. Knuth, and O. Patashnik.
But I have almost the exact opposite qualm about most books from what you air: I can't have enough precision. I agree that there can be too many technical details, but there can't be too much precision.
If CS undergrads can't take it, they deserve to suffer. There's always vocational training for people who want a focus on applications. Try to become e.g. a Fachinformatiker (http://de.wikipedia.org/wiki/Fachinformatiker).
P.S. I guess I am a bit too harsh. I agree with most of your points.
> I could have learnt all these algorithms, if I didn't need to chew through all that theoretical packaging and generalization. Instead I spend all my time to dig through precise definitions just to get one or two concepts, when I could have gotten them all, if representation was good enough.
Precise definitions can help your understanding. I hope you will some day get a professor who uses them to good effect.
> Learning is ineffective when you compare one algorithm with a blurred idea of another.
Isn't this a good argument to learn many algorithms with precision?
> I might sound like a confused student, but what I'm trying to say is that there should be one unified, simple and consistent source of algorithms in understandable languages.
Go, write one, please!
> I have the large algorithm encyclopedia from Springer Verlag, and it polluted with all uncertainties of the modern CS studies.
Are you talking about "The Algorithm Design Manual" from Skiena? I co-worker brought it to the office recently. I can't bring myself to like it. It seems there are too many references and not enough meat. I have fonder memories of Sedgewick's "Algorithms". But that may be nostalgia. (Get the version in C or the original Pascal.)
Feel free to ask me about algorithms or data structures, my email address is in my profile. I enjoy talking about algorithms way too much for my own good.
http://news.ycombinator.com/item?id=1077521
http://news.ycombinator.com/item?id=750858
http://news.ycombinator.com/item?id=730346
http://news.ycombinator.com/item?id=716870
http://news.ycombinator.com/item?id=555971
http://news.ycombinator.com/item?id=555549