<?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"
	>
<channel>
	<title>Comments for Container Types</title>
	<atom:link href="http://sneezy.cs.nott.ac.uk/containers/blog/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://sneezy.cs.nott.ac.uk/containers/blog</link>
	<description>East Midlands Containers Ltd.</description>
	<pubDate>Tue, 21 May 2013 06:02:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Comment on The universal property of logarithms by Kenn</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=19#comment-9853</link>
		<dc:creator>Kenn</dc:creator>
		<pubDate>Mon, 21 Apr 2008 02:14:54 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=19#comment-9853</guid>
		<description>Should read "the former is non-Naperian"...</description>
		<content:encoded><![CDATA[<p>Should read &#8220;the former is non-Naperian&#8221;&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The universal property of logarithms by Kenn</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=19#comment-9852</link>
		<dc:creator>Kenn</dc:creator>
		<pubDate>Mon, 21 Apr 2008 02:14:03 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=19#comment-9852</guid>
		<description>Confusingly, this just showed up in my RSS feed today, but is dated three years ago.  Since the only mention I've seen of Naperian types is in a preprint by Gibbons, I suspect there is clock skew and this really is newish.  Hopefully someone gets pinged by my comment.

When I wrote a type as an exponential, a labmate in a different discipline immediately asked what a logarithm would be, so I have been thinking along these same lines recently, playing with the recursive equations for Stream, List, Nat, and whatnot.  Is this perhaps useful for flattening a type for parallel computation?  What about non-Naperian types that are related to Naperian types?  Take lists as finite prefixes of infinite streams; the "McBridean formula" gives the same result for both, even though the latter is non-Naperian.

I'm hoping that you do find something non-trivial, as I want to read about it from someone who knows what they are talking about :-)</description>
		<content:encoded><![CDATA[<p>Confusingly, this just showed up in my RSS feed today, but is dated three years ago.  Since the only mention I&#8217;ve seen of Naperian types is in a preprint by Gibbons, I suspect there is clock skew and this really is newish.  Hopefully someone gets pinged by my comment.</p>
<p>When I wrote a type as an exponential, a labmate in a different discipline immediately asked what a logarithm would be, so I have been thinking along these same lines recently, playing with the recursive equations for Stream, List, Nat, and whatnot.  Is this perhaps useful for flattening a type for parallel computation?  What about non-Naperian types that are related to Naperian types?  Take lists as finite prefixes of infinite streams; the &#8220;McBridean formula&#8221; gives the same result for both, even though the latter is non-Naperian.</p>
<p>I&#8217;m hoping that you do find something non-trivial, as I want to read about it from someone who knows what they are talking about <img src='http://sneezy.cs.nott.ac.uk/containers/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Dissection by sigfpe</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=33#comment-299</link>
		<dc:creator>sigfpe</dc:creator>
		<pubDate>Tue, 16 Jan 2007 18:08:24 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/blog/?p=33#comment-299</guid>
		<description>Write the dissection operator as \&#124;/.

Then the operator D defined by D F X = \&#124;/ F X 1 is &lt;a href="http://www.math.ucdavis.edu/~mikew/free_calc.pdf" rel="nofollow"&gt;Fox's free derivative&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>Write the dissection operator as \|/.</p>
<p>Then the operator D defined by D F X = \|/ F X 1 is <a href="http://www.math.ucdavis.edu/~mikew/free_calc.pdf" rel="nofollow">Fox&#8217;s free derivative</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Dissection by sigfpe</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=33#comment-120</link>
		<dc:creator>sigfpe</dc:creator>
		<pubDate>Tue, 14 Nov 2006 00:53:45 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/blog/?p=33#comment-120</guid>
		<description>Conor,

Just responding to your comment here: http://sigfpe.blogspot.com/2006/06/taylor-series-for-types.html I had actually already found and read this dissection document. Interesting. It's nice to see a rigorous derivation of something like a Taylor expansion for types.

If you don't mind recklessly throwing all caution to the wind here's another way to 'derive' the Taylor series, different to my previous 'derivation':

If F[X] is an F-container of X's
dF[X] is an F-container with a hole
d^2F[X} is an F-container with an ordered pair of holes
(1+d^2/2)F[X} is an F-container with no holes or an unordered pair of holes, etc.
G[d]F[X] is an F-container with a G-container of holes in it(!!)
A.dF[X] is an F-container with an A-labelled hole
G[A.d]F[X] is an F-container with a G-container of A-labelled holes in it
exp(A.d)F[X] is an F-container with a set of A-labelled holes in it
But that's just an F[X+A].
Expanding the left hand side gives the Taylor series.

But yes, I'm fully aware this is a long way from rigour. But it's fun to play with, and a container of holes sounds like a useful thing to me. I think it'd be nice to make it rigorous somehow.</description>
		<content:encoded><![CDATA[<p>Conor,</p>
<p>Just responding to your comment here: <a href="http://sigfpe.blogspot.com/2006/06/taylor-series-for-types.html" rel="nofollow">http://sigfpe.blogspot.com/2006/06/taylor-series-for-types.html</a> I had actually already found and read this dissection document. Interesting. It&#8217;s nice to see a rigorous derivation of something like a Taylor expansion for types.</p>
<p>If you don&#8217;t mind recklessly throwing all caution to the wind here&#8217;s another way to &#8216;derive&#8217; the Taylor series, different to my previous &#8216;derivation&#8217;:</p>
<p>If F[X] is an F-container of X&#8217;s<br />
dF[X] is an F-container with a hole<br />
d^2F[X} is an F-container with an ordered pair of holes<br />
(1+d^2/2)F[X} is an F-container with no holes or an unordered pair of holes, etc.<br />
G[d]F[X] is an F-container with a G-container of holes in it(!!)<br />
A.dF[X] is an F-container with an A-labelled hole<br />
G[A.d]F[X] is an F-container with a G-container of A-labelled holes in it<br />
exp(A.d)F[X] is an F-container with a set of A-labelled holes in it<br />
But that&#8217;s just an F[X+A].<br />
Expanding the left hand side gives the Taylor series.</p>
<p>But yes, I&#8217;m fully aware this is a long way from rigour. But it&#8217;s fun to play with, and a container of holes sounds like a useful thing to me. I think it&#8217;d be nice to make it rigorous somehow.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Skeletons by ldixon</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=31#comment-79</link>
		<dc:creator>ldixon</dc:creator>
		<pubDate>Wed, 23 Aug 2006 18:17:41 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/blog/?p=31#comment-79</guid>
		<description>I think there is a small error: at the moment it looks like the variable must occur down every branch of a skeleton. But it should be possible that some branches don't contain the variable.

The original motivation for this idea was that I wanted a way to incrementally instantiate without having to parse through the whole of the term. We thought that providing "signposts" in the term would allow avoiding large sections of the term in which the variable did not occur.

Anyway, for the binary tree case I think it should be ....

   Term V = μ T. V + 1 + T²

   Zipper V = [2×(Term V)]

   Skeleton V =
     μ S. Zipper ∅ ×
     (V + S × S + S × Term V + Term V × S × Term V x Term V)

or more briefly:

   Skeleton V = μ S. Zipper ∅ × (V + (S + Term V)² )

(by "(a + b)² = a² + 2ab + b²")</description>
		<content:encoded><![CDATA[<p>I think there is a small error: at the moment it looks like the variable must occur down every branch of a skeleton. But it should be possible that some branches don&#8217;t contain the variable.</p>
<p>The original motivation for this idea was that I wanted a way to incrementally instantiate without having to parse through the whole of the term. We thought that providing &#8220;signposts&#8221; in the term would allow avoiding large sections of the term in which the variable did not occur.</p>
<p>Anyway, for the binary tree case I think it should be &#8230;.</p>
<p>   Term V = μ T. V + 1 + T²</p>
<p>   Zipper V = [2×(Term V)]</p>
<p>   Skeleton V =<br />
     μ S. Zipper ∅ ×<br />
     (V + S × S + S × Term V + Term V × S × Term V x Term V)</p>
<p>or more briefly:</p>
<p>   Skeleton V = μ S. Zipper ∅ × (V + (S + Term V)² )</p>
<p>(by &#8220;(a + b)² = a² + 2ab + b²&#8221;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fixpoints of Indexed Containers by Conor</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=26#comment-26</link>
		<dc:creator>Conor</dc:creator>
		<pubDate>Mon, 23 Jan 2006 18:31:36 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=26#comment-26</guid>
		<description>Curious. I've just updated the pdf of the fixpoint stuff with something of the story which I hacked. Don't know if it makes sense.</description>
		<content:encoded><![CDATA[<p>Curious. I&#8217;ve just updated the pdf of the fixpoint stuff with something of the story which I hacked. Don&#8217;t know if it makes sense.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fixpoints of Indexed Containers by Hank</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=26#comment-25</link>
		<dc:creator>Hank</dc:creator>
		<pubDate>Mon, 23 Jan 2006 16:22:56 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=26#comment-25</guid>
		<description>I looked at the Petersson-Synek paper "A set constructor for inductive sets in Martin-Löf's type theory" (from 1989 which you can find on Kent's page).  I notice that in section 4 of that paper, it is mentioned that Dan actually proved that their `tree-set' principle can be reduced to W-types.  The reference given is to a Chalmers technical report that does not seem to be online.  

"Deriving rules for inductive sets in Martin-Löf's type theory" also from 1989. 

The approach (only sketched) is to pick out "good" trees in a W-type. Unfortunately it isn't possible to tell how this predicate is defined.  Conceivably though he used the method given above (but to me it seems more likely he used a `large elimination').  

In any case, the next time someone is in Chalmers, could they please ask for a copy of this report?  Or if they bump into Dan somewhere?</description>
		<content:encoded><![CDATA[<p>I looked at the Petersson-Synek paper &#8220;A set constructor for inductive sets in Martin-Löf&#8217;s type theory&#8221; (from 1989 which you can find on Kent&#8217;s page).  I notice that in section 4 of that paper, it is mentioned that Dan actually proved that their `tree-set&#8217; principle can be reduced to W-types.  The reference given is to a Chalmers technical report that does not seem to be online.  </p>
<p>&#8220;Deriving rules for inductive sets in Martin-Löf&#8217;s type theory&#8221; also from 1989. </p>
<p>The approach (only sketched) is to pick out &#8220;good&#8221; trees in a W-type. Unfortunately it isn&#8217;t possible to tell how this predicate is defined.  Conceivably though he used the method given above (but to me it seems more likely he used a `large elimination&#8217;).  </p>
<p>In any case, the next time someone is in Chalmers, could they please ask for a copy of this report?  Or if they bump into Dan somewhere?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fixpoints of Indexed Containers by Conor</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=26#comment-24</link>
		<dc:creator>Conor</dc:creator>
		<pubDate>Mon, 23 Jan 2006 14:15:41 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=26#comment-24</guid>
		<description>And, moreover, I've done the fixpoint construction in Epigram (with ext as an axiom). I've written both directions of the iso, but not the proof that it is an iso. The code is &lt;a href="http://www.e-pig.org/durham/examples/ctm/IxCon.epi" rel="nofollow"&gt;here&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>And, moreover, I&#8217;ve done the fixpoint construction in Epigram (with ext as an axiom). I&#8217;ve written both directions of the iso, but not the proof that it is an iso. The code is <a href="http://www.e-pig.org/durham/examples/ctm/IxCon.epi" rel="nofollow">here</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fixpoints of Indexed Containers by Conor</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=26#comment-23</link>
		<dc:creator>Conor</dc:creator>
		<pubDate>Sun, 22 Jan 2006 19:27:51 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=26#comment-23</guid>
		<description>OK folks, how about &lt;a href="http://www.cs.nott.ac.uk/~ctm/fixpoint.pdf" rel="nofollow"&gt;this&lt;/a&gt;?</description>
		<content:encoded><![CDATA[<p>OK folks, how about <a href="http://www.cs.nott.ac.uk/~ctm/fixpoint.pdf" rel="nofollow">this</a>?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fixpoints of Indexed Containers by Conor</title>
		<link>http://sneezy.cs.nott.ac.uk/containers/blog/?p=26#comment-22</link>
		<dc:creator>Conor</dc:creator>
		<pubDate>Sun, 22 Jan 2006 15:35:55 +0000</pubDate>
		<guid isPermaLink="false">http://sneezy.cs.nott.ac.uk/containers/?p=26#comment-22</guid>
		<description>Dr Hancock happened to be passing, whereupon he reminded me that large eliminations are locally considered to be cheating. He further reminded me that someone had written a lump of Epigram which did it without large eliminations. I shall fix this presently.</description>
		<content:encoded><![CDATA[<p>Dr Hancock happened to be passing, whereupon he reminded me that large eliminations are locally considered to be cheating. He further reminded me that someone had written a lump of Epigram which did it without large eliminations. I shall fix this presently.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
