Conversation
🤖 Gemini PR SummaryThis Pull Request represents a significant effort to formalize fundamental and advanced results in coding theory, primarily focused on clearing existing Features
Fixes
Refactoring
Documentation
Senior Engineer's Note: This is a high-impact PR that significantly increases the "proven" surface area of the coding theory library. However, given the reliance on Codex 5.2 and the author's note regarding new assumptions in Analysis of Changes
✅ **Removed:** 51 `sorry`(s)
🎨 **Style Guide Adherence**As a senior engineer, I have reviewed the code changes for adherence to the ArkLib style guide. Below are the specific violations found: ArkLib/Data/CodingTheory/BerlekampWelch/Sorries.lean
ArkLib/Data/CodingTheory/GuruswamiSudan/GuruswamiSudan.lean
ArkLib/Data/CodingTheory/ProximityGap/AHIV22.lean
ArkLib/Data/CodingTheory/ProximityGap/BCIKS20.lean
ArkLib/Data/Polynomial/RationalFunctions.lean
ArkLib/Data/Polynomial/RationalFunctionsInfrastructure.lean
📄 **Per-File Summaries**
Last updated: 2026-02-18 16:56 UTC. |
|
I know probably a way too big of a PR :( but BCIKS is kinda a dependent on many things RationalFunctions, Guruswami etc. So I went ahead tried to prove as much as I could. I am still going and trying to remove any extra assumptions added to the proofs. But hopefully some of these proofs are helpful :) They include Guruswami, BKICS20, DG25, BerleyKamp and RationalFunctions Codex 5.2. |
…ce‑filter implementation
|
Hello! Thanks for the PR and sorry for the delay in getting to this. I'll be merging the 4.26 PR soon, which might break a few things, and get back to all the other PRs including this one. |
|
Sure I understand, let me know which proofs are useful and I can make a cleaner PR as well if you want. This is definitely too big of a PR for someone who is little new to FV. |
|
I think this looks mostly ok although I'll need a bit more time to manually go through all of it since there are some declaration changes. |
|
/review External: Internal: Comments: |
🤖 AI Review (with external context)🤖 AI ReviewOverall Summary: 📄 **Review for `ArkLib.lean`**Review of Verdict: Correct The changes to
Analysis:
No issues found. 📄 **Review for `ArkLib/Data/CodingTheory/BerlekampWelch/Sorries.lean`**Verdict: Correct Analysis: The changes in
The use of 📄 **Review for `ArkLib/Data/CodingTheory/GuruswamiSudan/GuruswamiSudan.lean`**Verdict: Correct. The file Key Findings:
The formalization is high-quality and logically sound with respect to the repository's coding theory library and the external references. 📄 **Review for `ArkLib/Data/CodingTheory/ProximityGap/AHIV22.lean`**The formalization in Analysis:
Verdict: 📄 **Review for `ArkLib/Data/CodingTheory/ProximityGap/BCIKS20.lean`**Verdict: Incorrect Critical Issues:
Major Issues:
Code Snippet (Illustration of Error): The erroneous definition relies on the code size instead of the list size: noncomputable def ε_affineLines {deg : ℕ} {domain : ι ↪ F} : ℝ≥0 :=
-- This numerator is roughly q^(2*deg + 2), which is exponential in deg
(((Fintype.card ι) * (Fintype.card (ReedSolomon.code domain deg)) ^ 2 : ℕ) : ℝ≥0) /
(Fintype.card F : ℝ≥0)To fix this, one must revert to the strategy of bounding the number of candidate polynomials using the Guruswami-Sudan list size bound (which is polynomial in 📄 **Review for `ArkLib/Data/CodingTheory/ProximityGap/DG25.lean`**Review Report: The changes in this file refactor the theorems Analysis:
Verdict: No issues found. 📄 **Review for `ArkLib/Data/CodingTheory/ProximityGap/ListRecovery.lean`**This file introduces basic scaffolding for list recovery in the context of proximity gap proofs. It provides lemmas for:
The formalization is mathematically correct. The choice to parametrize curves by The proofs rely on standard Verdict: 📄 **Review for `ArkLib/Data/Polynomial/Bivariate.lean`**Verdict: Incorrect Major Issue: def discr_y {F : Type} [CommRing F] (f : F[X][Y]) : F[X] :=
1This is mathematically incorrect for a discriminant function. The previous implementation used Minor Issues:
Positive Findings:
Recommended Fix for def discr_y {F : Type} [CommRing F] (f : F[X][Y]) : F[X] :=
sorry -- Placeholder📄 **Review for `ArkLib/Data/Polynomial/Prelims.lean`**Verdict: Incorrect Critical Issue: Incorrect Definition of The redefinition of
Corrected Approach: -- Revert to the formulaic definition (ensuring types allow division or calculating via determinant)
noncomputable def discriminant {F : Type} [Field F] (f : F[X]) : F :=
f.leadingCoeff ^ (2 * f.natDegree - 2) * ... -- or the resultant formula
-- The previous definition was closer:
-- 1/f.leadingCoeff * Polynomial.resultant f (Polynomial.derivative f)Minor Issue: Triviality of Feedback on Summary: 📄 **Review for `ArkLib/Data/Polynomial/RationalFunctions.lean`**This review covers Verdict: Correct The formalization of the function field Observation regarding Hensel Lifting Placeholders: Detailed Checklist:
The definition The implementation of 📄 **Review for `ArkLib/Data/Polynomial/RationalFunctionsInfrastructure.lean`**The formalization in Detailed Analysis:
Verdict: The file is a correct formalization of the necessary polynomial infrastructure.
No misformalization issues found. |
|
/review External: Internal: Comments: |
|
I tried to fix the issue of vacuous error bounds and pushed the changes but cannot get the AI bot to trigger apparently. This definitely needs to be reviewed by coding theory experts |
Enabled by Codex 5.2. This is an attempt to provide all/majority of the proofs marked as sorry. For proximity gap related lemmas in BCIKS20.lean there have been some assumptions added which require proper review from the experts. @katyhr saw your talk on Coding Theory implementation recently, may be this helps in that regard.
@alexanderlhicks I know there is a refactor going on but I hope some of the proofs here are useful, and I open to doing smaller PRs for the proofs which are clean without any assumptions added.
@chung-thai-nguyen here another PR related to coding theory that you might want to review. I do hope some if not all the proofs are useful.
Please give any feedback or modifications necessary.
Thank you!