Simple algorithms
algorithms.openmymind.net
algorithms.openmymind.net
If you plan on doing some tree/graph algorithms, perhaps you could have a brief introduction to the topic by talking about trees and graphs in general, then proceeding by discussing heaps, simple binary trees (which can branch off into more advanced topics like the various balanced binary trees), and so forth.
As a side note, I think binary trees are a great visual way to introduce the concept of asymptotic running time in a more accessible/pragmatic (albeit less rigorous) way, by showing that the more balanced a binary tree is, the fewer steps it will take on average to find an element (approaching the best-case of log base 2 of n). You can show how a worst-case unbalanced binary tree degrades to a linked list.
I'd like to add more, but as I said in another comment, when I started doing quicksort, it didn't feel right. I'd likely need to build a different UI paradigm to represent more complicated algorithms. Same with a btree, I really want to go over it, but that seemed like a ball of UI hurt. Might still try to tackle it though.
All in all - I hope you keep up the good work, solid tutorials like these make it more compelling to keep up with the basics and learn new things from the "CS 101" department.
A tip: It would be better if you could expand on the "Real World" section, especially when it comes to specific examples (e.g. dictionaries etc). That way, more students would relate to understanding exactly how those data structures are used in practical applications.
Do you plan to add more algorithms?
But, I might try again, or find a different approach to represent some slightly more complicated algorithms. Quicksort and some type of Btree would likely be next on my list, if I feel I can do them justice.
And, yes, including some kind of self-balancing tree would seem to be a good idea. But how the heck does one discuss such things concisely and simply? I couldn't say.
In any case, nice site.
data Heap k v = Empty | Heap k v [Heap k v]
merge Empty h = h
merge (Heap k1 v hs) h@(Heap k2 _ _) | k1 <= k2 = Heap k1 v (h:hs)
merge a b = merge b a
extractmin (Heap k v hs) = (v, foldr merge Empty hs)
insert h k v = merge h (Heap k v [])
Honestly, though, I don't think such a thing is what this website is aiming at. It seems to be more for the established, widely used stuff.
Still nice, though. (It's cute how, for so many of the "heap" data structures, the merge operation is really all you need to give much thought to. See also Binomial Heap, etc.)
> These 6 lines of code provide a heap data structure with amortized logarithmic time for extractmin and constant time insertion and merging (!).
Hmmm ... maybe. We need to be exceptionally careful in our reasoning about time complexity, when the code uses lazy evaluation (perhaps more careful than people know how to be, yet).
The potential "bug" you pointed out has nothing to do with the algorithm being taught, and is an implementation detail that's irrelevant for this application.
IEEE doubles only have a 52 bit mantissa, so you need to keep that array under 2^51 elements. Call it 2 quadrillion to be safe.
I would love if he could take this further and, say, cover graph algorithms in the same way the Linked List was done here.
In addiation I had thought to add a 'live run' feature so that you could actually run 1 or more algorithms together and compare performance/memory usage etc!
hmmm... if we defined an API for running a piece of code and returning results, we could build a series of independant web applications that could run sandboxed code in different languages live on the web...
From a teaching perspective I think it would be great to see the math behind this as well to get the worst case scenerio.