Every living creature ran on proteins. The enzymes that broke down food in your stomach, the hemoglobin carrying oxygen through your arteries, the antibodies patrolling your bloodstream for invaders — all of them proteins, all of them doing their work with a specificity and elegance that no human engineer had ever matched. But proteins kept their secrets jealously. They performed their functions not merely because of what they were made of, but because of the shape they assumed, and that shape was extraordinarily difficult to know.

Ravi, her graduate student, had arrived from Hyderabad with a sharp mind and an endearing habit of asking the questions that everyone else considered too basic to voice. On a grey Tuesday afternoon, while rain tapped steadily at the laboratory windows, he sat across from her and asked one of those questions. She had been explaining the problem of protein folding, and he had listened carefully, and then he said that it sounded impossible. She told him that it had been, for about fifty years.

To understand why, one had to begin with the alphabet. Proteins were built from amino acids, a set of twenty molecular building blocks, strung together in sequences that could run to tens of thousands of units in length. A gene was essentially an instruction: assemble these amino acids, in this order. But the resulting chain did not remain a chain. It folded. Guided by forces that operated at the atomic scale — hydrogen bonds drawing certain atoms toward each other, hydrophobic regions fleeing from water, electrical charges attracting and repelling across infinitesimal distances — the protein collapsed into a precise three-dimensional shape. That shape was not decorative. It was functional. The contours and cavities of a folded protein determined whether it would act as a catalyst, a carrier, a signal, a structural support, or a lock awaiting the right molecular key. When the folding went wrong, as it did in diseases like Alzheimer's and Parkinson's, the consequences spread through the body with slow catastrophe.

The only reliable way to observe a protein's shape, for most of the twentieth century, was a technique called X-ray crystallography, in which researchers coaxed proteins into forming crystals and then bombarded those crystals with X-ray beams, interpreting the resulting diffraction patterns to reconstruct the molecular architecture. It was painstaking work. A single structure could demand years of effort and sometimes could not be resolved at all. The known universe of proteins numbered in the hundreds of millions. The library of mapped structures, after decades of global scientific effort, contained perhaps two hundred thousand. The distance between what existed and what was known was, in practical terms, almost incomprehensible.

Maya walked to the whiteboard when she reached this part of the explanation, as she always did when ideas required space. She drew two parallel lines representing protein chains and spoke about evolution, which was, she said, simply the longest experiment the planet had ever conducted. Over billions of years of mutation and selection, proteins had been tested relentlessly. When an amino acid in a functional protein changed, the protein frequently broke, and the organism that depended on it died. But sometimes, when one amino acid changed, another changed alongside it, somewhere else in the chain, compensating, preserving the fold, maintaining the shape that kept the creature alive. These correlated mutations, tracked across thousands of species and millions of years, carried a hidden message. Amino acids that changed together across evolutionary time were, almost invariably, close neighbors in three-dimensional space. They were the protein's autobiography, written in the language of survival, and AlphaFold had learned to read it.

The first versions of AlphaFold, developed by a team at DeepMind, demonstrated that a machine learning system trained on the evolutionary record of protein sequences could predict folded structures with an accuracy that stunned the scientific community. The third iteration extended the ambition considerably. Proteins, it turned out, rarely acted in isolation. They bound to strands of DNA, latched onto RNA molecules, docked with small chemical compounds, and clasped the surfaces of other proteins in interactions whose geometry was as important as any individual structure. AlphaFold 3 was trained to model these interactions, to predict not merely the shape of a protein in solitude but the shape it assumed in relationship, the configuration it adopted when it was, as Maya put it to Ravi, moving through a room and deciding who to embrace.

The training data was the accumulated structural knowledge of biology — every crystal structure, every cryo-electron microscopy image, every nuclear magnetic resonance map that the scientific community had produced across decades of effort — digested by a system capable of finding patterns at a depth no human analyst could reach. The network did not memorize. It generalized. It extracted from the data something resembling an understanding of the underlying physical grammar of molecular shape, and it applied that understanding to sequences it had never encountered.

The practical consequences arrived quickly. Structures that had resisted experimental determination for years were predicted in minutes. Researchers working on neglected tropical diseases, on antibiotic-resistant bacteria, on cancers that had proven stubbornly unresponsive to existing treatments, found themselves suddenly able to examine the shapes of proteins that had previously been inaccessible. Drug designers could identify binding pockets — the molecular hollows and clefts where a carefully shaped compound might lodge itself and alter a protein's behavior. A laboratory in Seoul reported progress on a rare childhood disease. A researcher working in Kenya mapped a parasite protein that had never been structurally characterized. The tool was made publicly available, and people used it everywhere, from graduate seminars to high school science competitions.

Ravi asked, at the end of one of these conversations, whether AlphaFold 3 was simply correct, whether the problem had been solved and the remaining work was merely application. Maya gave him the kind of look that good scientists reserve for questions that contain comfortable assumptions. The system struggled with disordered proteins, she explained — molecules that did not hold a fixed shape but instead existed in a perpetual fluid motion, adopting different conformations in different contexts. It occasionally missed rare structural states. Its predictions, however accurate, remained predictions, models of what a protein probably looked like rather than direct observations of what it demonstrably was. Experimental confirmation still mattered. The picture was clearer, not complete.

But the nature of the problem had shifted, and that was perhaps the most significant thing. For half a century the central question had been whether the shape of a protein could be found at all, whether the gap between sequence and structure could be crossed. That question had changed. The new question was what to do with structures once they were known, how to interpret the shapes, how to use them to design molecules that might intervene in disease, how to understand the dynamic interactions between proteins and the environments they inhabited. It was, as Maya had observed, a considerably better problem to be working on. She turned away from the whiteboard and looked at the rain still falling outside, and felt, as she sometimes did in moments of genuine scientific progress, the specific satisfaction of a door that had stood closed for a very long time finally swinging open onto something worth seeing.

In this article, we derive key concepts from first principles.

1. Problem Setup

We define a supervised learning dataset:

$$ \mathcal{D} = {(x^{(i)}, y^{(i)})}_{i=1}^{m} $$

where:

$$ x^{(i)} \in \mathbb{R}^n $$

$$ y^{(i)} \in \mathbb{R} $$

We want to learn a function:

$$ h_\theta : \mathbb{R}^n \rightarrow \mathbb{R} $$

2. Linear Model

We define:

$$ h_\theta(x) = \theta^T x + b $$

Expanded:

$$ h_\theta(x) = \sum_{j=1}^{n} \theta_j x_j + b $$

3. Loss Function

Mean Squared Error:

$$ J(\theta) = \frac{1}{m} \sum_{i=1}^{m} \left( h_\theta(x^{(i)}) - y^{(i)} \right)^2 $$

4. Optimization Objective

We solve:

$$ \theta^* = \arg\min_\theta J(\theta) $$

5. Gradient Descent

Gradient:

$$ \frac{\partial J}{\partial \theta} = \frac{2}{m} \sum_{i=1}^{m} x^{(i)} \left( \theta^T x^{(i)} - y^{(i)} \right) $$

Update rule:

$$ \theta := \theta - \alpha \nabla_\theta J(\theta) $$

6. Vectorized Form

$$ J(\theta) = \frac{1}{m} (X\theta - y)^T (X\theta - y) $$

Gradient:

$$ \nabla_\theta J(\theta) = \frac{2}{m} X^T (X\theta - y) $$

7. Normal Equation

Closed-form solution:

$$ \theta^* = (X^T X)^{-1} X^T y $$

8. Regularization

L2 regularization:

$$ J(\theta) = \frac{1}{m} \sum (h_\theta(x) - y)^2 + \lambda |\theta|_2^2 $$

9. Probabilistic View

Assume:

$$ y = \theta^T x + \epsilon $$

where:

$$ \epsilon \sim \mathcal{N}(0, \sigma^2) $$

Likelihood:

$$ p(y|x,\theta) = \frac{1}{\sqrt{2\pi\sigma^2}} \exp\left(-\frac{(y - \theta^T x)^2}{2\sigma^2}\right) $$

10. Neural Networks Extension

$$ a^{(l)} = \sigma(W^{(l)} a^{(l-1)} + b^{(l)}) $$

Backpropagation:

