<?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: Eureka!</title>
	<atom:link href="http://www.mailund.dk/index.php/2009/01/30/eureka/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mailund.dk/index.php/2009/01/30/eureka/</link>
	<description>Computer science, bioinformatics, genetics, and everything in between</description>
	<lastBuildDate>Fri, 19 Aug 2011 16:35:39 +0200</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Thomas Mailund</title>
		<link>http://www.mailund.dk/index.php/2009/01/30/eureka/comment-page-1/#comment-2391</link>
		<dc:creator>Thomas Mailund</dc:creator>
		<pubDate>Sat, 31 Jan 2009 11:17:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.mailund.dk/?p=892#comment-2391</guid>
		<description>Yes, exactly.  The one for the coalescence is actually a Markov chain.  The past only depends on the present not on what happens later than the present.  Yeah, that sounds weird, but that is how coalescence theory works :)

The one along the sequence is an approximation to dealing with the ancestral recombination graph.  This is not really a Markov chain, &#039;cause the nucleotide to the right of your current position will have a past that depends on all the nucleotides to the left of you.  The two-nucleotide model I described above really tells you why: The number of lineages (carrying ancestral material) at any point in time depends on how many have coalesced, and that means the entire ancestral recombination graph.

but as you know from LD, the dependency shrinks with distance, so you can approximate it with a Markov chain.

The idea I wrote about in this post improves on the approximation along the sequence, by more accurately capturing the dependency of the right nucleotide of a pair on the left of the pair.  It is still a crude approximation on the true process, but it deals better with &quot;back coalescence&quot; events.

There is actually another Markov chain running in the setup.  Mutations are also put on the local genealogies using a continuous time Markov chain.  The coalescence/recombination chain should really handle the mutations as well, but it is easier to deal with them separately.

That gives us another bias, though, and I haven&#039;t figured out how to deal with that yet.  Asger did some calculations that showed that the effect was negligible but we have now pretty much convinced ourselves that they are not and introduce a bias in how we estimate speciation times.  We correct that one the same way we correct the bias on recombination (using a Monte Carlo strategy), but in future work we hope to get the calculations right.

I wasn&#039;t optimistic about that last week.  It is dealing with a number of multiple integrals.  But perhaps the new formulation as Markov chains for the transitions might also solve this problem.  I haven&#039;t figured that part out yet, but I&#039;m working on it :)</description>
		<content:encoded><![CDATA[<p>Yes, exactly.  The one for the coalescence is actually a Markov chain.  The past only depends on the present not on what happens later than the present.  Yeah, that sounds weird, but that is how coalescence theory works :)</p>
<p>The one along the sequence is an approximation to dealing with the ancestral recombination graph.  This is not really a Markov chain, &#8217;cause the nucleotide to the right of your current position will have a past that depends on all the nucleotides to the left of you.  The two-nucleotide model I described above really tells you why: The number of lineages (carrying ancestral material) at any point in time depends on how many have coalesced, and that means the entire ancestral recombination graph.</p>
<p>but as you know from LD, the dependency shrinks with distance, so you can approximate it with a Markov chain.</p>
<p>The idea I wrote about in this post improves on the approximation along the sequence, by more accurately capturing the dependency of the right nucleotide of a pair on the left of the pair.  It is still a crude approximation on the true process, but it deals better with &#8220;back coalescence&#8221; events.</p>
<p>There is actually another Markov chain running in the setup.  Mutations are also put on the local genealogies using a continuous time Markov chain.  The coalescence/recombination chain should really handle the mutations as well, but it is easier to deal with them separately.</p>
<p>That gives us another bias, though, and I haven&#8217;t figured out how to deal with that yet.  Asger did some calculations that showed that the effect was negligible but we have now pretty much convinced ourselves that they are not and introduce a bias in how we estimate speciation times.  We correct that one the same way we correct the bias on recombination (using a Monte Carlo strategy), but in future work we hope to get the calculations right.</p>
<p>I wasn&#8217;t optimistic about that last week.  It is dealing with a number of multiple integrals.  But perhaps the new formulation as Markov chains for the transitions might also solve this problem.  I haven&#8217;t figured that part out yet, but I&#8217;m working on it :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reed A. Cartwright</title>
		<link>http://www.mailund.dk/index.php/2009/01/30/eureka/comment-page-1/#comment-2386</link>
		<dc:creator>Reed A. Cartwright</dc:creator>
		<pubDate>Fri, 30 Jan 2009 18:40:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.mailund.dk/?p=892#comment-2386</guid>
		<description>So you have two markov chains?

One along a sequence and one for the coalescence?</description>
		<content:encoded><![CDATA[<p>So you have two markov chains?</p>
<p>One along a sequence and one for the coalescence?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

