coq-club AT inria.fr
Subject: The Coq mailing list
List archive
- From: Jason Gross <jasongross9 AT gmail.com>
- To: coq-club AT inria.fr
- Subject: Re: [Coq-Club] help with automating derived UIP_refl proofs
- Date: Thu, 01 Sep 2016 06:07:28 +0000
- Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=jasongross9 AT gmail.com; spf=Pass smtp.mailfrom=jasongross9 AT gmail.com; spf=None smtp.helo=postmaster AT mail-qk0-f170.google.com
- Ironport-phdr: 9a23:rJanih0Bukbi/JyUsmDT+DRfVm0co7zxezQtwd8ZsesRKPad9pjvdHbS+e9qxAeQG96KsrQZ06GP6/6oGTRZp83e4DZaKN0EfiRGoPtVtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBke3blItdaymUrLV2s+wzqW5/4DZSwROnju0J71ofzusqgCElMANho0qBbw20QCB9nlBYONQynlvPknCtxn578a0upVk9nID6Loa68dcXPCiLOwDRrtCAWF+Pg==
In UIP_iso_pointed you should be able to do [apply (f_equal BtoA) in H], and then prove that if you nest two [f_equal], you could have a single one that is on a function composition, and then prove that if you do [f_equal] with a function that is equal to the identity on the end-points of your path, you could just as well not have had the [f_equal] at all.
On Wed, Aug 31, 2016, 9:08 PM Jonathan Leivent <jonikelee AT gmail.com> wrote:
On 08/31/2016 11:41 PM, Jonathan Leivent wrote:
>
> On 08/31/2016 11:18 PM, Jason Gross wrote:
>> Actually, I think it's possible to do better; you should only need
>> AtoB_BtoA specialized to the point you care about. This should be a
>> relatively simple transformation to make, and, I think, should be
>> powerful
>> enough to let you handle recursive types
>
> I think you are right that AtoB_BtoA only needs to be at a point. But,
> if AtoB is always a ctor and BtoA is always a proj, then I'm not sure
> that this specialization helps much, if at all.
>
> -- Jonathan
>
Oops - it is needed. I just tried using UIP_iso_pointed to prove UIP on
nat, and got:
|- forall b : nat, S (pred b) = b
which is obviously not true at b=0. OK - how to make it only need
AtoB_BtoA at a point? Obviously, f_equal_cancel needs to be reworked,
but the obvious way "(e : x=x)" doesn't work. It always seems peculiar
to me that in some circumstances in Coq, one can do more to x=y than to
x=x - as in this case.
-- Jonathan
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Dominique Larchey-Wendling, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Message not available
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/02/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Dominique Larchey-Wendling, 09/08/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jason Gross, 09/01/2016
- Message not available
- Re: [Coq-Club] help with automating derived UIP_refl proofs, Jonathan Leivent, 09/01/2016
Archive powered by MHonArc 2.6.18.