<?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/"
	
	>
<channel>
	<title>Comments on: Why program with continuous time?</title>
	<atom:link href="http://conal.net/blog/posts/why-program-with-continuous-time/feed" rel="self" type="application/rss+xml" />
	<link>http://conal.net/blog/posts/why-program-with-continuous-time</link>
	<description>Inspirations &#38; experiments, mainly about denotative/functional programming in Haskell</description>
	<lastBuildDate>Sat, 26 Sep 2020 21:06:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.1.17</generator>
	<item>
		<title>By: Conal</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-72614</link>
		<dc:creator><![CDATA[Conal]]></dc:creator>
		<pubDate>Mon, 17 Dec 2018 03:07:50 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-72614</guid>
		<description><![CDATA[&lt;p&gt;Peter T.: Yes. Why &quot;But&quot;?&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Peter T.: Yes. Why &#8220;But&#8221;?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter T.</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-72605</link>
		<dc:creator><![CDATA[Peter T.]]></dc:creator>
		<pubDate>Sun, 16 Dec 2018 23:55:04 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-72605</guid>
		<description><![CDATA[&lt;p&gt;&quot;For that reason, we don’t generally use strings in place of numbers. If we did, composition operations (arithmetic) would be very awkward.&quot;&lt;/p&gt;

&lt;p&gt;As someone who has plumbed the depths of bigint optimization across multiple ISAs for elliptic curve cryptography, yes, it is indeed very awkward. :)&lt;/p&gt;

&lt;p&gt;But in the context of your analysis, wouldn&#039;t decoupling arithmetic from machine word size--entirely--be the purest ADT?&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>&#8220;For that reason, we don’t generally use strings in place of numbers. If we did, composition operations (arithmetic) would be very awkward.&#8221;</p>

<p>As someone who has plumbed the depths of bigint optimization across multiple ISAs for elliptic curve cryptography, yes, it is indeed very awkward. <img src="http://conal.net/blog/wp-includes/images/smilies/icon_smile.gif" alt=":)" class="wp-smiley" /></p>

<p>But in the context of your analysis, wouldn&#8217;t decoupling arithmetic from machine word size&#8211;entirely&#8211;be the purest ADT?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Hancock</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-530</link>
		<dc:creator><![CDATA[Peter Hancock]]></dc:creator>
		<pubDate>Wed, 07 Apr 2010 16:56:36 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-530</guid>
		<description><![CDATA[&lt;p&gt;I&#039;m inclined to agree with Conal that continuous time may not be, of itself, a problem.   What strikes me as intensely problematic are non-continuous &lt;em&gt;functions&lt;/em&gt; of time - such as step-functions  f(t) = if t &lt; 0 then 0 else 1, &quot;delta&quot; functions and so on.  There are good reasons to think that no
such function can be defined in a computable (ie. constructive) way.&lt;/p&gt;

&lt;p&gt;Actually &quot;continuous time&quot; seems like unfortunate language.  That issue is whether time is the &lt;em&gt;continuum&lt;/em&gt;, ie. the real line.  &quot;Continuous&quot; should be kept for functions between topological spaces.  I could be talking out of the wrong orifice, but it seems to me that the only functions from the reals
to a discrete space like {0,1} that can be defined constructively, are precisely the constant functions. (But if we took time to be Baire-space, which
is homeomorphic to the irrationals, there are lots of non-constant continuous functions that can be defined constructively.)&lt;/p&gt;

&lt;p&gt;Oh, on the topic of grep, I think in one respect it is &lt;em&gt;not&lt;/em&gt; a (total) function on infinite streams.
After all &quot;grep a input&quot; does not have such a value when the
argument does not contain infinitely many &#039;a&#039;s.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m inclined to agree with Conal that continuous time may not be, of itself, a problem.   What strikes me as intensely problematic are non-continuous <em>functions</em> of time &#8211; such as step-functions  f(t) = if t &lt; 0 then 0 else 1, &#8220;delta&#8221; functions and so on.  There are good reasons to think that no
such function can be defined in a computable (ie. constructive) way.</p>

<p>Actually &#8220;continuous time&#8221; seems like unfortunate language.  That issue is whether time is the <em>continuum</em>, ie. the real line.  &#8220;Continuous&#8221; should be kept for functions between topological spaces.  I could be talking out of the wrong orifice, but it seems to me that the only functions from the reals
to a discrete space like {0,1} that can be defined constructively, are precisely the constant functions. (But if we took time to be Baire-space, which
is homeomorphic to the irrationals, there are lots of non-constant continuous functions that can be defined constructively.)</p>

<p>Oh, on the topic of grep, I think in one respect it is <em>not</em> a (total) function on infinite streams.
After all &#8220;grep a input&#8221; does not have such a value when the
argument does not contain infinitely many &#8216;a&#8217;s.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-529</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Mon, 29 Mar 2010 02:24:27 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-529</guid>
		<description><![CDATA[&lt;p&gt;Hi James,&lt;/p&gt;

&lt;p&gt;Thanks for raising this issue about sinc.  Perhaps the infinite extent is not necessarily a problem.  Suppose we want to extract only finite information/precision &lt;em&gt;in the end&lt;/em&gt; (e.g., 44K samples per second and 32 bits per channel per sample), while (in theory) computing the exactly correct signal in the middle (during composition).  What I really mean is that the extracted approximation must agree with the exact value to the precision of the approximation.  Now the trick is to implement the composition steps finitely (and better yet, efficiently) &lt;em&gt;and&lt;/em&gt; correctly.&lt;/p&gt;

&lt;p&gt;Although sinc has infinite extent, I&#039;d guess that its influence on the finite information eventually extracted is (provably) finite.  So, with some cleverness, an implementation could probably get away with carrying forward only finite information.&lt;/p&gt;

&lt;p&gt;What do you think?&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hi James,</p>

<p>Thanks for raising this issue about sinc.  Perhaps the infinite extent is not necessarily a problem.  Suppose we want to extract only finite information/precision <em>in the end</em> (e.g., 44K samples per second and 32 bits per channel per sample), while (in theory) computing the exactly correct signal in the middle (during composition).  What I really mean is that the extracted approximation must agree with the exact value to the precision of the approximation.  Now the trick is to implement the composition steps finitely (and better yet, efficiently) <em>and</em> correctly.</p>

<p>Although sinc has infinite extent, I&#8217;d guess that its influence on the finite information eventually extracted is (provably) finite.  So, with some cleverness, an implementation could probably get away with carrying forward only finite information.</p>

<p>What do you think?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James McCartney</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-528</link>
		<dc:creator><![CDATA[James McCartney]]></dc:creator>
		<pubDate>Sun, 28 Mar 2010 18:25:56 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-528</guid>
		<description><![CDATA[&lt;p&gt;The biggest problem in my mind with continuous time is that the conversion of a signal from continuous time to discrete time is non-local. The sinc function has infinite extent. Simply sampling a non-bandlimited continuous time signal will cause aliasing frequencies.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>The biggest problem in my mind with continuous time is that the conversion of a signal from continuous time to discrete time is non-local. The sinc function has infinite extent. Simply sampling a non-bandlimited continuous time signal will cause aliasing frequencies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-527</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Thu, 07 Jan 2010 18:15:26 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-527</guid>
		<description><![CDATA[&lt;p&gt;Hi Josef,&lt;/p&gt;

&lt;p&gt;I&#039;ve been thinking about approximation and denotational design a fair bit lately, exploring two different paths.  One is to work with &lt;em&gt;exact&lt;/em&gt; values, and then allow extraction of any finite amount information to be extracted.  We play this game as a matter of course in lazy functional programming, e.g., with infinite lists &amp; trees.  Additional examples are &lt;em&gt;images&lt;/em&gt; and &lt;em&gt;surfaces&lt;/em&gt;, defined over infinite &amp; continuous space, and &lt;em&gt;behaviors&lt;/em&gt;, defined over infinite &amp; continuous time.  Similarly, I recently realized a simple way to perform &lt;a href=&quot;http://conal.net/blog/posts/exact-numeric-integration/&quot; rel=&quot;nofollow&quot;&gt;exact numeric integration&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Another path is to compute only &lt;em&gt;inexactly&lt;/em&gt; and use the ideal denotational semantics in order to quantify precisely the distance between ideal and implementation.  With this path, we can still speak precisely about the &lt;em&gt;accuracy&lt;/em&gt; of our implementations, and about choices that improve or degrade accuracy (no hand-waving needed).&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hi Josef,</p>

<p>I&#8217;ve been thinking about approximation and denotational design a fair bit lately, exploring two different paths.  One is to work with <em>exact</em> values, and then allow extraction of any finite amount information to be extracted.  We play this game as a matter of course in lazy functional programming, e.g., with infinite lists &amp; trees.  Additional examples are <em>images</em> and <em>surfaces</em>, defined over infinite &amp; continuous space, and <em>behaviors</em>, defined over infinite &amp; continuous time.  Similarly, I recently realized a simple way to perform <a href="http://conal.net/blog/posts/exact-numeric-integration/" rel="nofollow">exact numeric integration</a>.</p>

<p>Another path is to compute only <em>inexactly</em> and use the ideal denotational semantics in order to quantify precisely the distance between ideal and implementation.  With this path, we can still speak precisely about the <em>accuracy</em> of our implementations, and about choices that improve or degrade accuracy (no hand-waving needed).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josef Svenningsson</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-526</link>
		<dc:creator><![CDATA[Josef Svenningsson]]></dc:creator>
		<pubDate>Thu, 07 Jan 2010 17:48:50 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-526</guid>
		<description><![CDATA[&lt;p&gt;On second thought I want to revise some of the things I said above.&lt;/p&gt;

&lt;p&gt;You do indeed deal with approximations in some of your semantic designs. For instance sampling continuous time to make it discreet. I suppose that is one example of what I was looking for.&lt;/p&gt;

&lt;p&gt;Still, given a denotational semantics, it might not be obvious how and where to introduce the required approximations to derive an effectively computable implementation.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>On second thought I want to revise some of the things I said above.</p>

<p>You do indeed deal with approximations in some of your semantic designs. For instance sampling continuous time to make it discreet. I suppose that is one example of what I was looking for.</p>

<p>Still, given a denotational semantics, it might not be obvious how and where to introduce the required approximations to derive an effectively computable implementation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josef Svenningsson</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-525</link>
		<dc:creator><![CDATA[Josef Svenningsson]]></dc:creator>
		<pubDate>Thu, 07 Jan 2010 14:24:09 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-525</guid>
		<description><![CDATA[&lt;p&gt;Conal. I&#039;ve been meaning to ask you this question for some time.&lt;/p&gt;

&lt;p&gt;You advocate a &quot;semantic&quot; or &quot;denotational&quot; way of designing things which establishes the nature of the problem we are trying to solve. One can also say that it acts as a specification for the problem. But you go further than using the semantics as a specification, you have demonstrated several times how to derive an actual computable implementation from the semantics.&lt;/p&gt;

&lt;p&gt;I wonder if you could elaborate on the case when deriving an implementation from the semantics inherently requires some form of approximation. It seems that in all your examples you haven&#039;t had to deal with that question. But I have a background in program analysis. In that field it is also a good idea to establish the underlying semantic property one wishes to establish about programs before embarking on designing the actual program analysis. But one can never hope to derive a computable analysis from the semantic property. There is an inherent need for introducing some form of approximation in order to achieve that.&lt;/p&gt;

&lt;p&gt;One answer could be Abstract Interpretation. But it doesn&#039;t give us a particular approximation, it only tells us what an approximation should/could look like.&lt;/p&gt;

&lt;p&gt;Anyway, I&#039;d like to hear your thoughts on the matter.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Conal. I&#8217;ve been meaning to ask you this question for some time.</p>

<p>You advocate a &#8220;semantic&#8221; or &#8220;denotational&#8221; way of designing things which establishes the nature of the problem we are trying to solve. One can also say that it acts as a specification for the problem. But you go further than using the semantics as a specification, you have demonstrated several times how to derive an actual computable implementation from the semantics.</p>

<p>I wonder if you could elaborate on the case when deriving an implementation from the semantics inherently requires some form of approximation. It seems that in all your examples you haven&#8217;t had to deal with that question. But I have a background in program analysis. In that field it is also a good idea to establish the underlying semantic property one wishes to establish about programs before embarking on designing the actual program analysis. But one can never hope to derive a computable analysis from the semantic property. There is an inherent need for introducing some form of approximation in order to achieve that.</p>

<p>One answer could be Abstract Interpretation. But it doesn&#8217;t give us a particular approximation, it only tells us what an approximation should/could look like.</p>

<p>Anyway, I&#8217;d like to hear your thoughts on the matter.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Conal Elliott &#187; Blog Archive &#187; Can functional programming be liberated from the von Neumann paradigm?</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-524</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Can functional programming be liberated from the von Neumann paradigm?]]></dc:creator>
		<pubDate>Tue, 05 Jan 2010 18:33:04 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-524</guid>
		<description><![CDATA[&lt;p&gt;[...] my recent post, Why program with continuous time?, I had suggested that the abstraction of continuous time is useful even if &#8220;in the end all [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] my recent post, Why program with continuous time?, I had suggested that the abstraction of continuous time is useful even if &#8220;in the end all [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/why-program-with-continuous-time#comment-523</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Mon, 04 Jan 2010 07:15:54 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=93#comment-523</guid>
		<description><![CDATA[&lt;p&gt;Update: I trimmed &amp; tweaked the unsolicited advice near the end of the post.  Hopefully less peevish/patronizing now.  My thanks for the feedback on the &lt;a href=&quot;http://www.reddit.com/r/programming/comments/al2gf/why_program_with_continuous_time/&quot; rel=&quot;nofollow&quot;&gt;reddit thread&lt;/a&gt; for this post.
I was reacting out of a particular sensitivity (and matching personal value) of mine.
See &lt;em&gt;&lt;a href=&quot;http://conal.net/blog/posts/communication-curiosity-and-personal-style/&quot; rel=&quot;nofollow&quot;&gt;Communication, curiosity, and personal style&lt;/a&gt;&lt;/em&gt;.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Update: I trimmed &amp; tweaked the unsolicited advice near the end of the post.  Hopefully less peevish/patronizing now.  My thanks for the feedback on the <a href="http://www.reddit.com/r/programming/comments/al2gf/why_program_with_continuous_time/" rel="nofollow">reddit thread</a> for this post.
I was reacting out of a particular sensitivity (and matching personal value) of mine.
See <em><a href="http://conal.net/blog/posts/communication-curiosity-and-personal-style/" rel="nofollow">Communication, curiosity, and personal style</a></em>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
