-
Notifications
You must be signed in to change notification settings - Fork 356
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
[Merged by Bors] - chore: remove unnecessary uses of CategoryTheory.Equivalence.mk #15919
Conversation
PR summary cb45dbd899
|
File | Base Count | Head Count | Change |
---|---|---|---|
Mathlib.CategoryTheory.Sums.Basic | 273 | 271 | -2 (-0.73%) |
Mathlib.CategoryTheory.Sums.Associator | 274 | 272 | -2 (-0.73%) |
Mathlib.Algebra.Category.Grp.EquivalenceGroupAddGroup | 454 | 453 | -1 (-0.22%) |
Import changes for all files
Files | Import difference |
---|---|
Mathlib.CategoryTheory.Sums.Associator Mathlib.CategoryTheory.Sums.Basic |
-2 |
17 filesMathlib.Algebra.Homology.ShortComplex.Ab Mathlib.CategoryTheory.Preadditive.Yoneda.Projective Mathlib.Algebra.Category.Grp.EpiMono Mathlib.Algebra.Category.Grp.AB5 Mathlib.Topology.Category.Profinite.Nobeling Mathlib.Algebra.Category.Grp.Kernels Mathlib.Algebra.Homology.ShortComplex.ModuleCat Mathlib.Algebra.Category.Grp.EnoughInjectives Mathlib.CategoryTheory.Preadditive.Yoneda.Injective Mathlib.Algebra.Category.ModuleCat.Biproducts Mathlib.CategoryTheory.Abelian.Injective Mathlib.CategoryTheory.Abelian.Projective Mathlib.Algebra.Category.Grp.EquivalenceGroupAddGroup Mathlib.Algebra.Homology.ShortComplex.ConcreteCategory Mathlib.Algebra.Category.ModuleCat.Free Mathlib.CategoryTheory.Triangulated.Yoneda Mathlib.Algebra.Homology.ConcreteCategory |
-1 |
Declarations diff
+ isoMk
- from_toCostructuredArrow_eq
- to_fromCostructuredArrow_eq
-+-+ associativity
-+-+ equivalence
-+-+ swapEquiv
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.
NatIso.ofComponents | ||
(fun X ↦ Pointed.Iso.mk (by classical exact Equiv.optionSubtypeNe X.point) (by rfl)) | ||
fun {X Y} f ↦ Pointed.Hom.ext <| funext fun a ↦ by | ||
obtain _ | ⟨a, ha⟩ := a | ||
· exact f.map_point.symm | ||
simp_all [Option.casesOn'_eq_elim, Part.elim_toOption] | ||
functor_unitIso_comp X := by | ||
ext (_|x) |
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 slightly surprised aesop_cat can't do this?
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.
No, it cannot.
maintainer merge |
🚀 Pull request has been placed on the maintainer queue by dagurtomas. |
!bench |
Here are the benchmark results for commit b3c0c79. Benchmark Metric Change
==========================================================================
+ build compilation -5.4%
+ ~Mathlib.CategoryTheory.Comma.Basic instructions -36.6%
+ ~Mathlib.CategoryTheory.Comma.StructuredArrow instructions -42.1%
+ ~Mathlib.CategoryTheory.Elements instructions -35.5%
+ ~Mathlib.CategoryTheory.Functor.KanExtension.Basic instructions -47.6%
+ ~Mathlib.CategoryTheory.Limits.ConeCategory instructions -28.3%
+ ~Mathlib.CategoryTheory.Products.Associator instructions -53.8%
+ ~Mathlib.CategoryTheory.Products.Basic instructions -17.6% |
Very nice. |
Co-authored-by: Matthew Robert Ballard <100034030+mattrobball@users.noreply.github.com>
bors delegate+ Thanks! |
✌️ joelriou can now approve this pull request. To approve and merge a pull request, simply reply with |
Actually, I believe that at some point, some proofs of triangle compatibilities were removed because of performances issues. The situation looks better now :-) |
When it passes CI, please merge |
Thanks! bors merge |
An equivalence of categories consists of a functor, an inverse, and unit and counit isomorphisms which satisfy the same compatibilities as for adjoint functors. However, certain equivalences are constructed via the constructor `Equivalence.mk` which does not assume these compatibilities: by changing the unit isomorphism, it is possible to satisfy the compatibility. When only the existence of an equivalence matters, we may certainly use `Equivalence.mk` (e.g. inside proofs). However, the more we develop the library, the more we may need to unfold the definitions of unit/counit isomorphisms (as it happened in #12728). Then, I would suggest that we refrain from using `Equivalence.mk` as much as possible. In this PR, most uses of `Equivalence.mk` are removed: in most cases, the compatibilities satisfied by adjunctions were easy to prove. Co-authored-by: Joël Riou <37772949+joelriou@users.noreply.github.com>
Build failed (retrying...): |
An equivalence of categories consists of a functor, an inverse, and unit and counit isomorphisms which satisfy the same compatibilities as for adjoint functors. However, certain equivalences are constructed via the constructor `Equivalence.mk` which does not assume these compatibilities: by changing the unit isomorphism, it is possible to satisfy the compatibility. When only the existence of an equivalence matters, we may certainly use `Equivalence.mk` (e.g. inside proofs). However, the more we develop the library, the more we may need to unfold the definitions of unit/counit isomorphisms (as it happened in #12728). Then, I would suggest that we refrain from using `Equivalence.mk` as much as possible. In this PR, most uses of `Equivalence.mk` are removed: in most cases, the compatibilities satisfied by adjunctions were easy to prove. Co-authored-by: Joël Riou <37772949+joelriou@users.noreply.github.com>
Pull request successfully merged into master. Build succeeded: |
An equivalence of categories consists of a functor, an inverse, and unit and counit isomorphisms which satisfy the same compatibilities as for adjoint functors. However, certain equivalences are constructed via the constructor `Equivalence.mk` which does not assume these compatibilities: by changing the unit isomorphism, it is possible to satisfy the compatibility. When only the existence of an equivalence matters, we may certainly use `Equivalence.mk` (e.g. inside proofs). However, the more we develop the library, the more we may need to unfold the definitions of unit/counit isomorphisms (as it happened in #12728). Then, I would suggest that we refrain from using `Equivalence.mk` as much as possible. In this PR, most uses of `Equivalence.mk` are removed: in most cases, the compatibilities satisfied by adjunctions were easy to prove. Co-authored-by: Joël Riou <37772949+joelriou@users.noreply.github.com>
An equivalence of categories consists of a functor, an inverse, and unit and counit isomorphisms which satisfy the same compatibilities as for adjoint functors. However, certain equivalences are constructed via the constructor `Equivalence.mk` which does not assume these compatibilities: by changing the unit isomorphism, it is possible to satisfy the compatibility. When only the existence of an equivalence matters, we may certainly use `Equivalence.mk` (e.g. inside proofs). However, the more we develop the library, the more we may need to unfold the definitions of unit/counit isomorphisms (as it happened in #12728). Then, I would suggest that we refrain from using `Equivalence.mk` as much as possible. In this PR, most uses of `Equivalence.mk` are removed: in most cases, the compatibilities satisfied by adjunctions were easy to prove. Co-authored-by: Joël Riou <37772949+joelriou@users.noreply.github.com>
An equivalence of categories consists of a functor, an inverse, and unit and counit isomorphisms which satisfy the same compatibilities as for adjoint functors. However, certain equivalences are constructed via the constructor `Equivalence.mk` which does not assume these compatibilities: by changing the unit isomorphism, it is possible to satisfy the compatibility. When only the existence of an equivalence matters, we may certainly use `Equivalence.mk` (e.g. inside proofs). However, the more we develop the library, the more we may need to unfold the definitions of unit/counit isomorphisms (as it happened in #12728). Then, I would suggest that we refrain from using `Equivalence.mk` as much as possible. In this PR, most uses of `Equivalence.mk` are removed: in most cases, the compatibilities satisfied by adjunctions were easy to prove. Co-authored-by: Joël Riou <37772949+joelriou@users.noreply.github.com>
An equivalence of categories consists of a functor, an inverse, and unit and counit isomorphisms which satisfy the same compatibilities as for adjoint functors. However, certain equivalences are constructed via the constructor
Equivalence.mk
which does not assume these compatibilities: by changing the unit isomorphism, it is possible to satisfy the compatibility. When only the existence of an equivalence matters, we may certainly useEquivalence.mk
(e.g. inside proofs). However, the more we develop the library, the more we may need to unfold the definitions of unit/counit isomorphisms (as it happened in #12728). Then, I would suggest that we refrain from usingEquivalence.mk
as much as possible. In this PR, most uses ofEquivalence.mk
are removed: in most cases, the compatibilities satisfied by adjunctions were easy to prove.