-
Notifications
You must be signed in to change notification settings - Fork 4
Proofs for typeclass instances of CPolynomial #73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
…al.lean This partially resolves issue 38
Added the assumption that R is non-trivial in the relevant files. Removed instance of One for the trivial case.
This file was refactored so that it can accommodate the case when R is a Semiring. The variables R and Q are changed to Semirings and a section for lemmas and instances requiring R to be a Ring is added,
🤖 Gemini PR SummaryThis PR generalizes the Features
Refactoring
Documentation & Maintenance
|
| Metric | Count |
|---|---|
| 📝 Files Changed | 2 |
| ✅ Lines Added | 201 |
| ❌ Lines Removed | 123 |
sorry Tracking
✅ **Removed:** 10 `sorry`(s)
lemma zero_mul (p : CPolynomial R) : 0 * p = 0inCompPoly/Univariate/Basic.leaninstance [LawfulBEq R] [Nontrivial R] : Ring (CPolynomial R) whereinCompPoly/Univariate/Basic.leanlemma one_mul (p : CPolynomial R) : 1 * p = pinCompPoly/Univariate/Basic.leanlemma mul_assoc (p q r : CPolynomial R) : (p * q) * r = p * (q * r)inCompPoly/Univariate/Basic.leanlemma right_distrib (p q r : CPolynomial R) : (p + q) * r = p * r + q * rinCompPoly/Univariate/Basic.leandef monomialC [DecidableEq R] (n : ℕ) (c : R) : CPolynomial RinCompPoly/Univariate/Basic.leanlemma mul_zero (p : CPolynomial R) : p * 0 = 0inCompPoly/Univariate/Basic.leanlemma left_distrib (p q r : CPolynomial R) : p * (q + r) = p * q + p * rinCompPoly/Univariate/Basic.leanlemma mul_one (p : CPolynomial R) : p * 1 = pinCompPoly/Univariate/Basic.leaninstance [CommSemiring R] [LawfulBEq R] [Nontrivial R] : CommSemiring (CPolynomial R) whereinCompPoly/Univariate/Basic.lean
🎨 **Style Guide Adherence**
Review of Code Changes for CompPoly
CompPoly/Univariate/Basic.lean
- Line 153:
rw[this, one_mul_trim]— "We aim to adhere to the Lean community's contribution guidelines." (Missing space afterrw). - Line 153:
(1: CPolynomial.Raw R)— "Put spaces on both sides of:,:=, and infix operators." - Line 159:
rw[this, mul_one_trim]— "We aim to adhere to the Lean community's contribution guidelines." (Missing space afterrw). - Line 159:
(1: CPolynomial.Raw R)— "Put spaces on both sides of:,:=, and infix operators." - Line 214:
right_distrib := by intro p q r; exact right_distrib p q r— "We aim to adhere to the Lean community's contribution guidelines." (Extra whitespace afterby). - Line 258:
have dist_lhs : (-p + p).val = ((-p).val + p.val) := rfl— "We aim to adhere to the Lean community's contribution guidelines." (Extra whitespace before=).
CompPoly/Univariate/Raw.lean
- Line 1367:
def neg (p : CPolynomial.Raw R) : CPolynomial.Raw R := p.map (fun a => -a)— "Every definition and major theorem should have a docstring." - Line 1367:
(fun a => -a)— "Preferfun x ↦ ...overλ x, ...." (Use of=>instead of↦). - Line 1371:
def sub (p q : CPolynomial.Raw R) : CPolynomial.Raw R := p.add q.neg— "Every definition and major theorem should have a docstring." - Line 1373:
instance : Neg (CPolynomial.Raw R) := ⟨CPolynomial.Raw.neg⟩— "Use thewheresyntax for defining instances and structures." - Line 1374:
instance : Sub (CPolynomial.Raw R) := ⟨CPolynomial.Raw.sub⟩— "Use thewheresyntax for defining instances and structures." - Line 1375:
instance : IntCast (CPolynomial.Raw R) := ⟨fun n => CPolynomial.Raw.C (n : R)⟩— "Use thewheresyntax for defining instances and structures." - Line 1375:
(fun n => ...)— "Preferfun x ↦ ...overλ x, ...." (Use of=>instead of↦). - Line 1378:
def divModByMonicAux [Field R] ...— "Every definition and major theorem should have a docstring." - Line 1395:
def divByMonic [Field R] ...— "Every definition and major theorem should have a docstring." - Line 1400:
def modByMonic [Field R] ...— "Every definition and major theorem should have a docstring." - Line 1405:
def div [Field R] ...— "Every definition and major theorem should have a docstring." - Line 1409:
def mod [Field R] ...— "Every definition and major theorem should have a docstring." - Line 1411:
instance [Field R] : Div (CPolynomial.Raw R) := ⟨div⟩— "Use thewheresyntax for defining instances and structures." - Line 1412:
instance [Field R] : Mod (CPolynomial.Raw R) := ⟨mod⟩— "Use thewheresyntax for defining instances and structures." - Line 1414:
lemma neg_coeff : ∀ (p : CPolynomial.Raw R) (i : ℕ), ...— "Every definition and major theorem should have a docstring." - Line 1414:
lemma neg_coeff : ∀ (p : CPolynomial.Raw R) (i : ℕ), ...— "Prefer placing hypotheses to the left of the colon (e.g.,(h : P) : Q) rather than using arrows (: P → Q) when the proof introduces them." (Use of∀instead of variables left of colon).
📄 **Per-File Summaries**
- CompPoly/Univariate/Basic.lean: Generalized the
CPolynomialtype to support semirings and completed the proofs for its algebraic hierarchy, includingSemiring,CommSemiring,Ring, andCommRinginstances. - CompPoly/Univariate/Raw.lean: Generalize basic polynomial operations to semirings and reorganize ring- and field-specific definitions into dedicated sections.
Last updated: 2026-02-05 18:42 UTC.
dhsorens
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm encountering some weird typeclass issues after the refactor that look like might be a problem for you here as well - I wonder if we should revert the refactor, fill in the sorrys for canonical polynomials, and then I can do the refactor again but more carefully?
|
I opened #74 to have a reverted branch available - feel free to write a pull request into that branch if this one is giving too many problems and then I'll merge there and redo the refactor (hopefully in a way that doesn't cause weird problems for us in future) -- equally if the problems you're facing don't have anything to do with the refactor then feel free to keep going here and we'll sort things out! |
|
sorry to spam with comments - I opened #75 off of the refactored (main) branch and things seem to be fine, even though names are somewhat awkward still. the awkward naming doesn't have to be resolved now or in this PR |
This PR does a refactoring of
Raw.Leanto allow for the case whenRis a Semiring. This PR also fills in the proofs for the typeclass instances inBasic.Lean. This PR should close issues #37 #38 #39 #40 #41.TODO:
Raw.LeanandBasic.LeanI am afraid that I may have overloaded some of the notation which can cause unnecessary issues with typeclasses in proofs.npow n pandnpow_succEquiv.Lean, it is not compiling for some reason.