<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator><link href="https://dasaro.github.io/feed.xml" rel="self" type="application/atom+xml"/><link href="https://dasaro.github.io/" rel="alternate" type="text/html" hreflang="en"/><updated>2026-07-05T12:42:33+00:00</updated><id>https://dasaro.github.io/feed.xml</id><title type="html">blank</title><subtitle>A simple, whitespace theme for academics. Based on [*folio](https://github.com/bogoli/-folio) design. </subtitle><entry><title type="html">Unpredictable Does Not Mean Incomputable</title><link href="https://dasaro.github.io/blog/2026/unpredictable-does-not-mean-incomputable/" rel="alternate" type="text/html" title="Unpredictable Does Not Mean Incomputable"/><published>2026-07-05T08:30:00+00:00</published><updated>2026-07-05T08:30:00+00:00</updated><id>https://dasaro.github.io/blog/2026/unpredictable-does-not-mean-incomputable</id><content type="html" xml:base="https://dasaro.github.io/blog/2026/unpredictable-does-not-mean-incomputable/"><![CDATA[<p>Debates about whether living systems are “just computation”, or somehow obviously exceed it, often make the same mistake in opposite directions. One side says: if we can describe the behaviour of a system computationally, then the system itself must be computational. The other says: if the system is chaotic, open-ended, and impossible to predict in practice, then computation cannot possibly capture it.</p> <p>I do not think either conclusion follows.</p> <h2 id="the-pancomputationalist-temptation">The pancomputationalist temptation</h2> <p>Let us start with the first argument.</p> <p>Suppose a system admits a computable model that tracks its behaviour to arbitrary precision. This is already a substantial claim. The naive conclusion is tempting: if computation reproduces the system’s behaviour, then the system <strong>is a computer</strong>. Perhaps, even more strongly, computation is what the system fundamentally is.</p> <p>But why should that follow?</p> <p>Simulability, implementation, and constitution are different claims. No theorem in computability theory takes us automatically from the first to the other two.</p> <p>Philosophers of mind ran into a version of this problem long ago. Putnam observed that, if we allow a sufficiently permissive mapping between physical and computational states, almost any physical process can be made to implement almost any finite automaton. If implementation is this cheap, saying that a system “implements a computation” tells us almost nothing. Chalmers later tried to formulate stronger constraints. But the general problem remains: a mathematical mapping is not yet an ontology.</p> <p>The pancomputationalist would like to conclude:</p> <blockquote> <p>We can compute a model of it, therefore it is computation.</p> </blockquote> <p>The difficulty is not necessarily with the conclusion. The difficulty is that the mathematics, by itself, has not yet earned it.</p> <h2 id="the-anti-computationalist-temptation">The anti-computationalist temptation</h2> <p>Now consider the argument from the opposite side.</p> <p>Turing had already isolated part of the relevant distinction in 1950. For a discrete state machine, if you know the exact state and the transition rule, the next state is fixed. With some continuous physical systems, however, the practical situation is very different: a tiny error in the initial conditions can become a huge difference later, if we wait long enough. The three-body problem is the classical example; the double pendulum is the textbook one. Change the starting angle by a hair and, after a few swings, the two trajectories may have almost nothing in common.</p> <svg viewBox="0 0 680 300" width="680" height="300" style="width:100%;max-width:680px;height:auto;display:block;margin:1.8em auto 0.4em;" xmlns="http://www.w3.org/2000/svg"> <rect x="1" y="1" width="678" height="298" rx="14" fill="#ffffff" stroke="#e3e3ea" stroke-width="1.5"/> <text x="340" y="32" text-anchor="middle" font-family="Helvetica Neue, Arial, sans-serif" font-size="15" font-weight="600" fill="#1c2333">Two trajectories, nearly identical start</text> <path d="M60.0 150.0 L63.7 148.8 L67.4 147.6 L71.1 146.6 L74.9 145.6 L78.6 144.9 L82.3 144.3 L86.0 144.0 L89.7 143.8 L93.4 144.0 L97.1 144.3 L100.9 145.0 L104.6 145.8 L108.3 146.8 L112.0 148.0 L115.7 149.3 L119.4 150.6 L123.1 152.0 L126.9 153.3 L130.6 154.6 L134.3 155.7 L138.0 156.7 L141.7 157.4 L145.4 157.8 L149.1 158.0 L152.9 157.8 L156.6 157.3 L160.3 156.4 L164.0 155.2 L167.7 153.8 L171.4 152.1 L175.1 150.2 L178.9 148.2 L182.6 146.2 L186.3 144.2 L190.0 142.3 L193.7 140.7 L197.4 139.3 L201.1 138.3 L204.9 137.8 L208.6 137.7 L212.3 138.2 L216.0 139.2 L219.7 140.7 L223.4 142.7 L227.1 145.2 L230.9 148.0 L234.6 151.0 L238.3 154.3 L242.0 157.5 L245.7 160.6 L249.4 163.5 L253.1 165.9 L256.9 167.8 L260.6 169.1 L264.3 169.6 L268.0 169.3 L271.7 168.2 L275.4 166.2 L279.1 163.4 L282.9 159.9 L286.6 155.7 L290.3 151.1 L294.0 146.1 L297.7 141.0 L301.4 136.1 L305.1 131.4 L308.9 127.3 L312.6 123.9 L316.3 121.4 L320.0 120.0 L323.7 119.9 L327.4 121.0 L331.1 123.4 L334.9 127.0 L338.6 131.9 L342.3 137.7 L346.0 144.4 L349.7 151.6 L353.4 159.2 L357.1 166.7 L360.9 173.9 L364.6 180.5 L368.3 186.1 L372.0 190.4 L375.7 193.2 L379.4 194.3 L383.1 193.6 L386.9 191.0 L390.6 186.6 L394.3 180.4 L398.0 172.6 L401.7 163.5 L405.4 153.5 L409.1 142.9 L412.9 132.0 L416.6 121.5 L420.3 111.7 L424.0 103.1 L427.7 96.1 L431.4 91.1 L435.1 88.3 L438.9 88.1 L442.6 90.4 L446.3 95.3 L450.0 102.7 L453.7 112.4 L457.4 124.1 L461.1 137.3 L464.9 151.6 L468.6 166.4 L472.3 181.1 L476.0 195.0 L479.7 207.6 L483.4 218.3 L487.1 226.5 L490.9 231.8 L494.6 233.9 L498.3 232.6 L502.0 227.7 L505.7 219.4 L509.4 207.9 L513.1 193.6 L516.9 176.9 L520.6 158.5 L524.3 139.1 L528.0 119.5 L531.7 100.5 L535.4 82.9 L539.1 67.4 L542.9 54.9 L546.6 46.0 L550.3 41.0 L554.0 40.5 L557.7 44.5 L561.4 53.0 L565.1 65.9 L568.9 82.6 L572.6 102.8 L576.3 125.5 L580.0 150.0" fill="none" stroke="#22314f" stroke-width="2.3" stroke-linejoin="round" stroke-linecap="round"/> <path d="M60.0 149.1 L63.7 147.7 L67.4 146.5 L71.1 145.4 L74.9 144.6 L78.6 144.1 L82.3 143.9 L86.0 144.1 L89.7 144.5 L93.4 145.3 L97.1 146.4 L100.9 147.7 L104.6 149.1 L108.3 150.7 L112.0 152.2 L115.7 153.6 L119.4 154.9 L123.1 156.0 L126.9 156.8 L130.6 157.2 L134.3 157.2 L138.0 156.8 L141.7 156.0 L145.4 154.8 L149.1 153.3 L152.9 151.5 L156.6 149.6 L160.3 147.5 L164.0 145.5 L167.7 143.7 L171.4 142.1 L175.1 140.8 L178.9 140.1 L182.6 139.9 L186.3 140.2 L190.0 141.2 L193.7 142.7 L197.4 144.7 L201.1 147.2 L204.9 150.0 L208.6 153.0 L212.3 156.0 L216.0 158.8 L219.7 161.3 L223.4 163.2 L227.1 164.5 L230.9 165.1 L234.6 164.7 L238.3 163.5 L242.0 161.4 L245.7 158.5 L249.4 154.9 L253.1 150.9 L256.9 146.5 L260.6 142.0 L264.3 137.8 L268.0 134.0 L271.7 131.0 L275.4 128.8 L279.1 127.9 L282.9 128.1 L286.6 129.7 L290.3 132.5 L294.0 136.6 L297.7 141.6 L301.4 147.5 L305.1 153.8 L308.9 160.2 L312.6 166.4 L316.3 172.0 L320.0 176.6 L323.7 179.9 L327.4 181.6 L331.1 181.5 L334.9 179.6 L338.6 175.8 L342.3 170.4 L346.0 163.4 L349.7 155.4 L353.4 146.6 L357.1 137.5 L360.9 128.8 L364.6 120.8 L368.3 114.2 L372.0 109.3 L375.7 106.6 L379.4 106.3 L383.1 108.5 L386.9 113.3 L390.6 120.4 L394.3 129.5 L398.0 140.3 L401.7 152.2 L405.4 164.4 L409.1 176.3 L412.9 187.3 L416.6 196.6 L420.3 203.5 L424.0 207.7 L427.7 208.6 L431.4 206.2 L435.1 200.5 L438.9 191.5 L442.6 179.8 L446.3 165.9 L450.0 150.5 L453.7 134.4 L457.4 118.6 L461.1 103.9 L464.9 91.4 L468.6 81.7 L472.3 75.7 L476.0 73.7 L479.7 76.0 L483.4 82.7 L487.1 93.6 L490.9 108.1 L494.6 125.6 L498.3 145.2 L502.0 165.7 L505.7 186.1 L509.4 205.2 L513.1 221.8 L516.9 234.8 L520.6 243.4 L524.3 246.9 L528.0 244.9 L531.7 237.4 L535.4 224.6 L539.1 207.0 L542.9 185.6 L546.6 161.3 L550.3 135.6 L554.0 109.9 L557.7 85.6 L561.4 64.3 L565.1 47.2 L568.9 35.4 L572.6 29.8 L576.3 31.0 L580.0 39.1" fill="none" stroke="#d1603d" stroke-width="2.3" stroke-linejoin="round" stroke-linecap="round"/> <circle cx="60" cy="149.5" r="10" fill="none" stroke="#9599a3" stroke-width="1.3" stroke-dasharray="2.5 2.5"/> <text x="60" y="118" text-anchor="middle" font-family="Helvetica Neue, Arial, sans-serif" font-size="11.5" fill="#6b7280">almost the same state</text> <text x="592" y="153" font-family="Helvetica Neue, Arial, sans-serif" font-size="12" font-weight="600" fill="#22314f">A</text> <text x="592" y="42" font-family="Helvetica Neue, Arial, sans-serif" font-size="12" font-weight="600" fill="#d1603d">B</text> <path d="M600 39 L606 39 L606 150 L600 150" fill="none" stroke="#9599a3" stroke-width="1.2"/> <text x="611" y="90" font-family="Helvetica Neue, Arial, sans-serif" font-size="10.5" fill="#6b7280">diverged</text> <line x1="55" y1="272" x2="605" y2="272" stroke="#d8d9df" stroke-width="1.2"/> <text x="605" y="290" text-anchor="end" font-family="Helvetica Neue, Arial, sans-serif" font-size="11" fill="#9599a3">time &#8594;</text> </svg> <p style="text-align:center;font-size:0.88em;color:#6b7280;margin-top:0.2em;">Two runs starting a hair apart, evolving under one identical deterministic rule.</p> <p>The naive conclusion now runs in the other direction: if the future of the system is unpredictable, perhaps computation has reached its limit. And, if living systems display this kind of sensitivity, perhaps they must therefore exceed computation.</p> <p>The important word here is <strong>unpredictable</strong>. It does not mean <strong>incomputable</strong>.</p> <p>Take a simpler case. Suppose I give you an exact state, an effective update rule, and ask where the system will be after (t) steps. You apply the rule (t) times. The calculation may be enormous; two almost identical starting points may lead to completely different answers. But, in principle, there is no mystery about the procedure: start here, apply the rule, stop after (t) steps.</p> <p>Incomputability is a different kind of obstacle. The point is not that the calculation is too long, too delicate, or useless in practice. The point is that no general algorithm can always give the answer. Chaos, by itself, gives us nothing of this sort. It tells us that prediction may collapse because tiny errors in our knowledge of the initial state are amplified. This is a problem of access and precision. It is not automatically a failure of computation.</p> <p>This distinction is not even foreign to strongly anti-computationalists. In the more careful technical literature, unpredictability and incomputability are not simply treated as synonyms. The problem usually appears one step later, when broader philosophical conclusions are drawn too quickly.</p> <svg viewBox="0 0 680 220" width="680" height="220" style="width:100%;max-width:680px;height:auto;display:block;margin:1.8em auto 0.4em;" xmlns="http://www.w3.org/2000/svg"> <rect x="1" y="1" width="678" height="218" rx="14" fill="#ffffff" stroke="#e3e3ea" stroke-width="1.5"/> <text x="45" y="45" font-family="Helvetica Neue, Arial, sans-serif" font-size="13.5" font-weight="700" fill="#22314f">UNPREDICTABILITY</text> <line x1="45" y1="70" x2="255" y2="70" stroke="#22314f" stroke-width="2.5" stroke-linecap="round"/> <line x1="80" y1="65" x2="80" y2="75" stroke="#22314f" stroke-width="1.5"/> <line x1="115" y1="65" x2="115" y2="75" stroke="#22314f" stroke-width="1.5"/> <line x1="150" y1="65" x2="150" y2="75" stroke="#22314f" stroke-width="1.5"/> <line x1="185" y1="65" x2="185" y2="75" stroke="#22314f" stroke-width="1.5"/> <line x1="220" y1="65" x2="220" y2="75" stroke="#22314f" stroke-width="1.5"/> <circle cx="255" cy="70" r="5" fill="#22314f"/> <text x="45" y="93" font-family="Helvetica Neue, Arial, sans-serif" font-size="11.5" fill="#6b7280">prediction can fail after a handful of steps</text> <text x="45" y="140" font-family="Helvetica Neue, Arial, sans-serif" font-size="13.5" font-weight="700" fill="#d1603d">INCOMPUTABILITY</text> <line x1="45" y1="165" x2="520" y2="165" stroke="#d1603d" stroke-width="2.5" stroke-linecap="round"/> <line x1="520" y1="165" x2="555" y2="165" stroke="#d1603d" stroke-width="2.5" stroke-dasharray="1 7" stroke-linecap="round"/> <text x="572" y="172" font-family="Georgia, serif" font-size="20" fill="#d1603d">&#8734;</text> <text x="45" y="188" font-family="Helvetica Neue, Arial, sans-serif" font-size="11.5" fill="#6b7280">no general algorithm can always give the answer</text> </svg> <p style="text-align:center;font-size:0.88em;color:#6b7280;margin-top:0.2em;">One concerns the collapse of prediction. The other concerns the existence of an algorithm.</p> <p>The anti-computationalist would like to conclude:</p> <blockquote> <p>We cannot predict it, therefore computation cannot capture it.</p> </blockquote> <p>But chaos does not hypercompute. Sensitivity to initial conditions does not, by itself, produce a non-computable function, solve an undecidable problem, or take us beyond effective procedure. It may destroy prediction. That is already important. It is simply not the same claim.</p> <p>So, in the end, the two familiar arguments mirror each other.</p> <p>One moves too quickly from a successful computational description to an ontology of computation. The other moves too quickly from a failed prediction to a limit of computation.</p> <p>Both add a premise that the mathematics simply does not contain.</p> <p>Perhaps living systems are computational in a deep constitutive sense. Perhaps they are not. I have no intention of settling that question here. The more modest point is that computability and chaos, by themselves, do not settle it either.</p> <p>Before inferring ontology from a theorem, it may be worth checking that it is at least the right theorem.</p>]]></content><author><name></name></author><category term="philosophy-of-computation"/><category term="logic"/><category term="computability"/><category term="turing"/><summary type="html"><![CDATA[Two confusions that keep resurfacing in debates about computation and life, neither of which is actually licensed by the mathematics.]]></summary></entry></feed>