Skip to content
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

Closed
wants to merge 6 commits into from

Conversation

adamtopaz
Copy link
Collaborator

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


Open in Gitpod

@adamtopaz adamtopaz added awaiting-CI The author would like to see what CI has to say before doing more work. awaiting-review The author would like community review of the PR labels Nov 11, 2021
@github-actions github-actions bot removed the awaiting-CI The author would like to see what CI has to say before doing more work. label Nov 11, 2021
@alreadydone alreadydone added this to In progress in Algebraic geometry via automation Nov 11, 2021
@alreadydone alreadydone moved this from In progress to Pending review in Algebraic geometry Nov 11, 2021
Copy link
Member

@jcommelin jcommelin left a 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`. -/
Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! I like this.

/-- 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 :=
Copy link
Member

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?

Suggested change
def map_to_plus : P ⟶ (J.plus D).obj P :=
def to_plus_on_obj : P ⟶ (J.plus D).obj P :=

Copy link
Collaborator Author

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.

@adamtopaz adamtopaz moved this from Pending review to Done in Algebraic geometry Nov 12, 2021
@adamtopaz adamtopaz moved this from Done to Pending review in Algebraic geometry Nov 12, 2021
Copy link
Member

@jcommelin jcommelin left a 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`. -/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! I like this.

@github-actions github-actions bot added ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.) and removed awaiting-review The author would like community review of the PR labels Nov 12, 2021
bors bot pushed a commit that referenced this pull request Nov 12, 2021
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
@bors
Copy link

bors bot commented Nov 12, 2021

Pull request successfully merged into master.

Build succeeded:

@bors bors bot changed the title feat(category_theory/sites/plus): P⁺ for a presheaf P. [Merged by Bors] - feat(category_theory/sites/plus): P⁺ for a presheaf P. Nov 12, 2021
@bors bors bot closed this Nov 12, 2021
Algebraic geometry automation moved this from Pending review to Done Nov 12, 2021
@bors bors bot deleted the grothendieck_topology_cover branch November 12, 2021 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.)
Projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants