Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Valery Isaev <valery.isaev@gmail.com>
To: Michael Shulman <shulman@sandiego.edu>
Cc: Jon Sterling <jon@jonmsterling.com>,
	 "HomotopyTypeTheory@googlegroups.com"
	<homotopytypetheory@googlegroups.com>
Subject: Re: [HoTT] New theorem prover Arend is released
Date: Sun, 11 Aug 2019 13:46:19 +0300	[thread overview]
Message-ID: <CAA520ftYLYwiZs0B3fmuYb==8mWiOpVD0yVbV8otfTEfgWV8UQ@mail.gmail.com> (raw)
In-Reply-To: <CAOvivQxKMPvpm9Vwkt4ARR7R5qLmzJMUkFCrf=rFUL5sd4nXLQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3369 bytes --]

вс, 11 авг. 2019 г. в 02:37, Michael Shulman <shulman@sandiego.edu>:

> On Sat, Aug 10, 2019 at 5:25 AM Valery Isaev <valery.isaev@gmail.com>
> wrote:
> > The document is slightly outdated. We do not have the rule iso A B (λx ⇒
> x) (λx ⇒ x) idp idp i ⇒β A in the actual implementation since univalence is
> true even without it. This rule has another problem. It seems that the
> theory as presented in the document introduces a quasi-equivalence between
> A = B and Equiv A B, which means that there are some true statements which
> are not provable in it.
>
> I don't understand.  By "quasi-equivalence" do you mean an incoherent
> equivalence (what the book calls a map with a quasi-inverse)?  If so,
> then every quasi-equivalence can of course be promoted to a strong
> equivalence.
>

Yes, a quasi-equivalence is a function together with its quasi-inverse. The
problem is that we've got some terms in the theory of which we know
nothing about. It's the same as if I just add a new type *Magic *without
any additional rules. Then we cannot prove anything about it and the
resulting theory won't be equivalent to the original one.


>
> However, as I said, I'm more worried about the fourth rule coe_{λ k ⇒
> iso A B f g p q k} a right ⇒β f a.  That's the one that I have trouble
> seeing how to interpret in a model category.  Can you say anything
> about that?
>

I don't remember well, but I think the idea is that you need to prove that
there is a trivial cofibration Eq(A,B) -> F(U^I,A,B), where the first
object is the object of equivalences between A and B and the second object
is the fiber of U^I over A and B. The fact that this map is a weak
equivalence is just the univalence axiom. The problem is to show that it is
a cofibration and whether this is true or not depends on the definition of
Eq(A,B). I don't actually remember whether I finished this proof.


>
> > If you can prove that some \data or \record satisfies isSet (or, more
> generally, that it is an n-type), then you can put this proof in \use
> \level function corresponding to this definition and it will be put in the
> corresponding universe.
>
> What does it mean for it to be "put in" the corresponding universe?
>

I mean F(A,p) will have type \Set0 instead of \Type0 that it would have
without the \use \level annotation.


> The documentation for \use \level makes it sound as though the
> definition *itself*, rather than something equivalent to it, ends up
> in the corresponding universe.


Yes, F(A,p) *itself* has type \Set0, but A still has type \Type0.


> How is the equivalence between A and
> F(A,p) accessed inside the proof assistant?
>

Since F(A,p) is the usual (inductive) data type, you can do everything you
can do with other data types. In particular, since it has only one
constructor with one parameter A, it is easy to proof that it is equivalent
to A.

-- 
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/CAA520ftYLYwiZs0B3fmuYb%3D%3D8mWiOpVD0yVbV8otfTEfgWV8UQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4775 bytes --]

  reply	other threads:[~2019-08-11 10:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06 22:16 Валерий Исаев
2019-08-07 15:01 ` Andrej Bauer
2019-08-07 22:13 ` Nicolai Kraus
2019-08-08  9:55   ` Valery Isaev
2019-08-10  9:47     ` Michael Shulman
2019-08-10 12:30       ` Valery Isaev
2019-08-10 12:37       ` Valery Isaev
2019-08-08 12:20 ` Jon Sterling
2019-08-08 12:29   ` Bas Spitters
2019-08-08 14:44     ` Valery Isaev
2019-08-08 15:11       ` Jon Sterling
2019-08-08 15:22         ` Valery Isaev
2019-08-10  9:42           ` Michael Shulman
2019-08-10 12:24             ` Valery Isaev
2019-08-10 23:37               ` Michael Shulman
2019-08-11 10:46                 ` Valery Isaev [this message]
2019-08-11 12:39                   ` Michael Shulman
2019-08-11 16:55                     ` Michael Shulman
2019-08-12 14:44                       ` Daniel R. Grayson
2019-08-12 17:32                         ` Michael Shulman

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA520ftYLYwiZs0B3fmuYb==8mWiOpVD0yVbV8otfTEfgWV8UQ@mail.gmail.com' \
    --to=valery.isaev@gmail.com \
    --cc=homotopytypetheory@googlegroups.com \
    --cc=jon@jonmsterling.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 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).