feat(NumberTheory/AKSPrimality): Adds the AKS primality test#34507
feat(NumberTheory/AKSPrimality): Adds the AKS primality test#34507metakunt wants to merge 65 commits intoleanprover-community:masterfrom
Conversation
PR summary 06a46dae32Import changes for modified filesNo significant changes to the import graph Import changes for all files
|
Co-authored-by: Kim Morrison <[email protected]>
Co-authored-by: Kim Morrison <[email protected]>
✅ PR Title Formatted CorrectlyThe title of this PR has been updated to match our commit style conventions. |
Co-authored-by: Violeta Hernández Palacios <[email protected]>
|
I'll put this as draft until I finish the full theorem. Just wanted to get some feedback first. |
Co-authored-by: qawbecrdtey <[email protected]>
|
Thanks for the review @qawbecrdtey. I don't have any naming preferences so I took your suggestions verbatim. |
| /-- The introspective relation, named by the original authors, only used for the construction of the | ||
| final theorem, and thus made private. -/ | ||
| def introspective (f : K[X]) (n : ℕ) (r : ℕ) [NeZero r] : Prop := | ||
| ∀ μ ∈ (primitiveRoots r K), f.eval (μ ^ n) = f.eval μ ^ n |
There was a problem hiding this comment.
If you're going out of your way to develop API for this, then why not make it public?
There was a problem hiding this comment.
I've made it public now, although I'm not aware if anyone else has uses for it.
| /-- Helper structure to bundle hypotheses. -/ | ||
| structure Conditions (r p n a q : ℕ) (μ : K) [Fact p.Prime] [ExpChar K p] | ||
| [CharP K p] [NeZero r] where | ||
| n_coprime_r : n.Coprime r | ||
| n_ge_3 : 3 ≤ n | ||
| a_def : a = ⌊(√(φ r) * (Real.logb 2 n))⌋₊ | ||
| nlogb_lt_od : (Real.logb 2 n) ^ 2 < orderOf (n : ZMod r) | ||
| icc_coprime: ∀ y ∈ Icc 1 a, n.Coprime y | ||
| icc_introspective: ∀ y : Icc 0 a, introspective ((X : K[X]) - C (y : K)) n r | ||
| is_primitive_root : IsPrimitiveRoot μ r | ||
| p_prime : p.Prime | ||
| q_prime : q.Prime | ||
| p_dvd_n : p ∣ n | ||
| q_dvd_n : q ∣ n | ||
| p_ne_q : p ≠ q |
There was a problem hiding this comment.
To me this reads a lot like a technical math paper (here's our list of assumptions throughout the paper, and now we prove a much of technical lemmas). But with formalization there's an opportunity here to re-digest the proof and think about whether there are better ways to phrase the logical flow for Lean, lemmas to extract that could be helpful for the rest of the library. I haven't thought about this proof at all, but it's worth thinking about if you haven't done so already.
There was a problem hiding this comment.
That is an excellent point. If you read the paper you'll see that the proof is not precise in a sense of being nice to formalise.
Therefore I have done the following simplifications to be easier for a lean workflow.
- Usage of functioriality of injectivity, the authors don't mention it at all.
- Usage of the definition ofMultiset in [Merged by Bors] - feat(Algebra/Polynomial/Basic): Add ofMultiset #32496
- Merging of easily extractable results in [Merged by Bors] - feat(Algebra/Polynomial/Roots): Add ofMultiset_injective #32533 [Merged by Bors] - feat(Data/Nat/Factorization/PrimePow): add Nat.nontrivial_primeFactors_of_two_le_of_not_isPrimePow #33551 [Merged by Bors] - feat(Data/Nat/Choose): Add sum_range_multichoose #33656 [Merged by Bors] - feat(Data/ZMod): coprime_mod_iff_coprime #34500
- Usage of instances as opposed to hard coding AlgebraicClosure
The reason why I chose this structure was quite simple. Every lemma that I couldn't reasonably extract to the other part of the library should have a straightforward context at the beginning of the proof. I fought with missing instances or just in general with a lot of noise. Setting up the copy paste made grind work without thought.
I definitely agree that if a lemma can be generalised it should with the appropriate hypotheses. Most definitions like f, sp1, se2, etc. seem to only be useful for the context of this proof. I originally inlined them but I wanted explicit irreducibility, so that the infoview is nice and tidy and the easiest and most straightforward way is to just bundle them.
It was the best trade-off I could come up with, considering the section is intended to be private and not exposed. It allowed to fill the context of every lemma with everything I need as well as having consistent, short definition usages and theorem applications.
| · exact Coprime.pow_left _ (Coprime.of_dvd_left (div_dvd_of_dvd p_dvd_n) n_coprime_r) | ||
| exact ⟨hu.unit, rfl⟩ | ||
|
|
||
| theorem injective_f (h : Conditions r p n a q μ) : (f h).Injective := by |
There was a problem hiding this comment.
For instance, these injectivity results (here and below) could be generalized substantially, I think.
There was a problem hiding this comment.
What would good generalisations be? For injective_sp1 I could come up with this
theorem injective_sp1_extract {a p : ℕ} {R : Type*} [AddMonoidWithOne R] [CharP R p] (h : a < p)
: (fun x : Fin (a + 1) ↦ (x.val : R)).Injective := sorry
For injective_f I don't see what a good generalisation would be.
Adds the completed proof for the AKS primality test.
Everything except the final theorem is marked private as it's only needed for the final proof.
Also everything except the final theorem is namespaced with AKS.
Zulip discussion: https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/Aks.20primality.20Theorem.206.2E1.20Claim.20.28i.29.20proven