-
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
feat(CategoryTheory): the localized category is monoidal #12728
base: master
Are you sure you want to change the base?
Conversation
PR summary 52c3e3e78fImport changes for modified filesNo significant changes to the import graph Import changes for all files
|
Current number | Change | Type |
---|---|---|
1518 | 3 | erw |
Current commit 52c3e3e78f
Reference commit e820917259
You can run this locally as
./scripts/technical-debt-metrics.sh pr_summary
- The
relative
value is the weighted sum of the differences with weight given by the inverse of the current value of the statistic. - The
absolute
value is therelative
value divided by the total sum of the inverses of the current values (i.e. the weighted average of the differences).
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>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I just opened #18165 which, if merged, should avoid random merge conflicts appearing here. |
Do I understand that this PR is the next one in line in your epic derived + homology saga? |
Not exactly, in the future (not very soon), we should obtain a "left derived monoidal category structure" on the derived category using left derived functors instead of localized functors (which already invert The main application of this PR shall be the monoidal category structure on categories of sheaves (by thinking of the category of sheaves as a localization of the category of presheaves). It is related to the proof that presheaf categories are monoidal closed (abstract proof #16067 by @dagurtomas and a more explicit approach is #19103). With some little extra work, this internal hom will be used in order to show that the class |
In this PR, we shall show that if
C
is a monoidal category andW
is a class of morphism that is preserved by the tensor product, then the localized category is also monoidal.Co-authored-by: Dagur Asgeirsson dagurtomas@gmail.com
congrLeft
andcongrRight
more explicitly #18165This shall be used in order to obtain a monoidal category structure on sheaves of modules from the monoidal structure on presheaves of modules. This also prepares some of the bifunctor API for the left derived monoidal category structure (when the tensor product does not preserves
W
but can still be left derived).