Jupyter notebooks with solutions and discussions of the first 100 Project Euler problems
Go to file
filifa ff67099715 add license 2025-07-25 23:18:36 -04:00
notebooks simplify condition 2025-07-25 21:46:59 -04:00
.gitignore write up the first few problems, some wip 2025-03-24 00:51:30 -04:00
LICENSE add license 2025-07-25 23:18:36 -04:00
Makefile move notebooks to subdir 2025-04-15 19:26:01 -04:00
README.md add readme 2025-07-25 22:46:54 -04:00

README.md

eulerbooks

This is a collection of Jupyter notebooks containing solutions and discussions for the first 100 Project Euler problems using SageMath.

My main goal with these notebooks is not simply to provide working code for solving the problems. Frequently, solutions to these problems are short, but they're not always easy to follow without understanding some important mathematical principles. Therefore, my aim is to provide insight into the underlying algorithms and mathematical concepts that make an efficient solution possible. I personally find that these topics are frequently even more interesting than the problems themselves, which I see as mainly existing to provide situations to apply the concepts after learning about them. In short, it's more about the journey, not the destination, so these notebooks mainly exist to discuss the former.

Approach

Frequently, either Python or SageMath provide functions and libraries that make it trivially easy to write a solution. I don't have a problem with presenting solutions that use these, since for practical purposes, it's better to use what's already available than to reinvent the wheel. It also tends to lead to code that is easy to read and understand, which is the best kind of code.

However, when a function already exists that does the heavy lifting, I also tend to provide my own basic implementation and an explanation of why it works. This is especially true if a solution or algorithm is based off of an important mathematical concept that is not especially intuitive.

When not especially tedious, I like writing up solutions that do not require programming at all, since these approaches often require interesting mathematical techniques.

Another thing to note is that I don't prioritize a solution's performance above all. When a solution is fast enough (using Project Euler's own "one-minute rule" as a rule of thumb), I instead usually focus on making the code easy to read. You can basically always optimize, but there are frequently diminishing returns, and it tends to negatively impact readability. Once a solution is fast enough to solve the problem at hand, I only consider optimizing further if the concepts are reusable.