A Lean 4 Formalization of Euclidean Domain Algorithms from a 1986 Icon Experimentation Package
This paper presents a complete Lean 4 formalization of the 1986 ICON Euclidean Domain algorithms, separating mathematical definitions, computable implementations, and legacy output reproduction to provide machine-checked proofs for core procedures while preserving the original benchmark results.
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 have an old, dusty recipe book from 1986 written by a chef named Lars. This book contains 14 specific, complex recipes for "cooking" with numbers—things like finding the greatest common divisor, solving puzzles with remainders, and manipulating polynomials. The original book was written in a programming language called Icon, which was like a specialized, quirky kitchen tool that worked great at the time but is now hard for modern computers to understand.
This paper is about a team taking that 1986 recipe book and translating it into Lean 4, a modern, ultra-strict language used to prove mathematical truths. But they didn't just translate the words; they rebuilt the entire kitchen to make sure the food tastes exactly the same, while also adding a "safety inspector" to check if the math is actually correct.
Here is how they did it, broken down into simple concepts:
1. The Three-Layer Kitchen
The biggest challenge was that modern math tools (called Mathlib) are like a high-tech, automated kitchen. They are perfect and proven, but they are "non-computable"—meaning you can't actually run them to see the result on a screen; they only exist as abstract proofs. The 1986 Icon package, however, was a "run-and-see" system.
To bridge this gap, the authors built a kitchen with three distinct floors:
- Floor 1: The Proof Floor (The Safety Inspector). This floor uses the modern, high-tech Mathlib tools. It contains the "gold standard" mathematical definitions. If you ask this floor, "Is this recipe correct?" it gives you a machine-checked "Yes." However, you can't run the actual cooking here.
- Floor 2: The Computable Floor (The Working Kitchen). This floor is a custom-built, old-school kitchen that mimics the 1986 Icon system exactly. It uses pure, step-by-step instructions that a computer can actually run to produce results. It doesn't have the "Safety Inspector" yet, but it produces the exact same numbers as the original 1986 book.
- Floor 3: The Report Floor (The Waiter). This floor is responsible for formatting the output. It takes the numbers from the Working Kitchen and prints them out in the exact same font, spacing, and style as the 1986 report. This allows the team to do a "spot check" to ensure the new system is a perfect clone of the old one.
2. The "Ghost" in the Machine (The Typo Discovery)
One of the most exciting parts of the project was a historical mystery. In the 1986 report, there was a table of results for a specific calculation (called PREM). The printed table showed a massive, complicated number as the answer.
However, when the authors ran the original 1986 code on a modern computer, the answer was zero.
The paper explains that the 1986 report had a typo in the printed table. The math was actually simple: dividing a polynomial by a constant number should always leave a remainder of zero. The new Lean system caught this error by actually "cooking" the recipe and seeing that the result was zero, not the giant number printed in the book. They fixed a 40-year-old documentation error by running the code.
3. What They Actually Proved (and What They Didn't)
The authors are very honest about what is "proven" and what is just "trusted."
- The "Proven" Stuff (Tier A): For basic integer math (like finding the greatest common divisor of two whole numbers), they used the modern Safety Inspector. They have a machine-checked guarantee that these specific algorithms are mathematically perfect.
- The "Trusted" Stuff (Tier B): For the more complex, fancy recipes (like polynomial division or Fast Fourier Transforms), they haven't yet proved they match the modern Safety Inspector. Instead, they rely on Regression Testing. This means they ran the new code and compared the output line-by-line with the 1986 output. Since the 1986 code worked for 40 years, and the new code matches it perfectly, they "trust" it.
- The "To-Do" List (Tier C): They have identified the "Coherence Obligations." This is like a promise to future work: "We promise to eventually prove that the Working Kitchen (Floor 2) produces the exact same results as the Safety Inspector (Floor 1)." They haven't done this yet, but they have mapped out exactly where the proof needs to go.
4. Why This Matters
The paper isn't about inventing new math or using these algorithms for medical diagnosis or space travel. It's about preservation and verification.
- Preservation: They saved a piece of computer science history (the 1986 Icon package) by translating it into a language that will still be readable in 50 years.
- Verification: They showed that even "old" algorithms can be rigorously checked. They proved that the 1986 logic holds up, even if the original printed report had a typo.
- Transparency: They clearly labeled which parts of the code are mathematically proven and which parts are just "we checked it against the old book and it matches."
In short, this paper is a time capsule renovation. They took an old, slightly dusty house, reinforced the foundation with modern steel (Lean proofs), kept the original furniture layout (the 1986 algorithms), and even found a crack in the wall (the typo) that no one noticed for four decades.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.