[Merged by Bors] - refactor(Algebra/Category/ModuleCat): make ModuleCat.Hom a structure#19511
[Merged by Bors] - refactor(Algebra/Category/ModuleCat): make ModuleCat.Hom a structure#19511Vierkantor wants to merge 24 commits intomasterfrom
ModuleCat.Hom a structure#19511Conversation
PR summary f8f8363b30Import changes exceeding 2%
|
| File | Base Count | Head Count | Change |
|---|---|---|---|
| Mathlib.CategoryTheory.Limits.ConcreteCategory.WithAlgebraicStructures | 614 | 730 | +116 (+18.89%) |
Import changes for all files
| Files | Import difference |
|---|---|
Mathlib.CategoryTheory.Limits.ConcreteCategory.WithAlgebraicStructures |
116 |
Declarations diff
+ FGModuleCatEvaluation_apply'
+ Hom
+ Hom.hom₂
+ Hom.hom₂_ofHom₂
+ Hom.instModule
+ HomEquiv.fromRestriction_hom_apply_apply
+ HomEquiv.toRestriction_hom_apply
+ Iso.conj_hom_eq_conj
+ asHom
+ comp_apply
+ endMulEquiv
+ endMulEquiv_comp_ρ
+ endMulEquiv_symm_comp_ρ
+ forget_obj
+ homAddEquiv
+ homEquiv
+ homLinearEquiv
+ hom_action_ρ
+ hom_add
+ hom_bijective
+ hom_comp
+ hom_id
+ hom_injective
+ hom_inv_apply
+ hom_neg
+ hom_nsmul
+ hom_ofHom
+ hom_smul
+ hom_sub
+ hom_sum
+ hom_surjective
+ hom_zero
+ hom_zsmul
+ instance : Add (M ⟶ N)
+ instance : AddCommGroup (M ⟶ N)
+ instance : CoeFun (obj' f M) fun _ => S → M
+ instance : Inhabited (ModuleCat R)
+ instance : Neg (M ⟶ N)
+ instance : SMul S (M ⟶ N)
+ instance : SMul ℕ (M ⟶ N)
+ instance : SMul ℤ (M ⟶ N)
+ instance : Sub (M ⟶ N)
+ instance : Zero (M ⟶ N)
+ instance {M N : ModuleCat.{v} R} : CoeFun (M ⟶ N) (fun _ ↦ M → N)
+ inv_hom_apply
+ ofHom_apply
+ ofHom_comp
+ ofHom_hom
+ ofHom_id
+ ofHom_ρ
+ ofHom₂
+ ofHom₂_compr₂
+ ofHom₂_hom₂
+ pushforward_map_app_apply'
+ pushforward_obj_map_apply'
+ toSheafify_app_apply'
+ ρ_hom
++ hom_ext
++ ofHom
++-- of
- ModuleCat.asHom
- ModuleCat.ofHom
- ModuleCat.ofHom_apply
- coe_comp
- comp_def
- ext
- instance : CoeFun (obj' f M) fun _ => S → M where coe g := g.toFun
- instance {M N : FGModuleCat R} : FunLike (M ⟶ N) M N
- instance {M N : FGModuleCat R} : LinearMapClass (M ⟶ N) R M N
- instance {M N : ModuleCat.{v} R} : AddCommGroup (M ⟶ N) := LinearMap.addCommGroup
- instance {M N : ModuleCat.{v} R} : FunLike (M ⟶ N) M N
- instance {M N : ModuleCat.{v} R} : LinearMapClass (M ⟶ N) R M N
- instance {R : Type u₁} {S : Type u₂} [Ring R] [Ring S] {f : R →+* S}
- ofUnique
You can run this locally as follows
## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>The doc-module for script/declarations_diff.sh contains some details about this script.
Decrease in tech debt: (relative, absolute) = (5.49, 0.03)
| Current number | Change | Type |
|---|---|---|
| 4981 | -30 | porting notes |
| 202 | -2 | disabled simpNF lints |
| 1498 | -24 | erw |
Current commit f8f8363b30
Reference commit a38db992d0
You can run this locally as
./scripts/technical-debt-metrics.sh pr_summary
- The
relativevalue is the weighted sum of the differences with weight given by the inverse of the current value of the statistic. - The
absolutevalue is therelativevalue divided by the total sum of the inverses of the current values (i.e. the weighted average of the differences).
| (M : ModuleCat.{v} R) (N : ModuleCat.{v} S) : | ||
| (M →ₛₗ[f] N) ≃+ (M ⟶ (ModuleCat.restrictScalars f).obj N) where | ||
| toFun g := | ||
| toFun g := asHom (X := M) (Y := (ModuleCat.restrictScalars f).obj N) <| |
There was a problem hiding this comment.
Having to type-ascribe asHom suggests there is some defeq abuse going on.
| have : ∀ x, _ = (0 : _ →ₗ[_] _) x := LinearMap.ext_iff.1 (ModuleCat.hom_ext_iff.mp | ||
| ((linearYonedaObjResolution A).d_comp_d n (n + 1) (n + 2))) | ||
| simp only [ModuleCat.hom_comp, LinearMap.comp_apply] at this | ||
| dsimp only | ||
| simp only [d_eq, LinearEquiv.toModuleIso_inv, LinearEquiv.toModuleIso_hom, ModuleCat.coe_comp, | ||
| Function.comp_apply] | ||
| simp only [d_eq, LinearEquiv.toModuleIso_inv_hom, LinearEquiv.toModuleIso_hom_hom, | ||
| ModuleCat.hom_comp, LinearMap.comp_apply, LinearEquiv.coe_coe, ModuleCat.hom_zero] | ||
| /- Porting note: I can see I need to rewrite `LinearEquiv.coe_coe` twice to at | ||
| least reduce the need for `symm_apply_apply` to be an `erw`. However, even `erw` refuses to | ||
| rewrite the second `coe_coe`... -/ | ||
| erw [LinearEquiv.symm_apply_apply, this] | ||
| exact map_zero _ | ||
| erw [LinearEquiv.symm_apply_apply, this, LinearMap.zero_apply] | ||
| simp | ||
| rfl |
There was a problem hiding this comment.
This proof got uglier, not sure what the concrete cause is.
There was a problem hiding this comment.
I tried a few things and it seems there was already a lot of defeq abuse that got exposed now.
| ext | ||
| simp only [ChainComplex.linearYonedaObj_X, linearYoneda_obj_obj_carrier, CochainComplex.of_x, | ||
| linearYoneda_obj_obj_isAddCommGroup, linearYoneda_obj_obj_isModule, Iso.symm_hom, | ||
| ChainComplex.linearYonedaObj_d, ModuleCat.hom_comp, linearYoneda_obj_map_hom, | ||
| Quiver.Hom.unop_op, LinearEquiv.toModuleIso_inv_hom, LinearMap.coe_comp, Function.comp_apply, | ||
| Linear.leftComp_apply, inhomogeneousCochains.d_def, d_eq, LinearEquiv.toModuleIso_hom_hom, | ||
| ModuleCat.asHom_comp, Category.assoc, LinearEquiv.comp_coe, LinearEquiv.self_trans_symm, | ||
| LinearEquiv.refl_toLinearMap, LinearMap.id_comp, LinearEquiv.coe_coe] | ||
| rfl |
There was a problem hiding this comment.
This proof got a lot uglier, not sure what the concrete cause is.
1454f64 to
800d526
Compare
Mathlib/CategoryTheory/Limits/ConcreteCategory/WithAlgebraicStructures.lean
Show resolved
Hide resolved
|
Overall this looks very good and a lot of proofs got cleaner! Did you run your magic I hope you don't mind that I pushed some small changes to get rid of some more |
|
I tried to add a test file similar to the one for Do you understand this? |
|
I think the testcase fails because there is also the definition |
Ah, silly me, I didn't think of |
|
I put the tests in 554ba63, if you like them feel free to cherry-pick (or tell me to push it here). |
|
Thank you! Feel free to push your commit directly to this branch. :) |
I did run it on an earlier version of the branch, let me see if anything got cleared up in the meantime. (It should be as easy as merging the |
|
No free |
It seems to be only with `restrictScalars` or definitions using `restrictScalars` such as in `AlgebraicGeometry/Modules/Tilde.lean`
…eCat.ofHom` It seems the choice between `ofHom` and `asHom` is somewhat inconsistent in concrete categories, but `ofHom` wins. In particular, we want to be consistent with the newly refactored `AlgebraCat.ofHom` and the constructor for objects `ModuleCat.of`. I have not touched `asHomLeft` and `asHomRight` since #19511 will replace these with `ofHom` everywhere anyway. As discussed in the comments for #19511.
…eCat.ofHom` (#19705) As discussed in the comments for #19511. It seems the choice between `ofHom` and `asHom` is somewhat inconsistent in concrete categories, but `ofHom` wins. In particular, we want to be consistent with the newly refactored `AlgebraCat.ofHom` and the constructor for objects `ModuleCat.of`. The choice between `asHom` and `ofHom` was only made a few months ago: #17476. It's a bit unfortunate to go back on something that was deprecated so recently, but I think the result is worth the pain. I have not touched `asHomLeft` and `asHomRight` since #19511 will replace these with `ofHom` everywhere anyway.
|
This PR/issue depends on: |
|
!bench |
|
Here are the benchmark results for commit f8f8363. Benchmark Metric Change
==================================================================================
- ~Mathlib.Algebra.Category.ModuleCat.Algebra instructions 227.1%
- ~Mathlib.Algebra.Category.ModuleCat.Basic instructions 46.7%
+ ~Mathlib.Algebra.Category.ModuleCat.ChangeOfRings instructions -30.3%
- ~Mathlib.Algebra.Category.ModuleCat.Differentials.Presheaf instructions 15.2%
+ ~Mathlib.Algebra.Category.ModuleCat.Presheaf instructions -16.9%
- ~Mathlib.Algebra.Category.ModuleCat.Presheaf.ChangeOfRings instructions 28.3%
+ ~Mathlib.Algebra.Category.ModuleCat.Presheaf.Monoidal instructions -16.7%
- ~Mathlib.Algebra.Category.ModuleCat.Presheaf.Pushforward instructions 19.1%
+ ~Mathlib.Algebra.Category.ModuleCat.Presheaf.Sheafify instructions -13.4%
- ~Mathlib.Algebra.Category.ModuleCat.Sheaf.Colimits instructions 61.8%
- ~Mathlib.Algebra.Homology.ShortComplex.ModuleCat instructions 71.3%
- ~Mathlib.AlgebraicGeometry.Modules.Tilde instructions 24.1%
- ~Mathlib.CategoryTheory.Linear.Yoneda instructions 19.8%
+ ~Mathlib.CategoryTheory.Monoidal.Internal.Module instructions -9.2%
- ~Mathlib.RepresentationTheory.Rep instructions 12.1% |
|
Hmmm, we still don't get the helpful report... Don't know why not 😢 |
|
bors d+ |
|
✌️ Vierkantor can now approve this pull request. To approve and merge a pull request, simply reply with |
|
I checked again and am happy with the PR, so let's get this merged! bors merge |
#19511) This PR follows the approach of #19065 to solve painful definitional equalities problems by forbidding the identification of `A ⟶ B` and `A →ₗ[R] B`. These are not equal reducibly, so tactics get confused if one is replaced by the other. There seem to be a few regressions caused by defeq abuse that we were able to get away with previously, but some subtle elaboration differences made it evident. Otherwise the cost is inserting many `.hom`s and `asHom`s. A few steps that might clean up the diff, but would be too much work to incorporate in this PR: * Make the `ext` tactic pick up `TensorProduct.ext` again. * Replace the defeq abuse between `(restrictScalars f).obj M` and `M` with explicit maps going back and forth. Overall quite a few proofs could be cleaned up at the cost of more bookkeeping. Co-authored-by: Christian Merten <christian@merten.dev>
|
Pull request successfully merged into master. Build succeeded: |
ModuleCat.Hom a structureModuleCat.Hom a structure
This PR follows the approach of #19065 to solve painful definitional equalities problems by forbidding the identification of
A ⟶ BandA →ₗ[R] B. These are not equal reducibly, so tactics get confused if one is replaced by the other.There seem to be a few regressions caused by defeq abuse that we were able to get away with previously, but some subtle elaboration differences made it evident. Otherwise the cost is inserting many
.homs andasHoms.A few steps that might clean up the diff, but would be too much work to incorporate in this PR:
exttactic pick upTensorProduct.extagain.(restrictScalars f).obj MandMwith explicit maps going back and forth.Overall quite a few proofs could be cleaned up at the cost of more bookkeeping.
ModuleCat.asHomtoModuleCat.ofHom#19705