```
From: Evan Cavallo <evancavallo@gmail.com>
To: Michael Shulman <shulman@sandiego.edu>
Cc: "Licata, Dan" <dlicata@wesleyan.edu>,
"HomotopyTypeTheory@googlegroups.com"
<homotopytypetheory@googlegroups.com>
Subject: Re: [HoTT] Recovering an equivalence from univalence in cubical type theory
Date: Wed, 18 Sep 2019 16:35:53 -0400
Message-ID: <CAFcn59ZLBcQMwJUMnnDKq3ewf582x4z4aqce4xR16xzcQeRxgA@mail.gmail.com> (raw)
In-Reply-To: <CAOvivQz_wY2CVp9Y5caEehVotR7w7D=oP6jpoUxm463pNdNHuA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6392 bytes --]
The definition of univalence for BCH cubical sets in
https://arxiv.org/abs/1710.10941 does satisfy the property that
fst(coe(ua(e))) = fst(e) : A -> B exactly. They note (Remark 7) that the
definition can also be adjusted so that transporting backwards along the
equivalence gives the inverse function one can extract from e.
Roughly, the problem Dan describes in ABCFHL---that the B in Glue [alpha ->
T] B can also depend on the direction of coercion x---can be avoided in the
BCH analogue of Glue by simply demanding that B is degenerate in x. The
restricted operation is still sufficient to prove univalence. We can't make
sense of this in a structural cubical set model because the property of
being degenerate in a given variable isn't stable under diagonal
substitution.
Evan
2019年9月18日(水) 15:23 Michael Shulman <shulman@sandiego.edu>:
> Thanks, that's very interesting!
>
> The reason I ask is that I was wondering to what extent the type "A=B"
> can be regarded as "a coherent definition of equivalence" alongside
> half-adjoint equivalences, maps with contractible fibers, etc. Of
> course in some sense it is (even in Book HoTT), since it's equivalent
> to Equiv(A,B); but the question is how practical it is -- for
> instance, is it reasonable when doing synthetic homotopy theory to
> state all equivalences as equalities?
>
> In practice, the way we often construct equivalences is to make them
> out of a quasi-inverse pair, and all the standard definitions of
> equivalence have the nice property that they remember the two
> functions in the quasi-inverse pair judgmentally. My experience with
> the HoTT/Coq library is that this property is very useful, which is
> one reason we state equivalences as equivalences rather than making
> use of univalence to state them as equalities (another reason is that
> it avoids "univalence-redexes" all over the theory). Half-adjoint
> equivalences have the additional nice property that they remember one
> of the homotopies judgmentally, and if you're willing to prove the
> coherence 2-path by hand then they can be made to remember both of the
> homotopies; this seems to be much less useful than I thought it would
> be when we made the choice to use half-adjoint equivalences in the
> HoTT/Coq library, but it has proven useful at least once.
>
> So I was wondering to what extent equality of types in cubical type
> theory has properties like this. It sounds from what you say like the
> answer is "not much". This makes the lack of regularity seem like a
> rather more serious problem than I had previously thought.
>
> On Wed, Sep 18, 2019 at 9:15 AM Licata, Dan <dlicata@wesleyan.edu> wrote:
> >
> > In ABCFHL, even the function fst(coe(ua(e))) : A -> B is only path-equal
> to fst(e) : A -> B. If I recall correctly, the issue is that composition
> in the Glue type that you use to implement ua doesn’t judgementally give
> you f; instead there is some morally-the-identity-composition (that would
> cancel with regularity) that gets stuck in. This is because the general
> algorithm for composition in the glue type has to coerce in the “base” of
> the glue type (B in Glue [alpha -> T] B), which in the case of ua(e) = Glue
> [x = 0 -> (A,e), x=1 -> (B,id)] B is degenerate in x, but in general might
> not be.
> >
> > I don’t recall any cubical type theories solving this, but I don’t
> remember the details of all of the other variations that have been explored
> well enough to say for sure.
> >
> > > On Sep 18, 2019, at 11:42 AM, Michael Shulman <shulman@sandiego.edu>
> wrote:
> > >
> > > Let Equiv(A,B) denote the type of half-adjoint equivalences, so that
> > > an e:Equiv(A,B) consists of five data: a function A -> B, a function B
> > > -> A, two homotopies, and a coherence 2-path. Using univalence, we
> > > can make e into an identification ua(e) : A=B, and then back into an
> > > equivalence coe(ua(e)) : Equiv(A,B), which is typally equal to e.
> > >
> > > Now we might wonder whether coe(ua(e)) might be in fact *judgmentally*
> > > equal to e; or at least whether this might be true of some, if not
> > > all, of its five components. In Book HoTT this is clearly not the
> > > case, since univalence is posited as an axiom about which we know
> > > nothing else. But what about cubical type theories? Can any of the
> > > components of an equivalence e be recovered, up to judgmental
> > > equality, from coe(ua(e))? (My guess would be that at least the
> > > function A -> B, and probably also the function B -> A, can be
> > > recovered, but perhaps not more.)
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Homotopy Type Theory" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to HomotopyTypeTheory+unsubscribe@googlegroups.com.
> > > To view this discussion on the web visit
> https://groups.google.com/d/msgid/HomotopyTypeTheory/CAOvivQzzSXNHs%2BzbPQTyHEuU53aHXJ0sPe4pr%2Byf0ahLGvUpVA%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Homotopy Type Theory" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to HomotopyTypeTheory+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/HomotopyTypeTheory/1DF8E802-2959-4BEF-A85A-3C6E5E7B9595%40wesleyan.edu
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Homotopy Type Theory" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to HomotopyTypeTheory+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/HomotopyTypeTheory/CAOvivQz_wY2CVp9Y5caEehVotR7w7D%3DoP6jpoUxm463pNdNHuA%40mail.gmail.com
> .
>
--
You received this message because you are subscribed to the Google Groups "Homotopy Type Theory" group.
To unsubscribe from this group and stop receiving emails from it, send an email to HomotopyTypeTheory+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/HomotopyTypeTheory/CAFcn59ZLBcQMwJUMnnDKq3ewf582x4z4aqce4xR16xzcQeRxgA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8303 bytes --]
```

next prev parent reply indexThread overview:5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-18 15:42 Michael Shulman 2019-09-18 16:15 ` Licata, Dan 2019-09-18 19:23 ` Michael Shulman2019-09-18 20:35 ` Evan Cavallo [this message]2019-09-19 8:20 ` Anders Mortberg

Reply instructions:You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the--to,--cc, and--in-reply-toswitches of git-send-email(1): git send-email \ --in-reply-to=CAFcn59ZLBcQMwJUMnnDKq3ewf582x4z4aqce4xR16xzcQeRxgA@mail.gmail.com \ --to=evancavallo@gmail.com \ --cc=dlicata@wesleyan.edu \ --cc=homotopytypetheory@googlegroups.com \ --cc=shulman@sandiego.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting theIn-Reply-Toheader via mailto: links, try the mailto: link

Discussion of Homotopy Type Theory and Univalent Foundations Archives are clonable: git clone --mirror http://inbox.vuxu.org/hott Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.hott AGPL code for this site: git clone https://public-inbox.org/ public-inbox