<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Homotopy Type Theory</title>
	<atom:link href="http://homotopytypetheory.org/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://homotopytypetheory.org</link>
	<description></description>
	<lastBuildDate>Mon, 17 Jun 2013 17:03:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on Homotopy Theory in Type Theory: Progress Report by Nicolai Kraus</title>
		<link>http://homotopytypetheory.org/2013/05/20/homotopy-theory-in-type-theory-progress-report/#comment-4099</link>
		<dc:creator><![CDATA[Nicolai Kraus]]></dc:creator>
		<pubDate>Mon, 17 Jun 2013 17:03:15 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1736#comment-4099</guid>
		<description><![CDATA[Yes, the fact that one needs functoriality only for an actually *constructed* Delta set is what also gives me some hope here. It will certainly not be easy though: for example, your &quot;Axiom listsubsetsubseteq&quot; will probably cause problems as it postulates an inhabitant of a type that is in general not propositional. I would be very surprised if it was enough to ensure that there is this categorical structure; what we probably need is an omega-categorical structure. That&#039;s what I meant by &quot;horror with coherences&quot;. My hope would be that we can get these coherences automatically, if we prove &quot;listsubsetsubseteq&quot; in a &quot;good&quot; way - but I don&#039;t know. Reading what you described in the end, I guess you also have something like this in mind.
About the other thing, I think it is possible to use functions between finite sets and assume functional extensionality for those. If everything works in the end, one can encode these functions such that no assumption is needed anymore. Fair enough, one can also use such an encoding right from the beginning. I just wanted to do it first in a setting  with less obfuscation. &quot;Complexity&quot; is a meta-theoretic concept, we can&#039;t talk about that internally.]]></description>
		<content:encoded><![CDATA[<p>Yes, the fact that one needs functoriality only for an actually *constructed* Delta set is what also gives me some hope here. It will certainly not be easy though: for example, your &#8220;Axiom listsubsetsubseteq&#8221; will probably cause problems as it postulates an inhabitant of a type that is in general not propositional. I would be very surprised if it was enough to ensure that there is this categorical structure; what we probably need is an omega-categorical structure. That&#8217;s what I meant by &#8220;horror with coherences&#8221;. My hope would be that we can get these coherences automatically, if we prove &#8220;listsubsetsubseteq&#8221; in a &#8220;good&#8221; way &#8211; but I don&#8217;t know. Reading what you described in the end, I guess you also have something like this in mind.<br />
About the other thing, I think it is possible to use functions between finite sets and assume functional extensionality for those. If everything works in the end, one can encode these functions such that no assumption is needed anymore. Fair enough, one can also use such an encoding right from the beginning. I just wanted to do it first in a setting  with less obfuscation. &#8220;Complexity&#8221; is a meta-theoretic concept, we can&#8217;t talk about that internally.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Homotopy Theory in Type Theory: Progress Report by jessemckeown</title>
		<link>http://homotopytypetheory.org/2013/05/20/homotopy-theory-in-type-theory-progress-report/#comment-4090</link>
		<dc:creator><![CDATA[jessemckeown]]></dc:creator>
		<pubDate>Sun, 16 Jun 2013 13:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1736#comment-4090</guid>
		<description><![CDATA[I was avoiding function types because, even for functions between finite decidable-equality sets, deriving anything like decidable equality of functions is difficult — I suppose this means coq could be told to agree two implementations of a function were different if they had provably-different complexity... and in the end I had to toss in decidable equality as an axiom anyways!

I think I just want to emphasize that the things supposed equal in the last recursion --- the thing that looks like functoriality where I give up and throw in &quot;admit&quot; --- isn&#039;t functoriality for an &lt;i&gt;assumed&lt;/i&gt; Delta set, but for the &lt;i&gt;derived&lt;/i&gt; delta-set of n-filled l-simplices, which is why I have some hope that it could actually be finished, if one could replace the &quot;assert&quot; interaction with an explicit term...

In the process I&#039;ve come to a better appreciation of the dependences actually involved, which suggests that the notion itself is of limited computational use: in a general delta set, an explicit term for an n-cell will involve $latex 2^n \pm \varepsilon$ explicit terms for k-cells in lower degree before you can even name the type of the last filling, and each of those (n C k) k-cells needs $latex 2^k \pm \varepsilon$ to describe its type, each of which ...  maybe we are saved by not needing quite all that dependency in practical cases.  On the other hand, Delta Sets are built on hyper-cubic diagrams, which have permutahedra describing all the equalities involved; but for surprisingly many things, associahedra can do instead of permutahedra, while having rather fewer vertices --- I can&#039;t be sure of the cells altogether yet --- and so one should look for the diagrams that are to associahedra as cubes are to permutahedra, and then we&#039;ll really be getting somewhere.]]></description>
		<content:encoded><![CDATA[<p>I was avoiding function types because, even for functions between finite decidable-equality sets, deriving anything like decidable equality of functions is difficult — I suppose this means coq could be told to agree two implementations of a function were different if they had provably-different complexity&#8230; and in the end I had to toss in decidable equality as an axiom anyways!</p>
<p>I think I just want to emphasize that the things supposed equal in the last recursion &#8212; the thing that looks like functoriality where I give up and throw in &#8220;admit&#8221; &#8212; isn&#8217;t functoriality for an <i>assumed</i> Delta set, but for the <i>derived</i> delta-set of n-filled l-simplices, which is why I have some hope that it could actually be finished, if one could replace the &#8220;assert&#8221; interaction with an explicit term&#8230;</p>
<p>In the process I&#8217;ve come to a better appreciation of the dependences actually involved, which suggests that the notion itself is of limited computational use: in a general delta set, an explicit term for an n-cell will involve <img src='http://s0.wp.com/latex.php?latex=2%5En+%5Cpm+%5Cvarepsilon&amp;bg=ffffff&amp;fg=333333&amp;s=0' alt='2^n &#92;pm &#92;varepsilon' title='2^n &#92;pm &#92;varepsilon' class='latex' /> explicit terms for k-cells in lower degree before you can even name the type of the last filling, and each of those (n C k) k-cells needs <img src='http://s0.wp.com/latex.php?latex=2%5Ek+%5Cpm+%5Cvarepsilon&amp;bg=ffffff&amp;fg=333333&amp;s=0' alt='2^k &#92;pm &#92;varepsilon' title='2^k &#92;pm &#92;varepsilon' class='latex' /> to describe its type, each of which &#8230;  maybe we are saved by not needing quite all that dependency in practical cases.  On the other hand, Delta Sets are built on hyper-cubic diagrams, which have permutahedra describing all the equalities involved; but for surprisingly many things, associahedra can do instead of permutahedra, while having rather fewer vertices &#8212; I can&#8217;t be sure of the cells altogether yet &#8212; and so one should look for the diagrams that are to associahedra as cubes are to permutahedra, and then we&#8217;ll really be getting somewhere.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Homotopy Theory in Type Theory: Progress Report by Nicolai Kraus</title>
		<link>http://homotopytypetheory.org/2013/05/20/homotopy-theory-in-type-theory-progress-report/#comment-4083</link>
		<dc:creator><![CDATA[Nicolai Kraus]]></dc:creator>
		<pubDate>Sat, 15 Jun 2013 16:53:10 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1736#comment-4083</guid>
		<description><![CDATA[Hi! I had a very brief look at your code. What you are doing seems to be (at least) very similar to an approach that a couple of people try, or have tried. It is normal to think that this should definitely work and it&#039;s just a matter of actually doing it, but I am not sure about that anymore. It is very hard to describe what goes wrong and/or I do not understand the problem. It seems that, in order to define certain functions, one already needs to know that these (or other) functions behave &quot;functorially&quot; on lower levels. That is something one can show easily, but by doing so, one introduces nontrivial paths and the horror with coherences begins - even if everything is &quot;obviously well-founded&quot; (recall that the whole idea here is to use the directedness of the Delta_i category for avoiding coherence problems!).
I am not convinced that this approach cannot be completed, but neither am I convinced that it can. If it does not work, it would be really valuable to understand what the underlying reason is. Together with Nuo Li and Paolo Capriotti, I also have a git repository about this stuff (we use Agda), but it&#039;s a total mess (I&#039;ll post a link if we ever make progress and clean it up).
Here is maybe one positive thing I can say: Instead of your type chooseType for (n C k), try using strictly monotonous functions between finite ordered sets. Your composition of binominal coefficients then becomes literal composition of functions. E.g. to get a sub-skeleton, you just need to compose with the function that tells you which k of the skeleton&#039;s n points/vertices you want to keep. At least, this works quite neatly for us.]]></description>
		<content:encoded><![CDATA[<p>Hi! I had a very brief look at your code. What you are doing seems to be (at least) very similar to an approach that a couple of people try, or have tried. It is normal to think that this should definitely work and it&#8217;s just a matter of actually doing it, but I am not sure about that anymore. It is very hard to describe what goes wrong and/or I do not understand the problem. It seems that, in order to define certain functions, one already needs to know that these (or other) functions behave &#8220;functorially&#8221; on lower levels. That is something one can show easily, but by doing so, one introduces nontrivial paths and the horror with coherences begins &#8211; even if everything is &#8220;obviously well-founded&#8221; (recall that the whole idea here is to use the directedness of the Delta_i category for avoiding coherence problems!).<br />
I am not convinced that this approach cannot be completed, but neither am I convinced that it can. If it does not work, it would be really valuable to understand what the underlying reason is. Together with Nuo Li and Paolo Capriotti, I also have a git repository about this stuff (we use Agda), but it&#8217;s a total mess (I&#8217;ll post a link if we ever make progress and clean it up).<br />
Here is maybe one positive thing I can say: Instead of your type chooseType for (n C k), try using strictly monotonous functions between finite ordered sets. Your composition of binominal coefficients then becomes literal composition of functions. E.g. to get a sub-skeleton, you just need to compose with the function that tells you which k of the skeleton&#8217;s n points/vertices you want to keep. At least, this works quite neatly for us.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Homotopy Theory in Type Theory: Progress Report by jessemckeown</title>
		<link>http://homotopytypetheory.org/2013/05/20/homotopy-theory-in-type-theory-progress-report/#comment-4078</link>
		<dc:creator><![CDATA[jessemckeown]]></dc:creator>
		<pubDate>Sat, 15 Jun 2013 00:43:23 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1736#comment-4078</guid>
		<description><![CDATA[oh, on the plus side, it&#039;s clear that the first part of a DeltaSkeleton (S k) is its underlying (DeltaSkeleton k); so, not a total loss.]]></description>
		<content:encoded><![CDATA[<p>oh, on the plus side, it&#8217;s clear that the first part of a DeltaSkeleton (S k) is its underlying (DeltaSkeleton k); so, not a total loss.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Homotopy Theory in Type Theory: Progress Report by jessemckeown</title>
		<link>http://homotopytypetheory.org/2013/05/20/homotopy-theory-in-type-theory-progress-report/#comment-4077</link>
		<dc:creator><![CDATA[jessemckeown]]></dc:creator>
		<pubDate>Sat, 15 Jun 2013 00:38:27 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1736#comment-4077</guid>
		<description><![CDATA[In case of coqiphiles, I&#039;d heard there was a difficulty about saying &quot;Delta Set&quot; in coq... I haven&#039;t resolved that particular question as such, but maybe reduced some of the opacity, in the sense that coq can produce some Type, dependent on a natural number k,  that obviously ought to be the k-skeleton of a Delta set; on the other hand, discerning *what* that thing actually asks for is, to say the least, daunting, but not quite totally incomprehensible.
&lt;a href=&quot;https://gist.github.com/jcmckeown/5786253&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt; is the gist of it.  Enjoy!]]></description>
		<content:encoded><![CDATA[<p>In case of coqiphiles, I&#8217;d heard there was a difficulty about saying &#8220;Delta Set&#8221; in coq&#8230; I haven&#8217;t resolved that particular question as such, but maybe reduced some of the opacity, in the sense that coq can produce some Type, dependent on a natural number k,  that obviously ought to be the k-skeleton of a Delta set; on the other hand, discerning *what* that thing actually asks for is, to say the least, daunting, but not quite totally incomprehensible.<br />
<a href="https://gist.github.com/jcmckeown/5786253" rel="nofollow">here</a> is the gist of it.  Enjoy!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Homotopy Theory in Type Theory: Progress Report by Jason Gross</title>
		<link>http://homotopytypetheory.org/2013/05/20/homotopy-theory-in-type-theory-progress-report/#comment-3846</link>
		<dc:creator><![CDATA[Jason Gross]]></dc:creator>
		<pubDate>Tue, 21 May 2013 04:39:03 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1736#comment-3846</guid>
		<description><![CDATA[Great work!  I&#039;m interested in getting involved.  Is there a list of low-hanging fruit somewhere?]]></description>
		<content:encoded><![CDATA[<p>Great work!  I&#8217;m interested in getting involved.  Is there a list of low-hanging fruit somewhere?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Covering Spaces by Guillaume Brunerie</title>
		<link>http://homotopytypetheory.org/2013/04/27/covering-spaces/#comment-3653</link>
		<dc:creator><![CDATA[Guillaume Brunerie]]></dc:creator>
		<pubDate>Fri, 03 May 2013 03:11:05 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1571#comment-3653</guid>
		<description><![CDATA[I know added a third proof (closer to Mike’s original proof) which is ~105 lines long (same link).]]></description>
		<content:encoded><![CDATA[<p>I know added a third proof (closer to Mike’s original proof) which is ~105 lines long (same link).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Covering Spaces by Guillaume Brunerie</title>
		<link>http://homotopytypetheory.org/2013/04/27/covering-spaces/#comment-3651</link>
		<dc:creator><![CDATA[Guillaume Brunerie]]></dc:creator>
		<pubDate>Thu, 02 May 2013 20:29:26 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1571#comment-3651</guid>
		<description><![CDATA[In the upcoming new Agda library, I already have two proofs of $latex\pi_1(S^1)=\mathbb{Z}$ (encode-decode and flattening lemma) and they are both under 100 lines of code (excluding library code). The flattening lemma proof is a bit shorter, but uses much more library code. See https://github.com/HoTT/HoTT-Agda/blob/2.0/homotopy/LoopSpaceCircle.agda]]></description>
		<content:encoded><![CDATA[<p>In the upcoming new Agda library, I already have two proofs of $latex\pi_1(S^1)=\mathbb{Z}$ (encode-decode and flattening lemma) and they are both under 100 lines of code (excluding library code). The flattening lemma proof is a bit shorter, but uses much more library code. See <a href="https://github.com/HoTT/HoTT-Agda/blob/2.0/homotopy/LoopSpaceCircle.agda" rel="nofollow">https://github.com/HoTT/HoTT-Agda/blob/2.0/homotopy/LoopSpaceCircle.agda</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Covering Spaces by Bas Spitters</title>
		<link>http://homotopytypetheory.org/2013/04/27/covering-spaces/#comment-3647</link>
		<dc:creator><![CDATA[Bas Spitters]]></dc:creator>
		<pubDate>Thu, 02 May 2013 08:38:50 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1571#comment-3647</guid>
		<description><![CDATA[We have something close to Moore-Postnikov
[http://uf-ias-2012.wikispaces.com/file/view/images.pdf/401765624/images.pdf](here)

I will think about the precise formulation.]]></description>
		<content:encoded><![CDATA[<p>We have something close to Moore-Postnikov<br />
[http://uf-ias-2012.wikispaces.com/file/view/images.pdf/401765624/images.pdf](here)</p>
<p>I will think about the precise formulation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Covering Spaces by favonia</title>
		<link>http://homotopytypetheory.org/2013/04/27/covering-spaces/#comment-3635</link>
		<dc:creator><![CDATA[favonia]]></dc:creator>
		<pubDate>Tue, 30 Apr 2013 19:32:42 +0000</pubDate>
		<guid isPermaLink="false">http://homotopytypetheory.org/?p=1571#comment-3635</guid>
		<description><![CDATA[Hi!  Sorry that I&#039;m still learning the terminology in homotopy theory, but I&#039;ll take a look at the Postnikov tower and others.  I can answer (3) right now:  No, the calculation is not difficult; we already have 3~4 calculations of $latex \pi_1(S_1)$ in different styles, and some of them are under 150 lines of code.  It&#039;s just a little bit disappointing (to me) that the library cannot further simply calculation of $latex \pi_1(S_1)$ to, say, 100 or fewer lines.  I had some higher expectation.  :-)]]></description>
		<content:encoded><![CDATA[<p>Hi!  Sorry that I&#8217;m still learning the terminology in homotopy theory, but I&#8217;ll take a look at the Postnikov tower and others.  I can answer (3) right now:  No, the calculation is not difficult; we already have 3~4 calculations of <img src='http://s0.wp.com/latex.php?latex=%5Cpi_1%28S_1%29&amp;bg=ffffff&amp;fg=333333&amp;s=0' alt='&#92;pi_1(S_1)' title='&#92;pi_1(S_1)' class='latex' /> in different styles, and some of them are under 150 lines of code.  It&#8217;s just a little bit disappointing (to me) that the library cannot further simply calculation of <img src='http://s0.wp.com/latex.php?latex=%5Cpi_1%28S_1%29&amp;bg=ffffff&amp;fg=333333&amp;s=0' alt='&#92;pi_1(S_1)' title='&#92;pi_1(S_1)' class='latex' /> to, say, 100 or fewer lines.  I had some higher expectation.  <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>