Using Aristotle API for AI-Assisted Theorem Proving in Lean 4: A Formalisation Case Study of the Grasshopper Problem
This paper presents a Lean 4 formalization case study of the IMO 2009 Grasshopper problem using the Aristotle API, demonstrating that while AI can successfully verify local components of a proof strategy, it currently struggles to resolve the global combinatorial bookkeeping required to complete the main theorem.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are trying to solve a complex puzzle, like a high-level math competition problem. You hire a very smart, super-fast robot assistant (called "Aristotle") to help you build the solution. The robot is great at following instructions and checking small, local details, but it sometimes gets stuck on the big picture.
This paper is a report card on a specific test run where the author, Gabriel Lau, asked this robot to solve the famous "Grasshopper Problem" (a tricky math puzzle from 2009) using a computer language called Lean 4.
Here is the story of what happened, explained simply:
The Problem: The Jumping Grasshopper
Imagine a grasshopper sitting at zero on a number line. It has a bag of different jump lengths (all positive numbers). There is also a list of "forbidden spots" (a set ) that the grasshopper must never land on.
The challenge is to find an order to use those jumps so that the grasshopper lands safely every single time, avoiding all the forbidden spots. The paper asks the AI to prove that such a safe order always exists.
The Robot's Attempt: Building a House of Cards
The author asked the AI to write a formal proof. In the world of computer math, a proof is like a chain of logical steps. If every step is checked and verified, the proof is solid. However, there is a "cheat code" in the computer language called sorry. It's like putting a sticky note on a step that says, "Trust me, this works," without actually proving it. If a proof uses sorry, it's not a finished proof; it's just a draft.
What the AI Got Right (The Verified Parts):
The robot was excellent at the "local" work. It successfully built and verified four small, specific tools (lemmas) that act like the foundation and walls of a house:
- The Total Sum Check: It proved that if you add up all the jumps, you get the same total distance no matter the order.
- The Swap Test: It proved that if you swap two neighboring jumps, only one specific landing spot changes; the rest stay the same.
- The New Position: It calculated exactly where the grasshopper lands after that swap.
- The Maximality Logic: It proved a clever rule: "If we have the best possible order, and we are forced to swap two jumps, the new landing spot must also be a forbidden spot."
These four parts are like a perfectly built, inspected, and certified set of bricks. They are mathematically solid.
What the AI Got Wrong (The Missing Part):
The robot failed to build the roof. The main theorem (the final proof that a safe order exists) was closed with a sorry.
The paper explains that the robot knew how to swap jumps and knew that swapping creates "forbidden" landing spots. But it couldn't connect the dots for the global counting argument.
- The Analogy: Imagine the robot found 100 different ways to swap jumps, and each swap pointed to a "forbidden" spot. To win the game, you need to prove that these 100 spots are all different from each other, and that there are so many of them that they run out of room on the "forbidden list."
- The robot got stuck here. It couldn't organize all those scattered forbidden spots into a single, cohesive argument that says, "Look, there are too many forbidden spots to fit in the list, so our assumption must be wrong, and a safe path must exist."
The Big Lesson
The paper isn't about whether the math is true (it is); it's about how we trust AI.
The author uses this case to show a critical limitation: AI can be great at checking small, local details but might fail to see the big picture.
The AI generated a file that looks like a proof because it has verified helper lemmas. But because the main conclusion relies on a sorry (a placeholder), it is not a completed proof. The paper warns us that when AI helps with math, we can't just look at the "verified" green checkmarks. We have to look at the whole structure to see if the most important part is actually finished or just covered with a sticky note.
In short: The AI built a perfect set of tools to solve the puzzle, but it couldn't put the final piece together. The paper is a warning to check the "sticky notes" before trusting the AI's work.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.