Hi I wrote this thing. I guess I'll comment on this thread since it got some attention.<p>I think a lot of people that are in this thread went into this project with the complete wrong state of mind.<p>I'm not trying to teach people how a hash table or linked list implementation works. I'm not trying to make a library that is useful to anyone.<p>What I'm trying to do is connect the dots between a bunch of different important concepts in data structures.<p>People can go read things about each of these individual topics to great length and I encourage them too, but in general there are a lot of great computer science resources for just piecing a lot of related topics together for beginners.<p>Sure you can read a 600 page book that will cover things from end to end, but those are very intimidating when you have no prior knowledge of the topic and sometimes you don't get as much out of them if you don't know the basics.<p>If I can provide people with just a quick highlight reel of essential knowledge of data structures then I've done what I set out to do.<p>I hope Hacker News can appreciate that, I don't expect it to, but I can hope.
Most languages have a built in type for a dynamic array, but many of them lack a built-in queue. I have a favorite trick for a quick-and dirty queue in those languages. You need an array (initially empty) and an integer (initially zero). To add to the queue, add to the array. To get the front of the queue, just do array[int]. And finally, to remove from the queue, simply increment the integer. The advantages of this approach are simplicity and speed: each operation takes amortized constant time. The obvious disadvantage is that it's potentially a major memory leak. For instance, if you try to do breadth-first search of a tree using this queue, your memory usage will be proportional to the size of the tree. How much worse than optimal is this? It depends on the tree. If it's a complete binary tree, you've doubled your memory usage, which might not be too bad. But if the tree is a path, then you use linear memory, whereas a proper queue would only use O(1) memory.
Seems to be a lot of snark in this thread already. If you see a problem, create an issue or submit a pull request. It's great that OP is trying to help spread knowledge.
Hash table realization seems to be harmful with the "no collisions" assumption. That's like writing a red black tree and assuming that insert/delete operations will keep tree balanced so we don't need rotations.
One thing's for sure, it caught my attention. Humungo text that made me chuckle. Then, I clicked on the text, and <i>it</i> was the example. Pretty clever.
At first glance, this looks like it could be a useful reference. Regardless it's worth a visit for the ASCII art alone. My favorite: the literal interpretation of "hash tables".
> algorithms are implemented with data structures<p>Eh, for a certain definition of "algorithm". Plenty of signal processing algorithms, for instance, have nothing to do with data structures.
Question: for the hashtables example, it looks like it's setting arbitrary indexes inside a JS array, instead of incrementing ones. IIRC, Javascript stringifys arrays with gaps like this:<p>[ 1,2,3,undefined/null,undefined/null,undefined/null,undefined/null,undefined/null,4,5,6,undefined/null,undefined/null,undefined/null] - With the hashtables function, if you accidentally generate an index that is say 100,000, wouldn't you end up with an unwieldy-sized array that would be more difficult to search than one like this:<p>[{ value: 1, index: 103405}, { value: 2, index: 14550 }]<p>Or does JS store the arrays as an object internally and just stringify them with all the blanks?
I have 2 issues with this. First, you could say what you wanted to say in 1/3rd of the length if you weren't speaking in such a conversational manner and interspersing your discourse with irrelevant jokes and stuff like ""OOooooOOOooh <i>soo</i> exciting" right?". I don't read stuff on data structures to amuse myself. I want it to be as succint and to the point as possible and not waste my time kidding around. If I want to kid around I will do something else. But I guess some people prefer this, I suppose.<p>Second, I don't think the best place to go on lengthy explanations with figures included is in the comments of a source code file. Markdown is your friend.