$$ \frac{\partial J}{\partial W^{(l)}} = \frac{\partial J}{\partial a^{(l)}} \cdot \frac{\partial a^{(l)}}{\partial W^{(l)}} $$

11. General Learning Objective

$$ \min_{\theta} ; \mathbb{E}{(x,y)\sim \mathcal{D}} \left[ \ell(h\theta(x), y) \right] $$

12. Key Insight

$$ \text{Machine Learning} = \text{Optimization} + \text{Statistics} + \text{Linear Algebra} $$

Conclusion

We built the mathematical foundation of machine learning from:

• Linear models
• Loss functions
• Optimization
• Probability

This is the backbone of modern AI systems.

MOD = 998244353
N, M = map(int, input().split())
A = [0] + list(map(int, input().split()))
B = [0] + list(map(int, input().split()))
N += 1

S = [t:=0] + [t:=t+a for a in A]

sa = sb = 0
for i in range(N):
  sa = (sa + A[i]*i)%MOD
for j in range(1, M+1):
  sb = (sb + B[j])%MOD
ans = sa*sb%MOD

for j in range(1, M+1):
  for l in range(0, N, j):
    r = min(N, l+j)
    ans = (ans - (S[r]-S[l])*l*B[j])%MOD

print(ans)

import sys
input = sys.stdin.readline

def solve():
    n = int(input())
    c = input().strip()

    result = c.lstrip('o')
    print(result)

solve()

There's no standard dynamic programming formulation. No graph to traverse. No well-known data structure to reach for. You won't find the answer by applying the right textbook algorithm — because there isn't one. Instead, you must carefully read the problem, think from first principles, and craft a custom solution tailored exactly to what's being asked.

Ad hoc problems are the programming equivalent of a puzzle that has never been seen before. They show up in competitive programming contests, coding interviews, university coursework, and real-world engineering. They are both the simplest and sometimes the most frustrating category of problems — because the only tool you have is your own reasoning.

A Brief History of the Term in Programming

The phrase "ad hoc" entered the competitive programming lexicon through platforms like the ACM International Collegiate Programming Contest (ICPC) in the 1970s and 80s, where judges categorised problems by the techniques required to solve them. Problems involving sorting, graphs, or dynamic programming were easy to label. The ones that required original thinking — problems that resisted categorisation — were grouped together as "ad hoc."

Over time, platforms like SPOJ, Codeforces, UVa Online Judge, and HackerRank formalised the tag. Today, virtually every competitive programming archive uses "ad hoc" as an official problem category, typically meaning: this problem requires careful analysis and creative implementation, not a known algorithm.

What Makes a Problem "Ad Hoc"?

A problem is generally called ad hoc when:

• No standard algorithm directly solves it. You can't just reach for BFS, Dijkstra's, or knapsack DP.
• The logic is unique to the problem's setup. Each ad hoc problem tends to have its own internal rules that you must honour.
• The solution is often simpler than it looks — once you understand it. Many ad hoc problems reward a clear reading of the problem statement more than any algorithmic sophistication.
• Simulation is sometimes enough. Many ad hoc solutions are just careful, literal simulations of what the problem describes.

The difficulty isn't computational complexity — it's comprehension and creativity. You have to model the problem correctly in your head before you can model it in code.

Categories Within Ad Hoc

Although ad hoc problems resist categorisation by definition, they tend to cluster around a few recurring themes:

1. Simulation

You're told: "A system behaves like this. What is its state after N steps?"

The solution is to faithfully simulate the described process. The trick is usually identifying the right state representation and handling edge cases correctly. Simulation problems reward careful reading over clever algorithms.

Example flavour: A game board moves pieces according to described rules. Given an initial configuration and a sequence of moves, output the final board.

2. String and Pattern Manipulation

You're given a string and must detect, transform, or validate some pattern. This could be checking for palindromes, counting occurrences of substrings, or parsing custom-formatted input.

Unlike problems that require the KMP or Aho-Corasick algorithm (which are classified separately), ad hoc string problems can usually be solved with basic iteration and conditionals.

Example flavour: Given a sentence, count how many words have more vowels than consonants.

3. Geometry and Spatial Reasoning

Simple geometry problems — not requiring computational geometry algorithms like convex hull or sweep line — fall into ad hoc territory. These might involve checking if a point is inside a shape, computing distances, or finding intersections.

Example flavour: Given the coordinates of a rectangle and a point, determine whether the point lies strictly inside, on the border, or outside.

4. Mathematics Without Heavy Theory

Some ad hoc problems involve arithmetic, divisibility, number properties, or sequences — but not the deep number theory you'd find on Project Euler. These require mathematical thinking but not advanced theorems.

Example flavour: Given a number N, find the smallest number greater than N that reads the same forwards and backwards (a palindrome).

5. Sorting and Searching with a Twist

The data needs to be sorted or searched, but with a non-standard comparison or multi-criteria ranking that you must define yourself.

Example flavour: Sort a list of people by last name, but break ties by first name in reverse, and then by age if the names are identical.

6. Construction and Generation

Build something that satisfies a set of constraints — a sequence, a grid, a permutation — without a known formula for doing so.

Example flavour: Arrange the numbers 1 through N² in an N×N grid such that every row, column, and diagonal has the same sum (a magic square).

The Anatomy of an Ad Hoc Solution

What does solving an ad hoc problem actually look like? The process tends to follow a predictable rhythm:

Step 1: Read Slowly and Carefully

Ad hoc problems are often tricky because of subtleties buried in the problem statement. A single word — "strictly greater," "at most," "non-empty" — can change everything. Read twice before writing a single line of code.

Step 2: Work Through the Examples by Hand

Don't trust your first mental model. Take the given examples and trace through them manually. Make sure you can reproduce the expected output before attempting to code it.

Step 3: Identify the Core Logic

Ask: what is the fundamental operation this problem is asking me to perform? Strip away the narrative and find the mathematical or logical kernel. Once you can state the core operation in one sentence, you're ready to code.

Step 4: Handle Edge Cases Explicitly

Most ad hoc problems are won or lost on edge cases: empty inputs, single elements, maximum values, negative numbers, strings with only spaces. Think adversarially — what would break your solution?

Step 5: Write and Test

Ad hoc solutions are often surprisingly short — sometimes fewer than 20 lines. The complexity is intellectual, not syntactic. Write clean, readable code. If your solution is growing unwieldy, it's often a sign that you've misunderstood something fundamental.

A Walkthrough: Classic Ad Hoc Problem

Let's look at a typical ad hoc problem and walk through solving it.

Problem Statement:

You are given a 12-hour digital clock that displays hours and minutes (e.g., 3:07). The clock is broken: it displays the correct time exactly once every 12 hours, but gains exactly K minutes every hour. Given the time displayed right now and the value of K, what is the actual correct time?

Analysis: This doesn't fit any standard algorithm. It's a simple arithmetic problem, but you need to model the broken clock's behaviour carefully.

If the clock gains K minutes per hour, then after H hours have passed since the clock showed the correct time, the clock shows (actual time) + H * K minutes. We need to reverse-engineer the actual time.

Solution approach (Python):

