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

Theorem 8.8 #92

Merged
merged 17 commits into from
Oct 6, 2023
Merged

Theorem 8.8 #92

merged 17 commits into from
Oct 6, 2023

Conversation

TashiWalde
Copy link
Collaborator

@TashiWalde TashiWalde commented Oct 5, 2023

  1. Introduce the notions of left fibration and inner fibration as right orthogonal maps wrt {0} ⊂ Δ¹ and Λ ⊂ Δ², respectively.

  2. Show that the notions of naive left fibration and left fibration agree. In particular, every projection ∑ A, C -> A of a covariant family C : A -> U is a left fibration (regardless of whether A is Segal).

  3. Use the calculus of left orthogonal shapes to give a slick proof that every left fibration is an inner fibration.

  4. Deduce that for every covariant family C : A -> U over a Segal type A, the total type ∑ C is also Segal. This addresses Formalise Theorem 8.8 of RS17 paper #12 (dare I say closes?) unless @cesarbm03 (or anyone else) still wants to implement an alternative proof.

Notes:

@jonweinb
Copy link
Collaborator

jonweinb commented Oct 5, 2023

For a possible proof of 2.) that doesn't assume the base to be Segal see [BW23, Proposition 6.1.1.

Edit: More precisely, the statement referred to is that any covariant family is inner.

@TashiWalde
Copy link
Collaborator Author

For a possible proof of 2.) that doesn't assume the base to be Segal see [BW23, Proposition 6.1.1.

Edit: More precisely, the statement referred to is that any covariant family is inner.

The proof I implemented also does not use that the base is Segal.

jonweinb
jonweinb previously approved these changes Oct 6, 2023
Copy link
Collaborator

@jonweinb jonweinb left a comment

Choose a reason for hiding this comment

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

That looks great!

@fizruk
Copy link
Member

fizruk commented Oct 6, 2023

Currently this does not properly compile for what seems to be a very weird reason: rzk complains that the variable naiveextext is declared as used but is actually unused. This is not true; and in fact rzk complains about the very same undeclared variable if I omit the uses (naiveextext). @fizruk, what am I missing here?

First, currently you get the following error:

unused variables
  naiveextext
declared as used in definition of
  is-segal-domain-inner-fibration-is-segal-codomain

This is because this definition does not actually rely on naiveextext, so uses (naiveextext) is not needed.
Once you remove that, everything typechecks on my machine with rzk-0.6.6 (I did not push any fixes for that).

@TashiWalde
Copy link
Collaborator Author

Currently this does not properly compile for what seems to be a very weird reason: rzk complains that the variable naiveextext is declared as used but is actually unused. This is not true; and in fact rzk complains about the very same undeclared variable if I omit the uses (naiveextext). @fizruk, what am I missing here?

First, currently you get the following error:

unused variables
  naiveextext
declared as used in definition of
  is-segal-domain-inner-fibration-is-segal-codomain

This is because this definition does not actually rely on naiveextext, so uses (naiveextext) is not needed. Once you remove that, everything typechecks on my machine with rzk-0.6.6 (I did not push any fixes for that).

Thanks! I must have gotten confused and removed the wrong instance of uses (naiveextext).

fizruk
fizruk previously approved these changes Oct 6, 2023
@emilyriehl emilyriehl dismissed fizruk’s stale review October 6, 2023 16:46

The merge-base changed after approval.

@emilyriehl emilyriehl merged commit b87fd9f into rzk-lang:main Oct 6, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants