-
Notifications
You must be signed in to change notification settings - Fork 297
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] - feat(category_theory/sites/plus): P⁺
for a presheaf P
.
#10284
Conversation
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.
This is looking good! It's unfortunate that the functoriality proofs are such a long dsimp, simp, cases,
dance. But otherwise, lgtm
|
||
instance : inhabited (J.cover X) := ⟨⊤⟩ | ||
|
||
/-- An auxiliary structure, used to define `S.index` in `plus.lean`. -/ |
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.
These names L
and R
are very "unreadable". If you only plan to use this in plus.lean
, I would suggest moving them there, and marking them as implementation detail. If you want to expose them to others, maybe we can cook up a more descriptive name + docstring?
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 think I want to keep these definitions in this file, since they will be used is sheaf.lean
in my next PR. (Actually, I just shuffled some things around and moved the cover.index
definition from plus.lean
to grothendieck.lean
for the same reason).
The names L
and R
are meant to match the fields in cover.index
which in turn match the fields in multicospan_index
, so that's one possible argument for keeping them. Although I agree they're not very descriptive... I'll try to come up with a better name.
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.
Okay! I renamed S.L -> S.arrow
and S.R -> S.relation
for S : J.cover 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.
Great! I like this.
src/category_theory/sites/plus.lean
Outdated
/-- The canonical map from `P` to `J.plus.obj P`. | ||
See `to_plus` for a functorial version. -/ | ||
@[simps] | ||
def map_to_plus : P ⟶ (J.plus D).obj P := |
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.
map
sounds to much like you are mapping something through a functor or homomorphism. So I thought this might be to_plus.app
, but dot-notation is also not ideal. At the same time, you want to reserve to_plus_app
for simps. Would to_plus_on_obj
be a compromise?
def map_to_plus : P ⟶ (J.plus D).obj P := | |
def to_plus_on_obj : P ⟶ (J.plus D).obj P := |
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 agree the name is not ideal. I also realized that there were some @simps generated lemmas like plus_obj_2 because of naming collisions, so I renamed a few things. I'm happy to change the names again if needed.
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.
Thanks 🎉
bors merge
|
||
instance : inhabited (J.cover X) := ⟨⊤⟩ | ||
|
||
/-- An auxiliary structure, used to define `S.index` in `plus.lean`. -/ |
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.
Great! I like this.
This file adds the construction of `P⁺`, for a presheaf `P : Cᵒᵖ ⥤ D`, whenever `C` has a Grothendieck topology `J` and `D` has the appropriate (co)limits. Later, we will show that `P⁺⁺` is the sheafification of `P`, under certain additional hypotheses on `D`. See https://stacks.math.columbia.edu/tag/00W1
Pull request successfully merged into master. Build succeeded: |
P⁺
for a presheaf P
.P⁺
for a presheaf P
.
This file adds the construction of
P⁺
, for a presheafP : Cᵒᵖ ⥤ D
, wheneverC
has a Grothendieck topologyJ
andD
has the appropriate (co)limits.Later, we will show that
P⁺⁺
is the sheafification ofP
, under certain additional hypotheses onD
.See https://stacks.math.columbia.edu/tag/00W1