You might try The Algorithm Design Manual, the second half of the book is a giant index of algorithms. The first part is a guide on what algorithms you should pick depending on what you're doing.
I second this. I particularly like how they have an in depth section on how to mathematically derive the O complexity of code, and how to build up the proof from there. It't not necessary, but a fun exercise in learning how different algorithms get their complexity defined.
Last year was Advent of Code ( http://adventofcode.com/ ) and while they did not name them, each exercise was based on a known algorithmic problem (knapsack, traveling salesman, ...), and it was a fun way to engage people in a "1 exercise a day" pattern.
I guess you can also try your hand at CodinGame's puzzles ( https://www.codingame.com/training ) as they also involve known algorithms and they are realy fun to play.
But ultimately, both of these resources won't teach you how to implement algorithms.
I would probably recommend studying individual classes of algorithms, and to only move on when you feel ready, as opposed to learning algorithms in ascending difficulty (at the risk of learning them in a haphazard fashion).
VisuAlgo is another cool site that has lots of algorithm visualizations...
http://visualgo.net
What you will probably find is that it's more valuable to gain experience designing your own algorithms using tried-and-true techniques such as dynamic programming, greediness, divide-and-conqur, linear programming, etc. Also keep in mind that data structures are closely linked to algorithms, and vice versa. If you are not familiar with big-O notation I suggest you begin there as it can be used as a measure of both an algorithm's time complexity and its data complexity.
One algorithm a day -- the short answer is if you were going to really learn them and not just forget them then you would have to cheat and constantly review previously 'learned' algorithms as you go. Otherwise you will learn X algorithms and likely forget nearly X algorithms.
I have to question the value of only focusing on learning algorithms and on the idea of optimizing the quantity.
In terms of learning lots of them, it might be more useful to focus on learning more fundamental algorithms _better_ rather than tons of them. Or you might want to carefully select the most generally useful algorithms or ones in a specific field relevant to current projects.
Also, now that we have such powerful general purpose languages and efficient module versioning and distribution, learning to take advantage of those probably has more practical use.
For example, you could spend several weeks or years learning various statistical methods and algorithms for machine learning in a particular area. But then you realize that all of the algorithms are already implemented in python code libraries so you start learning how to apply the libraries in real code for applications rather than reimplementing the libraries.
But then you find out that deep learning techniques far outperform all of those algorithms you learned to implement and then apply via those libraries.
So then you train yourself on sophisticated deep learning techniques and start to implement LSTM in python. Then you realize you never quite got the fundamental understanding of neural networks so go back to work on learning that better.
Then you implement some core neural network algorithms in python and start to build back up to your LSTM implementation. Now you find out that TensorFlow exists but lacks good support for AMD which your university has (perhaps erroneously) made a large investment in.
So then you decide the best thing to do would actually be to try to fix some basic bugs that occur on your platform with the latest TensorFlow/OpenCl/AMD code (or whatever).
You manage to fix one of the minor issues and now several geniuses have their day improved by a bit or two.
The point is, trying to learn a ton of random algorithms in a short period probably isn't the best use of your time.
You might be interested in Programming Praxis https://programmingpraxis.com/, a blog that posts a few exercises per week, with solutions. Some of them are more interesting, some of them less so.
https://projecteuler.net/ is an excellent tool for developing algorithmic thinking. From the project description:
The problems range in difficulty and for many the experience is inductive chain learning. That is, by solving one problem it will expose you to a new concept that allows you to undertake a previously inaccessible problem. So the determined participant will slowly but surely work his/her way through every problem.
I disagree with this recommendation; Project Euler is focused on mathematical questions that don't teach a type of thinking very similar to the thinking used while constructing most algorithms.
I'd say you'd be far better off deriving your own algorithm every day.
Make something to solve a real problem every day of your life and you'll be far better at solving problems then other people. I'd rather be able to do that then just parrot back sorts, graph traversals, and what not.
Just read The Art Of Computer Programming by Knuth very slowly. There's basically a different algorithm every other page. Of course, it will still take you years.
Donald Knuth says he usually writes his book 1 page a day[0]:
Usually when I write a book I finish about one page a day, I mean if the book is 365 pages long it takes me a year, if it's 500 pages long it takes me a year and a half.
Taking up a new algorithm each day is the best way I can think of to be sure you don't know any algorithms well. Learn what the various algorithms are, what problems they solve, and what the general classifications of them are, then move on. You are then empowered to dig deeper into the correct one once you have the actual need for one, you know if it exists or not, and how to begin.
If you want to learn an algorithm I suggest implementing it as well. Since this question does not state any prerequisites I can only suggest the hands down best practical datastructure and algorithm study and reference book I've come accross:
http://infolab.stanford.edu/~ullman/focs.html
It's old but concise and very much to the point. All of the material is highly practical.
Pretty much in the beginning of translation to English, but the original resource in Russian is a trove of information on algorithms. Suits well for the "one also a day" learning format.
You can't. You may be able to consume the knowledge underpinning an algorithm and parrot it back but any attempt to learn it in one day is doomed to failure. Parrot knowledge has zero retention.
There's truth to this of course, but I do find that self-imposed checkpoints are a great source of motivation. Rather than 1 algorithm/day, a better plan (in my experience) would be to find a nice textbook, and schedule a chapter/month (depending on the density of the chosen text) with flexibility.
because "learning the shit out of any one algorithm" is not a very well-defined goal and is at best, a locally optimal strategy. If the OP's goal is to become literate in a many topics, then learning those topics in broad strokes may be better than learning all the details up front.
There often can be a vast literature on any one given topic or algorithm. Are you suggesting the OP acquire researcher-level expertise in everything? Everybody, at some point while learning, makes the decision as to whether or not they understand enough for their own purposes, and then chooses to dive deeper or move on to something else.
Not to overuse buzz terms, but the idea of repeatedly grazing over new concepts without ever gaining a firm grasp of them is a textbook local max way of learning.
Going deep on one algo at a time not only gives you a grasp of that individual algo; it gives you insight into computer science as a whole.
Not to mention that over time it would also look like broad strokes
Go for http://www.spoj.com/, every question there needed an algorithm and doing one question per day will help you in getting better and better in algorithms per day.
Code Wars is my favorite. The earlier ranks are pretty simple but there's a broad depth of challenging problems at the higher levels. Online editor and test runner verifies your solution and the community aspects are a big win.
41 comments
[ 2.9 ms ] story [ 88.5 ms ] threadI guess you can also try your hand at CodinGame's puzzles ( https://www.codingame.com/training ) as they also involve known algorithms and they are realy fun to play.
But ultimately, both of these resources won't teach you how to implement algorithms.
http://jeffe.cs.illinois.edu/teaching/algorithms/
I would probably recommend studying individual classes of algorithms, and to only move on when you feel ready, as opposed to learning algorithms in ascending difficulty (at the risk of learning them in a haphazard fashion).
VisuAlgo is another cool site that has lots of algorithm visualizations... http://visualgo.net
And, if you can handle the dude's voice, I recommend checking out Xoax.net's algorithm videos... http://xoax.net/comp_sci/crs/algorithms/index.php
What you will probably find is that it's more valuable to gain experience designing your own algorithms using tried-and-true techniques such as dynamic programming, greediness, divide-and-conqur, linear programming, etc. Also keep in mind that data structures are closely linked to algorithms, and vice versa. If you are not familiar with big-O notation I suggest you begin there as it can be used as a measure of both an algorithm's time complexity and its data complexity.
https://www.cs.usfca.edu/~galles/visualization/Algorithms.ht...
I have to question the value of only focusing on learning algorithms and on the idea of optimizing the quantity.
In terms of learning lots of them, it might be more useful to focus on learning more fundamental algorithms _better_ rather than tons of them. Or you might want to carefully select the most generally useful algorithms or ones in a specific field relevant to current projects.
Also, now that we have such powerful general purpose languages and efficient module versioning and distribution, learning to take advantage of those probably has more practical use.
For example, you could spend several weeks or years learning various statistical methods and algorithms for machine learning in a particular area. But then you realize that all of the algorithms are already implemented in python code libraries so you start learning how to apply the libraries in real code for applications rather than reimplementing the libraries.
But then you find out that deep learning techniques far outperform all of those algorithms you learned to implement and then apply via those libraries.
So then you train yourself on sophisticated deep learning techniques and start to implement LSTM in python. Then you realize you never quite got the fundamental understanding of neural networks so go back to work on learning that better.
Then you implement some core neural network algorithms in python and start to build back up to your LSTM implementation. Now you find out that TensorFlow exists but lacks good support for AMD which your university has (perhaps erroneously) made a large investment in.
So then you decide the best thing to do would actually be to try to fix some basic bugs that occur on your platform with the latest TensorFlow/OpenCl/AMD code (or whatever).
You manage to fix one of the minor issues and now several geniuses have their day improved by a bit or two.
The point is, trying to learn a ton of random algorithms in a short period probably isn't the best use of your time.
The problems range in difficulty and for many the experience is inductive chain learning. That is, by solving one problem it will expose you to a new concept that allows you to undertake a previously inaccessible problem. So the determined participant will slowly but surely work his/her way through every problem.
Doing old GJC problems would be a better move. https://code.google.com/codejam/contests.html
http://www.differable.com/technical-interview-preparation-an...
Would love to hear if this is helpful to you.
Make something to solve a real problem every day of your life and you'll be far better at solving problems then other people. I'd rather be able to do that then just parrot back sorts, graph traversals, and what not.
Usually when I write a book I finish about one page a day, I mean if the book is 365 pages long it takes me a year, if it's 500 pages long it takes me a year and a half.
So its just normal to read it very slowly.
[0] - https://github.com/kragen/knuth-interview-2006
It's old but concise and very much to the point. All of the material is highly practical.
Pretty much in the beginning of translation to English, but the original resource in Russian is a trove of information on algorithms. Suits well for the "one also a day" learning format.
You can't. You may be able to consume the knowledge underpinning an algorithm and parrot it back but any attempt to learn it in one day is doomed to failure. Parrot knowledge has zero retention.
There often can be a vast literature on any one given topic or algorithm. Are you suggesting the OP acquire researcher-level expertise in everything? Everybody, at some point while learning, makes the decision as to whether or not they understand enough for their own purposes, and then chooses to dive deeper or move on to something else.
Going deep on one algo at a time not only gives you a grasp of that individual algo; it gives you insight into computer science as a whole.
Not to mention that over time it would also look like broad strokes
[1] http://algorithm.wiki/ [2] https://news.ycombinator.com/item?id=12670674
Jeff Atwood aka CodingHorror (of Stackoverflow and Discourse fame) recommended this book strongly in this post titled "Practicing the Fundamentals: The New Turing Omnibus ": https://blog.codinghorror.com/practicing-the-fundamentals-th...
https://www.codewars.com/