I absolutely love project Euler. The math on the harder problems is way over my head but it is still my go-to site whenever I want to learn a new language. By the time you've done a bunch of them you'll be more than underway in understanding the territory and in a much better position to understand tutorials (which inevitably are written by experts in the language and usually make a ton of assumptions).
Alternating between project Euler, a book (or two), back to project Euler for a bit is a very fast school, and you determine how fast you can pace yourself.
I'm hardly in the position to be telling you how you learn a language best, but I always felt programming type puzzles of the oj.leetcode.com variety were better for getting me to learn a programming language, where as projecteuler.net was better at developing mathematical/algorithmic reasoning skills. A non-trivial amount of the early puzzles are do-able by hand.
Project Euler is like sex or diabetes (both of which I have or have had), what it means to you and how it fits into your life is very much an individual thing.
Yes, a lot of the problems can be done by hand. You could treat the problems as "a math problem to solve", or as "an exercise in solving a problem with software."
When you've solved a problem, you have either "obtained the correct answer," or you have "figured out how to obtain the correct answer with software." Or both.
For me, even solving the early trivial ones, that could be done by hand, are more an exercise in software than in math.
Most of the time, I try to write my solutions in a general way, so that I can change the parameters of the problem, run it through software I've already written, and get the right results. The challenge then is defining the boundaries and parameters, and imagining the possible and reasonable limits of those boundaries and parameters. Just like we do every day with the rest of our software challenges.
The fact that these are math problems make it more fun for me, because I am not at all mathematically inclined. So I have to learn a little more math, and then decide if I've learned it sufficiently that my solution is reasonable.
Reading other people's posted solutions is almost as fun as solving the puzzle. I've learned a lot, or at least been impressed, from the various languages and hand solutions.
As for learning a new language, I think Euler is a reasonable tool in the total box. I find that I don't really know a new language until I've struggled with something "real" that matters, to me or my employer. And even then, if I come back to code a year or two later, I sometimes cringe, since I've likely learned more about using the language's strengths in that time, beyond just writing C in a new language.
They can be done by hand but doing them algorithmically usually involves working around machine limitations or figuring out a non trivial algorithm to reduce the runtime complexity to something that will run in seconds rather than days.
One of my favorite parts of Project Euler was getting something where the math seemed beyond me, but I could use a tool like Google to get further.
Not to cheat using Google, but to discover the name of the branch of mathematics I had no clue about, and then to learn enough to keep going.
I still remember the afternoon I spent doing chromatic polynomials by hand, each graph I drew having more mental exclamations on the end, because I was goddamn getting it.
For me, the lift from earning a right answer is palpable.
I couldn't solve it analytically for the life of me. So I wrote a small simulator, computed the answer to within 7 decimal places or so and then tried to figure out why that was the right answer. Then the lightbulb went on and I realized what the real answer should be and it worked.
As I wrote above, I am not very good at math, but to be able to use the computer to make your math understanding better than what it was before you started solving a problem was a huge up for me.
Can you solve that problem analytically? The straightforward answer is to set up a recurrence relation for p(k,n) and use dynamic programming, but even then it's far too laborious to compute p(20000,1000000) without a computer.
Now I can, but initially I had no idea. But the simulation can be coded up in 15 minutes or so and you'll have your first 3 decimal places in a few minutes after that. To get to 9 decimal places takes a while longer.
By analytically, do you mean by hand, or just getting the exact answer by computer? Can project euler problems often be solved by hand? For example this 500th problem doesn't seem very hard with a computer, but doing it by hand seems like it will take a long long time.
There is an elegant way to solve these types of problems analytically using a technique called Poissonization. The aspect that makes computing the correct answer difficult is the dependence among counts for the various chips. Instead imagine the the number of defects is now Poisson distributed with mean lambda. A convenient property of the Poisson distribution is its "binning" property whereby the number of defects hitting each chip as now Poisson(lambda/n) and, most important, the counts are mutually independent. From here you can compute the correct answer by a power series argument. I'll spare you the details but see http://bulletin.imstat.org/2014/02/student-puzzle-corner/ for a worked example.
Interesting idea, but I don't quite get how that lets us compute the answer. If I understand it correctly then we need to get the coefficient of l^(10^6) of (e^-(l/20000) + (l/20000)e^-(l/20000) + (l/20000)^2/2e^-(l/20000))^20000, and I do not know how to do that. In fact that is equivalent to finding the coefficient of x^(10^6) of (1+x+x^2)^20000, and it's easy too see that directly from the original problem, so I'm also not sure what Poissonization does for us here. Perhaps I'm completely misunderstanding the technique?
Yes, I do exactly the same thing! The first 20 problems in particular are excellent for learning a new language. It covers basic math, list operations, file IO, string parsing; in other words all the basics in learning a new language. Plus several of the problems are strung together and encourage you to build up a structured library of tools to help you solve any number of problems.
I'm trying to make it a guide to the language, and programming in general, for true beginners. The very first post of actual coding (after installing, command line basics, and compiling/running with cargo) is a walk through of the first PE problem.
I know how you feel about most beginners guides not actually being suited for beginners. Since I'm a beginner, I'm hoping I'll be able to write one.
Feel free to check it out, and constructive criticism is encouraged!
> it is still my go-to site whenever I want to learn a new language
The great thing about Project Euler for this is that the correct answer isn't a piece of code or an algorithm in some language, but just a number.
Project Euler does not really care how that number was derived. Using a mathematical formula, plain pencil and paper, a program in some language, or cheating via Google-fu? Euler doesn't care.
Because of this, it is very inviting to code a solution in a different language: 1) to learn that language, 2) to use a concept of the language with a better fit with the problem, 3) to see which language yields the quickest answer, measured in development time or actual run time.
The drawback of Project Euler is that it's quite addictive.
Unless you're switching from e.g. Java to e.g. Prolog or Erlang (or Haskell...), is it really useful for learning a new language? I mean, when learning a new language, the basic syntax is the easiest part anyway, but the ecosystem/batteries/best_practices is where the main bottleneck is. And I have an impression that Project Euler problems will help you only with the very basics of the language.
Alternating between project Euler, a book (or two), back to project Euler for a bit is a very fast school, and you determine how fast you can pace yourself.