From: Jasper Hugunin <email@example.com>
Subject: Re: [HoTT] Re: A question about the problem with regularity in CCHM cubical type theory
Date: Sun, 15 Sep 2019 18:38:57 -0400 [thread overview]
Message-ID: <CAGTS-a9XATMbfyyp00M8kqiEoFyj7XsxahMa3AdzXth_=LbTiA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5326 bytes --]
In CCHM, my understanding is that composition for Glue [ phi |-> (T, f) ] A
is actually regular, and reduces to composition in T on (forall i. phi),
assuming composition is regular for A and T.
The regularity does seem to fail in ABCFHL, as you pointed out Anders, but
is perhaps repairable.
What Carlo told me was that the problem is getting composition for Glue [
phi |-> (T, f) ] A which is regular, reduces to composition in T on (forall
i. phi), *and* reduces to composition in A when (T, f) = (A, equivRefl).
We get the first two but not the third in CCHM.
The problem as Carlo explained it was that given a square of types i, j |-
A and a point a : A (i0) (j0), we can prove Path (coe^i A o coe^j A) (coe^j
A o coe^i A) (coercing around the square in right then up vs up then
right), and (assuming regularity for A), we can take this to be degenerate
when A is degenerate in i, or give a different path which is degenerate
when A is degenerate in j, but constructing a path which is degenerate when
A is degenerate in i or j is elusive.
I have an idea for how to add new terms/operations (a sort of
generalization of comp) such that such a path is constructible, but I
haven't yet checked that there is a univalent universe with these more
I also don't understand the negative results from Andrew well enough to
tell if they rule out such an approach.
The idea is to add terms witnessing that for every square x, y |- A x y we
have Path (coe^i (A i i)) ((coe^i (A i 0)) o (coe^i (A 1 i))) which is
degenerate when A is degenerate in x OR y, plus similar terms for higher
cubes, since once you need dimensions one and two you probably need
dimension n, and a similar thing for hcomp, or you can do coe and hcomp
together in just comp.
Composing two of these paths then gives the needed proof that coercing
around the square either way is equal, in a degenerate fashion if A is
degenerate in x or y.
- Jasper Hugunin
On Sun, Sep 15, 2019 at 7:55 AM Andrew Swan <firstname.lastname@example.org> wrote:
> You might have already seen this, but I have a paper on some related
> issues at https://arxiv.org/abs/1808.00920 . In that paper I didn't look
> at the original version of regularity, but a more recent version ("all
> monomorphisms are cofibrations") that fits better with the general
> framework of Orton and Pitts. In that case it is definitely equality of
> objects that causes problems.
> On Friday, 13 September 2019 08:10:42 UTC+2, Jasper Hugunin wrote:
>> Hello all,
>> I've been trying to understand better why composition for the universe
>> does not satisfy regularity.
>> Since comp^i [ phi |-> E ] A is defined as (roughly) Glue [ phi |->
>> equiv^i E ] A, I would expect regularity to follow from two parts:
>> 1. That Glue [ phi |-> equivRefl A ] A reduces to A (a sort of regularity
>> condition for the Glue type constructor itself)
>> 2. That equiv^i (refl A) reduces to equivRefl A
>> I'm curious as to which (or both) of these parts was the issue, or if
>> regularity for the universe was supposed to follow from a different
>> I've been studying and using CCHM cubical type theory recently, and often
>> finding myself wishing that J computed strictly.
>> If I understand correctly, early implementations of ctt did have strict J
>> for Path types, and this was justified by a "regularity" condition on the
>> composition operation, but as discussed in this thread on the HoTT
>> mailing list
>> the definition of composition for the universe was found to not satisfy
>> I don't remember seeing the regularity condition defined anywhere, but my
>> understanding is that it requires that composition in a degenerate line of
>> types, with the system of constraints giving the sides of the box also
>> degenerate in that direction, reduces to just the bottom of the box. This
>> seems to be closed under the usual type formers, plus Glue, but not the
>> universe with computation defined as in the CCHM paper
>> <http://www.cse.chalmers.se/~coquand/cubicaltt.pdf> (for trivial reasons
>> and non-trivial reasons; it gets stuck at the start with Glue [ phi |->
>> equiv^i refl ] A not reducing to anything).
>> Best regards,
>> - Jasper Hugunin
> 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 HomotopyTypeTheoryemail@example.com.
> To view this discussion on the web visit
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 HomotopyTypeTheoryfirstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/HomotopyTypeTheory/CAGTS-a9XATMbfyyp00M8kqiEoFyj7XsxahMa3AdzXth_%3DLbTiA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6717 bytes --]
next prev parent reply other threads:[~2019-09-15 22:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 6:10 [HoTT] " Jasper Hugunin
2019-09-15 5:57 ` [HoTT] " Jasper Hugunin
[not found] ` <CAMWCppk4PWzfZ1HKNLMdAZ=RBC-ARxtJXR8okvwO3raea5gC8Q@mail.gmail.com>
[not found] ` <CAGTS-a-SvWWF+br6sKxGj6ufVY=4m830FH9BDg06QJR1vbNFsw@mail.gmail.com>
2019-09-16 2:18 ` Fwd: " Jasper Hugunin
2019-09-16 16:18 ` [HoTT] " Licata, Dan
2019-09-16 17:09 ` Jasper Hugunin
2019-09-16 19:01 ` Licata, Dan
2019-09-16 20:17 ` Jasper Hugunin
2019-09-18 12:16 ` Anders Mortberg
2019-09-18 12:52 ` Thierry Coquand
2019-09-15 11:55 ` [HoTT] " Andrew Swan
2019-09-15 22:38 ` Jasper Hugunin [this message]
2019-09-16 1:04 ` Jon Sterling
[not found] ` <A605E6EE-0101-4390-B50D-A6AEB36FDCC2@icloud.com>
2019-09-16 1:44 ` Jon Sterling
You may reply publicly 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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).