def solve(display_h, display_m, K):
    display_total = display_h * 60 + display_m
    
    for h in range(12 * 60):  # actual time from 0..719 minutes
        drift = (h // 60) * K  # clock has gained this many minutes
        shown = (h + drift) % (12 * 60)
        if shown == display_total:
            actual_h = h // 60
            actual_m = h % 60
            print(f"Actual time: {actual_h}:{actual_m:02d}")
            return

display_h, display_m, K = 4, 30, 15
solve(display_h, display_m, K)

No graph, no DP, no fancy data structure. Just careful modelling of the described system and a simple loop. That's ad hoc.

Ad Hoc vs. Other Problem Types

Understanding where ad hoc ends and other categories begin helps you reason about what techniques to reach for:

In practice, the boundaries blur. A problem might be "mostly ad hoc" with one DP component. Classification is a tool for thinking, not a rigid taxonomy.

Where Do Ad Hoc Problems Appear?

Competitive Programming

Every major contest platform — Codeforces, LeetCode, AtCoder, CodeChef, SPOJ — has an ad hoc category. In rated contests, ad hoc problems often appear as the first one or two problems: approachable for everyone, but occasionally containing traps for those who rush.

Coding Interviews

Many interview problems at tech companies are essentially ad hoc. When an interviewer asks you to parse a custom-formatted string, simulate a board game, or implement a non-standard comparator, they're testing your ad hoc reasoning — your ability to think clearly without a predetermined template.

University Assignments

CS courses frequently assign ad hoc problems to test whether students can translate a natural-language specification into working code. The goal isn't to teach a specific algorithm — it's to teach the skill of problem modelling.

Real-World Engineering

The real world is full of ad hoc problems. Writing a script to reformat a legacy dataset, implementing a custom validation rule for a business process, or building a small interpreter for an internal DSL — these all require the same skills: read carefully, model accurately, implement cleanly, handle edge cases.

Why Ad Hoc Problems Are Valuable

They Test Thinking, Not Pattern Matching

Many algorithmic problems can be "solved" by pattern matching: "this looks like a shortest path problem, so I'll use Dijkstra." Ad hoc problems break this shortcut. You can't match a pattern you've never seen. You have to actually think.

They Reward Reading Comprehension

A significant percentage of failed ad hoc submissions are wrong not because of an algorithm bug, but because the solver misunderstood the problem. Reading carefully and precisely is a professional skill, and ad hoc problems sharpen it.

They're Great for Beginners

Ironically, ad hoc problems are among the most accessible for newcomers to competitive programming, precisely because they don't require advanced knowledge. A beginner with good logical thinking can solve an ad hoc problem that stumps someone who knows many algorithms but hasn't developed their reasoning skills.

They Build Resilience

Facing a problem you have no template for and working through it anyway is a confidence-building experience. Every programmer will eventually encounter something genuinely new. Ad hoc practice is training for exactly that moment.

Common Pitfalls

1. Over-engineering the solution Ad hoc problems often have simple solutions. If you find yourself reaching for a complex data structure or multi-stage algorithm, step back. You may have overcomplicated the model.

2. Ignoring edge cases in the problem statement The example test case usually doesn't cover every edge case. Systematically ask: what if the input is empty? What if all values are equal? What if the answer is 0?

3. Integer overflow and off-by-one errors These are the most common bug types in ad hoc problems. Be precise about whether bounds are inclusive or exclusive, and check whether your integer types can hold the maximum possible value.

4. Misreading the output format The problem says "print the answer with no trailing space." You print a trailing space. Wrong answer. Read the output specification as carefully as the problem statement.

Tips for Getting Better at Ad Hoc

1. Solve lots of them. There's no shortcut — exposure builds intuition for how these problems are structured.
2. Don't look at solutions immediately. Sit with a hard problem for at least 30 minutes before checking hints. The discomfort is the training.
3. Annotate what tripped you up. Keep a log of edge cases and misreadings. You'll notice patterns in your own mistakes.
4. Practice on UVa Online Judge or SPOJ. Both have large archives of classic ad hoc problems with an established community of solvers.
5. Simulate by hand before coding. Writing a few steps of the simulation on paper often reveals the logic more clearly than staring at code.
6. Embrace simplicity. The best ad hoc solutions are often remarkably plain. A clean loop with good variable names beats a "clever" trick that's hard to verify.

Ad Hoc in the Bigger Picture

If you think of programming skills as a tree, ad hoc problem solving is the roots. It's not glamorous — nobody becomes famous for their ad hoc solutions — but it underpins everything else. The ability to read a specification, model it precisely, handle its edge cases, and implement it cleanly is the foundation upon which all other programming skills are built.

Dynamic programming is dazzling. Graph algorithms are elegant. But when you encounter something that doesn't fit any box, when the problem is genuinely novel and your experience offers no direct template — that's when ad hoc thinking saves you. And that moment comes far more often than you'd expect.

The next time you're handed a problem and you think, "I don't know what category this is" — congratulations. You've just found an ad hoc problem. Now sit down, read carefully, and figure it out.

Resources to Practice

Ad hoc is not a weakness in your toolkit. It is the toolkit, before the toolkit exists.

What Is Project Euler?

Project Euler is a collection of challenging mathematical and computational problems designed to be solved with the help of programming. Named after the legendary Swiss mathematician Leonhard Euler (1707–1783), the project was launched in October 2001 by Colin Hughes (known online as euler) as a way to bridge the gap between recreational mathematics and computer programming.

At its core, Project Euler is a platform where you are given a problem — sometimes deceptively simple-looking — and you must write a program to compute the answer. The problems range from approachable puzzles for beginners to formidable challenges that require deep mathematical insight and highly optimized algorithms.

The website lives at projecteuler.net and currently hosts over 900 problems, with new ones added regularly.

The Origin Story

The project began as a supplementary tool for a UK-based study group, but word spread quickly through online mathematics and programming communities. By the mid-2000s, it had become a global phenomenon, with participants from virtually every country solving problems in dozens of different programming languages.

Leonhard Euler — the project's namesake — was one of the most prolific mathematicians in history. He made foundational contributions to graph theory, number theory, calculus, and topology. Naming the project after him was a fitting tribute, as many problems on the site draw directly from areas of mathematics he helped define.

How It Works

The Problem Format

Each problem on Project Euler follows a consistent structure:

1. A narrative setup — Usually a short paragraph that introduces the mathematical scenario.
2. A small worked example — Demonstrates the concept with a trivial case you can verify by hand.
3. The actual challenge — The same question but scaled up dramatically, making manual computation impossible.

For example, a problem might say:

"The sum of the natural numbers below 10 that are multiples of 3 or 5 are 3, 5, 6, and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1,000."

The small example (below 10) you can do in your head. The real problem (below 1,000) requires a program — but a simple loop will do. Later problems require far more sophisticated approaches.

The Answer

Every problem has a single numerical answer. You enter it into the website, and it either accepts or rejects it. There is no partial credit, no explanation required — just the number.

This design philosophy is intentional: it puts all the creative pressure on how you get there.

The One-Minute Rule

Project Euler has an informal but widely respected guideline: your solution should run in under one minute on a reasonably modern computer. This isn't enforced by the platform, but it's a cultural norm that pushes solvers toward elegant, efficient solutions rather than brute-force hacks.

Why Do People Love It?

1. The "Aha!" Moment

Many Project Euler problems are designed so that the naive approach is far too slow. You might write a solution that works but would take years to compute. Then, you discover a mathematical insight — a pattern, a theorem, a smarter representation — and suddenly your solution runs in milliseconds. That transition from "this will never finish" to "done in 0.003 seconds" is genuinely thrilling.

2. Language Agnostic

You can solve Project Euler problems in any programming language: Python, C++, Java, Haskell, Rust, JavaScript, Julia, even MATLAB or Excel if you're creative. This makes it a fantastic playground for learning a new language — you already know what the answer should be, so you can focus entirely on learning the language's syntax and idioms.

3. Self-Paced Learning

There are no deadlines, no grading, no pressure. You can spend an hour on a problem or three weeks. Some people blaze through the first 50 problems in a weekend; others savor one problem a month. The platform respects your pace completely.

4. A Sense of Community

After solving a problem, you unlock access to a discussion forum for that problem, where thousands of other solvers share their approaches. Reading these threads is often as educational as solving the problem itself — you see the same problem attacked from a dozen different angles, in different languages, with wildly different levels of mathematical sophistication.

5. The Gamification Element

Each problem you solve adds to your count on your profile. There are achievement levels, and the community maintains unofficial leaderboards. Crossing milestones like solving 25, 50, or 100 problems is genuinely motivating.

The Mathematics Behind the Problems

Project Euler problems are deeply rooted in classical mathematics. Here are some of the major themes you'll encounter:

Number Theory

• Prime numbers and primality testing
• Greatest common divisors and least common multiples
• Modular arithmetic
• Euler's totient function
• The Sieve of Eratosthenes

Combinatorics and Probability

• Counting permutations and combinations
• Pascal's triangle and binomial coefficients
• Random walks and expected values

Dynamic Programming and Recursion

• Fibonacci sequences and recurrence relations
• Lattice path counting
• Coin change and subset sum problems

Geometry and Algebra

• Pythagorean triples
• Continued fractions
• Diophantine equations
• Polygonal numbers (triangular, pentagonal, hexagonal, etc.)

Cryptography and Encoding

• ASCII encoding and XOR ciphers
• Pangrams and text analysis

Calculus and Analysis

• Convergent series
• Digit sums and digit products
• Infinite continued fractions

A Walkthrough: Problem 1

Let's walk through the very first problem to see the Project Euler experience in action.

Problem Statement:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

Naive Solution (Python):

total = 0
for i in range(1000):
    if i % 3 == 0 or i % 5 == 0:
        total += i
print(total)  # 233168

This works perfectly and runs instantly for 1,000. But what if the problem asked for numbers below 1,000,000,000? The loop would be too slow.

Mathematical Solution (Using the Inclusion-Exclusion Principle):

The sum of all multiples of k below n is:

k * (1 + 2 + 3 + ... + floor((n-1)/k))
= k * m*(m+1)/2   where m = floor((n-1)/k)

We compute the sum of multiples of 3, plus the sum of multiples of 5, minus the sum of multiples of 15 (to avoid double-counting):

def sum_multiples(k, n):
    m = (n - 1) // k
    return k * m * (m + 1) // 2

result = sum_multiples(3, 1000) + sum_multiples(5, 1000) - sum_multiples(15, 1000)
print(result)  # 233168

This runs in O(1) time — instant for any n, no matter how large. That's the Project Euler experience in one problem.

Difficulty Levels and Progression

Problems are rated by an approximate difficulty percentage (the percentage of solvers who found it challenging). The first ~50 problems are relatively accessible; by problem 100, you're regularly encountering topics like Gaussian integers, elliptic curves, or advanced dynamic programming.

Project Euler vs. Other Competitive Programming Platforms

Project Euler is often compared to platforms like LeetCode, HackerRank, or Codeforces. Here's how it differs:

Project Euler is better suited for people who love mathematics and want to deepen that love through programming. The other platforms are better for interview prep and competitive programming.

Who Is It For?

Project Euler has an incredibly diverse audience:

• Students learning to program who want meaningful problems to practice on
• Mathematicians who want to explore ideas computationally without deep CS background
• Software engineers who want to sharpen algorithmic thinking
• Hobbyists who simply enjoy puzzles and the satisfaction of a correct answer
• Teachers who use problems as curriculum material
• Language learners who use problems as a benchmark when picking up a new language

Tips for Getting Started

1. Start with Problem 1, not a random one. The early problems scaffold skills you'll need later.
2. Don't rush to look up solutions. The struggle is the point. Even spending two days on a problem and failing teaches you something.
3. Write readable code first, optimize second. Get a correct answer, then think about whether it can be made faster.
4. Keep a math reference handy. Wikipedia and Wolfram MathWorld are your friends. Don't be afraid to look up a theorem — the skill is in applying it, not memorizing it.
5. After solving, read the forum. Seeing five other approaches to the same problem expands your thinking enormously.
6. Don't be discouraged by the difficulty jump. Problems 1–10 are manageable. Problem 14 (Collatz sequence) catches many people off guard. That's normal.

The Legacy and Impact

Over 20 years after launch, Project Euler remains one of the most beloved platforms in the mathematical programming community. It has:

• Over 1 million registered accounts
• Problems solved in hundreds of programming languages
• Spawned countless blog posts, YouTube series, and university courses
• Inspired similar projects like Advent of Code, SPOJ, and Rosalind (for bioinformatics)

More importantly, it has introduced countless people to the idea that mathematics isn't just something you study in school — it's a living, playful, endlessly surprising discipline that comes alive when you can compute with it.

Final Thoughts

Project Euler occupies a unique space in the world of programming challenges. It doesn't care what language you use, how long you take, or how elegant your code looks. It only cares about one thing: did you understand the problem deeply enough to find the answer?

That single focus strips away a lot of noise and gets at something fundamental — the pure pleasure of understanding. Each solved problem is a small proof of competence, a receipt for time well spent thinking carefully about how numbers, patterns, and algorithms behave.

Whether you're a seasoned developer looking for a mental workout, a student just learning to code, or a lifelong math enthusiast who never quite learned to program, Project Euler has a problem waiting for you.

Go solve something.

Start your Project Euler journey at projecteuler.net