-
Notifications
You must be signed in to change notification settings - Fork 141
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
A direct proof of univalence from uaβ and uaη #1069
Conversation
I think this looks good. Any opinions @ecavallo ? |
Seems fine to me. |
I marked this as ready for review so that I can make a proper review. It's nice to see that uaη has a direct proof, maybe the 1lab should be updated as well |
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.
Just a suggestion and small request, otherwise very nice contribution!
Thanks, I took care of your requests. Once you're happy with the changes I will rebase and squash my commits. |
I'm really unhappy having to add |
But isn't |
271cbf6
to
8390161
Compare
The computation rules `uaβ` and `uaη` show that `pathToEquiv` and `ua` define both directions of an isomorphism. This sidesteps the proof in module `Univalence`, which is done by induction on paths (`J`) and equivalences (`EquivJ`).
8390161
to
cc06407
Compare
Rebased on current
Convinced. Let's leave it in
I see. I think |
While trying to resolve the duplication between
uaη
anduaTransportη
mentioned in this comment, I noticed that together withuaβ
this yields a very "cubical" proof ofunivalenceIso
, avoiding induction on paths and equivalences completely. I attempted to code-golf away the use ofisoToIsEquiv
and proveisEquivPathToEquiv
directly, but wasn't able to (at least not more efficiently).In detail, the commits do the following:
transpEquiv
toCubical.Foundations.Equiv.Base
and generalizes it to arbitrary lines of types. Arguably, this should be calledisEquivCoei→1
and live in*.CartesianKanOps
, but there's a module dependency cycle involving that and*.GroupoidLaws
that I'm not sure how to break.uaη
viaGlue
types from*.Transport
to*.Univalence
, deprecatesuaTransportη
in the former.univalenceIso
. The 1lab has a similar proof, they note however thatuaη
"is hard".I'd like some feedback on these changes,
so I'm marking this as a draft for now.In particular, I'm not sure how and where to place things in the module hierarchy, how to deprecate stuff (if at all), and whether the new proof is even better at all. Additionally, the improved proof ofuaη
is by @dolio originally, and I don't want the attribution to be lost.Pinging @mortberg who encouraged the cleanup as part of #1017.