<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/default.xsl"?>
<fr:tree xmlns:fr="http://www.forester-notes.org" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xml="http://www.w3.org/XML/1998/namespace" root="true" base-url="/">
  <fr:frontmatter>
    <fr:authors>
      <fr:author>
        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
      </fr:author>
    </fr:authors>
    <fr:uri>https://erischel.com/index/</fr:uri>
    <fr:display-uri>index</fr:display-uri>
    <fr:route>/index/</fr:route>
    <fr:title text="Eigil Fjeldgren Rischel">Eigil Fjeldgren Rischel</fr:title>
    <fr:meta name="author">false</fr:meta>
  </fr:frontmatter>
  <fr:mainmatter>
    <html:p>
My name is Eigil Fjeldgren Rischel.
I'm studying for a PhD in Computer and Information Sciences at the <fr:link href="http://msp.cis.strath.ac.uk/" type="external">Mathematically Structured Programming group</fr:link> at the University of Strathclyde.
My advisors are <fr:link href="https://personal.cis.strath.ac.uk/neil.ghani/" type="external">Neil Ghani</fr:link> and <fr:link href="https://personal.cis.strath.ac.uk/r.mardare/" type="external">Radu Mardare</fr:link>.
</html:p>
    <html:p>
  I'm also a Research Consultant at the <fr:link href="http://taltech.ee/en" type="external">Tallinn University of Technology</fr:link>, in the <fr:link href="https://compose.ioc.ee/" type="external">Laboratory for Compositional Systems and Methods</fr:link>. I'm currently employed working on the <fr:link href="https://www.aria.org.uk/opportunity-spaces/mathematics-for-safe-ai/safeguarded-ai" type="external">Safeguarded AI</fr:link> project.
</html:p>
    <html:p>
  I mainly work on applications of category theory to probability and statistics. 
</html:p>
    <html:p>
  This website is a "forest", made with the <fr:link href="https://forester-notes.org/" type="external">forester</fr:link> tool. It contains various notes I've made over the years, as well as some more structured blog posts.
</html:p>
    <html:p>
  Click on the headings below to expand, or on the bracketed link next to them to go to the relevant page.
</html:p>
    <fr:tree show-metadata="false">
      <fr:frontmatter>
        <fr:authors>
          <fr:author>
            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
          </fr:author>
        </fr:authors>
        <fr:uri>https://erischel.com/efr-0032/</fr:uri>
        <fr:display-uri>efr-0032</fr:display-uri>
        <fr:route>/efr-0032/</fr:route>
        <fr:title text="List of Publications">List of Publications</fr:title>
      </fr:frontmatter>
      <fr:mainmatter>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>Radu Mardare</fr:author>
              <fr:author>Neil Ghani</fr:author>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2025</fr:year>
              <fr:month>9</fr:month>
              <fr:day>17</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/mardare-ghani-rischel-2025/</fr:uri>
            <fr:display-uri>mardare-ghani-rischel-2025</fr:display-uri>
            <fr:route>/mardare-ghani-rischel-2025/</fr:route>
            <fr:title text="Metric Equational Theories">Metric Equational Theories</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="doi">10.4204/eptcs.428.11</fr:meta>
            <fr:meta name="bibtex"><![CDATA[@article{Mardare2025,
  title = {Metric Equational Theories},
  volume = {428},
  ISSN = {2075-2180},
  url = {http://dx.doi.org/10.4204/EPTCS.428.11},
  DOI = {10.4204/eptcs.428.11},
  journal = {Electronic Proceedings in Theoretical Computer Science},
  publisher = {Open Publishing Association},
  author = {Mardare,  Radu and Ghani,  Neil and Rischel,  Eigil},
  year = {2025},
  month = sep,
  pages = {144–160}
}]]>
</fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>Radu Mardare</fr:author>
                  <fr:author>Neil Ghani</fr:author>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2025</fr:year>
                  <fr:month>9</fr:month>
                  <fr:day>17</fr:day>
                </fr:date>
                <fr:title text="Abstract">Abstract</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
    This paper proposes appropriate sound and complete proof systems for algebraic structures over metric spaces by combining the development of Quantitative Equational Theories (QET) with the Enriched Lawvere Theories. We extend QETs to Metric Equational Theories (METs) where operations no longer have finite sets as arities (as in QETs and the general theory of universal algebras), but arities are now drawn from countable metric spaces. This extension is inspired by the theory of Enriched Lawvere Theories, which suggests that the arities of operations should be the lambda-presentable objects of the underlying lambda-accessible category. In this setting, the validity of terms in METs can no longer be guaranteed independently of the validity of equations, as is the case with QET. We solve this problem, and adapt the sound and complete proof system for QETs to these more general METs, taking advantage of the specific structure of metric spaces.
  </html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2025</fr:year>
              <fr:month>6</fr:month>
              <fr:day>2</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/rischel-cvxdual-2025/</fr:uri>
            <fr:display-uri>rischel-cvxdual-2025</fr:display-uri>
            <fr:route>/rischel-cvxdual-2025/</fr:route>
            <fr:title text="Convex Duality Made Difficult">Convex Duality Made Difficult</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="bibtex"><![CDATA[ @article
{rischel-cvxdual-2025, title={Convex Duality Made Difficult}, volume={??}, journal={EPTCS}, author={Rischel, Eigil Fjeldgren}, pages={1–14}, date={2025} }]]></fr:meta>
            <fr:meta name="external">https://cgi.cse.unsw.edu.au/~eptcs/paper.cgi?ACT2025:28</fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2024</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:uri>https://erischel.com/lcc-001Z/</fr:uri>
                <fr:display-uri>lcc-001Z</fr:display-uri>
                <fr:route>/lcc-001Z/</fr:route>
                <fr:title text="Convex Duality made Difficult">Convex Duality made Difficult</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="Introduction">Introduction</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The study of convex functions - in particular, of their optimization (really <html:em>minimization</html:em>) is one of the most important fields of applied mathematics. Convexity seems to be one of those incredibly well-chosen hypotheses which is just specific enough to admit a wealth of theorems, just general enough to produce a nontrivial theory (and a large amount of important examples).
  </html:p>
                    <html:p>
    Convex optimization, possibly because it has an "analytical" rather than "algebraic" feel, has not been very thoroughly studied by applied category theorists. The one notable exception is <fr:link href="/hanks-etal-convex-2024/" title="A Compositional Framework for First-Order Optimization" uri="https://erischel.com/hanks-etal-convex-2024/" display-uri="hanks-etal-convex-2024" type="local">Reference <fr:contextual-number uri="https://erischel.com/hanks-etal-convex-2024/" display-uri="hanks-etal-convex-2024" /></fr:link>, which studies the decomposition of optimization problems by categorical means. This paper takes a different approach, attempting to define a category with optimization problems as the objects, and to derive theorems about optimization by categorical means.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="Convex optimization">Convex optimization</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>22</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001G/</fr:uri>
                        <fr:display-uri>lcc-001G</fr:display-uri>
                        <fr:route>/lcc-001G/</fr:route>
                        <fr:title text="Standard form convex optimization problem">Standard form convex optimization problem</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    A <html:em>convex optimization problem in standard form</html:em> consists of
    <html:ol><html:li>A convex function <fr:tex display="inline"><![CDATA[f_0: \mathbb {R}^k \to  \mathbb {R}]]></fr:tex></html:li>
        <html:li>A list of convex functions <fr:tex display="inline"><![CDATA[f_1, \dots  f_n: \mathbb {R}^k \to  \mathbb {R}]]></fr:tex></html:li>
        <html:li>A list of <html:em>affine</html:em> functions <fr:tex display="inline"><![CDATA[g_1,\dots  g_m: \mathbb {R}^k \to  \mathbb {R}]]></fr:tex></html:li></html:ol>
    The problem then is to find <fr:tex display="inline"><![CDATA[x \in  \mathbb {R}^k]]></fr:tex> which minimizes <fr:tex display="inline"><![CDATA[f_0(x)]]></fr:tex> subject to the constraints <fr:tex display="inline"><![CDATA[f_i(x) \leq  0, g_i(x)=0]]></fr:tex></html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>17</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002K/</fr:uri>
                        <fr:display-uri>lcc-002K</fr:display-uri>
                        <fr:route>/lcc-002K/</fr:route>
                        <fr:title text="Lagrangian of an optimization problem">Lagrangian of an optimization problem</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  Let <fr:tex display="inline"><![CDATA[f_0: \mathbb {R}^k \to  \mathbb {R}, f_1, \dots  f_n, g_1 , \dots  g_m]]></fr:tex> be a standard-form convex optimization problem, as in <fr:link href="/lcc-001G/" title="Standard form convex optimization problem" uri="https://erischel.com/lcc-001G/" display-uri="lcc-001G" type="local">Definition <fr:contextual-number uri="https://erischel.com/lcc-001G/" display-uri="lcc-001G" /></fr:link>. Then the <html:em>Lagrangian</html:em> of this problem is the function <fr:tex display="inline"><![CDATA[L: \mathbb {R}^k \times  \mathbb {R}^n_+ \times  \mathbb {R}^m \to  \mathbb {R}]]></fr:tex> defined by
  
  <fr:tex display="block"><![CDATA[L(x;\lambda ,\nu ) = f_0(x) + \sum _i \lambda _i f_i(x) + \sum _i \nu _i g_i(x).]]></fr:tex>
  
  Recall that <fr:tex display="inline"><![CDATA[\mathbb {R}_+]]></fr:tex> denotes the <html:em>nonnegative</html:em> reals.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>
    Observe that <fr:tex display="inline"><![CDATA[\sup _{\lambda ,\nu } L(x,\lambda ,\nu )]]></fr:tex> is <fr:tex display="inline"><![CDATA[f_0(x)]]></fr:tex> if <fr:tex display="inline"><![CDATA[x]]></fr:tex> satisfies the constraints of the problem, and <fr:tex display="inline"><![CDATA[\infty ]]></fr:tex> otherwise. Hence we can think of this minimization problem as playing a zero-sum game: we choose <fr:tex display="inline"><![CDATA[x]]></fr:tex>, our adversary chooses <fr:tex display="inline"><![CDATA[\lambda ,\nu ]]></fr:tex>, and our loss function is <fr:tex display="inline"><![CDATA[L]]></fr:tex>.
  </html:p>
                    <html:p>
    It is natural to ask about the existence of Nash equilibria in this game - observe that the existence of an equilibrium <fr:tex display="inline"><![CDATA[(x^*,\lambda ^*,\nu ^*)]]></fr:tex> means that <fr:tex display="inline"><![CDATA[\inf _x \sup _{\lambda ,\nu } L(x,\lambda ,\nu ) = \sup _{\lambda ,\nu } \inf _x L(x,\lambda ,\nu ) = L(x^*,\lambda ^*,\nu ^*)]]></fr:tex>. This is of great utility in solving the original problem.
  </html:p>
                    <html:p>
    The <html:em>dual problem</html:em> is the problem of <html:em>maximizing</html:em> the function <fr:tex display="inline"><![CDATA[\inf _x L(x,\lambda ,\nu )]]></fr:tex>. This is always a concave problem.
  </html:p>
                    <html:p>
    In the world of convex optimization, two problems whose constraints carve out the same subset of <fr:tex display="inline"><![CDATA[\mathbb {R}^k]]></fr:tex> (and where the function to optimize is the same) would be called <html:em>equivalent</html:em>. But they can clearly not be regarded as <html:em>isomorphic</html:em>, because the choice of constraint functions makes an important difference to the theory of optimization (for example, it can lead to different dual problems). Here we take the viewpoint that the <html:em>Lagrangian</html:em> is really the fundamental object in convex optimization - by passing to a suitable category of Lagrangians, we can make the dual problem into an actual self-duality on this category.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="Convex spaces">Convex spaces</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>30</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-0020/</fr:uri>
                        <fr:display-uri>lcc-0020</fr:display-uri>
                        <fr:route>/lcc-0020/</fr:route>
                        <fr:title text="Convex Space">Convex Space</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  The category of <html:em>convex spaces</html:em> is the category of algebras for the monad <fr:tex display="inline"><![CDATA[\Delta : \mathsf {Set} \to  \mathsf {Set}]]></fr:tex> of discrete finite-support distributions. The morphisms are called <html:em><fr:tex display="inline"><![CDATA[\Delta ]]></fr:tex>-homomorphisms</html:em> or <html:em>homomorphisms of convex spaces</html:em>.
</html:p>
                        <html:p>
  So as not to multiply notation unnecessarily, we simply denote the category of convex spaces by <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta ]]></fr:tex>, using the usual notation for the Eilenberg-Moore category.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>20</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002N/</fr:uri>
                        <fr:display-uri>lcc-002N</fr:display-uri>
                        <fr:route>/lcc-002N/</fr:route>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  A function between vector spaces is called <html:em>affine</html:em> if it preserves those linear combinations <fr:tex display="inline"><![CDATA[\sum _i \lambda _i x_i]]></fr:tex> where <fr:tex display="inline"><![CDATA[\sum _i \lambda _i = 1]]></fr:tex></html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>20</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002M/</fr:uri>
                        <fr:display-uri>lcc-002M</fr:display-uri>
                        <fr:route>/lcc-002M/</fr:route>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  Let <fr:tex display="inline"><![CDATA[X]]></fr:tex> be a convex space. A <html:em>convex function on <fr:tex display="inline"><![CDATA[X]]></fr:tex></html:em> is a function <fr:tex display="inline"><![CDATA[f: X \to  \mathbb {R}]]></fr:tex> so that
  <fr:tex display="block"><![CDATA[f(\theta  x + (1-\theta )x') \leq  \theta  f(x) + (1-\theta )f(x')]]></fr:tex></html:p>
                        <html:p>
  A <html:em>concave function</html:em> is a function so that <fr:tex display="inline"><![CDATA[-f]]></fr:tex> is convex (in other words, <fr:tex display="inline"><![CDATA[f]]></fr:tex> satisfies the opposite inequality).
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>
    The term "convex function" in this sense clashes with the usual practice of naming structure-preserving functions after the structure they preserve (since convex functions do not preserve the convex structure). Unfortunately this usage is far too established to alter. (Convex functions are called convex because they are exactly those functions where the area above their graph is a convex subset of <fr:tex display="inline"><![CDATA[X \times  \mathbb {R}]]></fr:tex>. Although there appears to be no particular reason why the terms convex and concave should not be interchanged, other than convention).
  </html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>19</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002R/</fr:uri>
                        <fr:display-uri>lcc-002R</fr:display-uri>
                        <fr:route>/lcc-002R/</fr:route>
                        <fr:title text="Jensen's Inequality">Jensen's Inequality</fr:title>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  The inequality
  <fr:tex display="block"><![CDATA[f(\theta  x + (1-\theta )x') \leq  \theta  f(x) + (1-\theta )f(x'),]]></fr:tex>
  which holds whenever <fr:tex display="inline"><![CDATA[f]]></fr:tex> is convex, is called <html:em>Jensen's inequality</html:em>.
  Sometimes this name is used for a stronger version of this inequality,
  like the claim that <fr:tex display="inline"><![CDATA[f(\mathbb {E} X) \leq  \mathbb {E} f(X)]]></fr:tex> if <fr:tex display="inline"><![CDATA[X]]></fr:tex> is a random variable valued in the domain of <fr:tex display="inline"><![CDATA[f]]></fr:tex>. These generally follow just from convexity of <fr:tex display="inline"><![CDATA[f]]></fr:tex>.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>19</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002Q/</fr:uri>
                        <fr:display-uri>lcc-002Q</fr:display-uri>
                        <fr:route>/lcc-002Q/</fr:route>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    There is an natural way to extend the convex structure of <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex> to both <fr:tex display="inline"><![CDATA[\lsqb  -\infty , \infty  \rpar ]]></fr:tex> and <fr:tex display="inline"><![CDATA[\lpar  -\infty , \infty  \rsqb ]]></fr:tex>, by the convention that any nontrivial convex combination involving an infinity is equal to that infinity. This also gives the adjectives convex and concave a meaning when applied to functions <fr:tex display="inline"><![CDATA[X \to  \lpar  -\infty , \infty  \rsqb ]]></fr:tex>. For example, a function <fr:tex display="inline"><![CDATA[f: X \to  \lpar  -\infty , \infty  \rsqb ]]></fr:tex> is convex if and only if the subset where it's finite is a convex subset of <fr:tex display="inline"><![CDATA[X]]></fr:tex>, and it's a convex function in the ordinary sense on this set.
  </html:p>
                        <html:p>
    This doesn't work for the extended real line <fr:tex display="inline"><![CDATA[\eRR  = \lsqb  -\infty , \infty  \rsqb ]]></fr:tex>, since there is no sensible interpretation of <fr:tex display="inline"><![CDATA[\theta  \cdot  -\infty  + (1-\theta )\infty ]]></fr:tex>. We will inescapably meet some functions which take value in the full extended reals, but where we still wish to speak of their convexity (or concavity).
  </html:p>
                        <html:p>
    Hence we adopt the convention that a function <fr:tex display="inline"><![CDATA[f: X \to  \eRR ]]></fr:tex> is convex if it obeys Jensen's inequality whenever it makes sense, i.e whenever we do not have <fr:tex display="inline"><![CDATA[f(x) = -\infty , f(x') = \infty ]]></fr:tex> or vice versa. 
  </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>20</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002O/</fr:uri>
                        <fr:display-uri>lcc-002O</fr:display-uri>
                        <fr:route>/lcc-002O/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter><html:p>
  A function between vector spaces is <fr:link href="/lcc-002N/" title="https://erischel.com/lcc-002N/" uri="https://erischel.com/lcc-002N/" display-uri="lcc-002N" type="local">affine</fr:link> if and only if it is a <fr:link href="/lcc-0020/" title="Convex Space" uri="https://erischel.com/lcc-0020/" display-uri="lcc-0020" type="local"><fr:tex display="inline"><![CDATA[\Delta ]]></fr:tex>-homomorphism</fr:link>.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>20</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
    It's clear that an affine function is a <fr:tex display="inline"><![CDATA[\Delta ]]></fr:tex>-homomorphism.
    Suppose <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> is a <fr:tex display="inline"><![CDATA[\Delta ]]></fr:tex>-homomorphism. Note it suffices to prove <fr:tex display="inline"><![CDATA[f]]></fr:tex> preserves binary affine combinations <fr:tex display="inline"><![CDATA[\theta  x + (1-\theta )x']]></fr:tex> (for <fr:tex display="inline"><![CDATA[\theta ]]></fr:tex> not necessarily in <fr:tex display="inline"><![CDATA[[0,1]]]></fr:tex>).
    If <fr:tex display="inline"><![CDATA[\theta  \in  [0,1]]]></fr:tex>, we are done by assumption. Otherwise suppose <fr:tex display="inline"><![CDATA[\theta  > 1]]></fr:tex> (if not, replace it by <fr:tex display="inline"><![CDATA[1-\theta ]]></fr:tex> by symmetry). Then
    <fr:tex display="block"><![CDATA[x = (1/\theta )(\theta  x + (1-\theta )x') + (1 - 1/\theta )x']]></fr:tex>
    This is a convex combination, so
    <fr:tex display="block"><![CDATA[f(x) = (1/\theta )f(\theta  x + (1-\theta )x') + (1-1/\theta )f(x')]]></fr:tex>
    Rearranging, we find
    <fr:tex display="block"><![CDATA[\theta  f(x) + (1-\theta )f(x') = f(\theta  x + (1-\theta ')x)]]></fr:tex>
    as desired.
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter>
                    </fr:tree>
                    <html:p>
    Justified by <fr:link href="/lcc-002O/" title="https://erischel.com/lcc-002O/" uri="https://erischel.com/lcc-002O/" display-uri="lcc-002O" type="local">Proposition <fr:contextual-number uri="https://erischel.com/lcc-002O/" display-uri="lcc-002O" /></fr:link>, we will appropriate the term <html:em>affine</html:em> to refer to <fr:tex display="inline"><![CDATA[\Delta ]]></fr:tex>-homomorphisms, even between convex spaces which are not vector spaces. There is generally no chance of confusion, but it's worth emphasizing that the use of this term does not entail that the domain is closed under arbitrary affine combinations, for example.
  </html:p>
                    <html:p>Convex spaces admit both a Cartesian product (given by the product of the underlying sets equipped with pointwise operations) and a tensor product, which (co)represents "bihomomorphisms". This is analogous to the situation for vector spaces. Unlike vector spaces, however, since all constant maps are homomorphisms, the projections <fr:tex display="inline"><![CDATA[X \times  Y \to  X,Y]]></fr:tex> are bihomomorphisms, which induces a map <fr:tex display="inline"><![CDATA[X \otimes  Y \to  X \times  Y]]></fr:tex>. Thus homomorphisms <fr:tex display="inline"><![CDATA[X \times  Y \to  Z]]></fr:tex> are a subset of bihomomorphisms.</html:p>
                    <html:p>Since we are generally dealing with convex or concave functions, which can't freely be extended to the tensor product, we will work with the Cartesian product in this paper. But it's very possible that most of our constructions would work also with the tensor product, and maybe there is some situation where the extra generality is necessary.</html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>21</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002S/</fr:uri>
                        <fr:display-uri>lcc-002S</fr:display-uri>
                        <fr:route>/lcc-002S/</fr:route>
                        <fr:title text="Simplex">Simplex</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  The free convex space on a finite set <fr:tex display="inline"><![CDATA[\{0, \dots  n\}]]></fr:tex> of <fr:tex display="inline"><![CDATA[n+1]]></fr:tex> elements is called the <html:em><fr:tex display="inline"><![CDATA[n]]></fr:tex>-simplex</html:em> and denoted <fr:tex display="inline"><![CDATA[\Delta ^n]]></fr:tex> (the reason for the apparent mismatch of numbering is that the <fr:tex display="inline"><![CDATA[n]]></fr:tex>-simplex is <fr:tex display="inline"><![CDATA[n]]></fr:tex>-dimensional). Note that an element of <fr:tex display="inline"><![CDATA[\Delta ^n]]></fr:tex> is a tuple <fr:tex display="inline"><![CDATA[(s_i)_{i=0,\dots , n}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\sum _i s_i = 1]]></fr:tex> and <fr:tex display="inline"><![CDATA[s_i \geq  0]]></fr:tex>.
  In particular, <fr:tex display="inline"><![CDATA[\Delta ^1 \cong  [0,1]]]></fr:tex>.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>21</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002U/</fr:uri>
                        <fr:display-uri>lcc-002U</fr:display-uri>
                        <fr:route>/lcc-002U/</fr:route>
                        <fr:title text="Topological convex space">Topological convex space</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  A <html:em>topological convex space</html:em> is a convex space <fr:tex display="inline"><![CDATA[X]]></fr:tex> equipped with a topology so that any affine map <fr:tex display="inline"><![CDATA[\Delta ^n \to  X]]></fr:tex> is continuous (when <fr:tex display="inline"><![CDATA[\Delta ^n \subseteq  \mathbb {R}^{n+1}]]></fr:tex> is given the subspace topology).
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="The Category of Minmax problems">The Category of Minmax problems</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>22</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001C/</fr:uri>
                        <fr:display-uri>lcc-001C</fr:display-uri>
                        <fr:route>/lcc-001C/</fr:route>
                        <fr:title text="Minmax problem">Minmax problem</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    A <html:em>minmax problem</html:em> is a triple <fr:tex display="inline"><![CDATA[(X,Y,L),]]></fr:tex> where <fr:tex display="inline"><![CDATA[X,Y]]></fr:tex> are convex spaces (that is, algebras for the discrete distribution monad---more topological assumptions may be necessary here), and <fr:tex display="inline"><![CDATA[L: X \times  Y \to  \mathbb {R}]]></fr:tex> is a function which is
    <html:ol><html:li>Pointwise <html:em>convex</html:em> in <fr:tex display="inline"><![CDATA[X]]></fr:tex>---for each <fr:tex display="inline"><![CDATA[y]]></fr:tex>, given <fr:tex display="inline"><![CDATA[x_1,x_2 \in  X, \theta  \in  [0,1]]]></fr:tex>, <fr:tex display="block"><![CDATA[L(\theta  x_1 + (1-\theta )x-2,y) \leq  \theta  L(x_1,y) + (1-\theta )L(x_2,y)]]></fr:tex></html:li>
        <html:li>Pointwise <html:em>concave</html:em> in <fr:tex display="inline"><![CDATA[Y]]></fr:tex>---for each <fr:tex display="inline"><![CDATA[x]]></fr:tex>, given <fr:tex display="inline"><![CDATA[y_1,y_2 \in  Y, \theta  \in  [0,1]]]></fr:tex>, <fr:tex display="block"><![CDATA[L(x,\theta  y_1 + (1-\theta )y_2) \geq  \theta  L(x,y_1) + (1-\theta )L(x,y_2)]]></fr:tex></html:li></html:ol></html:p>
                        <html:p>
    A <html:em>morphism of minmax problems</html:em> <fr:tex display="inline"><![CDATA[(X,Y,L) \to  (X',Y',L')]]></fr:tex> is a pair of functions <fr:tex display="inline"><![CDATA[\phi ^+: X \to  X']]></fr:tex> and <fr:tex display="inline"><![CDATA[\phi ^-: Y' \to  Y]]></fr:tex> so that <fr:tex display="inline"><![CDATA[L(x, \phi ^-(y')) \geq  L'(\phi (x),y')]]></fr:tex></html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>We will see that various constructions on this category, which are natural and well-behaved from the point of view of category theory, capture relevant constructions from the theory of convex optimization.</html:p>
                    <html:ol><html:li><fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex> is bifibred over <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex>, and the Cartesian and coCartesian lifts capture the operations of minimizing over the primal variables or maximizing over the dual variables</html:li>
    <html:li>The property of <html:em>strong duality</html:em> amounts to the claim that a particular diagram has the local Beck-Chevalley property</html:li>
    <html:li>Relatedly, the existence of a Nash equilibrium for the game corresponding to <fr:tex display="inline"><![CDATA[L]]></fr:tex> amounts to the existence of a certain morphism. The fact that this implies strong duality can be derived by purely categorical means.</html:li></html:ol>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>10</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002H/</fr:uri>
                        <fr:display-uri>lcc-002H</fr:display-uri>
                        <fr:route>/lcc-002H/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  Let <fr:tex display="inline"><![CDATA[(X,A,L)]]></fr:tex> be a minmax problem.
  Suppose <fr:tex display="inline"><![CDATA[A]]></fr:tex> is a convex subspace of a vector space <fr:tex display="inline"><![CDATA[V]]></fr:tex>, and <fr:tex display="inline"><![CDATA[L(x,-): A \to  \mathbb {R}]]></fr:tex> is affine for each <fr:tex display="inline"><![CDATA[x]]></fr:tex>.
  Then there exists functions <fr:tex display="inline"><![CDATA[f: X \to  \mathbb {R}, g: X \to  V^*]]></fr:tex>, so that <fr:tex display="inline"><![CDATA[L(x,a) = f(x)+\langle  g(x),a \rangle ]]></fr:tex>.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>
    Observe that minmax problems affine in <fr:tex display="inline"><![CDATA[A]]></fr:tex> are thus very similar to standard-form convex optimization problems, the main difference being that the set of allowed points in <fr:tex display="inline"><![CDATA[A]]></fr:tex> may be constrained in some other way than by requiring certain coordinates to be nonnegative.
  </html:p>
                    <html:p>
    On the other hand, if <fr:tex display="inline"><![CDATA[A]]></fr:tex> is thus constrained, the proposition doesn't actually imply that <fr:tex display="inline"><![CDATA[f,g]]></fr:tex> are convex! The easiest way to see this is by considering <fr:tex display="inline"><![CDATA[A = \{a\}]]></fr:tex> for some nonzero <fr:tex display="inline"><![CDATA[a]]></fr:tex>. Then we have <fr:tex display="inline"><![CDATA[L(x,a) = f(x) + ag(x),]]></fr:tex>, and clearly we can choose this decomposition in such a way that these functions are not convex.
  </html:p>
                    <html:p>
    However, if <fr:tex display="inline"><![CDATA[A \subset  \mathbb {R}^m]]></fr:tex> contains the positive cone <fr:tex display="inline"><![CDATA[\mathbb {R}^m_+,]]></fr:tex> for example, we do have both <fr:tex display="inline"><![CDATA[f]]></fr:tex> and all the coordinates of <fr:tex display="inline"><![CDATA[g]]></fr:tex> convex.
  </html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>22</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001D/</fr:uri>
                        <fr:display-uri>lcc-001D</fr:display-uri>
                        <fr:route>/lcc-001D/</fr:route>
                        <fr:title text="Primal and dual optimization problems">Primal and dual optimization problems</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Let <fr:tex display="inline"><![CDATA[L: X \times  Y \to  \mathbb {R}]]></fr:tex> be a <fr:link href="/lcc-001C/" title="Minmax problem" uri="https://erischel.com/lcc-001C/" display-uri="lcc-001C" type="local">minimax problem</fr:link>.
    The <html:em>primal optimization problem</html:em> associated to <fr:tex display="inline"><![CDATA[L]]></fr:tex> is the function
    <fr:tex display="block"><![CDATA[L^+(-) = \sup _y L(-,y): X \to  \mathbb {R}]]></fr:tex>
    (the problem being to <html:em>minimize</html:em> this function).
</html:p>
                        <html:p>
    The dual optimization problem is the function <fr:tex display="inline"><![CDATA[L^-(-) = \inf _x L(x,-): Y \to  \mathbb {R}]]></fr:tex></html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>23</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001J/</fr:uri>
                        <fr:display-uri>lcc-001J</fr:display-uri>
                        <fr:route>/lcc-001J/</fr:route>
                        <fr:title text="Dual minmax problem">Dual minmax problem</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>Let <fr:tex display="inline"><![CDATA[L = (X,Y,L)]]></fr:tex> be a <fr:link href="/lcc-001C/" title="Minmax problem" uri="https://erischel.com/lcc-001C/" display-uri="lcc-001C" type="local">minmax problem</fr:link>. Then let <fr:tex display="inline"><![CDATA[L^*]]></fr:tex> denote the <html:em>dual</html:em> problem given by <fr:tex display="inline"><![CDATA[(Y,X,L^*(y,x) = -L(x,y))]]></fr:tex>.</html:p>
                        <html:p>If <fr:tex display="inline"><![CDATA[\phi  = (\phi ^+,\phi ^-) : L \to  L']]></fr:tex> is a morphism of minmax problems, then <fr:tex display="inline"><![CDATA[\phi ^* = (\phi ^-,\phi ^+): L'^* \to  L^*]]></fr:tex> is again a morphism in the other direction. This assignment makes <fr:tex display="inline"><![CDATA[(-)^*]]></fr:tex> into a self-inverse functor on the category of minmax problems</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>
    We will often utilize this duality to abbreviate proofs, proving something, for example, for the forwards direction and arguing "by duality" that it holds for the backwards direction as well.
  </html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>1</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-0027/</fr:uri>
                        <fr:display-uri>lcc-0027</fr:display-uri>
                        <fr:route>/lcc-0027/</fr:route>
                        <fr:title text="Backwards and forwards morphisms">Backwards and forwards morphisms</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  Let a morphism <fr:tex display="inline"><![CDATA[\phi  = (\phi ^+,\phi ^-)]]></fr:tex> in <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex> be called <html:em>forwards</html:em> if <fr:tex display="inline"><![CDATA[\phi ^-]]></fr:tex> is an isomorphism, and <html:em>backwards</html:em> if <fr:tex display="inline"><![CDATA[\phi ^+]]></fr:tex> is an isomorphism.
  Let <fr:tex display="inline"><![CDATA[F]]></fr:tex> denote the set of forwards morphisms, <fr:tex display="inline"><![CDATA[B]]></fr:tex> the set of backwards. Then clearly <fr:tex display="inline"><![CDATA[(F,B)]]></fr:tex> form an orthogonal factorization system - in fact, both <fr:tex display="inline"><![CDATA[(F,B)]]></fr:tex> and <fr:tex display="inline"><![CDATA[(B,F)]]></fr:tex> do.
</html:p>
                        <html:p>
  Note that <fr:tex display="inline"><![CDATA[F]]></fr:tex> consists exactly of the local equivalences for the inclusion of <fr:tex display="inline"><![CDATA[* \times  \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex>, so that the localization of <fr:tex display="inline"><![CDATA[(X,A)]]></fr:tex> can be formed as the terminal forwards map from it, which is clearly <fr:tex display="inline"><![CDATA[(X,A) \to  (*,A)]]></fr:tex> (of course, this is not surprising).
</html:p>
                        <html:p>
  We will say a morphism in <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex> is forwards, respectively backwards, if it is so considered as a morphism in <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex>, and reuse the notation <fr:tex display="inline"><![CDATA[F,B]]></fr:tex> for these subclasses of morphism.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>7</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002A/</fr:uri>
                        <fr:display-uri>lcc-002A</fr:display-uri>
                        <fr:route>/lcc-002A/</fr:route>
                        <fr:taxon>Lemma</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[X,Y]]></fr:tex> be convex spaces and let <fr:tex display="inline"><![CDATA[A \subset  X \times  Y]]></fr:tex> be a convex subspace. Let <fr:tex display="inline"><![CDATA[f: A \to  \mathbb {R}]]></fr:tex> be a convex function.
  Then <fr:tex display="inline"><![CDATA[x \mapsto  \inf _{y: (x,y) \in  A} f(x,y)]]></fr:tex> is again convex.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>7</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
    Let <fr:tex display="inline"><![CDATA[\theta  \in  [0,1],x,x' \in  X]]></fr:tex> be given, and consider:
  </html:p>
  <fr:tex display="block"><![CDATA[inf_{y: (\theta  x + (1-\theta )x',y) \in  A}f(\theta  x + (1-\theta  x'),y).]]></fr:tex>
  <html:p>Since if <fr:tex display="inline"><![CDATA[(x,y), (x',y') \in  A]]></fr:tex> then <fr:tex display="inline"><![CDATA[(\theta  x + (1-\theta )x',\theta  y + (1-\theta )y') \in  A]]></fr:tex>, we have that this is less than:
  <fr:tex display="block"><![CDATA[\leq  \inf _{y,y': (x,y),(x',y')\in  A} f(\theta  x + (1-\theta )x', \theta  y + (1-\theta ) y'),]]></fr:tex>
  because in the latter we are taking the infimum over a smaller set of <fr:tex display="inline"><![CDATA[f]]></fr:tex>'s</html:p>
  <html:p>
    Applying convexity, we get
    <fr:tex display="block"><![CDATA[\leq  \inf _{y,y': (x,y),(x,y') \in  A} \theta  f(x,y) + (1-\theta )f(x',y')]]></fr:tex>
    <fr:tex display="block"><![CDATA[\leq  \theta  \inf _{y: (x,y) \in  A}f(x,y) + (1-\theta )\inf _{y': (x',y')\in  A} f(x',y')]]></fr:tex>
    This is precisely the desired inequality.
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>30</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-0023/</fr:uri>
                        <fr:display-uri>lcc-0023</fr:display-uri>
                        <fr:route>/lcc-0023/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter><html:p>
  The forgetful functor <fr:tex display="inline"><![CDATA[\mathsf {Minmax} \to  \mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex> is a bifibration. Moreover, we have the following description of the (co)Cartesian morphisms over backwards and forwards maps.
  <html:ol><html:li>A forwards morphism <fr:tex display="inline"><![CDATA[(\phi ,1_A): (X,A,L) \to  (Y,A,L')]]></fr:tex> is Cartesian if and only if <fr:tex display="inline"><![CDATA[L(x,a) = L'(\phi (x),a)]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x,a]]></fr:tex></html:li>
  <html:li>A forwards morphism <fr:tex display="inline"><![CDATA[(\phi ,1_A): (X,A,L) \to  (Y,A,L')]]></fr:tex> is coCartesian if and only if <fr:tex display="inline"><![CDATA[L'(y,a) = \inf _{\phi (x) = y} L(x,a)]]></fr:tex></html:li>
  <html:li>A backwards morphism <fr:tex display="inline"><![CDATA[(1_X,\phi ): (X,A,L) \to  (X,B,L')]]></fr:tex> is Cartesian if and only if <fr:tex display="inline"><![CDATA[L(x,a) = \inf _{\phi (b)=a} L'(x,b)]]></fr:tex></html:li>
  <html:li>A backwards morphism <fr:tex display="inline"><![CDATA[(1_X,\phi ): (X,A,L) \to  (X,B,L')]]></fr:tex> is coCartesian if and only if <fr:tex display="inline"><![CDATA[L'(x,b) = L(x,\phi (b))]]></fr:tex></html:li></html:ol></html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>30</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
    Note that it suffices to provide Cartesian and coCartesian lifts for backwards and forwards morphisms (<fr:link href="/lcc-0027/" title="Backwards and forwards morphisms" uri="https://erischel.com/lcc-0027/" display-uri="lcc-0027" type="local">Definition <fr:contextual-number uri="https://erischel.com/lcc-0027/" display-uri="lcc-0027" /></fr:link>), since such lifts compose. Hence it suffices to verify that the given descriptions are correct, since clearly they suffice to compute a (co)Cartesian lift over any such morphism.
  </html:p>
  <html:p>
    Note also that, since the forgetful functor is faithful, to verify a morphism <fr:tex display="inline"><![CDATA[\phi ]]></fr:tex> is (co)Cartesian, it suffices to prove that any factorization in the base lifts - uniqueness is automatic.
  </html:p>
  <html:p>Thus let <fr:tex display="inline"><![CDATA[\phi  = (\phi ,1_A): (X,A,L) \to  (Y,A,L')]]></fr:tex> be so that <fr:tex display="inline"><![CDATA[L(x,a) = L'(\phi (x),a)]]></fr:tex>. Note that composition of a <fr:tex display="inline"><![CDATA[\Delta ]]></fr:tex>-homomorphism with a convex function is again convex, so this is indeed an object of <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex></html:p>
  <html:p>
  Now let <fr:tex display="inline"><![CDATA[\psi  = (\psi ^-,\psi ^+): (Z,B,K) \to  (Y,A,L')]]></fr:tex> be some morphism so that we have the factorization <fr:tex display="inline"><![CDATA[\psi  = \phi \psi ']]></fr:tex> in <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta \times \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex>. The goal is now to prove <fr:tex display="inline"><![CDATA[\psi ' : (Z,B,K) \to  (X,A,L)]]></fr:tex> is a homomorphism. This is the inequality
  <fr:tex display="block"><![CDATA[K(z,(\psi ')^-(a)) \geq  L((\psi ')^+(z),a) = L'((\phi \psi ')^+(z),a),]]></fr:tex> which holds by assumption</html:p>

  <html:p>Let <fr:tex display="inline"><![CDATA[\phi ]]></fr:tex> be as above, but suppose <fr:tex display="inline"><![CDATA[L'(y,a) = \inf {\phi (x)=y}L(x,a)]]></fr:tex>. First, observe that by <fr:link href="/lcc-002A/" title="https://erischel.com/lcc-002A/" uri="https://erischel.com/lcc-002A/" display-uri="lcc-002A" type="local">lcc-002A</fr:link>, this function is in fact convex in <fr:tex display="inline"><![CDATA[y]]></fr:tex> as desired.</html:p>
  <html:p>
    Let <fr:tex display="inline"><![CDATA[\psi : (X,A,L) \to  (Z,B,K)]]></fr:tex> be given, and now suppose we have a factorization <fr:tex display="inline"><![CDATA[\psi  = \psi '\phi ]]></fr:tex> in the base. We must prove that <fr:tex display="inline"><![CDATA[L'(y,(\psi ')^-(b)) \geq  K((\psi ')^+(y),b),]]></fr:tex>
    but since <fr:tex display="inline"><![CDATA[L'(y,(\psi ')^-(b)) = \inf _{\phi (x)=y}L(x,(\psi ')^-(b)),]]></fr:tex> this amounts to the equation
    <fr:tex display="inline"><![CDATA[L(x,(\psi ')^-(b)) \geq  K((\psi ')^+\phi (x),b),]]></fr:tex>
    which is again true by assumption.
  </html:p>
  <html:p>Now the case for backwards morphisms simply follows by duality.</html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter>
                    </fr:tree>
                    <html:p>
    What's "really" going on here is that <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex> is a two-sided fibration, the result of taking the functor <fr:tex display="inline"><![CDATA[\mathsf {Set}^{\Delta ,\mathrm {op}} \times  \mathsf {Set}^{\Delta ,\mathrm {op}} \to  \mathsf {Cat}]]></fr:tex> carrying a pair <fr:tex display="inline"><![CDATA[X,Y]]></fr:tex> to the poset of minmax problems <fr:tex display="inline"><![CDATA[L: X \times  Y \to  \mathbb {R}]]></fr:tex> (in the opposite order), with morphisms acting by precomposition, and applying the Grothendieck construction "contravariantly in the first variable and covariantly in the second variable". (And then observing that the precomposition action has left/right adjoints given by <fr:tex display="inline"><![CDATA[\inf ]]></fr:tex>/<fr:tex display="inline"><![CDATA[\sup ]]></fr:tex>, to make this into a <html:em>bi</html:em>fibration). But the theory of two-sided fibrations is quite complicated in general, and we will not go into it here.
  </html:p>
                    <html:p>
    Note also that this functor is quite close to displaying <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex> as <html:em>topological</html:em>. If we remove the restriction that minmax problems be convex/concave, we can construct the universal lifts required using a similar supremum formula. The problem is that the supremum of a general set of concave functions is not automatically concave (however, the supremum taken over a convex set, in a suitable sense, is).
  </html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001R/</fr:uri>
                        <fr:display-uri>lcc-001R</fr:display-uri>
                        <fr:route>/lcc-001R/</fr:route>
                        <fr:title text="\Conv  and \Conc "><fr:tex display="inline"><![CDATA[\Conv ]]></fr:tex> and <fr:tex display="inline"><![CDATA[\Conc ]]></fr:tex></fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Let <fr:tex display="inline"><![CDATA[\mathsf {Conv}]]></fr:tex> be the category where objects are pairs <fr:tex display="inline"><![CDATA[(X,f: X \to  \mathbb {R})]]></fr:tex> consisting of a convex space and a convex function, and where morphisms <fr:tex display="inline"><![CDATA[\phi : (X,f) \to  (Y,g)]]></fr:tex> are affine maps so that <fr:tex display="inline"><![CDATA[g(\phi (x)) \leq  f(x)]]></fr:tex>.
</html:p>
                        <html:p>
    Let <fr:tex display="inline"><![CDATA[\mathsf {Conc}]]></fr:tex> be the category where objects are pairs <fr:tex display="inline"><![CDATA[(X,f: X \to  \mathbb {R})]]></fr:tex> consisting of a convex space and a concave function, and where morphisms <fr:tex display="inline"><![CDATA[\phi : (X,f) \to  (Y,g)]]></fr:tex> are affine maps so that <fr:tex display="inline"><![CDATA[g(\phi (x)) \geq  f(x)]]></fr:tex>.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001S/</fr:uri>
                        <fr:display-uri>lcc-001S</fr:display-uri>
                        <fr:route>/lcc-001S/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    The assignment
    <fr:tex display="block"><![CDATA[(X,Y,L) \mapsto  (X,L^+),]]></fr:tex>
    <fr:tex display="block"><![CDATA[(\phi ^+,\phi ^-): L \to  L' \mapsto  \phi ^+]]></fr:tex>
    defines a functor <fr:tex display="inline"><![CDATA[(-)^+: \mathsf {Minmax} \to  \mathsf {Conv}]]></fr:tex></html:p>
                        <html:p>
    Similarly, <fr:tex display="inline"><![CDATA[(-)^-]]></fr:tex> defines a functor <fr:tex display="inline"><![CDATA[\mathsf {Minmax} \to  \mathsf {Conc}^\mathrm {op}]]></fr:tex>. (The reason for this idiosyncratic way of writing a contravariant functor will become apparent in a minute)
</html:p>
                        <html:p>
    The assignment <fr:tex display="inline"><![CDATA[(X,f) \mapsto  (X,-f)]]></fr:tex> defines a functor (identity on morphisms) <fr:tex display="inline"><![CDATA[\mathsf {Conc} \to  \mathsf {Conv}]]></fr:tex>, and vice versa. Then <fr:tex display="inline"><![CDATA[L^- = -(L^*)^+]]></fr:tex></html:p>
                        <html:p>
    The assignment <fr:tex display="inline"><![CDATA[(X,f) \mapsto  (X,*, f)]]></fr:tex> defines a fully faithful functor <fr:tex display="inline"><![CDATA[\mathsf {Conv} \to  \mathsf {Minmax}]]></fr:tex>,
    whose essential image consists of those tuples <fr:tex display="inline"><![CDATA[(X,Y,L)]]></fr:tex> where <fr:tex display="inline"><![CDATA[Y]]></fr:tex> is singleton.
    Analogously, <fr:tex display="inline"><![CDATA[(Y,f) \mapsto  (*,Y,f)]]></fr:tex> defines a fully faithful functor <fr:tex display="inline"><![CDATA[\mathsf {Conc}^\mathrm {op} \to  \mathsf {Minmax}]]></fr:tex></html:p>
                        <html:p>
    We will abuse notation and identify <fr:tex display="inline"><![CDATA[\mathsf {Conv}]]></fr:tex> and <fr:tex display="inline"><![CDATA[\mathsf {Conc}]]></fr:tex> with their images under these inclusions - thus, for example, <fr:tex display="inline"><![CDATA[L^+]]></fr:tex> will be regarded as an object of <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex>.
</html:p>
                        <html:p><fr:tex display="inline"><![CDATA[(-)^+]]></fr:tex> is right adjoint to the inclusion of <fr:tex display="inline"><![CDATA[\mathsf {Conv}]]></fr:tex>, and <fr:tex display="inline"><![CDATA[(-)^-]]></fr:tex> (viewed as a functor <fr:tex display="inline"><![CDATA[\mathsf {Minmax} \to  \mathsf {Conc}^\mathrm {op}]]></fr:tex>) is left adjoint to the inclusion of <fr:tex display="inline"><![CDATA[\mathsf {Conc}^\mathrm {op}]]></fr:tex></html:p>
                        <html:p>
    Using these identifications, we have <fr:tex display="inline"><![CDATA[(-)^- = (((-)^*)^+)^*]]></fr:tex></html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>
    Note that if <fr:tex display="inline"><![CDATA[\phi  = (\phi ^+,\phi ^-): L \to  L']]></fr:tex> is a morphism of <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex>, the two meanings of the notation <fr:tex display="inline"><![CDATA[\phi ^+]]></fr:tex> agree, and the same is true of <fr:tex display="inline"><![CDATA[\phi ^-]]></fr:tex>.
  </html:p>
                    <html:p>
    Note also that the reflexive subcategory <fr:tex display="inline"><![CDATA[\mathsf {Conc}^\mathrm {op} \subseteq  \mathsf {Minmax}]]></fr:tex> is the local subcategory with respect to the forwards morphisms - a morphism is forward if and only if <fr:tex display="inline"><![CDATA[\phi ^-]]></fr:tex> is an isomorphism (by definition), and the unit <fr:tex display="inline"><![CDATA[L \to  L^-]]></fr:tex> is the terminal forwards morphism with domain <fr:tex display="inline"><![CDATA[L]]></fr:tex>. A dual statement holds for <fr:tex display="inline"><![CDATA[\mathsf {Conv} \subseteq  \mathsf {Minmax}]]></fr:tex> (it is the <html:em>colocalization</html:em> with respect to the class of backwards morphisms).
  </html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>23</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001N/</fr:uri>
                        <fr:display-uri>lcc-001N</fr:display-uri>
                        <fr:route>/lcc-001N/</fr:route>
                        <fr:title text="Monoidal structure on minmax problems">Monoidal structure on minmax problems</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    There is a monoidal structure on minmax problems, given by
    <fr:tex display="inline"><![CDATA[(L \otimes  L') = (X \otimes  X', Y \otimes  Y', (x,x',y,y') \mapsto  L(x,y) + L(x',y')).]]></fr:tex>
    The unit here is <fr:tex display="inline"><![CDATA[(*,*,0)]]></fr:tex>.
</html:p>
                        <html:p>
    A state is a point <fr:tex display="inline"><![CDATA[x_0]]></fr:tex> so that <fr:tex display="inline"><![CDATA[L(x_0,y) \leq  0]]></fr:tex> for all <fr:tex display="inline"><![CDATA[y]]></fr:tex>.
    More interesting is asking for a state of <fr:tex display="inline"><![CDATA[L \otimes  L^*]]></fr:tex>.
    This is a pair <fr:tex display="inline"><![CDATA[x \in  X, y \in  Y]]></fr:tex> so that the inequality
    <fr:tex display="inline"><![CDATA[L(x,y') \leq  L(x',y)]]></fr:tex> holds for all <fr:tex display="inline"><![CDATA[y',x']]></fr:tex></html:p>
                        <html:p>
    Note that <fr:tex display="inline"><![CDATA[\sup _{y'} L(x,y') \geq  \inf _x L(x',y)]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x,y]]></fr:tex>, this is the minmax inequality (or "weak duality").
</html:p>
                        <html:p>
    Thus a choice of <fr:tex display="inline"><![CDATA[x,y]]></fr:tex> giving a state gives equality in that inequation---it is a <html:em>solution</html:em> of the minmax game. In other words, <fr:tex display="inline"><![CDATA[L \otimes  L^*]]></fr:tex> has a state if and only if strong duality holds for <fr:tex display="inline"><![CDATA[L]]></fr:tex>, and the state is given by an optimal and dual optimal pair in that case. 
</html:p>
                        <html:p>
    (By duality, and since <fr:tex display="inline"><![CDATA[(L \otimes  L^*)^* \cong  L \otimes  L^*]]></fr:tex>, such an object has a state if and only if it has a costate)
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>8</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002D/</fr:uri>
                        <fr:display-uri>lcc-002D</fr:display-uri>
                        <fr:route>/lcc-002D/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  The forgetful functor <fr:tex display="inline"><![CDATA[\mathsf {Minmax} \to  \mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}}]]></fr:tex> is a monoidal fibration, in the sense of <fr:link href="/shulman-monfibs/" title="Framed bicategories and monoidal fibrations" uri="https://erischel.com/shulman-monfibs/" display-uri="shulman-monfibs" type="local">Reference <fr:contextual-number uri="https://erischel.com/shulman-monfibs/" display-uri="shulman-monfibs" /></fr:link>, (see also <fr:link href="/moeller-vasilakopoulou/" title="Monoidal Grothendieck Construction" uri="https://erischel.com/moeller-vasilakopoulou/" display-uri="moeller-vasilakopoulou" type="local">Reference <fr:contextual-number uri="https://erischel.com/moeller-vasilakopoulou/" display-uri="moeller-vasilakopoulou" /></fr:link>). It is also a monoidal opfibration - in other words, both the classes of Cartesian and coCartesian maps are stable under tensor product.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>In the case of a Cartesian base, a monoidal fibration (like the one we have here) is equivalent to a fibration with a monoidal structure on each fiber, compatible with the reindexing in a certain way. Our base is not Cartesian, but does seem to come from a monoidal structure on each fiber, given by addition of <fr:tex display="inline"><![CDATA[L]]></fr:tex>s. The point is that, given <fr:tex display="inline"><![CDATA[(X,A,L)]]></fr:tex>, there is a canonical way to obtain an <fr:tex display="inline"><![CDATA[L]]></fr:tex> on <fr:tex display="inline"><![CDATA[(X\times  Y, A \times  B)]]></fr:tex>, given by using a Cartesian lift of <fr:tex display="inline"><![CDATA[X \times  Y \to  X]]></fr:tex> and a <html:em>coCartesian</html:em> lift of <fr:tex display="inline"><![CDATA[A \times  B \to  A]]></fr:tex>. This suggests there should be a useful theory of <html:em>monoidal two-sided fibrations</html:em>, but this notion does not appear to have been studied before.</html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>5</fr:month>
                          <fr:day>19</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-002P/</fr:uri>
                        <fr:display-uri>lcc-002P</fr:display-uri>
                        <fr:route>/lcc-002P/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  The localization (resp. colocalization) <fr:tex display="inline"><![CDATA[\mathsf {Conc}^\mathrm {op} \hookrightarrow  \mathsf {Minmax}]]></fr:tex> (<fr:tex display="inline"><![CDATA[\mathsf {Conv} \hookrightarrow  \mathsf {Minmax}]]></fr:tex>) is monoidal, in the sense that the class local equivalences is stable under tensor products. The thus induced monoidal structure on <fr:tex display="inline"><![CDATA[\mathsf {Conc}^\mathrm {op}]]></fr:tex> is given by <fr:tex display="inline"><![CDATA[(X,f) \otimes  (Y,g) = (X \times  Y, (x,y) \mapsto  f(x) + g(y))]]></fr:tex> (and the same for <fr:tex display="inline"><![CDATA[\mathsf {Conv}]]></fr:tex>). In particular the (co)localization functor is strong monoidal.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="Strong duality">Strong duality</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>26</fr:day></fr:date><fr:uri>https://erischel.com/lcc-001W/</fr:uri><fr:display-uri>lcc-001W</fr:display-uri><fr:route>/lcc-001W/</fr:route><fr:title text="weak duality">weak duality</fr:title><fr:taxon>Proposition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
    Let <fr:tex display="inline"><![CDATA[L]]></fr:tex> be a minmax problem.
    Then
    <fr:tex display="block"><![CDATA[\inf _x \sup _y L(x,y) = (L^+)^- \geq  (L^-)^+ = \sup _x \inf _y L(x,y),]]></fr:tex>
    where we abuse notation by identifying a minmax problem <fr:tex display="inline"><![CDATA[*,*, r]]></fr:tex> with the number <fr:tex display="inline"><![CDATA[r(*,*)]]></fr:tex></html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>26</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
    <html:p>
        The equations are clearly true by definition.
        Note that the inequality is equivalent to the existence of a morphism <fr:tex display="inline"><![CDATA[(L^+)^- \to  (L^-)^+]]></fr:tex></html:p>
    <html:p>
        We have canonical morphisms
        <fr:tex display="block"><![CDATA[L^+ \to  L \to  L^-]]></fr:tex>
        Since <fr:tex display="inline"><![CDATA[L^+]]></fr:tex> is a right adjoint to the inclusion of <fr:tex display="inline"><![CDATA[\mathsf {Conv}]]></fr:tex>, the above composite induces a map
        <fr:tex display="inline"><![CDATA[L^+ \to  (L^-)^+]]></fr:tex></html:p>
    <html:p>
        Since <fr:tex display="inline"><![CDATA[(-)^-]]></fr:tex> is a left adjoint to the inclusion of <fr:tex display="inline"><![CDATA[\mathsf {Conc}^\mathrm {op}]]></fr:tex>, that map induces a map
        <fr:tex display="inline"><![CDATA[(L^+)^- \to  (L^-)^+,]]></fr:tex> as desired.
    </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>9</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002F/</fr:uri><fr:display-uri>lcc-002F</fr:display-uri><fr:route>/lcc-002F/</fr:route><fr:title text="Strong duality">Strong duality</fr:title><fr:taxon>Definition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[L = (X,A,L)]]></fr:tex> be a minmax problem. By <fr:link href="/lcc-001W/" title="weak duality" uri="https://erischel.com/lcc-001W/" display-uri="lcc-001W" type="local">Proposition <fr:contextual-number uri="https://erischel.com/lcc-001W/" display-uri="lcc-001W" /></fr:link>, there is a morphism
  <fr:tex display="inline"><![CDATA[(L^+)^- \to  (L^-)^+]]></fr:tex>. We say <fr:tex display="inline"><![CDATA[L]]></fr:tex> <html:em>satisfies strong duality</html:em> if it is an isomorphism. (Note that this is really just an inequality of real numbers, which must be an equality).
</html:p></fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>26</fr:day></fr:date><fr:uri>https://erischel.com/lcc-001X/</fr:uri><fr:display-uri>lcc-001X</fr:display-uri><fr:route>/lcc-001X/</fr:route><fr:taxon>Proposition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
    Let <fr:tex display="inline"><![CDATA[L]]></fr:tex> be a minmax problem.
    Suppose there exists <fr:tex display="inline"><![CDATA[\phi : I \to  L \otimes  L^*]]></fr:tex>.
    Then strong duality holds, i.e <fr:tex display="inline"><![CDATA[(L^+)^- \cong  (L^-)^+]]></fr:tex></html:p><html:p><fr:tex display="inline"><![CDATA[((\phi )^+)^-]]></fr:tex> gives a morphism
    <fr:tex display="block"><![CDATA[I = (I^+)^- \to  ((L \otimes  L^*)^+)^- \cong  (L^+)^- \otimes  ((L^*)^+)^- \cong  (L^+)^- \otimes  ((L^-)^+)^*]]></fr:tex>
    Here we use the isomorphisms <fr:tex display="inline"><![CDATA[(L^+)^* = (L^*)^-]]></fr:tex> and vice versa, as well as strong monoidality of <fr:tex display="inline"><![CDATA[(-)^-]]></fr:tex> and <fr:tex display="inline"><![CDATA[(-)^+]]></fr:tex>.
    The existence of that morphism means that
    <fr:tex display="inline"><![CDATA[(L^+)^- \leq  (L^-)^+,]]></fr:tex>
    which is the other direction of the morphism we wanted.
</html:p></fr:mainmatter></fr:tree><html:p>
    If a minmax problem is a zero-sum game, a point <fr:tex display="inline"><![CDATA[I \to  L \otimes  L^*]]></fr:tex> is a choice of Nash equilibrium for this game.
  </html:p><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>6</fr:day></fr:date><fr:uri>https://erischel.com/lcc-0029/</fr:uri><fr:display-uri>lcc-0029</fr:display-uri><fr:route>/lcc-0029/</fr:route><fr:taxon>Proposition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[(X,Y,L)]]></fr:tex> be a minmax problem.
  Then there is a canonical commutative diagram
  
  <html:figure><fr:resource hash="ac36f89b6d448b7a687486c39b81e6c3"><fr:resource-content><html:img src="/ac36f89b6d448b7a687486c39b81e6c3.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
    \begin {tikzcd}
    (X,*) \ar [r, "\pi _X"] \ar [d, "\pi _A"] & (*,*)\ar [d, "\pi _A"]\\
    (X,A) \ar [r, "\pi _X"] & (*,A)
    \end {tikzcd}
  ]]></fr:resource-source></fr:resource></html:figure>

  in <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}},]]></fr:tex> which is a pullback.
  <fr:tex display="inline"><![CDATA[L]]></fr:tex> obeys strong duality if and only if this square has the local Beck-Chevalley condition for <fr:tex display="inline"><![CDATA[L]]></fr:tex>, in the sense that the canonical map <fr:tex display="inline"><![CDATA[\pi _{X,!}\pi _A^*L \to  \pi _A^*\pi _{X,!}L]]></fr:tex> is an isomorphism.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>6</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  Recall that <fr:tex display="inline"><![CDATA[\pi _{X,!}(L) = L^-, \pi _Y^*(L) = L^+]]></fr:tex>.
  Hence the claim is just that <fr:tex display="inline"><![CDATA[\inf _x \sup _a L(x,a) = (L^+)^- = (L^-)^+ = \sup _a\inf _x L(x,a),]]></fr:tex> which is precisely strong duality.
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree>(For more on the Beck-Chevalley condition, see <fr:link href="/pavlovic-descent-beck-chevalley-1991/" title="Categorical interpolation: Descent and the Beck-Chevalley condition without direct images" uri="https://erischel.com/pavlovic-descent-beck-chevalley-1991/" display-uri="pavlovic-descent-beck-chevalley-1991" type="local">Reference <fr:contextual-number uri="https://erischel.com/pavlovic-descent-beck-chevalley-1991/" display-uri="pavlovic-descent-beck-chevalley-1991" /></fr:link> or <fr:link href="https://ncatlab.org/nlab/show/Beck-Chevalley+condition" type="external">nlab: Beck-Chevalley Condition</fr:link>)<fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>18</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002L/</fr:uri><fr:display-uri>lcc-002L</fr:display-uri><fr:route>/lcc-002L/</fr:route><fr:title text="Slater's Constraint Qualification">Slater's Constraint Qualification</fr:title><fr:taxon>Proposition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Consider an optimization problem in standard form:
  <html:ol><html:li>Minimize <fr:tex display="inline"><![CDATA[f_0(x), x \in  \mathbb {R}^k]]></fr:tex></html:li>
    <html:li>Subject to <fr:tex display="inline"><![CDATA[f_1(x), \dots , f_n(x) \leq  0]]></fr:tex></html:li>
    <html:li>And <fr:tex display="inline"><![CDATA[g_1(x), \dots , g_m(x) = 0]]></fr:tex></html:li>
    <html:li>With each <fr:tex display="inline"><![CDATA[f_i]]></fr:tex> convex and each <fr:tex display="inline"><![CDATA[g_i]]></fr:tex> affine</html:li></html:ol>
  Now assume that <fr:tex display="inline"><![CDATA[l]]></fr:tex> is such that <fr:tex display="inline"><![CDATA[f_1, \dots , f_l]]></fr:tex> are all affine (possibly <fr:tex display="inline"><![CDATA[l=0]]></fr:tex>, and none of the <fr:tex display="inline"><![CDATA[f_i]]></fr:tex> are affine), and suppose there exists <fr:tex display="inline"><![CDATA[x_0 \in  \mathbb {R}^k]]></fr:tex> so that <fr:tex display="inline"><![CDATA[f_i(x) < 0]]></fr:tex> for all <fr:tex display="inline"><![CDATA[i > l]]></fr:tex>, and <fr:tex display="inline"><![CDATA[f_i(x) \leq  0]]></fr:tex> for all other <fr:tex display="inline"><![CDATA[i]]></fr:tex>, <fr:tex display="inline"><![CDATA[g_i(x) = 0]]></fr:tex> for all <fr:tex display="inline"><![CDATA[i]]></fr:tex>. Then strong duality holds for this optimization problem, and the dual optimal value is attained.
</html:p><html:p>
  Note: This is usually stated for a function defined on an arbitrary convex subset of <fr:tex display="inline"><![CDATA[\mathbb {R}^k]]></fr:tex>. In this case we must further ask that <fr:tex display="inline"><![CDATA[x_0]]></fr:tex> is in the relative interior of this domain.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>18</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>(Proof adapted from )</html:p>
  <html:p>For simplicity, we will assume <fr:tex display="inline"><![CDATA[l = 0]]></fr:tex>, i.e we will not assume any of the <fr:tex display="inline"><![CDATA[f_i]]></fr:tex> are affine, and <fr:tex display="inline"><![CDATA[f_u(x_0) \leq  0]]></fr:tex> for all <fr:tex display="inline"><![CDATA[i \geq  1]]></fr:tex>. (This is the standard form of Slater's constraint qualification).</html:p>
  <html:p>
    Let <fr:tex display="inline"><![CDATA[A, b]]></fr:tex> be a matrix and vector so that <fr:tex display="inline"><![CDATA[(g_i(x)) = Ax - b]]></fr:tex>. Then assume without loss of generality that <fr:tex display="inline"><![CDATA[A]]></fr:tex> has full rank. (Suppose <fr:tex display="inline"><![CDATA[g_j]]></fr:tex> is in the span of the other <fr:tex display="inline"><![CDATA[g_i]]></fr:tex>s. Then if the affine constraints are feasible at all, the equation corresponding to <fr:tex display="inline"><![CDATA[g_j]]></fr:tex> must be a consequence of the others. Hence we can delete <fr:tex display="inline"><![CDATA[g_j]]></fr:tex> without altering the primal optimal value, and given a dual optimal value for the problem with <fr:tex display="inline"><![CDATA[g_j]]></fr:tex> deleted, just set <fr:tex display="inline"><![CDATA[\nu _j = 0]]></fr:tex>.)
  </html:p>
  <html:p>
    Let <fr:tex display="block"><![CDATA[\mathcal {A} = \{(u,v,t) \mid  x \in  \mathbb {R}^k, u_i \geq  f_i(x), v_i = g_i(x), t \geq  f_0(x)\}]]></fr:tex>
    Observe that the optimal value is <fr:tex display="inline"><![CDATA[p^* = \inf _{(0,0,t) \in  \mathcal {A}} t]]></fr:tex>.
    Let <fr:tex display="inline"><![CDATA[\mathcal {B} = \{(0,0,t) \mid  s \leq  p^*\}]]></fr:tex>. It's not hard to see that these sets are disjoint and convex, and hence there exists a hyperplane separating them.
    In other words, there exists <fr:tex display="inline"><![CDATA[\tilde {\lambda },\tilde {\nu },\tilde {\mu },\alpha ]]></fr:tex> (not all <fr:tex display="inline"><![CDATA[0]]></fr:tex>) so that
    <fr:tex display="block"><![CDATA[(u,v,t) \in  \mathcal {A} \Rightarrow  \langle  \tilde {\lambda },u \rangle  + \langle  \tilde {\nu },v \rangle  + \mu  t \geq  \alpha ]]></fr:tex>
    <fr:tex display="block"><![CDATA[(u,v,t) \in  \mathcal {B} \Rightarrow  \langle  \tilde {\lambda },u \rangle  + \langle  \tilde {\nu },v \rangle  + \mu  t \leq  \alpha ]]></fr:tex>
    By the first inequality, we must have <fr:tex display="inline"><![CDATA[\tilde {\lambda } \geq  0]]></fr:tex> (or the right-hand side would be unbounded below on <fr:tex display="inline"><![CDATA[\mathcal {A}]]></fr:tex>, which is impossible). Similarly we have <fr:tex display="inline"><![CDATA[\mu  \geq  0]]></fr:tex>.
    The latter of the two statements is equivalent to the statement that <fr:tex display="inline"><![CDATA[\mu  t \leq  \alpha ]]></fr:tex> when <fr:tex display="inline"><![CDATA[t \leq  p^*]]></fr:tex>, which simply means <fr:tex display="inline"><![CDATA[\mu  p^* \leq  \alpha ]]></fr:tex>. Combining this with the first statement,
    we get for all <fr:tex display="inline"><![CDATA[x,]]></fr:tex>
    <fr:tex display="block"><![CDATA[\sum _i \tilde {\lambda }_i f_i(x) + \sum _i \tilde {nu}_i g_i(x) + \mu  f_0(x) \geq  \alpha  \geq  \mu  p^*.]]></fr:tex></html:p>
  <html:p>
    First assume <fr:tex display="inline"><![CDATA[\mu  \neq  0]]></fr:tex>. Then we can divide out and get <fr:tex display="inline"><![CDATA[L(x, \tilde {\lambda }/\mu , \tilde {\nu }/\mu ) \geq  p^*]]></fr:tex>, which proves that <fr:tex display="inline"><![CDATA[(\tilde {\lambda }/\mu , \tilde {\nu }/\mu )]]></fr:tex> is a dual optimal value and that strong duality holds.
  </html:p>
  <html:p>
    If <fr:tex display="inline"><![CDATA[\mu =0]]></fr:tex>, we have for all <fr:tex display="inline"><![CDATA[x]]></fr:tex>
    <fr:tex display="block"><![CDATA[\sum _i \tilde {\lambda }_i f_i(x) + \sum _i \tilde {nu}_i g_i(x) \geq  0]]></fr:tex></html:p>
  <html:p>
    Inserting <fr:tex display="inline"><![CDATA[x_0]]></fr:tex>, we find <fr:tex display="inline"><![CDATA[\sum _i \tilde {\lambda }_i f_i(x_0) \geq  0,]]></fr:tex>
    and since <fr:tex display="inline"><![CDATA[f_i(x_0) = 0,]]></fr:tex> we must have <fr:tex display="inline"><![CDATA[\tilde {\lambda } = 0]]></fr:tex>.
    This then implies <fr:tex display="inline"><![CDATA[\sum _i \tilde {\nu }_i g_i(x) \geq  0 = \langle  \tilde {nu},Ax - b \rangle ]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x]]></fr:tex>. But since this is an affine function, this can only be true if it's constantly zero. Since <fr:tex display="inline"><![CDATA[\tilde {\nu }]]></fr:tex> is nonzero and <fr:tex display="inline"><![CDATA[A]]></fr:tex> has full rank, this is impossible.
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>22</fr:day></fr:date><fr:uri>https://erischel.com/lcc-001E/</fr:uri><fr:display-uri>lcc-001E</fr:display-uri><fr:route>/lcc-001E/</fr:route><fr:title text="Minimax theorem">Minimax theorem</fr:title><fr:taxon>Theorem</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
    Let <fr:tex display="inline"><![CDATA[(L,X,A) \in  \mathsf {Minmax}]]></fr:tex>. If <fr:tex display="inline"><![CDATA[X,A]]></fr:tex> are both convex, compact subspaces of finite-dimensional vector spaces, and <fr:tex display="inline"><![CDATA[L]]></fr:tex> is continuous, then strong duality holds for <fr:tex display="inline"><![CDATA[L]]></fr:tex>, and moreover an equilibrium <fr:tex display="inline"><![CDATA[I \to  L \otimes  L^*]]></fr:tex> exists.
</html:p></fr:mainmatter></fr:tree><html:p>
        This theorem can be derived from the Kakutani fixpoint theorem in a very similar way to the usual proof of Nash's theorem about general, non-zerosum games - although note that it is not a special case, since <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[A]]></fr:tex> may not be simplices, and the payoff function here is merely convex, not necessarily <html:em>affine</html:em> as it is for a game-theoretic game.
  </html:p><html:p>
    However, we will give a different proof, which uses the structure of <fr:tex display="inline"><![CDATA[\mathsf {Minmax}]]></fr:tex> in a more direct way. Essentially, we will use compactness to reduce to the case of simplexes, then use an inductive argument to reduce to the case where <fr:tex display="inline"><![CDATA[X = A = \Delta ^1 = [0,1],]]></fr:tex> which can be shown by a direct topological argument. The inductive step is a fiber sequence argument, where we use the characterization of strong duality in terms of the Beck-Chevalley property, <fr:link href="/lcc-0029/" title="https://erischel.com/lcc-0029/" uri="https://erischel.com/lcc-0029/" display-uri="lcc-0029" type="local">Proposition <fr:contextual-number uri="https://erischel.com/lcc-0029/" display-uri="lcc-0029" /></fr:link>.
  </html:p><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002T/</fr:uri><fr:display-uri>lcc-002T</fr:display-uri><fr:route>/lcc-002T/</fr:route><fr:title text="Solvable pair">Solvable pair</fr:title><fr:taxon>Definition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[X,A]]></fr:tex> be <fr:link href="/lcc-002U/" title="Topological convex space" uri="https://erischel.com/lcc-002U/" display-uri="lcc-002U" type="local">topological convex spaces</fr:link>. We say the pair <fr:tex display="inline"><![CDATA[(X,A)]]></fr:tex> is a <html:em>solvable pair</html:em> if, for any continuous minmax problem <fr:tex display="inline"><![CDATA[L: X \times  A \to  \mathbb {R}]]></fr:tex>, strong duality holds.
</html:p></fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002V/</fr:uri><fr:display-uri>lcc-002V</fr:display-uri><fr:route>/lcc-002V/</fr:route><fr:taxon>Proposition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  The pair <fr:tex display="inline"><![CDATA[([0,1],[0,1])]]></fr:tex> (in other words, <fr:tex display="inline"><![CDATA[(\Delta ^1,\Delta ^1)]]></fr:tex>) is solvable.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
    Let <fr:tex display="inline"><![CDATA[L: [0,1] \times  [0,1] \to  \mathbb {R}]]></fr:tex> be a continuous minmax problem. Suppose strong duality does not hold. Then by adding a constant to <fr:tex display="inline"><![CDATA[L]]></fr:tex>, we can arrange that
    <fr:tex display="block"><![CDATA[\sup _\theta  \inf _s L(s,\theta ) < 0 < \inf _s \sup _\theta  L(s,\theta ).]]></fr:tex></html:p>
  <html:p>
        Consider the set <fr:tex display="inline"><![CDATA[P = \{(s,\theta ) \mid  L(s,\theta ) > 0\}]]></fr:tex>. Since we must have <fr:tex display="inline"><![CDATA[\sup _\theta  L(s,\theta ) > 0]]></fr:tex> for each <fr:tex display="inline"><![CDATA[s]]></fr:tex>, the first projection <fr:tex display="inline"><![CDATA[P \to  [0,1]]]></fr:tex> must be surjective. Since each fiber is convex, and hence connected, and the projection <fr:tex display="inline"><![CDATA[[0,1] \times  [0,1] \to  [0,1]]]></fr:tex> is open, <fr:tex display="inline"><![CDATA[P]]></fr:tex> is connected. As an open connected subset of a convex space, it is path connected. Hence there exists some path <fr:tex display="inline"><![CDATA[\gamma (t) \in  P]]></fr:tex> where <fr:tex display="inline"><![CDATA[\gamma (0) = (0,\theta _0)]]></fr:tex> and <fr:tex display="inline"><![CDATA[\gamma (1) = (1,\theta _1)]]></fr:tex>. In other words (picturing the square with the first coordinate horizontal), there exists a path from the left to the right side of the cube so that <fr:tex display="inline"><![CDATA[L(\gamma (t)) > 0]]></fr:tex> everywhere on the path. Dually, there also exists a path from top to bottom so that <fr:tex display="inline"><![CDATA[L]]></fr:tex> is strictly negative everywhere on that path. But they must intersect somewhere, and this is a contradiction. Hence <fr:tex display="inline"><![CDATA[L]]></fr:tex> must have a state or a costate, finishing the proof.   
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002W/</fr:uri><fr:display-uri>lcc-002W</fr:display-uri><fr:route>/lcc-002W/</fr:route><fr:taxon>Proposition</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[E \to  B]]></fr:tex> be a continuous, affine map between topological convex spaces. Let <fr:tex display="inline"><![CDATA[A]]></fr:tex> be another topological convex space, and suppose
  <html:ul><html:li><fr:tex display="inline"><![CDATA[(B,A)]]></fr:tex> is solvable.</html:li>
    <html:li>For every <fr:tex display="inline"><![CDATA[b \in  B]]></fr:tex>, <fr:tex display="inline"><![CDATA[(E_b,A)]]></fr:tex> is solvable, where <fr:tex display="inline"><![CDATA[E_b \subseteq  E]]></fr:tex> is the fiber.</html:li></html:ul>
  Then also <fr:tex display="inline"><![CDATA[(E,A)]]></fr:tex> is solvable. 
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
  Recall that <fr:tex display="inline"><![CDATA[(E,A)]]></fr:tex> being solvable means the following square has the Beck-Chevalley condition for continuous <fr:tex display="inline"><![CDATA[L]]></fr:tex>:</html:p>
  
  <html:figure><fr:resource hash="49d962fd2e7a213b00b44cee9ccd9225"><fr:resource-content><html:img src="/49d962fd2e7a213b00b44cee9ccd9225.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
    \begin {tikzcd}
      (E,*) \ar [d] \ar [r] & (*,*) \ar [d]\\
      (E,A) \ar [r] & (*, A)
    \end {tikzcd}
  ]]></fr:resource-source></fr:resource></html:figure>

  <html:p>Now we can factor this as follows:</html:p>
  
  <html:figure><fr:resource hash="d34d1240fb8857d719146be3e1d35f60"><fr:resource-content><html:img src="/d34d1240fb8857d719146be3e1d35f60.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
    \begin {tikzcd}
      (E,*) \ar [d] \ar [r] & (B,*) \ar [r] \ar [d] & (*,*) \ar [d]\\
      (E,A) \ar [r] & (B,A) \ar [r] & (*, A)
    \end {tikzcd}
  ]]></fr:resource-source></fr:resource></html:figure>

  <html:p>
    Note that the right-hand square here has the Beck-Chevalley condition by assumption. So it suffices to show the left-hand square does. For a given <fr:tex display="inline"><![CDATA[L]]></fr:tex>, this means showing that these two functions on <fr:tex display="inline"><![CDATA[B]]></fr:tex> are the same
    <fr:tex display="block"><![CDATA[b \mapsto  \inf _{e \mapsto  b} \sup _a L(e,a)]]></fr:tex>
    <fr:tex display="block"><![CDATA[b \mapsto  \sup _a \inf _{e \mapsto  b} L(e,a)]]></fr:tex>
    But this equation, for some given <fr:tex display="inline"><![CDATA[b]]></fr:tex>, is exactly strong duality in the restriction of <fr:tex display="inline"><![CDATA[L]]></fr:tex> to <fr:tex display="inline"><![CDATA[(E_b,A)]]></fr:tex>, which must hold because this is a solvable pair by assumption.
  </html:p>
</fr:mainmatter></fr:tree>
<fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:title text="Corollary">Corollary</fr:title></fr:frontmatter><fr:mainmatter><html:p>
    If <fr:tex display="inline"><![CDATA[(X,[0,1])]]></fr:tex> is solvable, so is <fr:tex display="inline"><![CDATA[(X,\Delta ^n)]]></fr:tex> for each <fr:tex display="inline"><![CDATA[n]]></fr:tex>, because the map <fr:tex display="inline"><![CDATA[\Delta ^n \to  [0,1]]]></fr:tex> which picks out the first coordinate has fibers isomorphic to <fr:tex display="inline"><![CDATA[\Delta ^{n-1},]]></fr:tex> so we can proceed by induction (the case <fr:tex display="inline"><![CDATA[n=0]]></fr:tex> being trivial.)
  </html:p></fr:mainmatter></fr:tree></fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002X/</fr:uri><fr:display-uri>lcc-002X</fr:display-uri><fr:route>/lcc-002X/</fr:route><fr:taxon>Lemma</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[X]]></fr:tex> be a compact topological convex space. Suppose <fr:tex display="inline"><![CDATA[(X,\Delta ^n)]]></fr:tex> is solvable for all <fr:tex display="inline"><![CDATA[n]]></fr:tex>. Then <fr:tex display="inline"><![CDATA[(X,A)]]></fr:tex> is solvable for all topological convex spaces <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  Suppose for contradiction <fr:tex display="inline"><![CDATA[L: X \times  A \to  \mathbb {R}]]></fr:tex> does not have strong duality, and assume without loss of generality that <fr:tex display="inline"><![CDATA[\sup _a \inf _x L(x,a) < 0 < \inf _x \sup _a L(x,a)]]></fr:tex>. For each <fr:tex display="inline"><![CDATA[a \in  A]]></fr:tex> let <fr:tex display="inline"><![CDATA[X_a]]></fr:tex> consist of those <fr:tex display="inline"><![CDATA[x \in  X]]></fr:tex> so that <fr:tex display="inline"><![CDATA[L(x,a) \leq  0]]></fr:tex>. Given some finite family <fr:tex display="inline"><![CDATA[a_0, \dots  a_n,]]></fr:tex> consider the induced map <fr:tex display="inline"><![CDATA[a: \Delta ^n \to  A]]></fr:tex> and apply solvability to the problem <fr:tex display="inline"><![CDATA[(a_!L,X,\Delta ^n)]]></fr:tex> - this implies in particular that <fr:tex display="inline"><![CDATA[\inf _x \sup _i L(x,a_i) \leq  0]]></fr:tex>. This means the family <fr:tex display="inline"><![CDATA[X_a]]></fr:tex> has the finite intersection property, so by compactness it has nonempty intersection. But then an element <fr:tex display="inline"><![CDATA[x^*]]></fr:tex> of the intersection must satisfy <fr:tex display="inline"><![CDATA[\sup _a L(x^*,a) \leq  0,]]></fr:tex> which is a contradiction.
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002Y/</fr:uri><fr:display-uri>lcc-002Y</fr:display-uri><fr:route>/lcc-002Y/</fr:route><fr:taxon>Corollary</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  If <fr:tex display="inline"><![CDATA[X]]></fr:tex> is compact, <fr:tex display="inline"><![CDATA[(X,A)]]></fr:tex> is solvable for any <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>21</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  By <fr:link href="/lcc-002W/" title="https://erischel.com/lcc-002W/" uri="https://erischel.com/lcc-002W/" display-uri="lcc-002W" type="local">Proposition <fr:contextual-number uri="https://erischel.com/lcc-002W/" display-uri="lcc-002W" /></fr:link> and its corollary, applied to <fr:link href="/lcc-002V/" title="https://erischel.com/lcc-002V/" uri="https://erischel.com/lcc-002V/" display-uri="lcc-002V" type="local">Proposition <fr:contextual-number uri="https://erischel.com/lcc-002V/" display-uri="lcc-002V" /></fr:link>, we have <fr:tex display="inline"><![CDATA[([0,1],\Delta ^n)]]></fr:tex> solvable for all <fr:tex display="inline"><![CDATA[n]]></fr:tex>. Since <fr:tex display="inline"><![CDATA[[0,1]]]></fr:tex> is compact, this means <fr:tex display="inline"><![CDATA[([0,1],A)]]></fr:tex> is solvable for all <fr:tex display="inline"><![CDATA[A]]></fr:tex>, by <fr:link href="/lcc-002X/" title="https://erischel.com/lcc-002X/" uri="https://erischel.com/lcc-002X/" display-uri="lcc-002X" type="local">Lemma <fr:contextual-number uri="https://erischel.com/lcc-002X/" display-uri="lcc-002X" /></fr:link>. Now by duality we have <fr:tex display="inline"><![CDATA[(X,[0,1])]]></fr:tex> solvable for all <fr:tex display="inline"><![CDATA[X,]]></fr:tex> which means <fr:tex display="inline"><![CDATA[(X,\Delta ^n)]]></fr:tex> is solvable, and by using <fr:link href="/lcc-002X/" title="https://erischel.com/lcc-002X/" uri="https://erischel.com/lcc-002X/" display-uri="lcc-002X" type="local">Lemma <fr:contextual-number uri="https://erischel.com/lcc-002X/" display-uri="lcc-002X" /></fr:link> again, we're done.
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>30</fr:day></fr:date></fr:frontmatter><fr:mainmatter><html:p>
      By <fr:link href="/lcc-002Y/" title="https://erischel.com/lcc-002Y/" uri="https://erischel.com/lcc-002Y/" display-uri="lcc-002Y" type="local">Corollary <fr:contextual-number uri="https://erischel.com/lcc-002Y/" display-uri="lcc-002Y" /></fr:link>, the pair <fr:tex display="inline"><![CDATA[(X,A)]]></fr:tex> is solvable, and strong duality holds. Since <fr:tex display="inline"><![CDATA[X,A]]></fr:tex> are both compact, there must exist <fr:tex display="inline"><![CDATA[x^*,a^*]]></fr:tex> attaining the infimum <fr:tex display="inline"><![CDATA[\inf _x \sup _a L(x,a)]]></fr:tex> and the supremum <fr:tex display="inline"><![CDATA[\sup _a \inf _x L(x,a)]]></fr:tex>. These form an equilibrium.
    </html:p></fr:mainmatter></fr:tree><html:p>
    It is interesting to note the use of compactness here. Recall that topological compactness is closely connected with the property, also called compactness, of <fr:tex display="inline"><![CDATA[\operatorname {\mathrm {Hom}}(X,-)]]></fr:tex> preserving filtered colimits (this property, instantiated in <fr:tex display="inline"><![CDATA[\mathsf {Top}]]></fr:tex>, is not actually the same thing as topological compactness). Our use of compactness here, to derive from the existence of a state in the "finitary" subproblems <fr:tex display="inline"><![CDATA[(L,X,\Delta ^n)]]></fr:tex> the existence of a state in the entire problem, does not have this form (nor is it even the case that <fr:tex display="inline"><![CDATA[A]]></fr:tex> is the colimit of its subsimplices), but it's possible that the proof could be rewritten to make this step more categorical.
  </html:p><html:p>
    The idea of proceeding by induction on <fr:tex display="inline"><![CDATA[n]]></fr:tex> was inspired by <fr:link href="/weinstein-elementary-minimax-2022/" title="Two Elementary Proofs of the Minimax Theorem" uri="https://erischel.com/weinstein-elementary-minimax-2022/" display-uri="weinstein-elementary-minimax-2022" type="local">Reference <fr:contextual-number uri="https://erischel.com/weinstein-elementary-minimax-2022/" display-uri="weinstein-elementary-minimax-2022" /></fr:link>, although our proof is rather different - they are only looking at <html:em>affine</html:em> games, and hence their induction step is completely different (and they have no need for the complicated <fr:tex display="inline"><![CDATA[n=1]]></fr:tex> base case that we do), and since we are not merely interested in games on simplices, we need an additional compactness argument.
  </html:p><html:p>We can use the minimax theorem to derive other statements of interest about convex optimization</html:p><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>22</fr:day></fr:date><fr:uri>https://erischel.com/lcc-002Z/</fr:uri><fr:display-uri>lcc-002Z</fr:display-uri><fr:route>/lcc-002Z/</fr:route><fr:title text="The separating hyperplane theorem (compact case)">The separating hyperplane theorem (compact case)</fr:title><fr:taxon>Theorem</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[X,Y \subset  \mathbb {R}^k]]></fr:tex> be disjoint, compact, convex subspaces. Then there exists <fr:tex display="inline"><![CDATA[v \in  \mathbb {R}^k]]></fr:tex> and <fr:tex display="inline"><![CDATA[\alpha  \in  \mathbb {R}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\langle  v,x \rangle  + \alpha  < 0 < \langle  v,y \rangle  + \alpha ]]></fr:tex> whenever <fr:tex display="inline"><![CDATA[x \in  X, y \in  Y]]></fr:tex>.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>22</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>Consider the minmax problem</html:p> 
  <fr:tex display="block"><![CDATA[(L,X \times  Y, A = \overline {B(0,1)} \subseteq  \mathbb {R}^k), L(x,y,v) = \langle  v,y-x \rangle .]]></fr:tex>
  <html:p>
    Since the closed unit ball is compact, by the minimax theorem there exists an equilibrium <fr:tex display="inline"><![CDATA[x^*,y^*,v^*]]></fr:tex>, which then satisfies
    <fr:tex display="block"><![CDATA[\langle  v,y^*-x^* \rangle  \leq  \langle  v^*,y^*-x^* \rangle  \leq  \langle  v^*,y-x \rangle ]]></fr:tex></html:p>
  <html:p>
    By disjointness, <fr:tex display="inline"><![CDATA[y^*-x^*]]></fr:tex> must be nonzero, so with a suitable choice of <fr:tex display="inline"><![CDATA[v]]></fr:tex> we can clearly make the left-hand item strictly positive. Hence <fr:tex display="inline"><![CDATA[\langle  v^*,y^*-x^* \rangle  =: \delta  > 0]]></fr:tex>. Now there must exist some <fr:tex display="inline"><![CDATA[\alpha  \in  \mathbb {R}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\langle  v^*,y^* \rangle  + \alpha  = -\langle  v^*,x^* \rangle  - \alpha  = \delta  /2 > 0]]></fr:tex>.
  </html:p>
  <html:p>
    By the equilibrium property, we see that <fr:tex display="inline"><![CDATA[y^*]]></fr:tex> must minimize <fr:tex display="inline"><![CDATA[\langle  v^*,y \rangle ]]></fr:tex> on <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, and analogously <fr:tex display="inline"><![CDATA[x^*]]></fr:tex> must maximize <fr:tex display="inline"><![CDATA[\langle  v^*,x \rangle ]]></fr:tex> on <fr:tex display="inline"><![CDATA[X]]></fr:tex>. Hence for all <fr:tex display="inline"><![CDATA[x,y]]></fr:tex>, we have
    <fr:tex display="block"><![CDATA[\langle  v^*,x \rangle  + \alpha  \leq  -\delta  /2 < 0 < \delta  /2 \leq  \langle  v^*,y \rangle  + \alpha ,]]></fr:tex> which concludes the proof.
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree><fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>22</fr:day></fr:date><fr:uri>https://erischel.com/lcc-0030/</fr:uri><fr:display-uri>lcc-0030</fr:display-uri><fr:route>/lcc-0030/</fr:route><fr:title text="The separating hyperplane theorem (general case)">The separating hyperplane theorem (general case)</fr:title><fr:taxon>Theorem</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
  Let <fr:tex display="inline"><![CDATA[X,Y \subseteq  \mathbb {R}^k]]></fr:tex> be disjoint convex subsets. Then there exists <fr:tex display="inline"><![CDATA[v,\alpha ]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\langle  v,x \rangle  + \alpha  \leq  0 \leq  \langle  v,y \rangle  + \alpha ]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x \in  X, y \in  Y]]></fr:tex>.
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>5</fr:month><fr:day>22</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
    Let <fr:tex display="inline"><![CDATA[K_i, L_i, i=1, \dots ]]></fr:tex> be two sequences of sets with the following properties:
    <html:ul><html:li>For each <fr:tex display="inline"><![CDATA[i]]></fr:tex>, <fr:tex display="inline"><![CDATA[K_i,L_i]]></fr:tex> are disjoint.</html:li>
      <html:li>For each <fr:tex display="inline"><![CDATA[i]]></fr:tex>, <fr:tex display="inline"><![CDATA[K_i \subseteq  K_{i+1}]]></fr:tex></html:li>
      <html:li>Each of the <fr:tex display="inline"><![CDATA[K_i,L_i]]></fr:tex> are compact and convex</html:li>
      <html:li><fr:tex display="inline"><![CDATA[\cup _i K_i = X, \cup _i L_i = Y]]></fr:tex></html:li></html:ul>
    These can be constructed for example by taking the intersection of <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y]]></fr:tex> with the boxes <fr:tex display="inline"><![CDATA[[-i,i]^k]]></fr:tex> to obtain compact, convex, disjoint subsets which exhaust <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y]]></fr:tex>.
  </html:p>
  <html:p>
    Now apply <fr:link href="/lcc-002Z/" title="The separating hyperplane theorem (compact case)" uri="https://erischel.com/lcc-002Z/" display-uri="lcc-002Z" type="local">Theorem <fr:contextual-number uri="https://erischel.com/lcc-002Z/" display-uri="lcc-002Z" /></fr:link> to obtain a sequence of <fr:tex display="inline"><![CDATA[v_i \in  \overline {B(0,1)}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\langle  v_i,- \rangle ]]></fr:tex> is negative on <fr:tex display="inline"><![CDATA[K_i]]></fr:tex> and positive on <fr:tex display="inline"><![CDATA[L_i]]></fr:tex>. By compactness of the unit ball, this sequence has a point of density <fr:tex display="inline"><![CDATA[v^*]]></fr:tex>. Now for every pair <fr:tex display="inline"><![CDATA[x \in  X, y \in  Y]]></fr:tex>, we can find some <fr:tex display="inline"><![CDATA[i]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\langle  v_i,x \rangle ]]></fr:tex> is within an arbitrary <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex> of <fr:tex display="inline"><![CDATA[\langle  v^*,x \rangle ]]></fr:tex> and the same is true for <fr:tex display="inline"><![CDATA[y]]></fr:tex>, and so that <fr:tex display="inline"><![CDATA[x \in  K_i, y \in  L_i]]></fr:tex>. But then <fr:tex display="inline"><![CDATA[\langle  v^*,y-x \rangle ]]></fr:tex> is within <fr:tex display="inline"><![CDATA[2\epsilon ]]></fr:tex> of <fr:tex display="inline"><![CDATA[\langle  v_i,y-x \rangle ,]]></fr:tex> which is positive, so that <fr:tex display="inline"><![CDATA[\langle  v^*,y-x \rangle  \geq  0]]></fr:tex>.
  </html:p>
  <html:p>
    Now for each <fr:tex display="inline"><![CDATA[i]]></fr:tex>, <fr:tex display="inline"><![CDATA[\langle  v^*,- \rangle ]]></fr:tex> has a maximizer <fr:tex display="inline"><![CDATA[x_i^*]]></fr:tex> on <fr:tex display="inline"><![CDATA[K_i]]></fr:tex> and a minimizer <fr:tex display="inline"><![CDATA[y_i^*]]></fr:tex> on <fr:tex display="inline"><![CDATA[L_i]]></fr:tex>. Hence, by an argument analogous to the proof of <fr:link href="/lcc-002Z/" title="The separating hyperplane theorem (compact case)" uri="https://erischel.com/lcc-002Z/" display-uri="lcc-002Z" type="local">Theorem <fr:contextual-number uri="https://erischel.com/lcc-002Z/" display-uri="lcc-002Z" /></fr:link>, there is a nonempty closed interval <fr:tex display="inline"><![CDATA[[a_i,b_i]]]></fr:tex> so that, if <fr:tex display="inline"><![CDATA[\alpha  \in  [a_i,b_i],]]></fr:tex> we have <fr:tex display="inline"><![CDATA[\langle  v^*,- \rangle  + \alpha ]]></fr:tex> <fr:tex display="inline"><![CDATA[\leq  0]]></fr:tex> on <fr:tex display="inline"><![CDATA[K_i]]></fr:tex> and <fr:tex display="inline"><![CDATA[\geq  0]]></fr:tex> on <fr:tex display="inline"><![CDATA[L_i]]></fr:tex>. But since the sets <fr:tex display="inline"><![CDATA[K_i, L_i]]></fr:tex> are increasing this sequence of intervals must be decreasing, and hence the intersection must be nonempty - and then any <fr:tex display="inline"><![CDATA[\alpha ]]></fr:tex> in this intersection will make <fr:tex display="inline"><![CDATA[\langle  v^*,- \rangle  + \alpha ]]></fr:tex> nonpositive on <fr:tex display="inline"><![CDATA[X]]></fr:tex>, nonnegative on <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, as desired.
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter></fr:tree></fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="The Legendre Transform">The Legendre Transform</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001P/</fr:uri>
                        <fr:display-uri>lcc-001P</fr:display-uri>
                        <fr:route>/lcc-001P/</fr:route>
                        <fr:title text="Convex conjugate">Convex conjugate</fr:title>
                        <fr:taxon>Definition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Let <fr:tex display="inline"><![CDATA[V]]></fr:tex> be a (real) vector space, and <fr:tex display="inline"><![CDATA[f: V \to  \mathbb {R}]]></fr:tex> be a function (not necessarily linear).
    Then the <html:em>convex conjugate</html:em> <fr:tex display="inline"><![CDATA[f^*: V^* \to  \mathbb {R}]]></fr:tex> is defined by
    <fr:tex display="block"><![CDATA[f^*(\alpha ) = \sup _x \alpha (x) - f(x)]]></fr:tex></html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <html:p>
    The convex conjugate is also called the <html:em>Legendre transform</html:em> or the <html:em>Fenchel-Legendre transform</html:em>. It is intimately related to convex duality. We will prove the following fundamental property of the convex conjugate using the categorical language of minmax problems, and along the way we will see the role that convex duality plays. Note that our invocation of the term "strong duality" here is somewhat more complicated than strictly necessary - normally one would merely invoke the separating hyperplane theorem directly.
  </html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001Q/</fr:uri>
                        <fr:display-uri>lcc-001Q</fr:display-uri>
                        <fr:route>/lcc-001Q/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Let <fr:tex display="inline"><![CDATA[f: V \to  \mathbb {R}]]></fr:tex> be convex, so that <fr:tex display="inline"><![CDATA[(V,*,f)]]></fr:tex> is a minmax problem.
    Then we can form the modified minmax problem <fr:tex display="inline"><![CDATA[L = (V,V^*,(x,\alpha ) \mapsto  f(x) - \alpha (x))]]></fr:tex> - note that, up to a sign change in the domain, this amounts to adding the constraint <fr:tex display="inline"><![CDATA[x = 0]]></fr:tex>.
</html:p>
                        <html:p>
    Then <fr:tex display="inline"><![CDATA[(L^*)^+ = -L^- = f^*]]></fr:tex></html:p>
                        <html:p>
    Note that the two uses of the asterisk in this equation conflict.
    We have both the reversed optimization problem <fr:tex display="inline"><![CDATA[L^*]]></fr:tex> given by flipping the variables,
    and the <fr:link href="/lcc-001P/" title="Convex conjugate" uri="https://erischel.com/lcc-001P/" display-uri="lcc-001P" type="local">convex conjugate</fr:link> function <fr:tex display="inline"><![CDATA[f^*]]></fr:tex>. It may be good to alter this notation to resolve the conflict.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001T/</fr:uri>
                        <fr:display-uri>lcc-001T</fr:display-uri>
                        <fr:route>/lcc-001T/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Given a minmax problem <fr:tex display="inline"><![CDATA[L = (X,Y,L)]]></fr:tex> where <fr:tex display="inline"><![CDATA[X]]></fr:tex> is a finite-dimensional real vector space, let
    <fr:tex display="inline"><![CDATA[L|_{0} = (X, Y \oplus  X^*, L \oplus  - \langle  -,- \rangle )]]></fr:tex>
    Note that <fr:tex display="inline"><![CDATA[(L|_0)^+(x) = \infty ]]></fr:tex> when <fr:tex display="inline"><![CDATA[x = 0]]></fr:tex> and <fr:tex display="inline"><![CDATA[L^+(0)]]></fr:tex> otherwise.
    Thus this amounts to adding a constraint that <fr:tex display="inline"><![CDATA[x = 0]]></fr:tex>.
    Analogously, define <fr:tex display="inline"><![CDATA[L|^0 = (L^*|_0)^* = (X \oplus  Y^*, Y, L \oplus  \langle  -, - \rangle )]]></fr:tex></html:p>
                        <html:p>
    Then the Legendre transform <fr:tex display="inline"><![CDATA[f^* = ((f|_0)^*)^+]]></fr:tex> (viewing both <fr:tex display="inline"><![CDATA[f]]></fr:tex> and <fr:tex display="inline"><![CDATA[f^*]]></fr:tex> as minmax problems using the inclusion <fr:tex display="inline"><![CDATA[\mathsf {Conv} \to  \mathsf {Minmax}]]></fr:tex>)
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001U/</fr:uri>
                        <fr:display-uri>lcc-001U</fr:display-uri>
                        <fr:route>/lcc-001U/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter><html:p>
    Let <fr:tex display="inline"><![CDATA[f: X \to  \mathbb {R}]]></fr:tex> be a continuous convex function defined on a vector space.
    Then there is strong duality in the minmax problem <fr:tex display="inline"><![CDATA[f|_0]]></fr:tex></html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>25</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
    <html:p>
        Observe that <fr:tex display="inline"><![CDATA[\{x,t \mid  f(x) \leq  t\} \subseteq  X \oplus  \mathbb {R}]]></fr:tex> is a closed convex set.
        Hence there is a hyperplane through <fr:tex display="inline"><![CDATA[(0,f(0))]]></fr:tex> so that the entire set is in one half-space.
        This means a nontrivial affine equation <fr:tex display="inline"><![CDATA[A(x,t) \geq  b]]></fr:tex> which is satisfied whenever <fr:tex display="inline"><![CDATA[t \geq  f(x)]]></fr:tex>, and where <fr:tex display="inline"><![CDATA[A(0,f(0)) = b]]></fr:tex>.
    </html:p>
    <html:p>
        Clearly <fr:tex display="inline"><![CDATA[A(x,t) = \alpha _0(x) - at]]></fr:tex> for some <fr:tex display="inline"><![CDATA[\alpha _0 \in  X^*, a \in  \mathbb {R}]]></fr:tex>.
        If <fr:tex display="inline"><![CDATA[a = 0]]></fr:tex> we have <fr:tex display="inline"><![CDATA[\alpha _0(x) \leq  b]]></fr:tex> for <html:em>all</html:em> <fr:tex display="inline"><![CDATA[x]]></fr:tex>, which impossible.
        So by normalizing let's set <fr:tex display="inline"><![CDATA[a = 1]]></fr:tex>.
        This means <fr:tex display="inline"><![CDATA[\alpha _0 (x) + f(x) \geq  b = f(0)]]></fr:tex>.
    </html:p>
    <html:p>
        Recall that the minmax problem <fr:tex display="inline"><![CDATA[f|_0]]></fr:tex> is given by <fr:tex display="inline"><![CDATA[(X,X^*,L(x,\alpha ) \mapsto  f(x) - \alpha (x))]]></fr:tex>.
        Strong duality means <fr:tex display="inline"><![CDATA[\inf _x\sup _\alpha  L(x,\alpha ) = \sup _\alpha  \inf _x L(x,\alpha )]]></fr:tex>.
        We always have the inequality <fr:tex display="inline"><![CDATA[\geq ]]></fr:tex>, so it suffices to identify an <fr:tex display="inline"><![CDATA[\alpha ^*]]></fr:tex> so that
        <fr:tex display="inline"><![CDATA[\inf _x \sup _\alpha  L(x,\alpha ) \leq  \inf _x L(x,\alpha ^*)]]></fr:tex></html:p>
    <html:p>
        Clearly, for our <fr:tex display="inline"><![CDATA[L]]></fr:tex>, we have <fr:tex display="inline"><![CDATA[\inf _x\sup _\alpha  L(x,\alpha ) = f(0)]]></fr:tex>, since the supremum is <fr:tex display="inline"><![CDATA[\infty ]]></fr:tex> unless <fr:tex display="inline"><![CDATA[x = 0]]></fr:tex>.
        On the other hand, taking <fr:tex display="inline"><![CDATA[\alpha ^* = -\alpha _0]]></fr:tex>, we have <fr:tex display="inline"><![CDATA[f(0) \leq  f(x) - \alpha ^*(x)]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x]]></fr:tex> by construction, finishing the proof.
    </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>6</fr:month>
                          <fr:day>4</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-003C/</fr:uri>
                        <fr:display-uri>lcc-003C</fr:display-uri>
                        <fr:route>/lcc-003C/</fr:route>
                        <fr:taxon>Lemma</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
  Given a commutative square:
  
  <html:figure><fr:resource hash="b7a2ac7a15891d75f1fd68c16adbea6d"><fr:resource-content><html:img src="/b7a2ac7a15891d75f1fd68c16adbea6d.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
    \begin {tikzcd}
    (X_1,A_1) \ar [r] \ar [d] & (Y_1,B_1) \ar [d]\\
    (X_2,A_2) \ar [r] & (Y_2,B_2)
    \end {tikzcd}
  ]]></fr:resource-source></fr:resource></html:figure>

  in <fr:tex display="inline"><![CDATA[\mathsf {Set}^\Delta  \times  \mathsf {Set}^{\Delta ,\mathrm {op}},]]></fr:tex> with the Beck-Chevalley property for the fibration from <fr:tex display="inline"><![CDATA[\mathsf {Minmax},]]></fr:tex>
  let <fr:tex display="inline"><![CDATA[(Z,C)]]></fr:tex> be some other pair of convex spaces. Then the square 
  
  <html:figure><fr:resource hash="d4b53e84413f0d97c39e8f378838b0f9"><fr:resource-content><html:img src="/d4b53e84413f0d97c39e8f378838b0f9.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
    \begin {tikzcd}
    (X_1 \times  Z,A_1 \times  C) \ar [r] \ar [d] & (Y_1 \times  Z,B_1 \times  C) \ar [d]\\
    (X_2 \times  Z,A_2 \times  C) \ar [r] & (Y_2 \times  Z,B_2 \times  C)
    \end {tikzcd}
  ]]></fr:resource-source></fr:resource></html:figure>

  also has the Beck-Chevalley condition
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>25</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001V/</fr:uri>
                        <fr:display-uri>lcc-001V</fr:display-uri>
                        <fr:route>/lcc-001V/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter><html:p>
    Let <fr:tex display="inline"><![CDATA[f]]></fr:tex> be a convex function.
    Then <fr:tex display="inline"><![CDATA[f = (f^*)^*]]></fr:tex> (where <fr:tex display="inline"><![CDATA[f^*]]></fr:tex> denotes the Legendre transform), under the identification <fr:tex display="inline"><![CDATA[(X^*)^* = X]]></fr:tex> of a finite-dimensional vector space with its double dual. 
</html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2024</fr:year><fr:month>4</fr:month><fr:day>25</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
    <html:p>
        Recall that <fr:tex display="inline"><![CDATA[f^* = ((f|_0)^*)^+,]]></fr:tex> as a minmax problem.
        Then the claim is that <fr:tex display="block"><![CDATA[(((((f|_0)^*)^+)|_0)^*)^+ = f.]]></fr:tex>
        Using first the rewrite <fr:tex display="inline"><![CDATA[((-)^*)^+ = ((-)^-)^*,]]></fr:tex> and the notation <fr:tex display="inline"><![CDATA[((-)^*|_0)^* = -|^0,]]></fr:tex>
        we can rewrite that as
        <fr:tex display="block"><![CDATA[((f|_0)^-|^0)^+]]></fr:tex></html:p>
    <html:p>
        Now observe that, restricted to the subcategory <fr:tex display="inline"><![CDATA[\mathsf {Minmax}_l]]></fr:tex> given by minmax problems <fr:tex display="inline"><![CDATA[(X,Y,L)]]></fr:tex> where <fr:tex display="inline"><![CDATA[X,Y]]></fr:tex> are real vector spaces, and those homomorphisms given by linear (rather than merely affine) maps, <fr:tex display="inline"><![CDATA[(-)|_0]]></fr:tex> and <fr:tex display="inline"><![CDATA[-|^0]]></fr:tex> form endofunctors, and <fr:tex display="inline"><![CDATA[(-)|_0 \dashv  (-)|^0]]></fr:tex>.
    </html:p>
    <html:p>
        Since <fr:tex display="inline"><![CDATA[(-)^-]]></fr:tex> is left adjoint to the inclusion, we have <fr:tex display="inline"><![CDATA[(-)|_0^- \dashv  -|^0]]></fr:tex>.
        Hence there is a canonical map, the unit of the adjunction, <fr:tex display="inline"><![CDATA[L \to  (L|_0)^-|^0]]></fr:tex> for any <fr:tex display="inline"><![CDATA[L]]></fr:tex>.
        If <fr:tex display="inline"><![CDATA[L = (X,*,f)]]></fr:tex> is an element of <fr:tex display="inline"><![CDATA[\mathsf {Conv}]]></fr:tex>, then by the universal property, this map factors over <fr:tex display="inline"><![CDATA[((f|_0)^-|^0)^+]]></fr:tex>. This gives us the inequality <fr:tex display="inline"><![CDATA[f \geq  (f^*)^*]]></fr:tex>.
    </html:p>
    <html:p>
        (Note that this inequality actually holds even if <fr:tex display="inline"><![CDATA[f]]></fr:tex> is not convex, and indeed we haven't really used convexity yet).
    </html:p>

    <html:p>
        Observe that, using the natural identification <fr:tex display="inline"><![CDATA[(X^*)^* = X]]></fr:tex>, we have <fr:tex display="block"><![CDATA[(f|_0)|^0 = (X \oplus  X, X^*, (x,x';\alpha ) \mapsto  f(x) - \alpha (x) + \alpha (x')).]]></fr:tex> Clearly <fr:tex display="inline"><![CDATA[\inf _x \sup _\alpha  f(x) - \alpha (x) + \alpha (x') = f(x'),]]></fr:tex> since the supremum is infinite unless <fr:tex display="inline"><![CDATA[x = x']]></fr:tex>. But observe that <fr:tex display="inline"><![CDATA[(f^*)^*(x') = \sup _\alpha  \inf _x f(x) - \alpha (x) + \alpha (x')]]></fr:tex></html:p>
    <html:p>
        Our claim now is that we may exchange these extremizers by strong duality. This amounts to the claim that the local Beck-Chevalley property holds for this square at <fr:tex display="inline"><![CDATA[(f|_0)|^0]]></fr:tex>:
        
  <html:figure><fr:resource hash="2171a835266bf1a007930945708deb76"><fr:resource-content><html:img src="/2171a835266bf1a007930945708deb76.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
            \begin {tikzcd}
            (X \oplus  (X^*)^*, *) \ar [d] \ar [r] & ((X^*)^*, *) \ar [d]\\
            (X \oplus  (X^*)^*, X^*) \ar [r] & ((X^*)^*, X^*)
            \end {tikzcd}
        ]]></fr:resource-source></fr:resource></html:figure></html:p>
    <html:p>
        But by <fr:link href="/lcc-001U/" title="https://erischel.com/lcc-001U/" uri="https://erischel.com/lcc-001U/" display-uri="lcc-001U" type="local">Proposition <fr:contextual-number uri="https://erischel.com/lcc-001U/" display-uri="lcc-001U" /></fr:link>, strong duality holds in every square of the form
        
  <html:figure><fr:resource hash="391f4d7c7e1fcef99810b65ed1eff27b"><fr:resource-content><html:img src="/391f4d7c7e1fcef99810b65ed1eff27b.svg" /></fr:resource-content><fr:resource-source type="latex" part="preamble"><![CDATA[
    \RequirePackage {tikz-cd}
    \RequirePackage {amssymb}
  \usetikzlibrary {calc}
  \usetikzlibrary {decorations.pathmorphing}
    \tikzset{curve/.style={settings={#1},to path={(\tikztostart)
    .. controls ($(\tikztostart)!\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    and ($(\tikztostart)!1-\pv{pos}!(\tikztotarget)!\pv{height}!270:(\tikztotarget)$)
    .. (\tikztotarget)\tikztonodes}},
    settings/.code={\tikzset{quiver/.cd,#1}
        \def\pv##1{\pgfkeysvalueof{/tikz/quiver/##1}}},
    quiver/.cd,pos/.initial=0.35,height/.initial=0}
\tikzset {tail reversed/.code={\pgfsetarrowsstart {tikzcd to}}}
\tikzset {2tail/.code={\pgfsetarrowsstart {Implies[reversed]}}}
\tikzset {2tail reversed/.code={\pgfsetarrowsstart {Implies}}}
\tikzset {no body/.style={/tikz/dash pattern=on 0 off 1mm}}

    
    \usepackage {amsopn, amssymb, mathrsfs}]]></fr:resource-source><fr:resource-source type="latex" part="body"><![CDATA[
            \begin {tikzcd}
            (X, *) \ar [d] \ar [r] & (*, *) \ar [d]\\
            (X, X^*) \ar [r] & (*, X^*)
            \end {tikzcd}
        ]]></fr:resource-source></fr:resource></html:figure>

        and by <fr:link href="/lcc-003C/" title="https://erischel.com/lcc-003C/" uri="https://erischel.com/lcc-003C/" display-uri="lcc-003C" type="local">Lemma <fr:contextual-number uri="https://erischel.com/lcc-003C/" display-uri="lcc-003C" /></fr:link>, this is establishes that the previous square has the Beck-Chevalley condition as well, which finishes the proof.
    </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2024</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>30</fr:day>
                    </fr:date>
                    <fr:title text="Misc stuff (sorting)">Misc stuff (sorting)</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>26</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001Y/</fr:uri>
                        <fr:display-uri>lcc-001Y</fr:display-uri>
                        <fr:route>/lcc-001Y/</fr:route>
                        <fr:title text="Composition of minmax problems">Composition of minmax problems</fr:title>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Let <fr:tex display="inline"><![CDATA[Y]]></fr:tex> be a real vector space, and let <fr:tex display="inline"><![CDATA[(X,Y,L), (Y^*,Z,L)]]></fr:tex> be minmax problems.
    Then we can try to define a composite minmax problem
    <fr:tex display="block"><![CDATA[L\circ _Y L'(x,z) = \sup _y \inf _{y'} L(x,y) + L(y',z) - y'(y)]]></fr:tex></html:p>
                        <html:p>
    For this composition to be associative relies on a strong duality property. We probably shouldn't want to treat this as well-defined unless it holds.
</html:p>
                        <html:p>
    Note that by the convex duality stuff, the minmax problem <fr:tex display="inline"><![CDATA[Y^*,Y,\operatorname {ev}]]></fr:tex> acts as an identity for this composition.
</html:p>
                        <html:p>
    This may fit together into a double category type structure for minmax problems (maybe restricted to linear maps between the spaces).
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>23</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001M/</fr:uri>
                        <fr:display-uri>lcc-001M</fr:display-uri>
                        <fr:route>/lcc-001M/</fr:route>
                        <fr:title text="Minmax problems are not star-autonomous">Minmax problems are not star-autonomous</fr:title>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    Since the category of <fr:link href="/lcc-001C/" title="Minmax problem" uri="https://erischel.com/lcc-001C/" display-uri="lcc-001C" type="local">minmax problems</fr:link> is very similar to a <span class="nlab"><fr:link href="https://ncatlab.org/nlab/show/Chu construction" type="external">Chu construction</fr:link></span>,
    we might hope that we could define a similar star-autonomous structure on minmax problems. Unfortunately, this does not work. We do have the duality, <fr:link href="/lcc-001J/" title="Dual minmax problem" uri="https://erischel.com/lcc-001J/" display-uri="lcc-001J" type="local">Dual minmax problem</fr:link>, but it doesn't extend to a star-autonomous structure.
</html:p>
                        <html:p>
    Morally speaking, the tensor product of <fr:tex display="inline"><![CDATA[(X,Y,L), (X',Y',L')]]></fr:tex> would be given by <fr:tex display="inline"><![CDATA[X \otimes  X']]></fr:tex> in the forwards direction, and pairs of affine functions <fr:tex display="inline"><![CDATA[f: X \to  Y', g: X' \to  Y]]></fr:tex> satisfying <fr:tex display="inline"><![CDATA[L(x,g(x')) = L'(x',f(x))]]></fr:tex> in the backwards direction, with either of these expressions giving the pairing.
    Since the first formula implies the pairing is convex in <fr:tex display="inline"><![CDATA[x]]></fr:tex> (as it must be), but the latter implies it's concave in <fr:tex display="inline"><![CDATA[x]]></fr:tex>, <fr:tex display="inline"><![CDATA[g]]></fr:tex> must take values only those <fr:tex display="inline"><![CDATA[y]]></fr:tex> so that <fr:tex display="inline"><![CDATA[L(-,y)]]></fr:tex> is affine, and similarly for <fr:tex display="inline"><![CDATA[f]]></fr:tex>.
    This can easily be an empty set, but in a star-autonomous category we always have a canonical costate <fr:tex display="inline"><![CDATA[L \otimes  L^* \to  I]]></fr:tex>, which would be impossible in that case.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2024</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>23</fr:day>
                        </fr:date>
                        <fr:uri>https://erischel.com/lcc-001K/</fr:uri>
                        <fr:display-uri>lcc-001K</fr:display-uri>
                        <fr:route>/lcc-001K/</fr:route>
                        <fr:taxon>Proposition</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
    The category of minmax problems has products, given by
    <fr:tex display="block"><![CDATA[(X,Y,L) \times  (X',Y',L') = (X \times  X', Y \oplus  Y', (L \times  L')),]]></fr:tex>
    <fr:tex display="block"><![CDATA[(L \times  L')(x,x'; \alpha  y + \beta  y') = \alpha  L(x,y) + \beta  L'(x',y')]]></fr:tex></html:p>
                        <html:p>
                          <fr:tex display="inline"><![CDATA[(L \times  L')^+(x,x') = \max  (L^+(x),L'^+(x'))]]></fr:tex>
                        </html:p>
                        <html:p>
    Here <fr:tex display="inline"><![CDATA[Y \oplus  Y']]></fr:tex> denotes the <fr:link href="/lcc-001K/" title="https://erischel.com/lcc-001K/" uri="https://erischel.com/lcc-001K/" display-uri="lcc-001K" type="local">coproduct of convex spaces</fr:link>, and <fr:tex display="inline"><![CDATA[\alpha  y + \beta  y']]></fr:tex> is a generic element (note that <fr:tex display="inline"><![CDATA[\alpha ,\beta  \in  [0,1], \alpha  + \beta  = 1]]></fr:tex>)
</html:p>
                        <html:p>
    By duality (with <fr:tex display="inline"><![CDATA[(-)^*]]></fr:tex>), it also has coproducts given by <fr:tex display="inline"><![CDATA[(X,Y,L) \oplus  (X',Y',L') = (X \oplus  X', Y \times  Y', L(\alpha  x + \beta  x';y,y') = \alpha  L(x,y) + \beta  L'(x',y'))]]></fr:tex>.
</html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>Tobias Fritz</fr:author>
              <fr:author>Tomas Gonda</fr:author>
              <fr:author>Paolo Perrone</fr:author>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2023</fr:year>
              <fr:month>6</fr:month>
              <fr:day>15</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/fritz-gonda-perrone-rischel-rep/</fr:uri>
            <fr:display-uri>fritz-gonda-perrone-rischel-rep</fr:display-uri>
            <fr:route>/fritz-gonda-perrone-rischel-rep/</fr:route>
            <fr:title text="Representable Markov categories and comparison of statistical experiments in categorical probability">Representable Markov categories and comparison of statistical experiments in categorical probability</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="doi">10.1016/j.tcs.2023.113896</fr:meta>
            <fr:meta name="bibtex"><![CDATA[ @article
{fritz-gonda-perrone-rischel-rep, title={Representable Markov categories and comparison of statistical experiments in categorical probability}, volume={961}, ISSN={0304-3975}, DOI={10.1016/j.tcs.2023.113896}, journal={Theoretical Computer Science}, author={Fritz, Tobias and Gonda, Tomas and Perrone, Paolo and Fjeldgren Rischel, Eigil}, year={2023}, month={Jun}, pages={113896} }]]></fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>Tobias Fritz</fr:author>
                  <fr:author>Tomas Gonda</fr:author>
                  <fr:author>Paolo Perrone</fr:author>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>15</fr:day>
                </fr:date>
                <fr:title text="Abstract">Abstract</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
Markov categories are a recent categorical approach to the mathematical foundations of probability and statistics. Here, this approach is advanced by stating and proving equivalent conditions for second-order stochastic dominance, a widely used way of comparing probability distributions by their spread. Furthermore, we lay the foundation for the theory of comparing statistical experiments within Markov categories by stating and proving the classical Blackwell-Sherman-Stein Theorem. Our version not only offers new insight into the proof, but its abstract nature also makes the result more general, automatically specializing to the standard Blackwell-Sherman-Stein Theorem in measure-theoretic probability as well as a Bayesian version that involves prior-dependent garbling. Along the way, we define and characterize representable Markov categories, within which one can talk about Markov kernels to or from spaces of distributions. We do so by exploring the relation between Markov categories and Kleisli categories of probability monads.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>Matteo Capucci</fr:author>
              <fr:author>Bruno Gavranović</fr:author>
              <fr:author>Jules Hedges</fr:author>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2022</fr:year>
              <fr:month>11</fr:month>
              <fr:day>3</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/towards-cybercat/</fr:uri>
            <fr:display-uri>towards-cybercat</fr:display-uri>
            <fr:route>/towards-cybercat/</fr:route>
            <fr:title text="Towards Foundations of Categorical Cybernetics">Towards Foundations of Categorical Cybernetics</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="doi">10.4204/EPTCS.372.17</fr:meta>
            <fr:meta name="bibtex"><![CDATA[@article
{towards-cybercat, title={Towards Foundations of Categorical Cybernetics}, volume={372}, ISSN={2075-2180}, DOI={10.4204/EPTCS.372.17}, url={https://arxiv.org/abs/2105.06332}, journal={Electronic Proceedings in Theoretical Computer Science}, author={Capucci, Matteo and Gavranović, Bruno and Hedges, Jules and Rischel, Eigil Fjeldgren}, year={2022}, month={Nov}, pages={235–248} }]]></fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>Matteo Capucci</fr:author>
                  <fr:author>Bruno Gavranović</fr:author>
                  <fr:author>Jules Hedges</fr:author>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2022</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>3</fr:day>
                </fr:date>
                <fr:title text="Abstract">Abstract</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
We propose a categorical framework for processes which interact bidirectionally with both an environment and a “controller”. Examples include open learners, in which the controller is an optimiser such as gradient descent, and an approach to compositional game theory closely related to open games, in which the controller is a composite of game-theoretic agents. We believe that “cybernetic” is an appropriate name for the processes that can be described in this framework.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>Dylan Braithwaite</fr:author>
              <fr:author>Matteo Capucci</fr:author>
              <fr:author>Bruno Gavranović</fr:author>
              <fr:author>Jules Hedges</fr:author>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>12</fr:month>
              <fr:day>21</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/fibre-optics-2021/</fr:uri>
            <fr:display-uri>fibre-optics-2021</fr:display-uri>
            <fr:route>/fibre-optics-2021/</fr:route>
            <fr:title text="Fibre optics">Fibre optics</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="doi">10.48550/arXiv.2112.11145</fr:meta>
            <fr:meta name="external">http://arxiv.org/abs/2112.11145</fr:meta>
            <fr:meta name="bibtex"><![CDATA[ @article
{fibre-optics-2021, title={Fibre optics}, url={http://arxiv.org/abs/2112.11145}, DOI={10.48550/arXiv.2112.11145}, number={arXiv:2112.11145}, publisher={arXiv}, author={Braithwaite, Dylan and Capucci, Matteo and Gavranović, Bruno and Hedges, Jules and Rischel, Eigil Fjeldgren}, year={2021}, month={Dec} }]]></fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>Dylan Braithwaite</fr:author>
                  <fr:author>Matteo Capucci</fr:author>
                  <fr:author>Bruno Gavranović</fr:author>
                  <fr:author>Jules Hedges</fr:author>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>12</fr:month>
                  <fr:day>21</fr:day>
                </fr:date>
                <fr:title text="Abstract">Abstract</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
Lenses, optics and dependent lenses (or equivalently morphisms of containers, or equivalently natural transformations of polynomial functors) are all widely used in applied category theory as models of bidirectional processes. From the definition of lenses over a finite product category, optics weaken the required structure to actions of monoidal categories, and dependent lenses make use of the additional property of finite completeness (or, in case of polynomials, even local cartesian closure). This has caused a split in the applied category theory literature between those using optics and those using dependent lenses. The goal of this paper is to unify optics with dependent lenses, by finding a definition of fibre optics admitting both as special cases.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
              <fr:author>Sebastian Weichwald</fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>8</fr:month>
              <fr:day>5</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/rischel_compositional_2021/</fr:uri>
            <fr:display-uri>rischel_compositional_2021</fr:display-uri>
            <fr:route>/rischel_compositional_2021/</fr:route>
            <fr:title text="Compositional abstraction error and a category of causal models">Compositional abstraction error and a category of causal models</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="bibtex"><![CDATA[@misc{rischel_compositional_2021,
 author = {Rischel, Eigil F. and Weichwald, Sebastian},
 date = {2021-08-05},
 doi = {10.48550/arXiv.2103.15758},
 eprint = {2103.15758 [cs, math, stat]},
 eprinttype = {arxiv},
 keywords = {Computer Science - Artificial Intelligence, Computer Science - Logic in Computer Science, Computer Science - Machine Learning, Mathematics - Category Theory, Statistics - Machine Learning},
 number = {{arXiv}:2103.15758},
 publisher = {{arXiv}},
 title = {Compositional Abstraction Error and a Category of Causal Models},
 url = {http://arxiv.org/abs/2103.15758},
 urldate = {2024-05-25}
}]]></fr:meta>
            <fr:meta name="doi">10.48550/arXiv.2103.15758</fr:meta>
            <fr:meta name="url">http://arxiv.org/abs/2103.15758</fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                  <fr:author>Sebastian Weichwald</fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>8</fr:month>
                  <fr:day>5</fr:day>
                </fr:date>
                <fr:title text="Abstract">Abstract</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
    Interventional causal models describe several joint distributions over some variables used to describe a system, one for each intervention setting. They provide a formal recipe for how to move between the different joint distributions and make predictions about the variables upon intervening on the system. Yet, it is difficult to formalise how we may change the underlying variables used to describe the system, say moving from fine-grained to coarse-grained variables. Here, we argue that compositionality is a desideratum for such model transformations and the associated errors: When abstracting a reference model M iteratively, first obtaining M' and then further simplifying that to obtain M'', we expect the composite transformation from M to M'' to exist and its error to be bounded by the errors incurred by each individual transformation step. Category theory, the study of mathematical objects via compositional transformations between them, offers a natural language to develop our framework for model transformations and abstractions. We introduce a category of finite interventional causal models and, leveraging theory of enriched categories, prove the desired compositionality properties for our framework.
  </html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>Tobias Fritz</fr:author>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>8</fr:month>
              <fr:day>11</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/rischel-fritz-infinite-products/</fr:uri>
            <fr:display-uri>rischel-fritz-infinite-products</fr:display-uri>
            <fr:route>/rischel-fritz-infinite-products/</fr:route>
            <fr:title text="Infinite products and zero-one laws in categorical probability">Infinite products and zero-one laws in categorical probability</fr:title>
            <fr:taxon>Reference</fr:taxon>
            <fr:meta name="doi">10.32408/compositionality-2-3</fr:meta>
            <fr:meta name="bibtex"><![CDATA[ @article
{rischel-fritz-infinite-products, title={Infinite products and zero-one laws in categorical probability}, volume={2}, ISSN={2631-4444}, DOI={10.32408/compositionality-2-3}, journal={Compositionality}, author={Fritz, Tobias and Rischel, Eigil Fjeldgren}, year={2020}, month={Aug}, pages={3},language={en} }]]></fr:meta>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>Tobias Fritz</fr:author>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>8</fr:month>
                  <fr:day>11</fr:day>
                </fr:date>
                <fr:title text="Abstract">Abstract</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
We state and prove the zero-one laws of Kolmogorov and Hewitt-Savage within the setting of Markov categories, a category-theoretic approach to the foundations of probability and statistics. This gives general versions of these results which can be instantiated not only in measure-theoretic probability, where they specialize to the standard ones in the setting of standard Borel spaces, but also in other contexts. For example, applying the Kolmogorov law to the Kleisli category of the hyperspace monad on topological spaces gives criteria for when maps out of an infinite product of topological spaces into a Hausdorff space are constant.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
      </fr:mainmatter>
    </fr:tree>
    <fr:tree show-metadata="false" expanded="false">
      <fr:frontmatter>
        <fr:authors>
          <fr:author>
            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
          </fr:author>
        </fr:authors>
        <fr:date>
          <fr:year>2025</fr:year>
          <fr:month>10</fr:month>
          <fr:day>15</fr:day>
        </fr:date>
        <fr:uri>https://erischel.com/efr-AE01/</fr:uri>
        <fr:display-uri>efr-AE01</fr:display-uri>
        <fr:route>/efr-AE01/</fr:route>
        <fr:title text="Blog">Blog</fr:title>
      </fr:frontmatter>
      <fr:mainmatter>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2025</fr:year>
              <fr:month>10</fr:month>
              <fr:day>13</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/efr-5NUC/</fr:uri>
            <fr:display-uri>efr-5NUC</fr:display-uri>
            <fr:route>/efr-5NUC/</fr:route>
            <fr:title text="A simple categorical proof of (a) Martingale Convergence Theorem">A simple categorical proof of (a) Martingale Convergence Theorem</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2025</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>13</fr:day>
                </fr:date>
                <fr:taxon>Theorem</fr:taxon>
              </fr:frontmatter>
              <fr:mainmatter><html:p>
    Let <fr:tex display="inline"><![CDATA[\Omega _1 \leftarrow  \Omega _2 \leftarrow  \dots ]]></fr:tex> be a sequence of probability spaces, for example <fr:tex display="inline"><![CDATA[\Omega _i = (\Omega , \mathcal {F}_i, P)]]></fr:tex> for some filtration of sigma-algebras. A <html:em>martingale</html:em> on this object is a sequence of random variables defined on <fr:tex display="inline"><![CDATA[\Omega _i]]></fr:tex> so that <fr:tex display="inline"><![CDATA[E[X_{i+1} \mid  \Omega _i] = X_i]]></fr:tex>. Let <fr:tex display="inline"><![CDATA[\Omega _\infty ]]></fr:tex> denote the limit of this diagram in probability spaces. Then every martingale of <fr:tex display="inline"><![CDATA[L^2]]></fr:tex>-random variables defines a sequence of random variables on <fr:tex display="inline"><![CDATA[\Omega _\infty ]]></fr:tex>. This sequence converges in <fr:tex display="inline"><![CDATA[L^2]]></fr:tex>, say to <fr:tex display="inline"><![CDATA[X_\infty ]]></fr:tex>, and <fr:tex display="inline"><![CDATA[X_n = E[X_\infty  \mid  \Omega _n]]]></fr:tex></html:p>
  <fr:tree show-metadata="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link></fr:author></fr:authors><fr:date><fr:year>2025</fr:year><fr:month>10</fr:month><fr:day>13</fr:day></fr:date><fr:taxon>Proof</fr:taxon></fr:frontmatter><fr:mainmatter>
  <html:p>
    Note that <fr:tex display="inline"><![CDATA[L^2(-)]]></fr:tex> defines a contravariant functor from probability spaces to Hilbert spaces and bounded maps. This functor carries the limit <fr:tex display="inline"><![CDATA[\Omega _\infty  = \lim _i \Omega _i]]></fr:tex> to a colimit. To see this, first note that it carries each map to an embedding (since every measure-preserving map is onto up to a set of measure zero), so it suffices to show that every <fr:tex display="inline"><![CDATA[L^2]]></fr:tex> measurable function <fr:tex display="inline"><![CDATA[f]]></fr:tex> on the limit is a limit of functions <fr:tex display="inline"><![CDATA[f_i]]></fr:tex> which factor over <fr:tex display="inline"><![CDATA[\Omega _i]]></fr:tex>.
  </html:p>
  <html:p>
    Let such an <fr:tex display="inline"><![CDATA[f]]></fr:tex> be given. Fix <fr:tex display="inline"><![CDATA[K]]></fr:tex> so that the <fr:tex display="inline"><![CDATA[L^2]]></fr:tex>-norm of the part of <fr:tex display="inline"><![CDATA[f]]></fr:tex> outside <fr:tex display="inline"><![CDATA[[-K,K]]]></fr:tex> is small. Partition <fr:tex display="inline"><![CDATA[[-K,K]]]></fr:tex> into intervals of width <fr:tex display="inline"><![CDATA[1/i]]></fr:tex>. Each of the sets <fr:tex display="inline"><![CDATA[f^{-1}([ k/i, k+1/i ))]]></fr:tex> is measurable. Hence there is some <fr:tex display="inline"><![CDATA[N_i]]></fr:tex> so that each of these intervals is approximated up to probability <fr:tex display="inline"><![CDATA[\epsilon  / i]]></fr:tex> by some <fr:tex display="inline"><![CDATA[\Omega _{N_i}]]></fr:tex>-measurable set. Define <fr:tex display="inline"><![CDATA[f_i]]></fr:tex> to be equal to <fr:tex display="inline"><![CDATA[k/i]]></fr:tex> on these approximating sets and zero outside of that. Then <fr:tex display="inline"><![CDATA[f_i]]></fr:tex> is within <fr:tex display="inline"><![CDATA[2\epsilon ]]></fr:tex> of <fr:tex display="inline"><![CDATA[f]]></fr:tex> in <fr:tex display="inline"><![CDATA[L^2]]></fr:tex>.
  </html:p>
  <html:p>
    Now since forming adjoints is a self-duality on Hilbert spaces, this immediately implies that <fr:tex display="inline"><![CDATA[L^2(\Omega _\infty )]]></fr:tex> is also the inverse limit of the adjoint diagram, where the map <fr:tex display="inline"><![CDATA[L^2(\Omega _{i+1}) \to  L^2(\Omega _i)]]></fr:tex> is given by conditional expectation. It is apparent that an element of this inverse limit is precisely a martingale. Hence every martingale is the conditional expectation of a unique 
  </html:p>
</fr:mainmatter></fr:tree>
</fr:mainmatter>
            </fr:tree>
            <html:p>
  This concept is essentially what is called a <html:em>bilimit</html:em> in domain theory and studied for embedding-projection pairs. 
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2023</fr:year>
              <fr:month>9</fr:month>
              <fr:day>28</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/againstcalibration/</fr:uri>
            <fr:display-uri>againstcalibration</fr:display-uri>
            <fr:route>/againstcalibration/</fr:route>
            <fr:title text="Against calibration">Against calibration</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Forecasting is predicting whether something will happen, like who will be the next US president or whether a natural disaster will happen or what the economy is going to be like in a year. It's notoriously difficult to think about. Typically who study this sort of thing think you should make quantifiable predictions with specific probabilities assigned to them, make them public, and then let people rate your performance later to figure out who's good at forecasting. I'm not gonna explain all this in too much detail. See eg the discussion at the start of <fr:link href="https://www.astralcodexten.com/p/mantic-monday-mantic-matt-y" type="external">this astralcodexten post</fr:link>.
</html:p>
            <html:p>
One way to rate forecasts is "Brier score".[^2] If you assign something probability <fr:tex display="inline"><![CDATA[p]]></fr:tex>, and it happens, your Brier score is <fr:tex display="inline"><![CDATA[(1-p)^2]]></fr:tex>. If it doesn't happen, your Brier score is <fr:tex display="inline"><![CDATA[p^2]]></fr:tex> (since you essentially said it wouldn't happen with probability <fr:tex display="inline"><![CDATA[1-p]]></fr:tex>). Lower is better - the lowest possible Brier score is <fr:tex display="inline"><![CDATA[0]]></fr:tex>, the highest is <fr:tex display="inline"><![CDATA[1.]]></fr:tex> If you make many predictions, your Brier score is the average Brier score across the whole set of questions.
</html:p>
            <html:p>
Another way to rate forecasters is "calibration". Calibration looks at the fraction of your "X% likely" predictions that occurred, and asks how close that fraction is to X% (for each X). Then you can plot it in graphs like this (source: <fr:link href="https://twitter.com/ManifoldMarkets/status/1661877668038709249" type="external">Manifold on twitter</fr:link>):
</html:p>
            <html:img src="/bafkrmiddkmgk3adcixtb4op774vly3bdu2npnwr4besw77hwhd2o3bjmi4.png" title="A calibration graph" />
            <html:p>
On average, clearly, 10% of your 10% predictions should come true if you're assigning probabilities sensibly, so it seems good to have good calibration. Brier scoring agrees with this, in the following sense: suppose in fact 14% of your 10% predictions come true. Then you would have obtained a higher Brier score by replacing all your 10% predictions with 14%[^1].
</html:p>
            <html:p>
[^1]: This is essentially what people mean when they say Brier scoring is a "proper scoring rule".
</html:p>
            <html:p>
There are a few reason people focus on calibration
</html:p>
            <html:ul><html:li>Perhaps most importantly, it's *comparable across question sets*. That is, if I make a bunch of predictions, and you make a *different set* of predictions, we can sensibly compare our calibration plots and see who did better. In contrast, predicting more difficult question sets will result in a lower Brier score even if you're doing as well as possible (in the limit, predicting coinflips, if you assign the correct 50-50 probability you'll get an average Brier score of 0.25, whereas if you predict events that happen 10% of the time and assign that probability correctly you'll get a Brier score of 0.09).</html:li>
  <html:li>There's some evidence that calibration is *trainable* and *generalizes.* That is, if you practice, you can improve your calibration, and if your calibration is good on one type of questions (say, about politics), it'll tend to be good on other questions (about technological advances, say) as well.</html:li></html:ul>
            <html:p>
These obviously make calibration a pretty useful concept, and I don't want to disparage that. It's good to practice your calibration if you want to make precise predictions, and it's good to publish your calibration graph if you want people to take your forecast seriously.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>9</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Calibration is a very weak statement about the quality of your forecasts">Calibration is a very weak statement about the quality of your forecasts</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Manifold (to their credit!) publishes their calibration plots. These are generally pretty good. Some people seem take this as strong evidence that Manifold makes good predictions.
</html:p>
                <html:p>
  We can try to think about perfect calibration in market terms. If some method could improve on Manifold's predictions, then that method could be turned into a profitable trading strategy. So we can think about statements that Manifold makes "good" predictions in terms of the classes of strategy they rule out. In the extreme case, if the market was perfectly efficient, no strategy could make a profit - meaning there's no way to improve the predictions.
</html:p>
                <html:p>
  Perfect calibration means that, (for example) of the markets currently trading at 10% YES, 10% will resolve YES. This means that no trading strategy of the type "whenever a market is valued at 10% YES, buy some of it" can make a profit in expectation. This is obviously an *incredibly weak* notion of market efficiency. We expect this to hold, but this doesn't mean the predictions are well-priced at all.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>9</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Good calibration doesn't mean you have a good Brier score">Good calibration doesn't mean you have a good Brier score</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Imagine two people forecasting the same set of 100 potential natural disasters. The first forecaster (call him A) assigns probability 1% to them all. The second forecaster (B) assigns probability 80% to two of them, and 2% to the rest. In the end, exactly one of the disasters happen, and it's one of the two that the second forecaster assigned 80% probability to.
</html:p>
                <html:p>
  A has perfect calibration. B, by contrast, has pretty bad calibration (his 80% "should" have been 50%, and his 2% should have been 0%).
</html:p>
                <html:p>
  But:
  - B has a better Brier score (A has <fr:tex display="inline"><![CDATA[(0.0099 + 0.99^2)/100]]></fr:tex>, B has approximately <fr:tex display="inline"><![CDATA[(0.8^2 + 0.2^2 + 0.0004 \cdot  98) /100]]></fr:tex>, and remember lower is better).
  - More to the point, B's forecast is *clearly more useful* - having some reasonable ideas *which* of the 100 potential disasters will happen is clearly more important than getting the overall rate right
  	- We could make this point even more stark by letting B assign 90% probability to the disaster that ended up happening, and 1% probability to the ones that don't.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>9</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Good calibration doesn't mean other people should adopt your forecasts">Good calibration doesn't mean other people should adopt your forecasts</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  People often say things like "X has good calibration, meaning when they say there's a 10% chance of something happening, it happens 10% of the time. So when they say there's a 10% chance of nuclear war (or whatever), we should take it seriously".
</html:p>
                <html:p>
  The first sentence is of course a correct explanation of calibration. But think of our disaster forecasters from before. A had perfect calibration, meaning when A says that disasters overall happen only one time in a hundred, he's right. But if he says that some *specific* disaster has a very low, 1%, probability of happening, we shouldn't necessarily take that forecast very seriously. Perhaps it's actually easy to know which 1% of disasters happen. A's ability to get the base rate right does say something about his forecasting, but the fact that he can't do better than the base rate doesn't prove that we can't, and should therefore adopt his forecast.
</html:p>
                <html:p>
  [^2]: Another is log scoring, where if you say X will happen with probability <fr:tex display="inline"><![CDATA[p]]></fr:tex> and it happens, you score is <fr:tex display="inline"><![CDATA[-\log  p]]></fr:tex> instead of <fr:tex display="inline"><![CDATA[(1-p)^2]]></fr:tex>. For our purposes the difference doesn't really matter (both have this property of being a "proper scoring rule", so if you have to assign the same probability to some set of questions, you optimize your score by assigning the fraction of them that comes out true).
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2023</fr:year>
              <fr:month>9</fr:month>
              <fr:day>20</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/coprods-lens-blogpost/</fr:uri>
            <fr:display-uri>coprods-lens-blogpost</fr:display-uri>
            <fr:route>/coprods-lens-blogpost/</fr:route>
            <fr:title text="Coproducts in the category of lenses">Coproducts in the category of lenses</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>9</fr:month>
                  <fr:day>20</fr:day>
                </fr:date>
                <fr:title text="Introduction">Introduction</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The category of bimorphic lenses and its many generalizations has been
  widely studied and utilized in applied category theory. We will not give
  a review of the literature here, but see e.g. Riley's paper on "optics"
  (one of the many generalizations) <fr:link href="/riley-optics/" title="Categories of optics" uri="https://erischel.com/riley-optics/" display-uri="riley-optics" type="local">Reference <fr:contextual-number uri="https://erischel.com/riley-optics/" display-uri="riley-optics" /></fr:link>, which includes a decent overview.
</html:p>
                <html:p>
  Dispensing with a point of notation, we will denote objects of the
  category of lenses <fr:tex display="inline"><![CDATA[\binom {A}{X}]]></fr:tex>, and morphisms
  <fr:tex display="inline"><![CDATA[\varphi : \binom {A}{X} \to  \binom {B}{Y}]]></fr:tex> as
  <fr:tex display="inline"><![CDATA[(\varphi ^+: X \to  Y,\varphi ^- : X \times  B \to  A)]]></fr:tex>. Note that we write
  the *forwards* pass on the bottom of the tuple, breaking with the
  convention used by Riley and many others.
</html:p>
                <html:p>
  The category <fr:tex display="inline"><![CDATA[\mathsf {Lens}= \mathsf {Lens}(\mathsf {Set})]]></fr:tex> of lenses
  embeds into the category of polynomial functors <fr:tex display="inline"><![CDATA[\mathsf {Poly}]]></fr:tex> and
  natural transformations as the full subcategory of functors of the form
  <fr:tex display="inline"><![CDATA[X \times  (-)^A]]></fr:tex>. Since <fr:tex display="inline"><![CDATA[\mathsf {Poly}]]></fr:tex> admits all coproducts, and these
  are computed pointwise, one immediate consequence is that we have the
  coproducts <fr:tex display="inline"><![CDATA[\binom {A}{X} + \binom {A}{Y} = \binom {A}{X + Y}]]></fr:tex> in
  <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex>. These seem to have been studied first by Hedges (<fr:link href="/hedges-morphisms-open-games/" title="Morphisms of Open Games" uri="https://erischel.com/hedges-morphisms-open-games/" display-uri="hedges-morphisms-open-games" type="local">Reference <fr:contextual-number uri="https://erischel.com/hedges-morphisms-open-games/" display-uri="hedges-morphisms-open-games" /></fr:link>). (For a reference on <fr:tex display="inline"><![CDATA[\mathsf {Poly}]]></fr:tex>,
  including this inclusion, see eg Spivak <fr:link href="/spivak-poly-abundant/" title="Poly: An abundant categorical setting for mode-dependent dynamics" uri="https://erischel.com/spivak-poly-abundant/" display-uri="spivak-poly-abundant" type="local">Reference <fr:contextual-number uri="https://erischel.com/spivak-poly-abundant/" display-uri="spivak-poly-abundant" /></fr:link>. <fr:tex display="inline"><![CDATA[\mathsf {Poly}]]></fr:tex> is another
  branch on the tree of generalizations of <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex>, studied
  extensively by Spivak and others).
</html:p>
                <html:p>
  Given the above, one might expect these to be all the coproducts of
  <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex> (up to isomorphism) - they are certainly the only ones
  preserved by this inclusion[^1]. But this turns out not to be the case.
</html:p>
                <html:p>
  Let's begin with a worked example of the "exotic" coproducts. Note that
  I simply denote by <fr:tex display="inline"><![CDATA[n \in  \mathbb {N}]]></fr:tex> the set <fr:tex display="inline"><![CDATA[\{1, \dots  n\}]]></fr:tex> with <fr:tex display="inline"><![CDATA[n]]></fr:tex>
  elements. In particular <fr:tex display="inline"><![CDATA[0]]></fr:tex> is the empty set.
</html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:taxon>Example</fr:taxon>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    In <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex>, <fr:tex display="inline"><![CDATA[\binom {0}{1} + \binom {1}{1} = \binom {0}{2}]]></fr:tex>, with the coproduct inclusions having as their forwards pass the two distinct maps <fr:tex display="inline"><![CDATA[1 \to  2]]></fr:tex>, and the backwards passes in both cases being trivial.
</html:p>
                    <html:p>
    To see this is a coproduct, consider the natural transformation
</html:p>
                    <fr:tex display="block"><![CDATA[\mathsf {Lens}\left (\binom {0}{2},\binom {A}{X}\right ) \to  \mathsf {Lens}\left (\binom {0}{1},\binom {A}{X}\right ) \times  \mathsf {Lens}\left (\binom {1}{1},\binom {A}{X}\right )]]></fr:tex>
                    <html:p>
    In the case where <fr:tex display="inline"><![CDATA[A]]></fr:tex> is nonempty, this is simply the map <fr:tex display="inline"><![CDATA[0 \to  0]]></fr:tex>, because there are no maps <fr:tex display="inline"><![CDATA[2 \times  A \to  0]]></fr:tex>, and also no maps <fr:tex display="inline"><![CDATA[1 \times  A \to  0]]></fr:tex>. Clearly <fr:tex display="inline"><![CDATA[0 \to  0]]></fr:tex> is a bijection. On the other hand if <fr:tex display="inline"><![CDATA[A]]></fr:tex> is empty, all the backwards passes are trivial, so we're just left with the map <fr:tex display="inline"><![CDATA[\mathsf {Set}(2,A) \to  \mathsf {Set}(1,A) \times  \mathsf {Set}(1,A)]]></fr:tex>, which is clearly a bijection. Hence this is a natural isomorphism, so we have a coproduct.
</html:p>
                    <html:p>
    To see why this is not preserved by the inclusion <fr:tex display="inline"><![CDATA[\mathsf {Lens}\hookrightarrow  \mathsf {Poly}]]></fr:tex>, consider the polynomial <fr:tex display="inline"><![CDATA[y \mapsto  y + 1]]></fr:tex> (this is the actual coproduct of the polynomials corresponding to these lenses). The inclusion maps from <fr:tex display="inline"><![CDATA[y = 1 \times  y^1]]></fr:tex> and <fr:tex display="inline"><![CDATA[1 = 1 \times  y^0]]></fr:tex> into this polynomial should induce a map from <fr:tex display="inline"><![CDATA[2 = 2 \times  y^0]]></fr:tex>, but of course there's no way to map into the <fr:tex display="inline"><![CDATA[y]]></fr:tex> (unless we map the entire thing into the <fr:tex display="inline"><![CDATA[1]]></fr:tex> component, but this clearly won't pull back to the inclusion map of <fr:tex display="inline"><![CDATA[y]]></fr:tex> when we compose with the map <fr:tex display="inline"><![CDATA[y \to  2]]></fr:tex>). The problem is that, where in the lens/monomial case, to have any maps at all the backwards set must be <fr:tex display="inline"><![CDATA[0]]></fr:tex>, making the whole backwards pass trivial, in the polynomial case we can have the backwards set be empty only when it's forced to be.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>9</fr:month>
                  <fr:day>20</fr:day>
                </fr:date>
                <fr:title text="The coproducts in \mathsf {Lens}">The coproducts in <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex></fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Having seen the above, we may begin to lose hope of understanding the coproducts in <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex> at all. Fortunately the situation is not completely chaotic - in some sense, the preceding example is the *only* problem - all the coproducts in <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex> are either of the form <fr:tex display="inline"><![CDATA[\binom {A}{\coprod _i X_i}]]></fr:tex> (up to isomorphism), or they are of the same form as the example.
</html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:taxon>Theorem</fr:taxon>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    In <fr:tex display="inline"><![CDATA[\mathsf {Lens}= \mathsf {Lens}(\mathsf {Set})]]></fr:tex>, a tuple of lenses <fr:tex display="inline"><![CDATA[\{\binom {A_i}{X_i} \overset {\varphi _i}{\to } \binom {B}{Y}\}]]></fr:tex> is a coproduct diagram if and only if the forwards passes <fr:tex display="inline"><![CDATA[\{X_i \to  Y\}]]></fr:tex> form a coproduct diagram in <fr:tex display="inline"><![CDATA[\mathsf {Set}]]></fr:tex>, and one of these conditions hold:
</html:p>
                    <html:ol><html:li>
    For all <fr:tex display="inline"><![CDATA[i]]></fr:tex>, and for all <fr:tex display="inline"><![CDATA[x \in  X_i]]></fr:tex>, the function
        <fr:tex display="inline"><![CDATA[\varphi _i(x, -): B \to  A_i]]></fr:tex> is a bijection.
</html:li>

<html:li>
    For at least one <fr:tex display="inline"><![CDATA[i]]></fr:tex>, <fr:tex display="inline"><![CDATA[A_i]]></fr:tex> is empty and <fr:tex display="inline"><![CDATA[X_i]]></fr:tex> is nonempty. (The existence of any lens <fr:tex display="inline"><![CDATA[\binom {A_i}{X_i} \to  \binom {B}{Y}]]></fr:tex> then implies that <fr:tex display="inline"><![CDATA[B]]></fr:tex> must be empty as well)
</html:li></html:ol>
                    <html:p>
    The first class of coproducts are the "good" ones - these are preserved by the functor from lenses to polynomial functors, and seem to capture the correct notion of "branching" for bidirectional systems. The other class, the "exotic" coproducts, are more mysterious.
</html:p>
                    <html:p>
    We will begin the proof of this theorem with some preliminaries about lenses in a general (Cartesian) distributive category. While we can't obtain the preceding theorem in this generality (for reasons that will become clear later), it may be useful to know what <html:em>can</html:em> be said here.
</html:p>
                    <html:p>
    Let us fix a (Cartesian) distributive category <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> - that is, <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> has finite products and coproducts, and the universal map <fr:tex display="inline"><![CDATA[\coprod _i A \times  X_i \to  A \times  (\coprod _i X_i)]]></fr:tex> is always an isomorphism. I will denote the initial object by <fr:tex display="inline"><![CDATA[0]]></fr:tex>.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:title text="Proposition 2.2">Proposition 2.2</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The functor <fr:tex display="inline"><![CDATA[\mathsf {Lens}(\mathcal {C}) \to  \mathcal {C}]]></fr:tex> which carries <fr:tex display="inline"><![CDATA[\binom {A}{X}]]></fr:tex> to <fr:tex display="inline"><![CDATA[X]]></fr:tex> and a lens <fr:tex display="inline"><![CDATA[(\varphi ^+, \varphi ^-)]]></fr:tex> to its foward pass <fr:tex display="inline"><![CDATA[\varphi ^+]]></fr:tex> admits a right adjoint, given by <fr:tex display="inline"><![CDATA[X \mapsto  \binom {0}{X}]]></fr:tex>.
</html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2023</fr:year>
                          <fr:month>9</fr:month>
                          <fr:day>20</fr:day>
                        </fr:date>
                        <fr:taxon>Proof</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
      We simply have to verify <fr:tex display="inline"><![CDATA[\mathsf {Lens}(\mathcal {C})(\binom {A}{X},\binom {0}{Y}) = \mathcal {C}(X,Y)]]></fr:tex>. But this is trivial - the forwards pass of such a lens is clearly an element of the right-hand side, so it suffices to prove that there is always a unique choice of backwards pass. But the backwards pass is a map <fr:tex display="inline"><![CDATA[0 \times  X \to  A]]></fr:tex>, and by distributivity <fr:tex display="inline"><![CDATA[0 \times  X]]></fr:tex> is initial. This concludes the proof.
</html:p>
                        <html:p>
      Because left adjoints preserve (in particular) coproducts, we obtain the following:
    </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:taxon>Corollary</fr:taxon>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    For a tuple <fr:tex display="inline"><![CDATA[\{\binom {A_i}{X_i} \overset {\varphi _i}{\to } \binom {B}{Y}\}]]></fr:tex> to be a coproduct diagram, the forwards passes <fr:tex display="inline"><![CDATA[X_i \to  Y]]></fr:tex> must form a coproduct diagram in <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>.
</html:p>
                  </fr:mainmatter>
                </fr:tree>
                <html:p>
    The following result, characterizing the "good" coproducts, was already essentially proven by Hedges in <fr:link href="/hedges-morphisms-open-games/" title="Morphisms of Open Games" uri="https://erischel.com/hedges-morphisms-open-games/" display-uri="hedges-morphisms-open-games" type="local">Reference <fr:contextual-number uri="https://erischel.com/hedges-morphisms-open-games/" display-uri="hedges-morphisms-open-games" /></fr:link> [^2], but I'll state it here and sketch a proof for completeness.
  </html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:taxon>Proposition</fr:taxon>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    Let <fr:tex display="inline"><![CDATA[X_i]]></fr:tex> be a collection of objects of <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>, and <fr:tex display="inline"><![CDATA[\coprod _i X_i]]></fr:tex> a coproduct. Let also <fr:tex display="inline"><![CDATA[A \in  \mathcal {C}]]></fr:tex>. Then the family of lenses <fr:tex display="inline"><![CDATA[\binom {A}{X_i} \to  \binom {A}{\coprod _i X_i}]]></fr:tex> with forwards passes given by the coproduct inclusions, and backwards passes by the projection <fr:tex display="inline"><![CDATA[X_i \times  A \to  A]]></fr:tex>, is a coproduct diagram.
</html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2023</fr:year>
                          <fr:month>9</fr:month>
                          <fr:day>20</fr:day>
                        </fr:date>
                        <fr:taxon>Proof</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <fr:tex display="block"><![CDATA[\mathsf {Lens}(\mathcal {C})(\binom {A}{\coprod _i X_i},\binom {B}{Y}) = \mathcal {C}(\coprod _i X_i, B) \times  \mathcal {C}((\coprod _i X_i) \times  B, a)]]></fr:tex>
                        <fr:tex display="block"><![CDATA[\cong  \prod _i \left (\mathcal {C}(X_i, B) \times  \mathcal {C}(X_i \times  B, a)\right ),]]></fr:tex>
                        <html:p>
      using the universal property of coproducts and the distributivity. This is clearly the set of tuples of lenses <fr:tex display="inline"><![CDATA[\binom {A}{X_i} \to  \binom {B}{Y}]]></fr:tex>, and moreover precomposition with the inclusion maps clearly picks out the elements of the tuple, verifying
      the universal property of the coproduct.
    </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:taxon>Proposition</fr:taxon>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    Let a tuple <fr:tex display="inline"><![CDATA[\{\binom {A_i}{X_i} \overset {\varphi _i}{\to } \binom {B}{\coprod _i X_i}\}]]></fr:tex> be given, such that each <fr:tex display="inline"><![CDATA[\varphi _i^+: X_i \to  \coprod _j X_j]]></fr:tex> is the coproduct inclusion.
</html:p>
                    <html:p>
    Given some object <fr:tex display="inline"><![CDATA[C \in  \mathcal {C}]]></fr:tex>, each <fr:tex display="inline"><![CDATA[\varphi _i^-: X_i \times  B \to  A_i]]></fr:tex> determines a map <fr:tex display="inline"><![CDATA[ (\varphi _i^-)^*: \mathcal {C}(X_i \times  C, B) \to  \mathcal {C}(X_i \times  C, A_i) ]]></fr:tex>, given by <fr:tex display="inline"><![CDATA[ (\varphi _i^-)^*\psi (x,c) = \varphi _i^-(x,\psi (x,c))]]></fr:tex>. The tuple <fr:tex display="inline"><![CDATA[(\varphi _i)]]></fr:tex> is a coproduct diagram if and only if, for all <fr:tex display="inline"><![CDATA[C]]></fr:tex>, one of these conditions hold (not necessarily the same one for each <fr:tex display="inline"><![CDATA[C]]></fr:tex>):
</html:p>
                    <html:p>
    1.  Each <fr:tex display="inline"><![CDATA[(\varphi _i^-)^*]]></fr:tex> is a bijection.
</html:p>
                    <html:p>
    2.  For some <fr:tex display="inline"><![CDATA[i]]></fr:tex>, the set <fr:tex display="inline"><![CDATA[\mathcal {C}(X_i \times  C, A_i)]]></fr:tex> is empty.
</html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2023</fr:year>
                          <fr:month>9</fr:month>
                          <fr:day>20</fr:day>
                        </fr:date>
                        <fr:taxon>Proof</fr:taxon>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
      Note that each of the lenses <fr:tex display="inline"><![CDATA[\varphi _i]]></fr:tex> factors as <fr:tex display="inline"><![CDATA[\binom {A_i}{X_i} \to  \binom {B}{X_i} \to  \binom {B}{\coprod  X_i} = \coprod _i \binom {B}{X_i}]]></fr:tex>, where the first map is <fr:tex display="inline"><![CDATA[(1_{X_i},\varphi _i^-)]]></fr:tex>, and the second map is
      the coproduct inclusion.
</html:p>
                        <html:p>
      Hence the natural transformation
</html:p>
                        <fr:tex display="block"><![CDATA[\alpha : \mathsf {Lens}(\mathcal {C})\left (\binom {B}{\coprod _i X_i},\binom {C}{Z}\right ) \to  \prod _i \mathsf {Lens}(\mathcal {C})\left (\binom {A_i}{X_i},\binom {C}{Z}\right )]]></fr:tex>
                        <html:p>
      factors as
</html:p>
                        <fr:tex display="block"><![CDATA[\mathsf {Lens}(\mathcal {C})\left (\binom {B}{\coprod _i X_i},\binom {C}{Z}\right )
          \cong  \prod _i\mathsf {Lens}(\mathcal {C})\left (\binom {B}{X_i},\binom {C}{Z}\right )]]></fr:tex>
                        <fr:tex display="block"><![CDATA[\to  \prod _i\mathsf {Lens}(\mathcal {C})\left (\binom {A_i}{X_i},\binom {C}{Z}\right )]]></fr:tex>
                        <html:p>
      where the second map is the parallel product of the precomposition morphisms <fr:tex display="inline"><![CDATA[- \circ  (1_{X_i},\varphi _i^-)]]></fr:tex> for each <fr:tex display="inline"><![CDATA[i]]></fr:tex>.
</html:p>
                        <html:p>
      The tuple is a coproduct diagram if and only if this composite is a bijection, which is true if and only if this second map is a bijection.
</html:p>
                        <html:p>
      A product of functions in <fr:tex display="inline"><![CDATA[\mathsf {Set}]]></fr:tex> is a bijection if and only if each component map is a bijection, or one of the product sets in the target is empty (in which case the corresponding set in the domain must be empty as well for a map to exist, and so both products are empty).
</html:p>
                        <html:p>
      We can rewrite the sets involved here as
</html:p>
                        <fr:tex display="block"><![CDATA[\mathsf {Lens}(\mathcal {C})\left (\binom {B}{X_i},\binom {C}{Z}\right ) = \mathsf {Set}(X_i,Z) \times  \mathsf {Set}(X_i \times  C, B),]]></fr:tex>
                        <html:p>
      and
</html:p>
                        <fr:tex display="block"><![CDATA[\mathsf {Lens}(\mathcal {C})\left (\binom {A_i}{X_i},\binom {C}{Z}\right ) = \mathsf {Set}(X_i,Z) \times  \mathsf {Set}(X_i \times  C, A_i).]]></fr:tex>
                        <html:p>
      This is simply the definition of <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex></html:p>
                        <html:p>
      Under this expansion the map <fr:tex display="inline"><![CDATA[- \circ  (1_{X_i},\varphi _i^-)]]></fr:tex> carries a lens <fr:tex display="inline"><![CDATA[(\psi ^+, \psi ^-)]]></fr:tex> to <fr:tex display="inline"><![CDATA[(\psi ^+, (\varphi _i^-)^*\psi ^-)]]></fr:tex>. So <fr:tex display="inline"><![CDATA[- \circ  (1_{X_i},\varphi _i^-)i]]></fr:tex> is a bijection if and only if we have <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i,Z)]]></fr:tex> empty or <fr:tex display="inline"><![CDATA[(\varphi _i^-)^*]]></fr:tex> a bijection (or both).
</html:p>
                        <html:p>
      Now, clearly if condition 1. holds, we've just seen that each <fr:tex display="inline"><![CDATA[- \circ  (1_{X_i},\varphi _i^-)]]></fr:tex> becomes a bijection, and so our map <fr:tex display="inline"><![CDATA[\alpha ]]></fr:tex> is a bijection. If condition 2. holds, then <fr:tex display="inline"><![CDATA[\mathsf {Lens}(\mathcal {C})\left (\binom {A_i}{X_i},\binom {C}{Z}\right )]]></fr:tex> is empty, and so we again have a (trivial) bijection.
</html:p>
                        <html:p>
      So if at least one of the conditions hold for each <fr:tex display="inline"><![CDATA[C]]></fr:tex>, <fr:tex display="inline"><![CDATA[\alpha ]]></fr:tex> is always a bijection, and so we have a coproduct.
</html:p>
                        <html:p>
      On the other hand, suppose there is some <fr:tex display="inline"><![CDATA[C]]></fr:tex> so that neither condition holds. Take <fr:tex display="inline"><![CDATA[Z = \coprod _i X_i]]></fr:tex>. Then none of the mapping sets <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i, Z = \coprod _i X_i)]]></fr:tex> are empty, so the only way for <fr:tex display="inline"><![CDATA[- \circ  (1_{X_i},\varphi _i^-)]]></fr:tex> to be a bijection is for <fr:tex display="inline"><![CDATA[(\varphi _i^-)^*]]></fr:tex> to be a bijection, but by hypothesis this fails for at least one <fr:tex display="inline"><![CDATA[i]]></fr:tex>. By assumption none of the sets <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> are empty, and none of the sets <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i, Z)]]></fr:tex> are empty either, so the product is not empty - hence the map <fr:tex display="inline"><![CDATA[\alpha ]]></fr:tex> is not a bijection in this case.
</html:p>
                        <html:p>
      We can now return to the main theorem. The following argument is somewhat clunky and ad hoc. The main point is that we can characterize the cases where <fr:tex display="inline"><![CDATA[\mathsf {Set}(U,V)]]></fr:tex> is empty, namely only when <fr:tex display="inline"><![CDATA[V]]></fr:tex> is empty and <fr:tex display="inline"><![CDATA[U]]></fr:tex> is not. In a general category, this can be much more complicated, and there does not seem to be any completely general method. This means we don't know which possible <fr:tex display="inline"><![CDATA[C]]></fr:tex> we need to deal with when understanding when the backwards pass is a bijection, which makes it seemingly impossible to give a general classification of the coproducts by this method.
</html:p>
                        <html:p>
      (The second point is that it's easy to understand when the maps between hom-spaces are bijections in <fr:tex display="inline"><![CDATA[\mathsf {Set}]]></fr:tex> - we have a somewhat clunky argument but it's pretty straightforward and it can probably be done in a more conceptual way, if one took the time to find it).
</html:p>
                        <html:p>
      We can replace <fr:tex display="inline"><![CDATA[Y]]></fr:tex> with the coproduct <fr:tex display="inline"><![CDATA[\coprod _i X_i]]></fr:tex>, and each forwards pass <fr:tex display="inline"><![CDATA[\varphi _i^+]]></fr:tex> with the inclusion, without loss of generality (if we are not in this situation up to isomorphism, we don't have a coproduct by the above)
    </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2023</fr:year>
                      <fr:month>9</fr:month>
                      <fr:day>20</fr:day>
                    </fr:date>
                    <fr:title text="Proof of the theorem">Proof of the theorem</fr:title>
                    <fr:taxon>Proof</fr:taxon>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    It's clear that the first condition of the theorem implies that <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i \times  C, B) \to  \mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> is a bijection always, and so we have a coproduct. As for the second condition, suppose <fr:tex display="inline"><![CDATA[X_i]]></fr:tex> is nonempty and <fr:tex display="inline"><![CDATA[A_i]]></fr:tex> is empty. Then for nonempty <fr:tex display="inline"><![CDATA[C]]></fr:tex>, the set <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> is clearly empty, fulfilling the second condition of the lemma, whereas for empty <fr:tex display="inline"><![CDATA[C]]></fr:tex>, the map <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i \times  C, B) \to  \mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> is a map between two singletons (since <fr:tex display="inline"><![CDATA[X_i \times  C]]></fr:tex> is empty), and hence a
    bijection.
</html:p>
                    <html:p>
    This proves that if one of the two conditions hold, we have a coproduct. To see the other direction, suppose neither condition holds. If the second condition doesn't hold, then there is always a map <fr:tex display="inline"><![CDATA[X_i \to  A_i]]></fr:tex>, and hence the set <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> is never empty, so according to the lemma, it suffices to show that for some <fr:tex display="inline"><![CDATA[i]]></fr:tex> and some <fr:tex display="inline"><![CDATA[C]]></fr:tex>, the map <fr:tex display="inline"><![CDATA[(\varphi _i^-)^*: \mathsf {Set}(X_i \times  C, B) \to  \mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> is not a bijection.
</html:p>
                    <html:p>
    Since the first condition doesn't hold, let <fr:tex display="inline"><![CDATA[j, x' \in  X_j]]></fr:tex> be such that the map <fr:tex display="inline"><![CDATA[\varphi ^-_j(x',-): B \to  A_j]]></fr:tex> is not a bijection. Suppose first it's not surjective and let <fr:tex display="inline"><![CDATA[a']]></fr:tex> be something not in the image. 
</html:p>
                    <html:p>
    Take <fr:tex display="inline"><![CDATA[C = *]]></fr:tex>. Then the constant function <fr:tex display="inline"><![CDATA[- \mapsto  a' : X_j \times  * \to  A_j]]></fr:tex> is clearly not in the image of <fr:tex display="inline"><![CDATA[(\varphi _j^-)^*]]></fr:tex>, since that would require, for some <fr:tex display="inline"><![CDATA[\psi ]]></fr:tex>,
    <fr:tex display="inline"><![CDATA[\varphi _j^-(x,\psi (x,*)) = a']]></fr:tex> for all <fr:tex display="inline"><![CDATA[x]]></fr:tex>, and in particular for <fr:tex display="inline"><![CDATA[x = x']]></fr:tex>, but that's a contradiction.
</html:p>
                    <html:p>
    On the other hand suppose it's not injective, and that <fr:tex display="inline"><![CDATA[\varphi _j^-(x',b_0) = \varphi _j^-(x',b_1)]]></fr:tex> for some <fr:tex display="inline"><![CDATA[b_0,b_1 \in  B]]></fr:tex>. Now take <fr:tex display="inline"><![CDATA[C = B]]></fr:tex> and consider a function <fr:tex display="inline"><![CDATA[\psi : X_j \times  B \to  B]]></fr:tex>, defined by <fr:tex display="inline"><![CDATA[\psi (x',b_0) = b_1]]></fr:tex>, and <fr:tex display="inline"><![CDATA[\psi (x,b) = b]]></fr:tex> for all other pairs <fr:tex display="inline"><![CDATA[(x,b)]]></fr:tex>. Now <fr:tex display="inline"><![CDATA[\varphi _j^-(x',\psi (x',b_0)) = \varphi _j^-(x',b_1) = \varphi _j^-(x',b_0)]]></fr:tex>. And for all other <fr:tex display="inline"><![CDATA[x]]></fr:tex> or <fr:tex display="inline"><![CDATA[b]]></fr:tex>, clearly <fr:tex display="inline"><![CDATA[\varphi _j^-(x,\psi (x,b)) = \varphi _j^-(x,b)]]></fr:tex>. Hence <fr:tex display="inline"><![CDATA[(\varphi _j^-)^*\psi  = (\varphi _j^-)*(\pi _B: X_j \times  B \to  B)]]></fr:tex> (<fr:tex display="inline"><![CDATA[\pi _B]]></fr:tex> being the projection). But <fr:tex display="inline"><![CDATA[\psi  \neq  \pi _B]]></fr:tex>, so <fr:tex display="inline"><![CDATA[(\varphi _j^-)^*]]></fr:tex> is not injective in this case. This concludes the proof.
</html:p>
                    <html:p>
    The forwards part of this proof almost works for any distributive category <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> with a *strict* initial object (meaning the only maps <fr:tex display="inline"><![CDATA[X \to  0]]></fr:tex> are isomorphisms, i.e <fr:tex display="inline"><![CDATA[X]]></fr:tex> has to be another initial object). The trouble is that <fr:tex display="inline"><![CDATA[X_i \times  C]]></fr:tex> can be initial even when neither <fr:tex display="inline"><![CDATA[X_i]]></fr:tex> nor <fr:tex display="inline"><![CDATA[C]]></fr:tex> is, meaning even when <fr:tex display="inline"><![CDATA[A_i]]></fr:tex> is initial and <fr:tex display="inline"><![CDATA[X_i]]></fr:tex> isn't, the nonemptyness of <fr:tex display="inline"><![CDATA[\mathsf {Set}(X_i \times  C, A_i)]]></fr:tex> does not imply that <fr:tex display="inline"><![CDATA[C]]></fr:tex> is initial, meaning that we don't automatically get that all the <fr:tex display="inline"><![CDATA[(\varphi _i^-)^*]]></fr:tex> maps are bijections. A simple example of this is something like <fr:tex display="inline"><![CDATA[\mathcal {C} = \mathsf {Set}^k]]></fr:tex> for some natural number <fr:tex display="inline"><![CDATA[k > 1]]></fr:tex>. Then as long as we have <fr:tex display="inline"><![CDATA[C^{(n)}]]></fr:tex> empty *or* <fr:tex display="inline"><![CDATA[X_i^{(n)}]]></fr:tex> empty for each <fr:tex display="inline"><![CDATA[n = 1 \dots  k]]></fr:tex>, their product is empty.
</html:p>
                    <html:p>
    A more general class of example with the same flavor is <fr:tex display="inline"><![CDATA[\mathcal {C} = Sh(X)]]></fr:tex> the category of sheaves on a topological space. Then again as long as the supports of <fr:tex display="inline"><![CDATA[C]]></fr:tex> and <fr:tex display="inline"><![CDATA[X_i]]></fr:tex> are disjoint, their product is empty.
</html:p>
                    <html:p>
    It may be possible to develop a generalization of the theorem, or at least of the forwards part of the theorem, using considerations like
    these to control the sets of morphisms.
</html:p>
                    <html:p>
    [^1]: There is a quibble here, since <fr:tex display="inline"><![CDATA[\binom {A}{0} \cong  \binom {B}{0}]]></fr:tex>
        for any sets <fr:tex display="inline"><![CDATA[A,B]]></fr:tex>, these being the initial objects of
        <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex>. This is of course the natural "nullary" version of
        the binary formula, but it also means that
        <fr:tex display="inline"><![CDATA[\binom {A}{0}+\binom {B}{X} = \binom {B}{X}]]></fr:tex>, and that this coproduct
        is preserved by the inclusion into <fr:tex display="inline"><![CDATA[\mathsf {Poly}]]></fr:tex>, even if
        <fr:tex display="inline"><![CDATA[A \not \cong  B]]></fr:tex>.
</html:p>
                    <html:p>
    [^2]: Hedges states it only for <fr:tex display="inline"><![CDATA[\mathcal {C} = \mathsf {Set}]]></fr:tex>, but his
        proof goes through unaltered for our case. He also only constructs a
        particular family of coproduct diagrams, but the ones considered
        here are just his composed with isomorphisms in <fr:tex display="inline"><![CDATA[\mathsf {Lens}]]></fr:tex>, so
        there is really nothing serious going on
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2022</fr:year>
              <fr:month>11</fr:month>
              <fr:day>15</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/kelly-betting/</fr:uri>
            <fr:display-uri>kelly-betting</fr:display-uri>
            <fr:route>/kelly-betting/</fr:route>
            <fr:title text="Thoughts on the Kelly Criterion">Thoughts on the Kelly Criterion</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
(Epistemic status: contains some mildly sloppy math, but is essentially true).
</html:p>
            <html:p>
Suppose someone offers you the chance to bet some money on a coinflip. On a heads, you multiply your stake by <fr:tex display="inline"><![CDATA[3.75]]></fr:tex>, but if you lose, you lose your stake. Should you bet, and how much? Clearly this bet has positive *expected value*, and higher expected value the more your bet, but equally clearly, the actual decision depends a lot on your circumstances - and you'd be a fool to bet your entire life savings on this, or to take out as large a loan as possible to gamble on it.
</html:p>
            <html:p>
One way of thinking about a bet like this is the so-called <fr:link href="https://en.wikipedia.org/wiki/Kelly_criterion" type="external">Kelly criterion</fr:link>. It's a particular formula for how large a fraction of your total wealth you should bet (depending on the odds of the bet), with the following nice property: if you make an infinite sequence of bets at the same odds, and bet the Kelly at each opportunity, your total profit is eventually larger than any other betting strategy, with probability 1.
</html:p>
            <html:p>
Since the Kelly criterion never bets its entire bankroll, but the EV-maximizing thing is always to bet your entire bankroll, some people take this to mean there's some fundamental flaw with EV in this case - that expected value is simply misapplied to one bet in a sequence like this.
It's true that we have to be more careful here - if the thing we care about is our wealth after some sequence of <fr:tex display="inline"><![CDATA[N]]></fr:tex> bets (<fr:tex display="inline"><![CDATA[N]]></fr:tex> going to <fr:tex display="inline"><![CDATA[\infty ]]></fr:tex>), we can't just assume that we should maximize EV after one bet. But if we try to maximize EV after <fr:tex display="inline"><![CDATA[N]]></fr:tex> bets, we *still* find that the maximizing thing is to bet the entire bankroll every time. But how can this be true if the Kelly dominates every other strategy with probability 1? What's going on here?
</html:p>
            <html:p>
---
</html:p>
            <html:p>
One way you can justify evaluating bets by their expected value is this: suppose you will get many opportunities to take a given bet, and the way the payouts aggregate is additive - that is, your total “score” that you care about maximizing is the score from each independent instance of the bet added together. Then, assuming the variance of each bet outcome is not too heavy-tailed, as the number of bets goes to infinity, the distribution of the sums approximates a normal distribution with median <fr:tex display="inline"><![CDATA[NE]]></fr:tex> and variance proportional to <fr:tex display="inline"><![CDATA[\sqrt {N}]]></fr:tex>, where <fr:tex display="inline"><![CDATA[n]]></fr:tex> is the number of bets and <fr:tex display="inline"><![CDATA[E]]></fr:tex> is the expected value.[^1]
</html:p>
            <html:p>
Since for large <fr:tex display="inline"><![CDATA[n]]></fr:tex> the variance is much smaller than the expected value, the final outcome is more or less entirely determined by the expected value! This type of result is called a concentration theorem. This is a powerful justification for replacing a bet with its expected value, but only if bets combine additively!
</html:p>
            <html:p>
For example, suppose the bet is something like “invest all your money in the stock market for a year”. You will get many opportunities to make this bet, but it’s not really appropriate to treat them additively - because, if you make a profit one year, you have more to invest next year, meaning you’ll be able to make an even bigger profit then, and vice versa if you lose.
</html:p>
            <html:p>
Suppose a stock market investment has a <fr:tex display="inline"><![CDATA[50%]]></fr:tex> chance of multiplying your investment by <fr:tex display="inline"><![CDATA[1.5]]></fr:tex>, and a <fr:tex display="inline"><![CDATA[50%]]></fr:tex> chance of multiplying it by <fr:tex display="inline"><![CDATA[0.6]]></fr:tex>. This is positive expected value, but if you execute this investment many times, it’s not the case that with high probability you’ll increase your money by some amount - in fact, with high probability, your total amount of money will converge to <fr:tex display="inline"><![CDATA[0]]></fr:tex>!
</html:p>
            <html:p>
We can prove this by noting that this bet aggregates by multiplication - your final score is the product of your initial bankroll, <fr:tex display="inline"><![CDATA[1.5]]></fr:tex> for every win, and <fr:tex display="inline"><![CDATA[0.6]]></fr:tex> for every loss. This means that the logarithm of your final score is the sum of the logarithm of your bankroll, log(1.5) for every win, and <fr:tex display="inline"><![CDATA[\log  0.6]]></fr:tex> for every loss. Hence by the concentration theorem discussed above, the logarithm will tend toward <fr:tex display="inline"><![CDATA[\frac {n (\log  1.5 - \log  0.6)}{2}]]></fr:tex>, and since 
<fr:tex display="inline"><![CDATA[\log  1.5 - \log  0.6 = \log  0.9]]></fr:tex> is negative, this goes towards negative infinity, meaning your actual score must go to zero.
</html:p>
            <html:p>
So IF the concentration theorem was your reason for taking EV seriously, you’re forced to work with expected log score in the case of multiplicative bets, which, if you do the math, leads you to the Kelly criterion for how much to bet each round.
</html:p>
            <html:p>
BUT! Who says you should care about concentration theorems? The concentration theorem says there is at most a low probability that the log of your score is big - but if the log of your score is big, then your score must be really big! If you do the math, you’ll see that the expected value of a “bet everything every time” strategy with the odds above, given <fr:tex display="inline"><![CDATA[n]]></fr:tex> bets, is <fr:tex display="inline"><![CDATA[1.05^{n/2}]]></fr:tex> - which goes to infinity as n does. Of course, clearly most of this EV must live in some very unlikely outcomes.
</html:p>
            <html:p>
When economists bring out something like the Von Neumann-Morgenstern theorem to say that rational actions are described by maximizing EV of some “utility” random variable, they’re simply not invoking a concentration theorem, so saying “the concentration theorem doesn’t apply” is just not a useful knockdown, and it doesn’t mean that utility maximization theory fails to account for this type of repeated bets. Of course, utility theory doesn’t rule out the Kelly betting behavior either - Kelly betting is perfectly rational, explained by utility that’s logarithmic in money (or whatever the bet is being made in).
</html:p>
            <html:p>
[^1]: The mean, that is to say the sum of the first <fr:tex display="inline"><![CDATA[n]]></fr:tex> samples divided by <fr:tex display="inline"><![CDATA[n]]></fr:tex>, always converges to the expected value with probability <fr:tex display="inline"><![CDATA[1]]></fr:tex>, this is "the law of large numbers". Of course maximizing <fr:tex display="inline"><![CDATA[x]]></fr:tex> and maximizing <fr:tex display="inline"><![CDATA[x/n]]></fr:tex> amounts to the same thing, but you probably should care about the fact that the variance is growing with <fr:tex display="inline"><![CDATA[n]]></fr:tex>!
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2022</fr:year>
              <fr:month>6</fr:month>
              <fr:day>4</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/approximate-categories/</fr:uri>
            <fr:display-uri>approximate-categories</fr:display-uri>
            <fr:route>/approximate-categories/</fr:route>
            <fr:title text="An approach to approximate category theory">An approach to approximate category theory</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
A number of different people have thought about ways to bring notions of
approximation into category theory. There seem to be essentially two
notions that one would like to express here:
</html:p>
            <html:p>
1.  The idea that a digram, while it may not quite commute, commutes *up
    to some specified tolerance <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex>*
</html:p>
            <html:p>
2.  The idea that a mapping, while it may not quite preserve the
    relevant structures, preserves them *up to some specified tolerance
    <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex>*.
</html:p>
            <html:p>
The first idea is, at a basic level, captured by categories enriched in
(some monoidal category of) metric spaces, whereas the other can be
captured by categories enriched in some category of sets with a function
<fr:tex display="inline"><![CDATA[S \to  \mathbb {R}]]></fr:tex>, again equipped with a monoidal product suitable for
the purpose at hand.
</html:p>
            <html:p>
Categories enriched in metric spaces can be weakened to the *metagories*
of Tholen and Wang (<fr:link href="https://arxiv.org/abs/1810.08828" type="external">link</fr:link>) - these are, essentially, graphs with an "area"
measure <fr:tex display="inline"><![CDATA[A(f,g,h) \in  [ 0,\infty  )]]></fr:tex>, defined whenever <fr:tex display="inline"><![CDATA[f:x \to  y]]></fr:tex>,
<fr:tex display="inline"><![CDATA[g:y \to  z]]></fr:tex> and <fr:tex display="inline"><![CDATA[h: x \to  z]]></fr:tex> form the edges of a 2-simplex, satisfying
some sort of resonable 2-dimensional analogue of the triangle
inequality. The basic idea is that the area measure indicates the
failure of the given triangle to commute. So if <fr:tex display="inline"><![CDATA[A(f,g,h) = 0]]></fr:tex>, <fr:tex display="inline"><![CDATA[h]]></fr:tex> is a
suitable choice for <fr:tex display="inline"><![CDATA[g \circ  f]]></fr:tex>. The axioms correspond to unitality and
associativity. They also imply that
</html:p>
            <html:p>
1.  The set of maps <fr:tex display="inline"><![CDATA[x \to  y]]></fr:tex> has a pseudometric[^1]
</html:p>
            <html:p>
2.  Composites in the sense above are well-defined up to distance zero,
    i.e given two choices of composite they have <fr:tex display="inline"><![CDATA[d(h,h') = 0]]></fr:tex>.
</html:p>
            <html:p>
Of course, given a category enriched in metric spaces, you can take
<fr:tex display="inline"><![CDATA[A(f,g,h) = d(gf,h)]]></fr:tex>.
</html:p>
            <html:p>
The second idea seems to be Paolo Perrone is discussing in <fr:link href="https://www.youtube.com/watch?v=JEOKvG1zcbY" type="external">this talk</fr:link>, calling categories like this "weighted categories".
</html:p>
            <html:p>
I want to spell out here a common generalization of the two approaches
to "quantitative category theory" that I haven't seen discussed anywhere
else. I think, beyond the convenience of having a formalism capturing
both ideas, it is in fact natural to do so - certain operations, natural
to a category theorist, take you from one of these worlds to the other,
in a way that's neatly described by this approach. That being said,
there are still some issues, which I'll also discuss.
</html:p>
            <html:p>
The basic approach is to consider a type of *filtered simplicial set*,
i.e a functor <fr:tex display="inline"><![CDATA[\Delta ^{op} \times  ([ 0, \infty  ), \leq ) \to  \mathsf {Set}]]></fr:tex>.
Let's write this as <fr:tex display="inline"><![CDATA[X([n],r) = X^{\leq  r}[n]]]></fr:tex>. We will probably want to
assume that the maps <fr:tex display="inline"><![CDATA[X^{\leq  r}[n] \to  X^{\leq  r'}[n]]]></fr:tex> for <fr:tex display="inline"><![CDATA[r \leq  r']]></fr:tex>
are all injections. Such an object is almost the same thing as a
simplicial set (defined by
<fr:tex display="inline"><![CDATA[X^{\leq  \infty }[n] = \mathop {\mathrm {colim}}_{r}X^{\leq  r}[n]]]></fr:tex>) where
each simplex <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex> has an associated real number
<fr:tex display="inline"><![CDATA[r(\sigma ) \in  [ 0, \infty  )]]></fr:tex>, given by the first <fr:tex display="inline"><![CDATA[r]]></fr:tex> where that simplex
appears in <fr:tex display="inline"><![CDATA[X^{\leq  r}[n] \subseteq  X^{\leq  \infty }[n]]]></fr:tex>, such that the
face an degeneracy maps never increase <fr:tex display="inline"><![CDATA[r]]></fr:tex>. This is not quite correct,
because for each simplex the set of <fr:tex display="inline"><![CDATA[r]]></fr:tex> such that
<fr:tex display="inline"><![CDATA[\sigma  \in  X^{\leq  r}]]></fr:tex> can be either <fr:tex display="inline"><![CDATA[[ a, \infty  )]]></fr:tex> or <fr:tex display="inline"><![CDATA[(a,\infty )]]></fr:tex> for
some <fr:tex display="inline"><![CDATA[a]]></fr:tex>. We will probably want to impose the further condition that
it's always the former. This amounts to the claim that <fr:tex display="inline"><![CDATA[X^{\leq  r}[n]]]></fr:tex>
is the intersection of <fr:tex display="inline"><![CDATA[X^{\leq  r'}]]></fr:tex> for all <fr:tex display="inline"><![CDATA[r' > r]]></fr:tex>, which is a sort
of sheaf condition.
</html:p>
            <html:p>
Okay, so the basic setup now is that we have a simplicial set, where
each simplex has some associated positive number. It will be useful to
think of this as the *error* of the simplex. Let me give a few examples
of this to illustrate how I want to use this structure:
</html:p>
            <html:p>
1.  Given a category enriched in metric sets <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>, we can
    consider the filtered simplicial set where
</html:p>
            <html:p>
    -   <fr:tex display="inline"><![CDATA[X^{\leq  r}[0] = \operatorname {ob} \mathcal {C}]]></fr:tex> for each <fr:tex display="inline"><![CDATA[r]]></fr:tex>.
</html:p>
            <html:p>
    -   <fr:tex display="inline"><![CDATA[X^{\leq  r}[1]]]></fr:tex> is the set of morphisms in <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>, again
        regardless of <fr:tex display="inline"><![CDATA[r]]></fr:tex>.
</html:p>
            <html:p>
    -   <fr:tex display="inline"><![CDATA[X^{\leq  r}[2]]]></fr:tex> consists of triples
        <fr:tex display="inline"><![CDATA[f:x \to  y, g: y \to  z, h: x \to  z]]></fr:tex> so that
        <fr:tex display="inline"><![CDATA[d_{\mathcal {C}(x,z)}(gf,h) \leq  r]]></fr:tex>.
</html:p>
            <html:p>
    -   Each <fr:tex display="inline"><![CDATA[X^{\leq  r}]]></fr:tex> is <fr:tex display="inline"><![CDATA[2]]></fr:tex>-coskeletal, i.e given a compatible
        boundary for a higher simplex, there is always a unique such
        simplex (at any given error level).
</html:p>
            <html:p>
    It's clear that this data characterized such a category up to
    equivalence, although it's not totally obvious how to characterize
    the subclass of filtered simplicial sets which have this form.
</html:p>
            <html:p>
2.  Given a category equipped with a *weight* in the sense of Perrone,
    i.e a number <fr:tex display="inline"><![CDATA[d(f)]]></fr:tex> for each morphism such that <fr:tex display="inline"><![CDATA[d(1) = 0]]></fr:tex>,
    <fr:tex display="inline"><![CDATA[d(fg) \leq  d(f) + d(g)]]></fr:tex>, we can build a filtered simplicial set as
    follows:
</html:p>
            <html:p>
    -   <fr:tex display="inline"><![CDATA[X^{\leq  r}[0]]]></fr:tex> is the set of objects, for all <fr:tex display="inline"><![CDATA[r]]></fr:tex>.
</html:p>
            <html:p>
    -   <fr:tex display="inline"><![CDATA[X^{\leq  r}[1]]]></fr:tex> is the set of morphisms with <fr:tex display="inline"><![CDATA[d(f) \leq  r]]></fr:tex>.
</html:p>
            <html:p>
    -   <fr:tex display="inline"><![CDATA[X^{\leq  r}[2]]]></fr:tex> is the set of commuting triangles <fr:tex display="inline"><![CDATA[(f,g,h)]]></fr:tex> with
        <fr:tex display="inline"><![CDATA[d(f),d(g),d(h) \leq  r]]></fr:tex>.
</html:p>
            <html:p>
    -   Each filtration degree is coskeletal, as above.
</html:p>
            <html:p>
    Again, it's clear that we can pull out a category with a metric on
    it in a unique way from a filtered simplicial set like this.
</html:p>
            <html:p>
Thus, you're supposed to interpret a 2-simplex in <fr:tex display="inline"><![CDATA[X^{\leq  r}[2]]]></fr:tex> as
saying "this triangle commutes, at least at error tolerance <fr:tex display="inline"><![CDATA[r]]></fr:tex>", a
morphism in <fr:tex display="inline"><![CDATA[X^{\leq  r}[1]]]></fr:tex> as being "a morphism up to error/metric
<fr:tex display="inline"><![CDATA[r]]></fr:tex>". In principle you could also have objects with errors, and higher
simplices with errors if you wanted to do higher-categorical stuff.
</html:p>
            <html:p>
Let's think about what makes such a simplicial set suitable for use as a
category. Recall that an ordinary simplicial set <fr:tex display="inline"><![CDATA[X]]></fr:tex> is the nerve of a
category if and only if every inner horn <fr:tex display="inline"><![CDATA[\Lambda ^{n}_{k} \to  X]]></fr:tex> has a
unique filler, which is in turn equivalent to asking that horns of every
dimension have unique fillers, or that the maps
<fr:tex display="inline"><![CDATA[]]></fr:tex>X[n] \to  X[1] \times _{X[0]} X[1] \times _{X[0]} \dots  \times _{X[0]} X[1]<fr:tex display="inline"><![CDATA[]]></fr:tex>
are all bijections.
</html:p>
            <html:p>
In other words, this is about fillers for certain horns existing, and
perhaps existing uniquely. The world of quantitative categories is a bit
more complicated, for the essential reason that
</html:p>
            <html:p>
Here is my attempt at a suitable definition. For each
<fr:tex display="inline"><![CDATA[n, 0 \leq  k \leq  n]]></fr:tex>, and <fr:tex display="inline"><![CDATA[r_{0}, \dots , r_{k-1},r_{k+1}, \dots  r_{n}]]></fr:tex>,
let <fr:tex display="inline"><![CDATA[\Lambda ^n_{k}(r_{0},\dots  r_{n})]]></fr:tex> be the filtered simplicial set
given by a horn <fr:tex display="inline"><![CDATA[\Lambda _{k}^{n}]]></fr:tex>, with the <fr:tex display="inline"><![CDATA[i]]></fr:tex>th face for each <fr:tex display="inline"><![CDATA[i]]></fr:tex>
having value <fr:tex display="inline"><![CDATA[r_{i}]]></fr:tex>, i.e appearing in
<fr:tex display="inline"><![CDATA[\Lambda _{k}^{n}(r_{1},\dots  r_{n})^{\leq  r_{i}}]]></fr:tex> but not before (with
the lower-dimensional faces all having the maximal possible value given
this).
</html:p>
            <html:p>
Similarly define <fr:tex display="inline"><![CDATA[\Delta ^{n}(r_{0}, \dots  r_{n})]]></fr:tex> (given a full list of
<fr:tex display="inline"><![CDATA[n+1]]></fr:tex> values). Then we say a filtered simplicial set <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> is a
*approximation quasicategory* if, for every <fr:tex display="inline"><![CDATA[0 < k < n]]></fr:tex>, and each tuple
<fr:tex display="inline"><![CDATA[r_{0}, \dots  r_{k-1},r_{k+1}, \dots  r_{n}]]></fr:tex> every map
<fr:tex display="inline"><![CDATA[\Lambda _{k}^{n}(r_{0}, \dots  r_{n}) \to  \mathcal {C}]]></fr:tex> admits an
extension along
<fr:tex display="inline"><![CDATA[\Lambda _k^n(r_{0},\dots  r_{n}) \to  \Delta ^{n}(r_{0}, \dots  r_{k-1}, \sum _{i \neq  k} r_{i}, r_{k}, \dots  r_{n})]]></fr:tex>.
</html:p>
            <html:p>
This obviously corresponds to the definition of quasicategory (aka
<fr:tex display="inline"><![CDATA[\infty ]]></fr:tex>-category, weak Kan complex...), with the additional structure
of the filtration incorporated in such a way that errors add when
composing morphisms. This is perhaps a good time to note that one could
also have combined errors with <fr:tex display="inline"><![CDATA[\operatorname {max}]]></fr:tex> instead of <fr:tex display="inline"><![CDATA[\Sigma ]]></fr:tex>.
This would have amounted to asking that each
<fr:tex display="inline"><![CDATA[\mathcal {C}^{\leq  \epsilon }]]></fr:tex> be a quasicategory in itself. From a
categorical point of view this condition is much more natural, but
adding errors seem more natural from the point of view of metrics,
incorporating the triangle identity.
</html:p>
            <html:p>
It is not entirely clear to me whether requiring each filler to exist
uniquely, rather than merely exist, captures the right notion of
1-category. The reason is that it demands that composites be unique,
whereas we might expect (from our earlier look at metagories) that they
should only be unique up to an induced metric-0 notion. I tend to think
that it's more sensible to require this equivalence relation to be
already quotiented out, to make that part of the definition of
approximation quasicategory, but I'm not entirely decided on this point.
</html:p>
            <html:p>
1.  The category of morphisms <fr:tex display="inline"><![CDATA[[\mathcal {C},\mathcal {D}]]]></fr:tex> in a
    metric-enriched category naturally acquires a nontrivial filtration
    in the morphisms (which are commutative diagrams).
</html:p>
            <html:p>
2.  Iterating this, the category of morphisms in such a category
    naturally acquires a nontrivial filtration in the *objects*.
</html:p>
            <html:p>
Working out all of category theory in this context is a big undertaking,
which will probably not get done until people derive more actual utility
from it. However, as a sort of test case to explore this system, I've spent some time thinking about how colimits should be defined, which I hope to explore in a future post.
</html:p>
            <html:p>
[^1]: A metric without the requirement that <fr:tex display="inline"><![CDATA[d(f,g) = 0]]></fr:tex> implies <fr:tex display="inline"><![CDATA[f=g]]></fr:tex></html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2022</fr:year>
              <fr:month>3</fr:month>
              <fr:day>28</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/20220325115704-frag-coarse-spaces-have-a-nice-group-theory/</fr:uri>
            <fr:display-uri>20220325115704-frag-coarse-spaces-have-a-nice-group-theory</fr:display-uri>
            <fr:route>/20220325115704-frag-coarse-spaces-have-a-nice-group-theory/</fr:route>
            <fr:title text="Fragmentary-coarse groups are categorically neat">Fragmentary-coarse groups are categorically neat</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2022</fr:year>
                  <fr:month>3</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Coarse geometry">Coarse geometry</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The idea of a _coarse space_ is to formalize a sense in which the inclusion of metric spaces <fr:tex display="inline"><![CDATA[\mathbb {Z} \hookrightarrow  \mathbb {R}]]></fr:tex> is an equivalence.
  These two spaces have the same "large-scale structure", in the sense that any function into <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex> can be approximated up to uniformly bounded error by one into <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex>. Say two functions <fr:tex display="inline"><![CDATA[f,f': X \to  Y]]></fr:tex> into a metric space are _close_ if there exists a constant <fr:tex display="inline"><![CDATA[C]]></fr:tex> with <fr:tex display="inline"><![CDATA[d_Y(f(x),f'(x)) \leq  C]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x]]></fr:tex>. Say a function between metric spaces is _controlled_ if postcomposition with it preserves closeness (it turns out there is a simpler equivalent statement of that, but it doesn't really matter). Then we can consider equivalence classes of controlled functions between metric spaces, under the equivalence relation of closeness. This is "coarse geometry".
</html:p>
                <html:p>
  It turns out there is a way to abstract away from the metric and describe a "coarse structure" on a set, which remembers enough information to tell which pairs of functions are close and which are controlled, but nothing else - and that there then exist coarse structures that aren't induced by metrics. I personally think of this as kind of complementary to the way topologies remember what's necessary to talk about continuity - if continuous functions between metric spaces are about preserving the "small-scale structure", the notion of convergence, then coarse geometry is the opposite of that.
</html:p>
                <html:p>
  The category of coarse spaces admits finite products, so we can talk about "coarse group theory", which is explored in <fr:link href="&lt;https://arxiv.org/pdf/2203.08591.pdf&gt;" type="external">An Invitation to Coarse Groups</fr:link> by Leitner and Vigolo, which I've been reading a bit recently. It's full of interesting stuff - maybe my favorite bit is the story about geometric group theory. If you have a group <fr:tex display="inline"><![CDATA[G]]></fr:tex> with a generating set <fr:tex display="inline"><![CDATA[S]]></fr:tex>, you can define a metric by setting <fr:tex display="inline"><![CDATA[d(a,b)]]></fr:tex> to be the length of the shortest way of writing <fr:tex display="inline"><![CDATA[a^{-1}b]]></fr:tex> as a word in generators - this amounts to taking the graph distance on the Cayley graph. Studying this metric structure on the group <fr:tex display="inline"><![CDATA[G]]></fr:tex> can tell you a lot of interesting stuff about the group - but the metric is highly dependent on the choice of generating set <fr:tex display="inline"><![CDATA[S]]></fr:tex>! So it's somehow very surprising that all these different metric come back and give us the same group-theoretic information (since the group <fr:tex display="inline"><![CDATA[G]]></fr:tex> is fixed). Leitner and Vigolo shows that for all finite <fr:tex display="inline"><![CDATA[S]]></fr:tex>, the metrics give the same coarse structure on <fr:tex display="inline"><![CDATA[G]]></fr:tex>, and much of geometric group theory "sees" only coarse structure!
</html:p>
                <html:p>
  I find all this really cool and I highly recommend the paper. I want to talk about a subtlety that comes up in the category of coarse groups.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2022</fr:year>
                  <fr:month>3</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="The problem: group homomorphisms lack kernels">The problem: group homomorphisms lack kernels</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Consider two possible coarse structures on the set <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> - the trivial structure and the one induced by the normal metric, which we can write <fr:tex display="inline"><![CDATA[\mathbb {Z}_{|\cdot |}]]></fr:tex>. The identity map <fr:tex display="inline"><![CDATA[\mathbb {Z}_{\mathrm {triv}} \to  \mathbb {Z}_{|\cdot |}]]></fr:tex> is obviously a coarse group homomorphism. It's also an epimorphism. In normal group theory we have the very convenient isomorphism theorem saying that the image of a group homomorphism is, up to isomorphism, the quotient of the domain by the kernel. But there is no coarse subgroup of <fr:tex display="inline"><![CDATA[\mathbb {Z}_{\mathrm {triv}}]]></fr:tex> that can play this role.
</html:p>
                <html:p>
  Let's think about how to remedy this. The universal property of the kernel dictates that maps into it must be precisely those maps into <fr:tex display="inline"><![CDATA[\mathbb {Z}_{\mathrm {triv}}]]></fr:tex> that are close to zero in <fr:tex display="inline"><![CDATA[\mathbb {Z}_{|\cdot |}]]></fr:tex>. The first condition boils down to taking each coarsely connected component to the same point, and the second condition means that the image must be a bounded subset (in the metric). Of course, there is no coarse set like this - it would have to consist of "the bounded subsets of <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex>", but of course every point is contained in one of these subsets.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2022</fr:year>
                  <fr:month>3</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="The solution: relaxing the notion of coarse space">The solution: relaxing the notion of coarse space</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The answer is to relax the notion of coarse space, by removing the condition that <fr:tex display="inline"><![CDATA[\Delta _X]]></fr:tex> is among the controlled sets.
  This leads to the notion of _fragmentary coarse space_:
</html:p>
                <html:p>
  -   A fragmentary coarse space is a set <fr:tex display="inline"><![CDATA[X]]></fr:tex> equipped with a family <fr:tex display="inline"><![CDATA[\mathcal {E}_X]]></fr:tex> of subsets of <fr:tex display="inline"><![CDATA[X \times  X]]></fr:tex>, stable under finite unions, subsets, and so that if <fr:tex display="inline"><![CDATA[E_1,E_2 \in  \mathcal {E}_X]]></fr:tex>, then <fr:tex display="inline"><![CDATA[E_1 \circ  E_2 \in  \mathcal {E}_X]]></fr:tex>.
  -   A subset <fr:tex display="inline"><![CDATA[A \subset  X]]></fr:tex> is called a _fragment_ if <fr:tex display="inline"><![CDATA[\Delta _A]]></fr:tex> is in <fr:tex display="inline"><![CDATA[\mathcal {E}_X]]></fr:tex>.
  -   Two functions <fr:tex display="inline"><![CDATA[f,f': X \to  Y]]></fr:tex> between fragmentary coarse spaces are _fragmentary close_ if, for each fragment <fr:tex display="inline"><![CDATA[A]]></fr:tex> of <fr:tex display="inline"><![CDATA[X]]></fr:tex>, <fr:tex display="inline"><![CDATA[f(A) \times  f'(A) \in  \mathcal {E}_Y]]></fr:tex>.
  -   A function <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> is _fragmentary controlled_ if, for each <fr:tex display="inline"><![CDATA[A \in  \mathcal {E}_X]]></fr:tex>, <fr:tex display="inline"><![CDATA[(f\times  f)(A) \in  \mathcal {E}_Y]]></fr:tex>.
  -   The category of fragmentary coarse spaces and equivalence classes of fragmentary controlled functions up to fragmentary closeness is denoted <fr:tex display="inline"><![CDATA[\mathbf {FragCrs}]]></fr:tex></html:p>
                <html:p>
  Leitner and Vigolo show that <fr:tex display="inline"><![CDATA[\mathbf {FragCrs}]]></fr:tex> is complete and cocomplete, and in fact even Cartesian closed (these convenient properties are the reason they introduce the notion of frag-coarse space). I now claim that it is furthermore _regular_.
</html:p>
                <html:p>
  Observe that this property passes to the category of group objects in <fr:tex display="inline"><![CDATA[\mathbf {FragCrs}]]></fr:tex>. Hence given any quotient homomorphism <fr:tex display="inline"><![CDATA[f: G \to  H]]></fr:tex> between (fragmentary) coarse groups, there exists a kernel <fr:tex display="inline"><![CDATA[\mathrm {ker}(f)]]></fr:tex> so that <fr:tex display="inline"><![CDATA[H = G/\mathrm {ker}(f)]]></fr:tex>, although the kernel may have to be a fragmentary-coarse group even if <fr:tex display="inline"><![CDATA[G]]></fr:tex> and <fr:tex display="inline"><![CDATA[H]]></fr:tex> are coarse. Thus, passing to fragmentary-coarse groups provides us with a nice group theory.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2022</fr:year>
                  <fr:month>3</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Proof that \mathbf {FragCrs} is regular">Proof that <fr:tex display="inline"><![CDATA[\mathbf {FragCrs}]]></fr:tex> is regular</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Since <fr:tex display="inline"><![CDATA[\mathbf {FragCrs}]]></fr:tex> is complete and cocomplete, it suffices to show that pullbacks of regular epimorphisms are again regular.
  We first claim that every epimorphism <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> is in fact regular.
  Note that Leitner-Vigolo show that <fr:tex display="inline"><![CDATA[f]]></fr:tex> is an epimorphism if and only if, for each fragment <fr:tex display="inline"><![CDATA[Y']]></fr:tex> of <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, there exists a fragment <fr:tex display="inline"><![CDATA[X']]></fr:tex> of <fr:tex display="inline"><![CDATA[X]]></fr:tex> and a controlled set <fr:tex display="inline"><![CDATA[F \in  \mathcal {E}_Y]]></fr:tex>, so that <fr:tex display="inline"><![CDATA[Y' \subset  F(f(X'))]]></fr:tex> (i.e for every <fr:tex display="inline"><![CDATA[y \in  Y']]></fr:tex>, there exists <fr:tex display="inline"><![CDATA[x \in  X']]></fr:tex> so that <fr:tex display="inline"><![CDATA[(f(x),y) \in  F]]></fr:tex>).
  Given this, we see that <fr:tex display="inline"><![CDATA[Y]]></fr:tex> is frag-coarse-equivalent to <fr:tex display="inline"><![CDATA[X]]></fr:tex> equipped with the frag-coarse structure <fr:tex display="inline"><![CDATA[f^{-1}(\mathcal {E}_Y)]]></fr:tex> - clearly <fr:tex display="inline"><![CDATA[f]]></fr:tex> is a frag-coarse surjection from this space to <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, and also a frag-coarse embedding, hence an equivalence.
  So every epimorphism is, up to isomorphism, given by a map which is set-theoretically the identity. One also sees that the codomain necessarily has the same fragments as the domain.
  Now, inspecting the construction of coequalizers for frag-coarse spaces, it's not too hard to see that the frag-coarse structure on <fr:tex display="inline"><![CDATA[X]]></fr:tex> that gives the coequalizer of the kernel pair of <fr:tex display="inline"><![CDATA[f]]></fr:tex> must coincide with the one on the codomain on <fr:tex display="inline"><![CDATA[f]]></fr:tex>. Hence every epimorphism is regular.
</html:p>
                <html:p>
  Now, if <fr:tex display="inline"><![CDATA[i: X \to  \bar {X}]]></fr:tex> is an epi (assumed to be set-theoretically the identity), and <fr:tex display="inline"><![CDATA[f: Y \to  \bar {X}]]></fr:tex> is any map, we must show that again <fr:tex display="inline"><![CDATA[Y \times _{\bar {X}} X \to  Y]]></fr:tex> is an epimorphism. The construction of limits makes it clear that the fragments of the pullback are each contained in a set of the form <fr:tex display="inline"><![CDATA[A \times  B]]></fr:tex> where <fr:tex display="inline"><![CDATA[A,B]]></fr:tex> are fragments of <fr:tex display="inline"><![CDATA[Y]]></fr:tex> and <fr:tex display="inline"><![CDATA[X]]></fr:tex> respectively and <fr:tex display="inline"><![CDATA[f(A) \times  B]]></fr:tex> is controlled in <fr:tex display="inline"><![CDATA[\bar {X}]]></fr:tex>.
  Since for each fragment <fr:tex display="inline"><![CDATA[A]]></fr:tex> of <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, <fr:tex display="inline"><![CDATA[f(A)]]></fr:tex> is a fragment of <fr:tex display="inline"><![CDATA[\bar {X}]]></fr:tex>, it's clear that we can find a matching fragment <fr:tex display="inline"><![CDATA[B]]></fr:tex> for each <fr:tex display="inline"><![CDATA[A]]></fr:tex>. Then the projection from this fragment is surjective on the nose, and hence the projection is epimorphic.
</html:p>
                <html:p>
  Now let's consider the example of <fr:tex display="inline"><![CDATA[\mathbb {Z}_{\mathrm {triv}} \to  \mathbb {Z}_{|\cdot |}]]></fr:tex>. In fact since the forgetful functor from group objects preserves all limits, we can compute the kernel of this map just in <fr:tex display="inline"><![CDATA[\mathbf {FragCrs}]]></fr:tex>. It is given by the frag-coarse structure on <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> where a set is <fr:tex display="inline"><![CDATA[U]]></fr:tex> controlled if it's bounded (namely if the identity is close to zero on it) - not if the distance <fr:tex display="inline"><![CDATA[d(x,y)]]></fr:tex> is bounded as <fr:tex display="inline"><![CDATA[(x,y)]]></fr:tex> ranges over <fr:tex display="inline"><![CDATA[U]]></fr:tex>, but if the whole thing is a bounded subset of <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> in the <fr:tex display="inline"><![CDATA[1]]></fr:tex>-norm. This means that the fragments are exactly the bounded subsets of <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> (and that there is no nontrivial frag-coarse structure beyond that - a set is controlled if and only if it's contained in the product <fr:tex display="inline"><![CDATA[A \times  A]]></fr:tex> for a fragment <fr:tex display="inline"><![CDATA[A]]></fr:tex>).
</html:p>
                <html:p>
  It's not too hard in this case to verify that the quotient of <fr:tex display="inline"><![CDATA[\mathbb {Z}_{\mathrm {triv}}]]></fr:tex> by this subgroup is in fact <fr:tex display="inline"><![CDATA[\mathbb {Z}_{|\cdot |}]]></fr:tex>. Namely, a coarse map out of <fr:tex display="inline"><![CDATA[\mathbb {Z}_{\mathrm {triv}}]]></fr:tex> restricts to zero on the subgroup if and only if it carries the bounded subsets of <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> to sets that are bounded-close to zero in the codomain, i.e sets so that <fr:tex display="inline"><![CDATA[A \times  \{0\}]]></fr:tex> is controlled. But for a coarse group homomorphism, this is enough to be controlled as a morphism on <fr:tex display="inline"><![CDATA[\mathbb {Z}_{|\cdot |}]]></fr:tex>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2022</fr:year>
              <fr:month>1</fr:month>
              <fr:day>26</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/links-2022-01-26/</fr:uri>
            <fr:display-uri>links-2022-01-26</fr:display-uri>
            <fr:route>/links-2022-01-26/</fr:route>
            <fr:title text="Links 2022-01-26">Links 2022-01-26</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:ul><html:li>Astral Codex Ten: <fr:link href="https://astralcodexten.substack.com/p/bounded-distrust" type="external">Bounded Distrust</fr:link>, also <fr:link href="https://astralcodexten.substack.com/p/against-that-poverty-and-infant-eegs" type="external">Against That Poverty And Infants EEGs Study</fr:link></html:li>
  <html:li><fr:link href="https://obliqueville.substack.com/p/in-search-of-visual-texture?r=12sa4j&amp;utm_campaign=post&amp;utm_medium=web" type="external">In Search of Visual Texture</fr:link></html:li>
  <html:li><fr:link href="https://marginalrevolution.com/marginalrevolution/2022/01/how-should-you-talk-to-think-better.html?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=how-should-you-talk-to-think-better" type="external">How should you talk to think better?</fr:link></html:li>
  <html:li><fr:link href="https://x.com/visakanv/status/1481201800200220675" type="external">Tweet</fr:link></html:li>
<html:p /></html:ul>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2022</fr:year>
              <fr:month>1</fr:month>
              <fr:day>22</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/links-2022-01-22/</fr:uri>
            <fr:display-uri>links-2022-01-22</fr:display-uri>
            <fr:route>/links-2022-01-22/</fr:route>
            <fr:title text="Links 2022-01-22">Links 2022-01-22</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:ul><html:li><fr:link href="https://zaratustra.itch.io/dordle" type="external">Dordle</fr:link>, a Wordle variant where you have to guess two words at the same time.</html:li>
  <html:li><fr:link href="https://topos.site/intercats/" type="external">Intercats</fr:link>, a new seminar from the Topos Institute on "categorical interaction". I'm scheduled to speak here (in June, so don't get too excited yet)</html:li>
  <html:li><fr:link href="https://www.nicoledieker.com/p/how-to-become-a-magician" type="external">How To Become A Magician</fr:link>. See also <fr:link href="https://autotranslucence.wordpress.com/2018/03/30/becoming-a-magician/" type="external">Becoming A Magician</fr:link>.</html:li>
  <html:li><fr:link href="https://www.lesswrong.com/posts/McN9BNtNcbYNfdCB5/postmortem-on-ratvac" type="external">Postmortem on RatVac</fr:link>. I have the highest level of respect for everyone who made their own vaccine - major props.</html:li>
  <html:li><fr:link href="https://golem.ph.utexas.edu/category/2021/11/compositional_thermostatics.html" type="external">Compositional Thermostatics</fr:link> from Baez, Lynch, and Moeller. I can also recommend Owen's <fr:link href="https://owenlynch.org/" type="external">blog</fr:link>.</html:li>
<html:p /></html:ul>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>11</fr:month>
              <fr:day>13</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/smooth-dynamical-systems-as-infinitesimal/</fr:uri>
            <fr:display-uri>smooth-dynamical-systems-as-infinitesimal</fr:display-uri>
            <fr:route>/smooth-dynamical-systems-as-infinitesimal/</fr:route>
            <fr:title text="Smooth dynamical systems as infinitesimal discrete dynamical systems">Smooth dynamical systems as infinitesimal discrete dynamical systems</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Here I am working with nonstandard analysis in the sense of Robinson, taking an ultrapower of the real numbers and building things out of that. But in general I am going to be a bit sloppy and not worry too much about the details.
</html:p>
            <html:p>
Recall that a standard function is _differentiable_ if, for every standard <fr:tex display="inline"><![CDATA[x]]></fr:tex> and for every infinitesimal <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex>, <fr:tex display="inline"><![CDATA[f(x+\epsilon )-f(x)/\epsilon  \approx  a]]></fr:tex>, where <fr:tex display="inline"><![CDATA[a]]></fr:tex> is also standard.
</html:p>
            <html:p>
Fix an infinitesimal <fr:tex display="inline"><![CDATA[h]]></fr:tex>.
Let <fr:tex display="inline"><![CDATA[M]]></fr:tex> be a standard differentiable manifold, fix <fr:tex display="inline"><![CDATA[p \in  M]]></fr:tex>, and consider the tangent space <fr:tex display="inline"><![CDATA[T_pM]]></fr:tex>. Recall that the elements of this vector space (may be taken to be) smooth paths <fr:tex display="inline"><![CDATA[\gamma : I \to  M]]></fr:tex>, with <fr:tex display="inline"><![CDATA[0 \in  I \subset  \mathbb {R}]]></fr:tex> some open interval, up to the equivalence relation of having the same first derivative at <fr:tex display="inline"><![CDATA[p]]></fr:tex> (which may be checked in any choice of local coordinates, all coordinates giving the same answer).
In particular we may compute this derivative, letting <fr:tex display="inline"><![CDATA[\phi : U \to  \mathbb {R}]]></fr:tex>, <fr:tex display="inline"><![CDATA[p \in  U \subset  M]]></fr:tex> being the local coordinates of choice, as  the standard part of <fr:tex display="inline"><![CDATA[(\phi (\gamma (h))-\phi (p))/h]]></fr:tex>.
Having fixed <fr:tex display="inline"><![CDATA[h]]></fr:tex>, we may thus replace each curve with just the choice of <fr:tex display="inline"><![CDATA[\gamma (h)]]></fr:tex>, the only condition on this being that in any choice of local coordinates, the above quotient has a standard part (eg it is not unbounded). But since the change-of-coordinate maps are in particular differentiable, it suffices to verify this for one such choice.
We may call this property "being at <fr:tex display="inline"><![CDATA[O(h)]]></fr:tex>-order infinitesimal distance from from <fr:tex display="inline"><![CDATA[p]]></fr:tex>".
For example, suppose that <fr:tex display="inline"><![CDATA[M = \mathbb {R}]]></fr:tex>, <fr:tex display="inline"><![CDATA[p=0]]></fr:tex> and <fr:tex display="inline"><![CDATA[\phi  = 1_\mathbb {R}]]></fr:tex>. Then if <fr:tex display="inline"><![CDATA[h = (1/n)]]></fr:tex>, it will not do to take <fr:tex display="inline"><![CDATA[\gamma (h) = (1/\sqrt {n})]]></fr:tex>, for in that case we will get the unbounded nonstandard real <fr:tex display="inline"><![CDATA[(\sqrt {n})]]></fr:tex> for the difference quotient.
</html:p>
            <html:p>
Let <fr:tex display="inline"><![CDATA[\widetilde {D_pM}]]></fr:tex> be the set of such points in <fr:tex display="inline"><![CDATA[M]]></fr:tex>. We don't quite have a map <fr:tex display="inline"><![CDATA[T_pM \to  \widetilde {D_pM}]]></fr:tex>, because e.g the path <fr:tex display="inline"><![CDATA[\gamma (t)=t^2]]></fr:tex>, which has local derivative zero, has <fr:tex display="inline"><![CDATA[\gamma (h) = h^2 \neq  0]]></fr:tex>. In order to make this map well-defined, we need to consider a quotient by the relation of "being at distance <fr:tex display="inline"><![CDATA[o(h)]]></fr:tex>". More precisely, let <fr:tex display="inline"><![CDATA[v \approx  v']]></fr:tex> if, if any coordiante chart, <fr:tex display="inline"><![CDATA[d(v,v')/h]]></fr:tex> is infinitesimal. (The local differentiability ensures this does not depend on the choice of coordinates.) Then let <fr:tex display="inline"><![CDATA[D_pM = \widetilde {D_pM}/\approx ]]></fr:tex> - now the map <fr:tex display="inline"><![CDATA[T_pM \to  D_pM]]></fr:tex> is well-defined.
</html:p>
            <html:p>
We can also define a vector space structure on <fr:tex display="inline"><![CDATA[D_pM]]></fr:tex> that makes this map linear.
We simply lift the addition and scalar multiplication from any coordinate chart.
Local differentiability imply that <fr:tex display="inline"><![CDATA[\psi (h(v+v')) = \psi '(0) h(v+v') + h\epsilon ]]></fr:tex>, wher <fr:tex display="inline"><![CDATA[\psi ]]></fr:tex> is a change-of-coordinate map, so that addition is well-defined up to an infinitesimal times <fr:tex display="inline"><![CDATA[h]]></fr:tex>, which is quotiented out by in any case. Scalar multiplication works similarly.
Note that we are defining a vector space over <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex>, _not_ over the full <fr:tex display="inline"><![CDATA[*\mathbb {R}]]></fr:tex>. Multiplication by a number of order <fr:tex display="inline"><![CDATA[o(h)]]></fr:tex> is not invertible (in fact such products are always zero), and similarly scaling by an unbounded number may take you out of the coordinate patch, and is thus not well-defined.
</html:p>
            <html:p>
In fact with this, we have an isomorphism <fr:tex display="inline"><![CDATA[T_pM \to  D_pM]]></fr:tex> - any <fr:tex display="inline"><![CDATA[v \in  D_pM]]></fr:tex> is the image of <fr:tex display="inline"><![CDATA[\gamma (t) = p + tv/h]]></fr:tex>, and two curves have the same derivative exactly if <fr:tex display="inline"><![CDATA[\gamma (h) \approx  \gamma '(h)]]></fr:tex>.
</html:p>
            <html:p>
Recall that smooth dynamical system on <fr:tex display="inline"><![CDATA[M]]></fr:tex> is a smoth section <fr:tex display="inline"><![CDATA[M \to  TM]]></fr:tex>.
We can exploit our isomorphism above, by observing that each <fr:tex display="inline"><![CDATA[D_p]]></fr:tex> is actually a quotient of a subset of <fr:tex display="inline"><![CDATA[M]]></fr:tex>. Hence we may ask for a function <fr:tex display="inline"><![CDATA[s: *M \to  *M]]></fr:tex> so that <fr:tex display="inline"><![CDATA[s(p) \in  \widetilde {D_p} \subset  *M]]></fr:tex> - this induces a smooth dynamical system. Every (standard) smooth dynamical system has this form, and <fr:tex display="inline"><![CDATA[s,s']]></fr:tex> induce the same system if <fr:tex display="inline"><![CDATA[s(p) \approx  s'(p)]]></fr:tex> for each <fr:tex display="inline"><![CDATA[p]]></fr:tex>.
</html:p>
            <html:p>
What's cool about this is that these are essentially _discrete_ dynamical systems, albeit nonstandard ones. A discrete dynamical system is a set with an "advance one timestep" function <fr:tex display="inline"><![CDATA[s: X \to  X]]></fr:tex>. So a smooth dynamical system is a manifold with an "advance time <fr:tex display="inline"><![CDATA[h]]></fr:tex>" function <fr:tex display="inline"><![CDATA[s: *M \to  *M]]></fr:tex>, subject to the condition that <fr:tex display="inline"><![CDATA[s(p)]]></fr:tex> is <fr:tex display="inline"><![CDATA[h]]></fr:tex>-close to <fr:tex display="inline"><![CDATA[p]]></fr:tex>, and up to a certain equivalence relation. This suggests a way to use the same conceptual tools to study smooth and discrete dynamical systems.
</html:p>
            <html:p>
The paper <fr:link href="https://arxiv.org/abs/1405.0984" type="external">Differential geomtry via infinitesimal displacements</fr:link>, by Nowik and Katz, provides a more in-depth analysis of this idea.
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>6</fr:month>
              <fr:day>19</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/20210618162423-martin_lof_random_sequences/</fr:uri>
            <fr:display-uri>20210618162423-martin_lof_random_sequences</fr:display-uri>
            <fr:route>/20210618162423-martin_lof_random_sequences/</fr:route>
            <fr:title text="Martin-Löf Random Sequences">Martin-Löf Random Sequences</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
A sequence of bits <fr:tex display="inline"><![CDATA[N \to  \{0,1\}]]></fr:tex> is _Martin-Löf random_ (or _algorithmically random_) if, roughly speaking, there is no _computable_ pattern to it.
</html:p>
            <html:p>
There are three equivalent definitions:
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>19</fr:day>
                </fr:date>
                <fr:title text="Kolmogorov complexity definition">Kolmogorov complexity definition</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Let <fr:tex display="inline"><![CDATA[K(x)]]></fr:tex> be the kolmogorov complexity of a binary string (finite).
  Say <fr:tex display="inline"><![CDATA[x]]></fr:tex> is <fr:tex display="inline"><![CDATA[c]]></fr:tex>-incompressible if <fr:tex display="inline"><![CDATA[K(x) \geq  |x| - c]]></fr:tex>. An infinite string is Martin-löf random if there exists <fr:tex display="inline"><![CDATA[c]]></fr:tex> so that all its finite prefixes are <fr:tex display="inline"><![CDATA[c]]></fr:tex>-incompressible.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>19</fr:day>
                </fr:date>
                <fr:title text="Constructive &quot;covers&quot;">Constructive "covers"</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Given a finite string <fr:tex display="inline"><![CDATA[w]]></fr:tex>, <fr:tex display="inline"><![CDATA[C_w]]></fr:tex> is the open set of strings with that prefix.
  A constructive open is an open given as the union of an enumerable sequence of such things.
  A constructive nullcover is a computable sequence <fr:tex display="inline"><![CDATA[U_i \supset  U_{i+1}]]></fr:tex> of constructive opens so that <fr:tex display="inline"><![CDATA[\mu (U_i) \leq  2^i]]></fr:tex> (<fr:tex display="inline"><![CDATA[\mu ]]></fr:tex> being the obvious "lebesgue" measure on Cantor space).
  A sequence <fr:tex display="inline"><![CDATA[x]]></fr:tex> is Martin-Löf random if, for any constructive nullcover, <fr:tex display="inline"><![CDATA[x \neq  \cup ^\infty  U_i]]></fr:tex>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>19</fr:day>
                </fr:date>
                <fr:title text="Constructive Martingales">Constructive Martingales</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  A _Martingale_ is a function <fr:tex display="inline"><![CDATA[\{0,1\}^* \to  [ 0,\infty  )]]></fr:tex>, interpreted as the profit of a betting strategy (betting on coinflips) on the given sequence of coinflip outcomes.
  It's _fair_ if <fr:tex display="inline"><![CDATA[m(x) = (m(x .0) + m(x.1))/2]]></fr:tex> - in other words, the amount you win on a zero must equal the amount you lose on a one. Ie "you're betting at fair odds".
</html:p>
                <html:p>
  A martingale _succeeds_ on a Martin-löf random sequence if its limsup on the prefixes is infinite - i.e if it wins unbounded amounts of money at fair odds without ever risking any more than its finite starting pot (since it cannot go negative).
</html:p>
                <html:p>
  A martingale is _constructive_ if it is "lower computable", and a sequence is Martin-Löf random if there is no constructive martingale that succeeds on it.
</html:p>
                <html:p>
  Ie if there is no computable gambling strategy to extract unbounded money from the assumption "this sequence produces fair coinflips".
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>19</fr:day>
                </fr:date>
                <fr:title text="Discussion">Discussion</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  In other words, as long as the world is computable, you can comfortably treat any Martin-löf sequence as random. Of course, if the world is computable, you cannot store one in any way, and any black box that outputs a Martin-Löf sequence is in some sense "either random or uncomputable".
</html:p>
                <html:p>
  So in some sense there's _no way_ of telling the difference between a deterministic, computable world that contains some black boxes that output Martin-Löf sequences, and a computable world that contains some black boxes that output "actually random" sequences.
  This provides some justification for the philosophical position that "randomness" is always about quantifying the limitations (of information, or in this case, of which functions they can compute) of the observer, advanced eg <fr:link href="https://www.lesswrong.com/posts/f6ZLxEWaankRZ2Crv/probability-is-in-the-mind" type="external">here</fr:link>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>19</fr:day>
                </fr:date>
                <fr:title text="Proof (sketches) of equivalence">Proof (sketches) of equivalence</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Suppose <fr:tex display="inline"><![CDATA[x]]></fr:tex> belongs to some constructive nullcover, <fr:tex display="inline"><![CDATA[(U_n)]]></fr:tex>
  Then we can construct a constructive martingale which essentially makes the bet "<fr:tex display="inline"><![CDATA[x]]></fr:tex> will be in <fr:tex display="inline"><![CDATA[U_n]]></fr:tex>", continuously making a profit.
  Basically, assume we have already defined <fr:tex display="inline"><![CDATA[m(w)]]></fr:tex> for all the strings up to length <fr:tex display="inline"><![CDATA[k]]></fr:tex>,
  Consider a string <fr:tex display="inline"><![CDATA[w]]></fr:tex> of that length. Either both of <fr:tex display="inline"><![CDATA[w.0]]></fr:tex> and <fr:tex display="inline"><![CDATA[w.1]]></fr:tex> belong to <fr:tex display="inline"><![CDATA[U_k]]></fr:tex>, or neither, or exactly one of them.
  If neither do, then we know we're not looking at <fr:tex display="inline"><![CDATA[x]]></fr:tex>, so it doesn't matter.
  If both do, then we make no bet at this point, but use <fr:tex display="inline"><![CDATA[U_k]]></fr:tex> again to compure <fr:tex display="inline"><![CDATA[w.00, w.01]]></fr:tex> and so on.
  If only one of them do, then we bet all our money on that one.
  This martingale succeeds on <fr:tex display="inline"><![CDATA[x]]></fr:tex>, and is constructive because the <fr:tex display="inline"><![CDATA[U_n]]></fr:tex>s are.
</html:p>
                <html:p>
  On the other hand, suppose a constructive martingale <fr:tex display="inline"><![CDATA[m]]></fr:tex> succeeds on <fr:tex display="inline"><![CDATA[x]]></fr:tex>.
  Without loss of generality, assume <fr:tex display="inline"><![CDATA[m(\epsilon ) = 1]]></fr:tex>, where <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex> is the empty string.
  Let <fr:tex display="inline"><![CDATA[U_n]]></fr:tex> be the set of strings where <fr:tex display="inline"><![CDATA[m(w) > 2^n]]></fr:tex> for some prefix.
  Clearly no fair betting strategy can get positive expected value, so the measure of <fr:tex display="inline"><![CDATA[U_n]]></fr:tex> is at most <fr:tex display="inline"><![CDATA[2^{-n}]]></fr:tex>. On the other hand <fr:tex display="inline"><![CDATA[U_n]]></fr:tex> is computable because <fr:tex display="inline"><![CDATA[m]]></fr:tex> is. This proves equivalence of the martingale and constructive nullcover definitions.
</html:p>
                <html:p>
  Now suppose <fr:tex display="inline"><![CDATA[x]]></fr:tex> is compressible, i.e the value <fr:tex display="inline"><![CDATA[n - K(x_n)]]></fr:tex> is unbounded.
  Then there exists a program which receives and infinite bitstring as input and produces output one bit at a time, and an input <fr:tex display="inline"><![CDATA[y]]></fr:tex>, so that when run with input <fr:tex display="inline"><![CDATA[y]]></fr:tex> it produces <fr:tex display="inline"><![CDATA[x]]></fr:tex> as output, and so that the difference between the number of input bits consumed and the number of output bits produced grows without bound (the input is just a suitable sequence of very effective compressions of <fr:tex display="inline"><![CDATA[x]]></fr:tex>. The program simulates these, then outputs the extra bits from the end).
  Note that given <fr:tex display="inline"><![CDATA[n]]></fr:tex>, we can compute <fr:tex display="inline"><![CDATA[k]]></fr:tex> so that, after consuming <fr:tex display="inline"><![CDATA[k]]></fr:tex> bits of input, the program produces <fr:tex display="inline"><![CDATA[n+k]]></fr:tex> bits of output.
  Then we can define <fr:tex display="inline"><![CDATA[U_n]]></fr:tex> to be the set of infinite strings that have a length <fr:tex display="inline"><![CDATA[n+k]]></fr:tex> prefix which is a possible output of the program on an input of length <fr:tex display="inline"><![CDATA[k]]></fr:tex>.
  There are at most <fr:tex display="inline"><![CDATA[2^k]]></fr:tex> such outputs, each of which determines a set of measure <fr:tex display="inline"><![CDATA[2^{-n-k}]]></fr:tex>, so this has measure <fr:tex display="inline"><![CDATA[2^{-n}]]></fr:tex>. But clearly <fr:tex display="inline"><![CDATA[n]]></fr:tex> is in there.
</html:p>
                <html:p>
  On the other hand, suppose <fr:tex display="inline"><![CDATA[x]]></fr:tex> is in some nullcover <fr:tex display="inline"><![CDATA[U_n]]></fr:tex>.
  Then we can try to compress the prefixes of <fr:tex display="inline"><![CDATA[x]]></fr:tex> as follows:
</html:p>
                <html:p>
  -   Compute the gödel number of the program enumerating the prefixes defining <fr:tex display="inline"><![CDATA[U_n]]></fr:tex>, for some <fr:tex display="inline"><![CDATA[n]]></fr:tex>
  -   Find the <fr:tex display="inline"><![CDATA[k]]></fr:tex>th output of this program, for some <fr:tex display="inline"><![CDATA[k]]></fr:tex>, which is necessarily a prefix of <fr:tex display="inline"><![CDATA[x]]></fr:tex>. We may assume wlog that this program produces its output in ascending order of length.
</html:p>
                <html:p>
  The length of this program is a constant <fr:tex display="inline"><![CDATA[c]]></fr:tex>, to store the program computing <fr:tex display="inline"><![CDATA[(U_n)]]></fr:tex> and for gluing code, plus <fr:tex display="inline"><![CDATA[\log  n + \log  k]]></fr:tex> bits to store <fr:tex display="inline"><![CDATA[n]]></fr:tex> and <fr:tex display="inline"><![CDATA[k]]></fr:tex>.
  Let <fr:tex display="inline"><![CDATA[l_i]]></fr:tex> be the length of the <fr:tex display="inline"><![CDATA[i]]></fr:tex>th prefix defining <fr:tex display="inline"><![CDATA[U_n]]></fr:tex>
  Then <fr:tex display="inline"><![CDATA[\sum _i 2^{-l_i} \leq  2^{-n}]]></fr:tex>.
  This implies that the <fr:tex display="inline"><![CDATA[l_i]]></fr:tex> is at least <fr:tex display="inline"><![CDATA[n + \log  i]]></fr:tex>.
  Hence this is a length <fr:tex display="inline"><![CDATA[c + \log  n + \log  k]]></fr:tex> program that produces a prefix of <fr:tex display="inline"><![CDATA[x]]></fr:tex> of length at least <fr:tex display="inline"><![CDATA[n + \log  k]]></fr:tex> - hence for <fr:tex display="inline"><![CDATA[n]]></fr:tex> large enough, this is an arbitrarily good compression.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>4</fr:month>
              <fr:day>25</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/example-of-reading-process-cellular-sheaves/</fr:uri>
            <fr:display-uri>example-of-reading-process-cellular-sheaves</fr:display-uri>
            <fr:route>/example-of-reading-process-cellular-sheaves/</fr:route>
            <fr:title text="Example of my reading process: Cellular sheaves of lattices and the Tarski laplacian">Example of my reading process: Cellular sheaves of lattices and the Tarski laplacian</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
There's a lot of sort of "implicit" skills that are important in various fields of science, that you really only learn by just hanging around older people that already know them and picking things up by osmosis. This is one of the things that make it hard to just learn things by reading textbooks, as opposed to actually going to a university and getting a degree. I think we should be doing more to study and teach these sorts of skills, to the extent that it may be possible.
</html:p>
            <html:p>
Therefore, I've decided to write this post where I describe my "process" for reading papers by means of example. The paper I'll be reading is a random one that came across my feed[^fn:1]: <fr:link href="https://arxiv.org/abs/2007.04099" type="external">Ghrist and Riess: Cellular Sheaves of Lattices and the Tarski Laplacian</fr:link>.
</html:p>
            <html:p>
I got the idea for this project from Alexey Guzey <fr:link href="https://x.com/alexeyguzey/status/1385263375979008001" type="external">tweeting this:</fr:link></html:p>
            <html:p>
This post is an "async" version of Alexey's request - although as he notes in the replies to that tweet, the difference in learning rate between "reading what someone wrote about doing something" and "interacting with them as they do it live" is pretty insane. So this post is also an offer: if anyone wants to hop on a video call with me and hang out while I read a paper, let me know! My email is ayegill (at) gmail (dot) com.
</html:p>
            <html:p>
Some notes before we begin:
</html:p>
            <html:ul><html:li>I selected this papre by skimming the abstract and deciding it looked interesting. Once I'd decided I would use this paper for this post, I committed to "finishing" reading it even if it turned out to be not that interesting - normally I might have skimmed it and decided not to keep reading it.</html:li>
  <html:li>"Finishing" is obviously still pretty variable - some papers I will read in a lot more detail than this one.</html:li>
  <html:li>My process involves a lot of being distracted by twitter, having to go do something else, and so on, which has been elided in this description.</html:li>
<html:p /></html:ul>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>25</fr:day>
                </fr:date>
                <fr:title text="My process">My process</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The very first thing I do is to send the paper to my [reMarkable]. I read the paper on the reMarkable, and keep a piece of paper next to me for scratches, and my laptop open for googling and for notes.
</html:p>
                <html:p>
  I go over the beginning of the paper, taking some loose notes.
  I jot the following down on a piece of paper:
  **Terms**
</html:p>
                <html:p>
  -   Reeb graphs
  -   The thesis of curry
  -   Cellular sheaves? How do they work?
      -   (Unwritten thought: I remember that I've read about "cellular sheaves" before. They're some sort of system for encoding a sheaf on a cellular complex of some soty, in a way that's "analogous" to sheaves on the geometric realization on the complex.)
  -   Hodge Laplacian for vector spaces?
      -   (Unwritten thought: the paper is about a laplacian for lattices - this seems to be a different version of the same concept? What's that like?)
  -   Graph signal processing?
      -   (Unwritten thought: the paper described this as signal processing where the signals live on graphs instead of in real numbers?)
</html:p>
                <html:p>
  I also make notes when something makes me think of an idea related to one of my projects. At this point I'm at page 7, and I've made two such notes thus far.
</html:p>
                <html:p>
  At this point I have a vague idea of where the paper is situated - what's going on. There's a lot of references in this introduction to ideas I don't really know about, or only half remember. But nothing has made me think I should go look it up before I proceed.
</html:p>
                <html:p>
  At page 7 or so is where I get impatient with the paper just dumping a bunch of definitions around lattices on me, and start skimming forward a bit. On page 8, I notice the important point that we're dealing with categories of lattices where the morphisms are _connections_. Here I remember that I already know about <fr:link href="https://ncatlab.org/nlab/show/Galois+connection" type="external">galois connections</fr:link> - a connection being the same thing but here they don't reverse the order.
</html:p>
                <html:p>
  On page 9 we get to "cellular sheaf theory". Here the authors luckily recall the definition of cellular sheaf I was missing before. I make a note in the margin at the top of page 10: "Ie <fr:tex display="inline"><![CDATA[F(\bullet ) \to  F(\bullet  - \bullet )]]></fr:tex> - **not** the other way".
  This is the important point of a cellular sheaf
</html:p>
                <html:p>
  -   It assigns an object (vector space,set,etc) to each _cell_ in a cell complex
  -   The restriction maps go the opposite way from what you expect, from points to segments (and in general to higher-dimensional cells), not the other way around
  -   There is no sheaf condition.
</html:p>
                <html:p>
  I briefly try to connect this picture with something I half-remember about the connection between a space and the geometric realization of the <fr:link href="https://en.wikipedia.org/wiki/Nerve_of_a_covering" type="external">nerve</fr:link> of a cover (while reading the paper, I didn't remember the term Cech nerve, but just had a picture in my head which upon reflection seems to be captured by that term). I fail to make any actual progress with this but mentally note that this idea smells right. I skim the description of global sections and so on, but note the definition of the cellular cochain complex.
</html:p>
                <html:p>
  In the section on Cellular Hodge theory, I make the following note in the margin: "every de Rham class has a unique harmonic rep", summarizing what they're saying about the kernel of the Laplacian for Riemannian manifolds (/what I half-remember about this stuff). "Harmonic" here means exactly "in the kernel of the Laplacian". I make a note of the "hodge laplacian".
</html:p>
                <html:p>
  At this point I am skimming forwards a lot. I stare at the Tarski Laplacian on page  12 for a bit. I write "how does this 'diffusion' work?" in the margin. Then I think a bit about how to view this stuff as "diffusion".
  I think something like the following:
</html:p>
                <html:p>
  -   The expanding part is the completion associated to the connection
</html:p>
                <html:p><fr:tex display="inline"><![CDATA[F(v) \to  F(e)]]></fr:tex> whenever <fr:tex display="inline"><![CDATA[e]]></fr:tex> is an edge adjacent to <fr:tex display="inline"><![CDATA[v]]></fr:tex>, then the "intersection" of all those completions for every edge.
  The the mixing part is kinda this same thing, but for every _neighbor_ vertex, i.e for every edge from a different vertex <fr:tex display="inline"><![CDATA[w]]></fr:tex>, you "extend" from <fr:tex display="inline"><![CDATA[w]]></fr:tex> to the edge, then restrict to <fr:tex display="inline"><![CDATA[v]]></fr:tex>. "Mixing".
</html:p>
                <html:p>
  I read some of the stuff about how diffusion lets a cochain "flow" to a global section, and made a note of the similar property of the Tarski laplacian - that the fixpoints of <fr:tex display="inline"><![CDATA[1 \wedge  L]]></fr:tex> are exactly the global sections. Here I also thought to myself that it was interesting that this is just a _zero-dimensional_ theory, no higher homology objects.
</html:p>
                <html:p>
  Now I skim forward a bit more to page 15 at the bottom, "Tarski Cohomology", where the authors get to the question I just raised (this sort of "author mindreading" is always pleasing). They note here essentially that the definition for dimension zero also works in higher dimensions.
</html:p>
                <html:p>
  Then they pass to the comparison with more "ordinary" chain complex based cohomology. Here I initially skim forward and try to get the gist of things. I see they introduce something called the "Grandis cohomology", which I note is cohomology of a chain complex in lattices (which is in fact a preadditive category, so this makes sense kinda). You can compare this with usual cohomology by considering the "Grassmannian functor" associating to a vector space its lattice of subspaces. Here I got a bit confused about the relationship between the various types of cohomology, so I had to go back and forth a bit to make sense
</html:p>
                <html:p>
  -   The Tarski cohomology is the fixpoints of a certain endomorphism on the <fr:tex display="inline"><![CDATA[k]]></fr:tex>-chains (defined in a natural way)
  -   Given a chain complex, the Grandis cohomology is the cohomology in the usual sense
  -   We can compare these in the case of a sheaf of vector spaces, by either
      -   Constructing the usual chain complex of vector spaces, usign the Grasmannian functor and taking grandis cohomology
      -   Or taking the associated Grassmannian sheaf and then taking its Tarski cohomology.
</html:p>
                <html:p>
  These are not in general the same.
  The reason you can't just build a chain complex out of a sheaf of lattices is that, while you can define a coboundary map, it doesn't form a chain complex, in the sense that <fr:tex display="inline"><![CDATA[\delta ^2 \neq  0]]></fr:tex>.
  We can however do still do something with this fake chain complex, apparently involving mimicking the definition of the Hodge laplacian. This gives another type of cohomology, which is also not equivalent to Taski cohomology.
</html:p>
                <html:p>
  At this point there are still a lot of details I don't understand. I have the big picture, though. The next step would probably be to pick up some of the references to understand why this is useful - but I decide not to do that.
</html:p>
                <html:p>
  I also consider making flashcards or notes about this paper. This blog post is already a file in my notes, so I have that. I decide that these concepts _probably_ aren't worth comitting to memory, except "cellular sheaves", which I've come across a few times. I also decide to make notes on some of the concepts.
</html:p>
                <html:p>
  If you want to look at the sparse margin notes I took while reading this paper, it's <fr:link href="/ox-hugo/2020-04-25-ghrist.pdf" type="external">here</fr:link>.
</html:p>
                <html:p>
  [^fn:1]: In this case, it was recommended to me by &lt;https://arxivist.com&gt;
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>4</fr:month>
              <fr:day>25</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/this-weeks-finds-in-act-20210425/</fr:uri>
            <fr:display-uri>this-weeks-finds-in-act-20210425</fr:display-uri>
            <fr:route>/this-weeks-finds-in-act-20210425/</fr:route>
            <fr:title text="This Week's Finds in ACT - April 25th">This Week's Finds in ACT - April 25th</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
I wrote a long post on one of the papers I read this week: <fr:link href="/example-of-reading-process-cellular-sheaves/" title="Example of my reading process: Cellular sheaves of lattices and the Tarski laplacian" uri="https://erischel.com/example-of-reading-process-cellular-sheaves/" display-uri="example-of-reading-process-cellular-sheaves" type="local">Example of my reading process: Cellular sheaves of lattices and the Tarski laplacian</fr:link>.
See that post for the details!
</html:p>
            <html:p>
Some other stuff:
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>25</fr:day>
                </fr:date>
                <fr:title text="Jade Master: The Open Algebraic Path Problem">
                  <fr:link href="https://arxiv.org/abs/2005.06682" type="external">Jade Master: The Open Algebraic Path Problem</fr:link>
                </fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  This paper came out in 2020, so it's practically ancient history.
  But it's really cool! It's about
</html:p>
                <html:p>
  -   The problem of finding a path between two vertices on a graph
  -   An algebraic generalization of this where you replace "graph" by more exotic things (the "algebraic path problem")
  -   An _open_ generalization of this where you build your (generalized) graph by gluing together smaller examples.
</html:p>
                <html:p>
  The basic algebraic structure is a _quantale_ - an ordered set equipped with a binary operation (compatible with the order), which has all joins.
  Some basic examples:
</html:p>
                <html:p>
  -   <fr:tex display="inline"><![CDATA[\{0 \leq  1\}]]></fr:tex> with the operation <fr:tex display="inline"><![CDATA[\vee ]]></fr:tex> (OR). Here the algebraic path problem detects the existence of a path from one vertex to another.
  -   <fr:tex display="inline"><![CDATA[[0,\infty ]]]></fr:tex> equipped with <fr:tex display="inline"><![CDATA[+]]></fr:tex> and given the _reverse_ order (so join = infimum). In this case the algebraic path problem finds the length of the _shortest_ path (<fr:tex display="inline"><![CDATA[\infty ]]></fr:tex> if there is no path).
</html:p>
                <html:p>
  The first observation is that this boils down to computing the pointwise join <fr:tex display="inline"><![CDATA[\bigvee _i M^i]]></fr:tex> of all the powers of the adjacency matrix corresponding to a graph - where we simply _define_ a "graph over a quantale" to be such an adjacency matrix. If the quantale is <fr:tex display="inline"><![CDATA[\{0,1\}]]></fr:tex>, this is a graph in the usual sense, each edge is either there or not. If the quantale is <fr:tex display="inline"><![CDATA[[0,\infty ]]]></fr:tex>, each edge has a certain length (which may be infinite to denote "no edge"). Thus we have "the algebraic path problem".
</html:p>
                <html:p>
  The second observation is that you can "glue graphs together" by taking pushouts in a certain category of matrices, and this respects the computation of the paths above. There is a lot of very nice category theory in this.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>25</fr:day>
                </fr:date>
                <fr:title text="Tom Leinster: The Magnitude Of Metric Spaces">
                  <fr:link href="https://arxiv.org/abs/1012.5857v3" type="external">Tom Leinster: The Magnitude Of Metric Spaces</fr:link>
                </fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  This is an even older paper, which spawned a lively field of research (see eg <fr:link href="https://golem.ph.utexas.edu/category/2011/01/magnitude_of_metric_spaces_a_r.html" type="external">here</fr:link> and <fr:link href="https://golem.ph.utexas.edu/category/2016/09/magnitude_homology.html" type="external">here</fr:link>). This is about associating an invariant called _magnitude_ to metric spaces, which measures their "size" in a kind of hard-to-understand way:
</html:p>
                <html:p>
  -   The magnitude of a finite set of points, all at distance <fr:tex display="inline"><![CDATA[\infty ]]></fr:tex>, is the number of points
  -   As the distances go to zero, the magnitude converges to one (in the above case of finitely many points)
  -   The magnitude of the interval <fr:tex display="inline"><![CDATA[[0,t]]]></fr:tex> is <fr:tex display="inline"><![CDATA[1 + t/2]]></fr:tex>.
</html:p>
                <html:p>
  I don't think I really understand this stuff deeply, but it's very interesting!
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>4</fr:month>
              <fr:day>18</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/this-weeks-finds-in-act-20210418/</fr:uri>
            <fr:display-uri>this-weeks-finds-in-act-20210418</fr:display-uri>
            <fr:route>/this-weeks-finds-in-act-20210418/</fr:route>
            <fr:title text="This Week's Finds in ACT">This Week's Finds in ACT</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
John Baez wrote a regular blog/column called "<fr:link href="https://math.ucr.edu/home/baez/TWF.html" type="external">This Week's Finds in Mathematical Physics</fr:link>" circa 1993-2012. The entries are really a treasure trove of cool mathematical nuggets, covering everything from hardcore theoretical physics, group theory, climate models, category theory, and more.
</html:p>
            <html:p>
Imitation being the sincerest form of flattery, I decided to shamelessly steal this format, and so this is hopefully the first of many "This Week's Finds in Applied Category Theory". Below, I've summarized a few of the papers/blog post/notes/whatever I read this week. I didn't stick religiously to things I first came across this week, and indeed some of these are pretty old, but they're all things I spent some time mulling over this week.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Tom Leinster: Algebraic Closure">
                  <fr:link href="https://golem.ph.utexas.edu/category/2021/04/algebraic_closure.html" type="external">Tom Leinster: Algebraic Closure</fr:link>
                </fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Galois theory is one of the cornerstones of algebra.
  It studies the relationship between _field extensions_ - that is, inclusions <fr:tex display="inline"><![CDATA[F \subseteq  K]]></fr:tex> of one field in another - and subgroups of the group <fr:tex display="inline"><![CDATA[Aut(K/F)]]></fr:tex>, of those automorphisms <fr:tex display="inline"><![CDATA[\phi ]]></fr:tex> of <fr:tex display="inline"><![CDATA[K]]></fr:tex> with <fr:tex display="inline"><![CDATA[\phi (f) = f]]></fr:tex> for all <fr:tex display="inline"><![CDATA[f \in  F]]></fr:tex>.
  It's somewhat clunky to treat this topic using category theory, for the simple reason that a lot of constructions aren't functorial, involving some choices that can't be made canonically.
</html:p>
                <html:p>
  Tom Leinster explains a neat proof of one of the fundamental theorems, namely that all fields admit an algebraic closure. The trick here is to work with _rings_ for as long as possible, and then right at the end quotient by a maximal ideal to pass back to fields.
</html:p>
                <html:p>
  The post ends with a remarkable idea.
  The algebraic closure is not functorial, in the sense that there is no endofunctor <fr:tex display="inline"><![CDATA[\bar {-}: \mathsf {Field} \to  \mathsf {Field}]]></fr:tex> and natural transformation <fr:tex display="inline"><![CDATA[1 \to  \bar {-}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[X \to  \bar {X}]]></fr:tex> is always the inclusion of <fr:tex display="inline"><![CDATA[X]]></fr:tex> in its algebraic closure.
  However, Leinster conjectures that this can be remedied as follows:
  Consider a pair <fr:tex display="inline"><![CDATA[(\mathcal {E},k)]]></fr:tex>, where <fr:tex display="inline"><![CDATA[\mathcal {E}]]></fr:tex> is a topos and <fr:tex display="inline"><![CDATA[k]]></fr:tex> is a field in <fr:tex display="inline"><![CDATA[\mathcal {E}]]></fr:tex> - meaning a ring satisfying the formula <fr:tex display="inline"><![CDATA[\forall  x. x = 0 \vee  \exists  y. xy = 1]]></fr:tex>. Then we can consider the collection of morphisms to pairs <fr:tex display="inline"><![CDATA[(\mathcal {E}',k')]]></fr:tex>, where <fr:tex display="inline"><![CDATA[k']]></fr:tex> is algebraically closed. Then for <fr:tex display="inline"><![CDATA[\mathcal {E} = \mathsf {Set}]]></fr:tex>, <fr:tex display="inline"><![CDATA[k]]></fr:tex> a normal field, there is an initial such map, given by the topos <fr:tex display="inline"><![CDATA[Gal(k)-\mathsf {Set}]]></fr:tex> of sets with an action of the absolute Galois group of <fr:tex display="inline"><![CDATA[k]]></fr:tex>, and <fr:tex display="inline"><![CDATA[\bar {k}]]></fr:tex> equipped with its natural action.
</html:p>
                <html:p>
  Unfortunately, this doesn't hold.
  To see why, first recall why the map of ordinary fields <fr:tex display="inline"><![CDATA[i: k \to  \bar {k}]]></fr:tex> is not initial among maps from <fr:tex display="inline"><![CDATA[k]]></fr:tex> to algebraically closed fields. The reason is simply that <fr:tex display="inline"><![CDATA[Gal(\bar {k}/k)]]></fr:tex> is not trivial, so there are multiple maps <fr:tex display="inline"><![CDATA[\bar {k} \to  \bar {k}]]></fr:tex> from <fr:tex display="inline"><![CDATA[i]]></fr:tex> to <fr:tex display="inline"><![CDATA[i]]></fr:tex>.
</html:p>
                <html:p>
  Now let <fr:tex display="inline"><![CDATA[\phi ]]></fr:tex> be an element of the absolute Galois group, and consider the functor <fr:tex display="inline"><![CDATA[\phi _*: Gal(k)-\mathsf {Set} \to  Gal(k)-\mathsf {Set}]]></fr:tex> that carries a set <fr:tex display="inline"><![CDATA[X]]></fr:tex> to itself with the <fr:tex display="inline"><![CDATA[&phi;]]></fr:tex>-conjugate <fr:tex display="inline"><![CDATA[Gal(k)]]></fr:tex>-action, with <fr:tex display="inline"><![CDATA[(g,x) \mapsto  \phi  g \phi ^{-1} . x]]></fr:tex> (here <fr:tex display="inline"><![CDATA[g.x]]></fr:tex> is the original action).
  This is an equivalence of categories, so certainly a geometric morphism (even "in both directions").
  Now <fr:tex display="inline"><![CDATA[\phi ]]></fr:tex> is a map <fr:tex display="inline"><![CDATA[\bar {k} \to  \bar {k}]]></fr:tex> "over" the inclusion <fr:tex display="inline"><![CDATA[i: k \to  \bar {k}]]></fr:tex>. It's obviously not <fr:tex display="inline"><![CDATA[Gal(k)]]></fr:tex>-equivariant - but it _is_ equivariant from <fr:tex display="inline"><![CDATA[\bar {k} \to  \phi _*\bar {k}]]></fr:tex>.
  Namely, <fr:tex display="inline"><![CDATA[\phi  g \phi ^{-1} .  \phi  . x = \phi  . g.x]]></fr:tex>, which is exactly what should hold.
  Thus, both the identity and <fr:tex display="inline"><![CDATA[(\phi _*,\phi )]]></fr:tex> form maps
</html:p>
                <fr:tex display="block"><![CDATA[(Gal(k)-\mathsf {Set},\bar {k}) \to  (Gal(k)-\mathsf {Set},\bar {k})]]></fr:tex>
                <html:p>
  over <fr:tex display="inline"><![CDATA[(\mathsf {Set},k)]]></fr:tex>
  (To verify commutativity of the geomtric morphisms, the functor <fr:tex display="inline"><![CDATA[\mathsf {Set} \to  Gal(k)-\mathsf {Set}]]></fr:tex> equips a set with the trivial action, and obviously conjugating the trivial action you still get the trivial action). Just as in the normal case, this contradicts initiality.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Dan Shiebler Categorical Stochastic Processes and Likelyhood">
                  <fr:link href="https://arxiv.org/abs/2005.04735" type="external">Dan Shiebler Categorical Stochastic Processes and Likelyhood</fr:link>
                </fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  In categorical approaches to probability, we usually study categories of stochastic maps given as Kleisli categories of "probability monads" - the ur-example being the Giry monad <fr:tex display="inline"><![CDATA[G: \mathsf {Meas} \to  \mathsf {Meas}]]></fr:tex> which carries a measurable space to the space of probability measures on it.
  This is quite distinct from how something like a stochastic process is usually treated in probability theory. There one would usually consider a function <fr:tex display="inline"><![CDATA[f: X \times  \Omega  \to  Y]]></fr:tex>, where <fr:tex display="inline"><![CDATA[\Omega ]]></fr:tex> is some "background space of samples", equipped with a probability measure.
  This formulation is strictly more expressive, since it allows you to express correlations between <fr:tex display="inline"><![CDATA[f(x)]]></fr:tex> and <fr:tex display="inline"><![CDATA[f(x')]]></fr:tex>, but since this is exactly expressive power that you usually _don't_ want in the usual categorical setups, in some sense the Giry formulation may be more appropriate.
  In any case, Dan Shiebler develops this alternative approach in this paper.
  He also considers how the paradigm of _maximum likelyhood_ statistics fits into the categorical learning framework as developed eg by Fong-Spivak-Tuyeras in <fr:link href="https://arxiv.org/abs/1711.10455" type="external">Backprop as Functor</fr:link> and further by Crutwell-Gavranovic-Ghani-Wilson-Zanasi, <fr:link href="https://arxiv.org/abs/2103.01931" type="external">Categorical Foundations of Gradient-Based Learning</fr:link></html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Composing Open Dynamical Systems 2: Undirected Composition">
                  <fr:link href="https://www.algebraicjulia.org/blog/post/2021/01/resource_sharers/index.html" type="external">Composing Open Dynamical Systems 2: Undirected Composition</fr:link>
                </fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  A blog post from the AlgebraicJulia project, about implementing certain ideas from ACT in actual software.
  Here, they're discussing a notion of "composing dynamical systems".
  There are different ways of doing this:
</html:p>
                <html:p>
  -   If you have a _parameterized_ dynamical system - one which depends on certain inputs - you can let another dynamical system control those inputs
  -   If you have two dynamical systems, both with a distinguished variable of the same type, you might be able to have them _share_ that variable. This requires that you can somehow "add up" the changes prescribed by each of the dynamical systems. For example, for ODEs you can add the derivatives, and for "difference equations" like <fr:tex display="inline"><![CDATA[y_{n+1} - y_n = F(y_n)]]></fr:tex>, you can add the differences. But of course given a fully general "discrete dynamical system" like <fr:tex display="inline"><![CDATA[y_{n+1} = s(y_n)]]></fr:tex>, you can't do this.
</html:p>
                <html:p>
  The blog posts discusses the implementation of this idea in the `AlgebraicDynamics.jl` package.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Realizability as the Connection between Computable and Constructive Mathematics">
                  <fr:link href="http://math.andrej.com/2005/08/23/realizability-as-the-connection-between-computable-and-constructive-mathematics/" type="external">Realizability as the Connection between Computable and Constructive Mathematics</fr:link>
                </fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  You probably know that _intuitionistic_ logic is where you don't assume the Law of Excluded middle, <fr:tex display="inline"><![CDATA[P \vee  \neg  P]]></fr:tex> for all formulas <fr:tex display="inline"><![CDATA[P]]></fr:tex>.
  You may have heard this described also as _constructive_ logic, and heard something along the lines of "to prove an existence statement constructively, you have to provide an explicit algorithm for constructing an example".
  Since there are many interesting models of intuitionstic logic that refute LEM, which have nothing to do with algorithms (like toposes), this statement is obviously a bit odd. The right way to interpret it is _realizability logic_, which formalizes the idea of "there is a computable procedure verifying this statement". Then we find that
</html:p>
                <html:p>
  -   In order for <fr:tex display="inline"><![CDATA[\exists  a: P(a)]]></fr:tex> to hold, there must be an algorithm that produces <fr:tex display="inline"><![CDATA[a]]></fr:tex> such that <fr:tex display="inline"><![CDATA[P(a)]]></fr:tex> (in a suitable sense)
  -   The logic obeys the rules of intuitionistic logic (but not in general LEM, because this would require that for any statement, there was an algorithm which figured out whether <fr:tex display="inline"><![CDATA[P(x)]]></fr:tex> or <fr:tex display="inline"><![CDATA[\neg  P(x)]]></fr:tex> holds, which is not true).
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>3</fr:month>
              <fr:day>28</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/march-2021-links/</fr:uri>
            <fr:display-uri>march-2021-links</fr:display-uri>
            <fr:route>/march-2021-links/</fr:route>
            <fr:title text="March 2021 Links">March 2021 Links</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Also contains links from February.
</html:p>
            <html:p>
              <fr:link href="https://fantasticanachronism.com/2021/03/23/two-paths-to-the-future/" type="external">Fantastic Anachronism: Two Paths to the Future</fr:link>
            </html:p>
            <html:p><fr:link href="https://ansuz.sooke.bc.ca/entry/23" type="external">Ansuz: What color are your bits?</fr:link> What do the notions of "random number" and "copyrighted music" have in common? They're not about the specific bits under consideration, but about their _color_.
</html:p>
            <html:p><fr:link href="https://www.lesswrong.com/posts/6vPvpTZTBqe6evmKL/some-random-parenting-ideas" type="external">mike_hawke: Some random parenting ideas</fr:link>.
</html:p>
            <html:p>
              <fr:link href="https://www.lesswrong.com/posts/cR7Zfrc4BtnFes46y/why-i-am-not-in-charge" type="external">Zvi: Why I Am Not In Charge</fr:link>
            </html:p>
            <html:p>
I was very taken with Lucy Greer's blog <fr:link href="https://drossbucket.com/" type="external">drossbucket</fr:link> in general, and I particularly enjoyed this recent post: <fr:link href="https://drossbucket.com/2021/03/14/speedrun-sensemaking/" type="external">Speedrun: "Sensemaking"</fr:link>, where she tries find out as much as she can about this nebulous term in one hour. Seems like a cool thing to emulate!
</html:p>
            <html:p><fr:link href="https://futureofmatter.com/maps_of_matter.html" type="external">Michael Nielsen: Maps of Matter</fr:link>.
</html:p>
            <html:p>
              <fr:link href="https://sive.rs/kimo" type="external">Derek Sivers: There is no speed limit</fr:link>
            </html:p>
            <html:p>
              <fr:link href="https://autotranslucence.wordpress.com/2018/03/30/becoming-a-magician/" type="external">Autotranslucence: Becoming a Magician</fr:link>
            </html:p>
            <html:p>
Higman's embedding theorem states that a finitely generated group can be embedded as a subgroup of a finitely presented group precisely if there is a presentation where the relations are recursively enumerable, i.e there is a computer program that generates them one after the other.
Of course this statement makes sense if you replace "group" here by any single-sorted algebraic theory (i.e Lawvere theory) - <fr:link href="https://ncatlab.org/nlab/show/Boone+conjecture" type="external">The Boone Conjecture</fr:link> is the conjecture that it's always true.
This is now known to be false in general, but of course the problem of characterizing those algebraic theories which have this property remains.
I find this extremely cool because it reduces a question about computability theory - which seems to require a lot of essentially arbitrary choices about how powerful the model of computation should be, etc - to a purely algebraic question.
</html:p>
            <html:p><fr:link href="https://buttondown.email/hillelwayne/archive/a-binder-full-of-questions/" type="external">Hillel Wayne: A Binder Full Of Questions</fr:link>.
</html:p>
            <html:p><fr:link href="https://www.lesswrong.com/posts/JD7fwtRQ27yc8NoqS/strong-evidence-is-common" type="external">Mark Xu: Strong Evidence is Common</fr:link>.
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>2</fr:month>
              <fr:day>6</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/why-python-is-better-than-haskell/</fr:uri>
            <fr:display-uri>why-python-is-better-than-haskell</fr:display-uri>
            <fr:route>/why-python-is-better-than-haskell/</fr:route>
            <fr:title text="Why Python Is Better Than Haskell">Why Python Is Better Than Haskell</fr:title>
          </fr:frontmatter>
          <fr:mainmatter><html:p>
Also read Hillel Wayne: <fr:link href="https://buttondown.email/hillelwayne/archive/2269df89-b3fc-406f-ac2e-9d7464879ba3" type="external">Why Python Is My Favorite Language</fr:link>.
</html:p><html:p><fr:link href="https://x.com/Ayegill/status/1319624318469476352" type="external">Tweet</fr:link></html:p><html:p>
So: I like python a lot. On the other hand, I also really like haskell. I like functional programming. I like putting information into types, and having the types checked at compile-time. I like higher-order function like `map`. By god, I even like monads. I think monadic parser-combinators are just about the coolest thing in the world - especially the fact that you can implement them as a library!
</html:p><html:p>
Python is very antithetical to that. It obviously doesn't have static types. It has higher-order functions, but their use isn't super idiomatic. It's not pure. But... I still really like coding in it. In a lot of cases I _strongly_ prefer writing Python to Haskell. Probably the strongest reason for that is the build situation in Haskell, which is extremely stupid. But actually even allowing that, python seems to have a certain ease of use that Haskell doesn't. Why is that? I think the key thing is that _Haskell makes it easy to create new abstractions and regards it as a normal part of coding_.
</html:p><html:p>
Wait, what? Weren't we talking about things that make _python_ easier to use? Yes. That's what I mean. The fact that Haskell makes it easy and expected to introduce new abstractions means that, to pick up a new library, I need to understand its abstractions, and probably massage an interface between them and my program. That's super annoying.
</html:p><html:p>
When writing in python, there are essentially no abstractions, beyond the bare minimum of procedural "each command modifies variables and does IO and returns a value", along with a very small set of types of data: numbers, strings, maps, lists.
It's not that this makes libraries easy to integrate, it's that it makes them _easy to understand_. To use `requests` to talk to <fr:link href="https://www.mailgun.com/" type="external">mailgun</fr:link>, here's what I did:
</html:p><![CDATA[# the variables are populated further up...
r = requests.post(
    mgurl,
    auth=("api",MAILGUN_APIKEY),
        data={"from": sender,
              "to": [TARGET_MAIL],
              "subject": subject,
              "text": text})
return(r.text)]]><html:p>
I want to make a post request with some arguments, and get a response back (actually the response doesn't matter that much in this application, but whatever). I build the arguments (strings) and the url (a string), then shove all this into `post` function.
</html:p><html:p><fr:link href="https://stackoverflow.com/questions/33983629/basic-way-of-sending-http-post-in-haskell-using-http-conduit" type="external">Here's</fr:link> the top google result for "haskell make post request", which I just googled now while writing this post. Okay.. so I need to find a `RequestBody` (what's that?) and use `parseRequest` to turn my url into a request, where I can then insert my body..?
</html:p><html:p>
I go to the `http-conduit` docs, where I see this:
</html:p><html:img src="/bafkrmid5ybqtxkqobhiqiu6vvwquzlbnhclu6efigk2ak46yzy7bv22nn4.png" title="" /><html:p>
Okay, so after staring at this for a bit, it seems like you just put in a bytestring? That's _slightly_ more low-level than I was hoping - to be honest, I don't even know how to format a list of arguments like the above into a http request!
</html:p><html:p>
After digging around the docs page for a little while, I find this:
</html:p><html:img src="/bafkrmicd2cmvbxm6sbapmgi35teoprxpnoq3y4v3njn6z4qwks7frlyzea.png" title="" /><html:p>
Okay.. that doesn't look too bad. Now we can implement the fragment above in Haskell like this:
</html:p><![CDATA[do
  manager <- newManager defaultManagerSettings
  request <- urlEncodeBody [("from", sender),("to",targetMail),("subject",subject),("text",text)] <$> parseRequest mgurl
  response <- httpLbs request manager
  return $ body response]]><html:p>
(I actually haven't checked whether this works like I expect it to, so don't be shocked if this code doesn't work as written).
</html:p><html:p>
Okay, so in this _very simple_ case, we needed to understand two new types: `Manager` and `Request`. `RequestBody` turned out to be a red herring, although I also looked that one up. I'm going to allow `ByteString` as part of the "standard library", but if I was really writing this code I probably would've had to look up/remember how to convert between string types.
</html:p><html:p>
The `Manager` object keeps track of open connections, which is probably not needed for my application. Do I need to close my connections after I'm done or something? I actually make some other http requests earlier in this application - does it matter if I use the same manager?
</html:p><html:p>
Why does `parseRequest` use the `IO` monad? (Looks at the docs) okay, it actually uses `MonadThrow`, so I guess I should make a decision about how to handle a parse error - should I just crash with an exception or handle the error more gracefully (the Python version of this script has logging - that's probably what "should" be done).
</html:p><html:p>
Is this all very complicated? No. Is it bad design? Also no. `http-conduit` provides stuff like `simpleHttp :: MonadIO m =&gt; String -&gt; m ByteString` which lets you do simple requests. I'm gonna assume giving people the option of passing a manager object around is a good idea. Making people be explicit about what request they want instead of just making a best guess based on the arguments passed to `requests.post`.
</html:p><html:p>
Once your application gets more complicated, the extra structure imposed by Haskell starts paying dividends - the abstractions begin to simplify things, justifying the upfront cost of understanding them. And the abstractions built by the _user_ - not imported from libraries but custom-built for this application - start becoming worthwhile.
</html:p><html:p>
But while you're still at the "fucking around to do something simple" stage, it's all very overkill.
</html:p></fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>1</fr:month>
              <fr:day>31</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/january-2021-links/</fr:uri>
            <fr:display-uri>january-2021-links</fr:display-uri>
            <fr:route>/january-2021-links/</fr:route>
            <fr:title text="January 2021 Links">January 2021 Links</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Alvaro de Menard: <fr:link href="https://fantasticanachronism.com/2021/01/11/are-experts-real/" type="external">Are Experts Real?</fr:link>, and the followup, <fr:link href="https://fantasticanachronism.com/2021/01/12/unjustified-true-disbelief/" type="external">Unjustified True Disbelief</fr:link>.
The former:
</html:p>
            <html:p>
&gt; There's a superficial uniformity in the academy. If you visit the physics department and the psychology department of a university they will appear very similar: the people working there have the same titles, they instruct students in the same degrees, and publish similar-looking papers in similar-looking journals.6 The N=59 crew display the exact same shibboleths as the real scientists. This similarity provides cover so that hacks can attain the prestige, without the competence, of academic credentials.

&gt; Despite vastly different levels of rigor, different fields are treated with the ~same seriousness. Electrical engineering is definitely real, and the government bases all sorts of policies on the knowledge of electrical engineers. On the other hand nutrition is pretty much completely fake, yet the government dutifully informs you that you should eat tons of cereal and a couple loaves of bread every day. A USDA bureaucrat can hardly override the Scientists (and really, would you want them to?).
</html:p>
            <html:p>
Concavenator: <fr:link href="https://www.deviantart.com/concavenator/art/Gods-of-Salt-773947897" type="external">Gods of Salt</fr:link>.
</html:p>
            <html:p>
Michael Shulman: <fr:link href="https://arxiv.org/pdf/1703.03007.pdf" type="external">The Logic of Space</fr:link>. Especially recommend section 2.1, "On Syntax." See also <fr:link href="https://twitter.com/SC_Griffith/status/1348794302235860993" type="external">this discussion</fr:link> of a related point on twitter. "How much information is actually in a universal property" is a fascinating question, one I actually might write a longer post about at some point.
</html:p>
            <html:p>
Sarah Constantin: <fr:link href="https://srconstantin.github.io/2018/04/24/wrongology-101.html" type="external">Wrongology 101</fr:link>. Unfortunately seems to suffer from a spot of bad formatting.
</html:p>
            <html:p>
Escardó-Simpson: <fr:link href="https://sci-hub.se/10.1109/LICS.2001.932488" type="external">A universal characterization of the closed Euclidean interval</fr:link>. People often say stuff like "analysis is coalgebraic" - the description of the unit interval in this paper in what is essentially finitary terms is probably the purest example I've seen of this.
</html:p>
            <html:p>
Interesting thread: <fr:link href="https://twitter.com/JDHamkins/status/1340971317277941762" type="external">Joel David Hamkins On Twitter</fr:link></html:p>
            <html:p>
Nintil: <fr:link href="https://nintil.com/longevity/" type="external">Longevity FAQ</fr:link>.
</html:p>
            <html:p><fr:link href="https://astralcodexten.substack.com/" type="external">SSC IS BACK BABY</fr:link>, now called "Astral Codex Ten". I also recommend going to the website of Scott's new psychiatry practice, <fr:link href="https://lorienpsych.com/" type="external">Lorien Psychiatry</fr:link>, and reading his writing on psych, especially <fr:link href="https://lorienpsych.com/2020/10/30/ontology-of-psychiatric-conditions-taxometrics/" type="external">Ontology of Psychiatric Conditions: Taxometrics</fr:link>. I enjoyed <fr:link href="https://astralcodexten.substack.com/p/contra-weyl-on-technocracy" type="external">Contra Weyl on Technocracy</fr:link>, but found it a bit weak (I especially feel the "technocracy success stories" weren't very strong). I think this is because both Scott and Weyl are using the term Technocracy in a sort of confused way, although Scott seems to be grappling towards understanding in this post. I think this is an object-level disagreement masquerading as a meta-level disagreement (which is also why all of Weyls actual alternative policy proposals smell so much like more technocracy - technocracy isn't really describing what it is he's against.) I really liked this quote:
</html:p>
            <html:p>
&gt; There is no way to perfectly calculate the devastation of a potential pandemic that hasn't happened yet. But once you make even a weak effort, you notice that all the numbers are really really big.
</html:p>
            <html:p>
Jeff Kaufman: <fr:link href="https://www.jefftk.com/p/bets-bonds-and-kindergarteners" type="external">Bets, Bonds and Kindergarten</fr:link>. I might steal this idea for when I have my own children.
</html:p>
            <html:p>
Alice Maz: <fr:link href="https://www.alicemaz.com/writing/alien.html" type="external">Alien Intelligences</fr:link></html:p>
            <html:p>
Philip Wadler: <fr:link href="http://ecee.colorado.edu/ecen5533/fall11/reading/free.pdf" type="external">Theorems for free!</fr:link></html:p>
            <html:p>
Junk Heap Homotopy: <fr:link href="https://zrkrlc.com/notes/the-four-intuitions/1562959680/" type="external">The Four Intuitions</fr:link>. (Physical, Computational, Algebraic, Geometric).
</html:p>
            <html:p>
Milan Cvitcovic: <fr:link href="https://milan.cvitkovic.net/writing/things_youre_allowed_to_do/" type="external">Things You're Allowed To Do</fr:link>. Put it on Tab Snooze and read it every month.
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>1</fr:month>
              <fr:day>30</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/notes-from-pfpl/</fr:uri>
            <fr:display-uri>notes-from-pfpl</fr:display-uri>
            <fr:route>/notes-from-pfpl/</fr:route>
            <fr:title text="Notes from &quot;Practical Foundations for Programming Languages">Notes from "Practical Foundations for Programming Languages</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
_Practical Foundations for Programming Languages_ (PFPL), by Robert Harper, is an introduction to the theory of programming languages.
I recently finished reading through it. My read was fairly cursory - I stopped to think about ideas which seemed important or interesting, but I didn't read everything deeply, and I didn't do a lot of exercises.
</html:p>
            <html:p>
In this post I'll summarize the things I got from it that seemed really interesting.
I'll be giving my own perspective (much more category-oritented), not trying to stick to the book. This also means I might be mixing in some of my own thoughts that weren't really in the text, without any effort made to distinguish them. Sorry! If there's a dumb thing here don't assume that means the book is dumb.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="Should you read it?">Should you read it?</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  I don't regret skimming. The book spends a lot of time on concepts which didn't really seem interesting to me - but of course that's highly personal, and I guess it's trying to be somewhat comprehensive, so that's the price you pay.
  I might have strongly preferred to read a summary of the interesting ideas (like this one), but it's hard to say how much I would have absorbed - somehow you usually learn more from being a bit immersed in things.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="Table of contents">Table of contents</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  (of the book). Reproduced here so you can see if anything strikes your fancy:
</html:p>
                <html:p>
  1.  Judgment and rules
  2.  Statics and dynamics
  3.  Total functions
  4.  Finite data types
  5.  Types and propositions
  6.  Infinite data types
  7.  Variable types
  8.  Partiality and recursive types
  9.  Dynamic types
  10. Subtyping
  11. Dynamic dispatch
  12. Control flow
  13. Symbolic data
  14. Mutable state
  15. Parallelism
  16. Concurrency and distribution
  17. Modularity
  18. Equational reasoning
  19. Appendices.
</html:p>
                <html:p>
  My notes won't be following this structure.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="Induction and coinduction">Induction and coinduction</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  This is probably the biggest thing I got out of this book.
  A lot of this is just my existing learning on this stuff finally crystallizing - so what I've written here may reflect me a lot more than the book.
</html:p>
                <html:p>
  Given a functor <fr:tex display="inline"><![CDATA[F: \mathcal {C} \to  \mathcal {C}]]></fr:tex>, we can try to solve the equation <fr:tex display="inline"><![CDATA[F(X) \cong  X]]></fr:tex> in at least two ways:
  We can take an _initial algebra_ of <fr:tex display="inline"><![CDATA[F]]></fr:tex>, or a _terminal coalgebra_ of <fr:tex display="inline"><![CDATA[F]]></fr:tex>.
  Recall that an algebra is an object <fr:tex display="inline"><![CDATA[X]]></fr:tex> with a map <fr:tex display="inline"><![CDATA[FX \to  X]]></fr:tex>.
  There's an obvious category of algebras, and it's a theorem that for the initial object <fr:tex display="inline"><![CDATA[I]]></fr:tex>, if it exists, the map <fr:tex display="inline"><![CDATA[FI \to  I]]></fr:tex> is an isomorphism.
  Dually, a coalgebra is an object with a map <fr:tex display="inline"><![CDATA[X \to  FX]]></fr:tex>, there's a category of coalgebras, and if there is a terminal object <fr:tex display="inline"><![CDATA[T]]></fr:tex>, <fr:tex display="inline"><![CDATA[T \to  FT]]></fr:tex> is an isomorphism.
  These correspond in some sense to "minimal" and "maximal" solutions of the equation <fr:tex display="inline"><![CDATA[F(X) \cong  X]]></fr:tex>.
</html:p>
                <html:p>
  Example: Let <fr:tex display="inline"><![CDATA[\mathcal {C} = \mathsf {Set}]]></fr:tex>, <fr:tex display="inline"><![CDATA[F(X) = 1 + X]]></fr:tex>.
  The initial algbra is the set of naturals, with <fr:tex display="inline"><![CDATA[\xi : 1 + \mathbb {N} \to  \mathbb {N}]]></fr:tex> taking <fr:tex display="inline"><![CDATA[* \in  1]]></fr:tex> to <fr:tex display="inline"><![CDATA[0]]></fr:tex> and <fr:tex display="inline"><![CDATA[n \in  \mathbb {N}]]></fr:tex> to <fr:tex display="inline"><![CDATA[n+1]]></fr:tex>.
  The terminal coalgebra is the set of _conaturals_, <fr:tex display="inline"><![CDATA[\mathbb {N} \cup  \{\infty \}]]></fr:tex>, with <fr:tex display="inline"><![CDATA[\xi ]]></fr:tex> taking <fr:tex display="inline"><![CDATA[0]]></fr:tex> to <fr:tex display="inline"><![CDATA[*]]></fr:tex>, and every other conatural <fr:tex display="inline"><![CDATA[n]]></fr:tex> to <fr:tex display="inline"><![CDATA[n-1]]></fr:tex> (with <fr:tex display="inline"><![CDATA[\infty  - 1 = \infty ]]></fr:tex>).
</html:p>
                <html:p>
  Let's say you want to construct a map <fr:tex display="inline"><![CDATA[\mathbb {N} \to  X]]></fr:tex>. You can do so by _induction_: specify an <fr:tex display="inline"><![CDATA[F]]></fr:tex>-algebra structure on <fr:tex display="inline"><![CDATA[X]]></fr:tex>,
  and there'll automatically be a unique homomorphism <fr:tex display="inline"><![CDATA[\mathbb {N} \to  X]]></fr:tex>.
  This algebra structure corresponds to a map <fr:tex display="inline"><![CDATA[f: 1 + X \to  X]]></fr:tex>. This map tells you:
</html:p>
                <html:p>
  1.  <fr:tex display="inline"><![CDATA[f(* \in  1)]]></fr:tex> is where <fr:tex display="inline"><![CDATA[0]]></fr:tex> should go
  2.  <fr:tex display="inline"><![CDATA[f(x \in  X)]]></fr:tex> is where <fr:tex display="inline"><![CDATA[n+1]]></fr:tex> should go, if <fr:tex display="inline"><![CDATA[n]]></fr:tex> goes to <fr:tex display="inline"><![CDATA[x]]></fr:tex>.
</html:p>
                <html:p>
  In other words, and inductive definition.
</html:p>
                <html:p>
  Moreover, you can prove properties of such maps using initiality.
  Let <fr:tex display="inline"><![CDATA[f: \mathbb {N} \to  X]]></fr:tex> be an algebra homomorphism, and let's suppose I want to show that <fr:tex display="inline"><![CDATA[f(n) \in  U \subset  X]]></fr:tex> for some subset.
  Then it suffices to prove that there is an algebra homomorphism <fr:tex display="inline"><![CDATA[p: Y \to  X]]></fr:tex> with image contained in <fr:tex display="inline"><![CDATA[U]]></fr:tex>.
  The obvious way to construct this homomorphism is to let <fr:tex display="inline"><![CDATA[Y]]></fr:tex> be some subset of <fr:tex display="inline"><![CDATA[X]]></fr:tex>, contained in <fr:tex display="inline"><![CDATA[U]]></fr:tex>.
  For <fr:tex display="inline"><![CDATA[Y]]></fr:tex> to be an algebra, we must have, if <fr:tex display="inline"><![CDATA[s: 1 + X \to  X]]></fr:tex>, <fr:tex display="inline"><![CDATA[s(*)\in  Y]]></fr:tex> and <fr:tex display="inline"><![CDATA[s(y) \in  Y]]></fr:tex> for <fr:tex display="inline"><![CDATA[y \in  Y]]></fr:tex>.
  In other words, <fr:tex display="inline"><![CDATA[Y]]></fr:tex> must be stable under successor and contain the initial element.
</html:p>
                <html:p>
  We can in particular do ordinary induction by applying this to the identity map.
  Let <fr:tex display="inline"><![CDATA[U \subset  \mathbb {N}]]></fr:tex> be the subset of elements satisfying some property.
  I want to show that the identity has image contained in <fr:tex display="inline"><![CDATA[U]]></fr:tex>, i.e that <fr:tex display="inline"><![CDATA[U]]></fr:tex> is the whole thing.
  It suffices to show that it contains <fr:tex display="inline"><![CDATA[0]]></fr:tex> and is closed under taking successor, i.e to perform induction in the usual sense.
</html:p>
                <html:p>
  Coinduction is dual to this. It lets you construct maps into the terminal algebra, and prove equality between such maps.
  Now maybe let <fr:tex display="inline"><![CDATA[F(X) = A \times  X]]></fr:tex> for some set <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
  The terminal coalgebra is the set <fr:tex display="inline"><![CDATA[A^\omega ]]></fr:tex> of _streams_, functions <fr:tex display="inline"><![CDATA[\mathbb {N} \to  A]]></fr:tex>, with the structure map <fr:tex display="inline"><![CDATA[A^\omega  \to  A \times  A^\omega ]]></fr:tex> slicing off the first element.
</html:p>
                <html:p>
  Given a map <fr:tex display="inline"><![CDATA[X \to  A \times  X]]></fr:tex>, we get a map <fr:tex display="inline"><![CDATA[f: X \to  A^\omega ]]></fr:tex> by terminality.
  Moreover, we can use _coinduction_ to show that <fr:tex display="inline"><![CDATA[f(x) = f(y)]]></fr:tex> for some <fr:tex display="inline"><![CDATA[x,y \in  X]]></fr:tex>.
  Namely, if we can find any coalgebra homomorphism <fr:tex display="inline"><![CDATA[g: X \to  \bar {X}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[g(x) = g(y)]]></fr:tex>,
  then we must have <fr:tex display="inline"><![CDATA[f(x) = f(y)]]></fr:tex>, since we automatically have <fr:tex display="inline"><![CDATA[f = f'g]]></fr:tex>, with <fr:tex display="inline"><![CDATA[f': \bar {X} \to  A^\omega ]]></fr:tex> the unique map.
  How do we construct such a map? The obvious way is to let <fr:tex display="inline"><![CDATA[\bar {X}]]></fr:tex> the quotient of <fr:tex display="inline"><![CDATA[X]]></fr:tex> by some equivalence relation <fr:tex display="inline"><![CDATA[\sim ]]></fr:tex>.
  For <fr:tex display="inline"><![CDATA[X/\sim ]]></fr:tex> to still be an algebra - in other words, for the map <fr:tex display="inline"><![CDATA[X \to  A \times  X]]></fr:tex> to descend to a map <fr:tex display="inline"><![CDATA[X/\sim  \to  A \times  X/\sim ]]></fr:tex>,
  we must have that
</html:p>
                <html:p>
  1.  <fr:tex display="inline"><![CDATA[x \sim  y]]></fr:tex> entails <fr:tex display="inline"><![CDATA[s_1(x) = s_1(y)]]></fr:tex>
  2.  <fr:tex display="inline"><![CDATA[x \sim  y]]></fr:tex> entails <fr:tex display="inline"><![CDATA[s_2(x) \sim  s_2(y)]]></fr:tex></html:p>
                <html:p>
  where <fr:tex display="inline"><![CDATA[s_1: X \to  A, s_2: X \to  X]]></fr:tex> are the two components of <fr:tex display="inline"><![CDATA[s: X \to  A \times  X]]></fr:tex>.
</html:p>
                <html:p>
  The general slogan is that induction lets us understand _maps out of the structure_ - which includes
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="What does &quot;type safety&quot; even mean?">What does "type safety" even mean?</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The simplest explanation of this is that type safety is a property of a type system and a "operational semantics",
  i.e of a model of program execution. In turn the simplest notion of execution is to give:
</html:p>
                <html:p>
  -   A subset of expressions in the language called "values", which are "done", i.e they represent the results of computation
  -   A relation <fr:tex display="inline"><![CDATA[e \mapsto  e']]></fr:tex> on expressions saying "e can evaluate to e' in one execution step".
</html:p>
                <html:p>
  Then type safety means, if <fr:tex display="inline"><![CDATA[e]]></fr:tex> is well-typed of type <fr:tex display="inline"><![CDATA[\tau ]]></fr:tex>, either <fr:tex display="inline"><![CDATA[e \mapsto  e']]></fr:tex> for some <fr:tex display="inline"><![CDATA[e' : \tau ]]></fr:tex>, or <fr:tex display="inline"><![CDATA[e]]></fr:tex> is a value.
  You _don't_ want to say something like "any well-typed program evaluated to a value of that type", because your type system probably doesn't guarantee termination (if it does, you language is not Turing complete).
  Obviously you need more sophisticated versions of this to account for more complicated models of program evaluation, programs with side effects, etc, but this is the idea.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="Quantified and self-referential types">Quantified and self-referential types</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Given a type <fr:tex display="inline"><![CDATA[T]]></fr:tex> with a free type variable <fr:tex display="inline"><![CDATA[t]]></fr:tex> (like <fr:tex display="inline"><![CDATA[t \times  \mathrm {int}]]></fr:tex>), we can form the type <fr:tex display="inline"><![CDATA[\forall  t. T]]></fr:tex>.
  An element of this type should be something that can "play the role" of <fr:tex display="inline"><![CDATA[T]]></fr:tex> no matter what <fr:tex display="inline"><![CDATA[t]]></fr:tex> is.
  For example <fr:tex display="inline"><![CDATA[\lambda  x^A.x: A \to  A]]></fr:tex> gives an element of <fr:tex display="inline"><![CDATA[\forall  A. A \to  A]]></fr:tex>.
</html:p>
                <html:p>
  The behaviour of elements of this type is basically:
</html:p>
                <html:p>
  -   you can "cast" an element of <fr:tex display="inline"><![CDATA[\forall  t. T]]></fr:tex> to <fr:tex display="inline"><![CDATA[T[A/t]]]></fr:tex>, i.e you can "specialize" the value.
  -   To produce an element of <fr:tex display="inline"><![CDATA[\forall  t. T]]></fr:tex>, i have to produce an element that typechecks as <fr:tex display="inline"><![CDATA[T]]></fr:tex>, no matter what the value of <fr:tex display="inline"><![CDATA[t]]></fr:tex> is (the type variable <fr:tex display="inline"><![CDATA[t]]></fr:tex> can't appear in the context).
</html:p>
                <html:p>
  Similarly you can make sense of "existential types" <fr:tex display="inline"><![CDATA[\exist  t. T]]></fr:tex>.
</html:p>
                <html:p>
  Once you have these, you can define _recursive_ types, too.
  Take something like a list of integers: `Data Intlist = Nil | Cons Int Intlist`.
  In other words, `Intlist = () + (Int,Intlist)`.
</html:p>
                <html:p>
  We can type this using universally quantified types as <fr:tex display="inline"><![CDATA[\forall  t. ((() + \mathrm {Int} \times  A) \to  A) \to  A]]></fr:tex>.
  This basically means: you give me an <fr:tex display="inline"><![CDATA[a : A]]></fr:tex> and a map <fr:tex display="inline"><![CDATA[m: \mathrm {Int} \times  A \to  A]]></fr:tex>, and I give you an <fr:tex display="inline"><![CDATA[A]]></fr:tex>, for any type <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
  The `Nil` constructor is the map which simply returns the given <fr:tex display="inline"><![CDATA[a]]></fr:tex>.
  The `Cons n l` constructor, for `n` an integer, returns an intlist which, given <fr:tex display="inline"><![CDATA[(a,m)]]></fr:tex>, feeds it to `l` (returning <fr:tex display="inline"><![CDATA[a']]></fr:tex>),
  then computes <fr:tex display="inline"><![CDATA[m(n,a')]]></fr:tex> and returns it.
</html:p>
                <html:p>
  If you unpack this in your head, you'll see that this is exactly folding. A list is something you can fold over - the <fr:tex display="inline"><![CDATA[a]]></fr:tex> provided is the initial accumulator and the <fr:tex display="inline"><![CDATA[m: \mathrm {Int} \times  A \to  A]]></fr:tex> is the combination map.
</html:p>
                <html:p>
  The general formulation of the above is <fr:tex display="inline"><![CDATA[\forall  a. (T(a) \to  a) \to  a]]></fr:tex>. Essentially, we are picking out the _initial algebra_ of <fr:tex display="inline"><![CDATA[T]]></fr:tex>, by saying that this is the universal thing with a map to <fr:tex display="inline"><![CDATA[a]]></fr:tex> for each <fr:tex display="inline"><![CDATA[T]]></fr:tex>-algebra structure on <fr:tex display="inline"><![CDATA[a]]></fr:tex> [^fn:1].
</html:p>
                <html:p>
  We could also pick out the _terminal coalgebra_, by writing <fr:tex display="inline"><![CDATA[\exists  (a \to  T(a), a)]]></fr:tex>.
  This has the dual meaning - given any <fr:tex display="inline"><![CDATA[T]]></fr:tex>-coalgbra structure, and a point in the carrier, we obtain a point of the terminal coalgebra.
  The terminal coalgebra of <fr:tex display="inline"><![CDATA[T(x) = () + x \times  \mathrm {Int}]]></fr:tex> is the type of "colists" - possibly infinite lists (of integers).
  We see above that to produce a colist, we have to provide an element <fr:tex display="inline"><![CDATA[a : A]]></fr:tex> of some type, as well as a map <fr:tex display="inline"><![CDATA[s: A \to  () + A \times  \mathrm {Int}]]></fr:tex>. <fr:tex display="inline"><![CDATA[s(a) = ()]]></fr:tex> means the list is empty, <fr:tex display="inline"><![CDATA[s(a) = (a',n)]]></fr:tex> means <fr:tex display="inline"><![CDATA[n]]></fr:tex> is the head and the rest of the list corresponds to the pair <fr:tex display="inline"><![CDATA[(s,a')]]></fr:tex>. This is "iteration", or maybe "cofolding".
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="How a call stack works">How a call stack works</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  This is about how to evaluate programs. Simple "pure functional" languages can "just" be evaluated by successively applying reduction rules. But this is pretty limited - both in performance terms, but also prevents you from doing a few cool things, like _continuations_.
</html:p>
                <html:p>
  A _call stack_ is basically a list of functions - in the sense of "expressions with a hole in them" - that are waiting for the result of computation, along with a value that's being evaluated, and a "pointer" which tells us whether the next step is to reduce the active value some more, or to return it, i.e plug it into the next function
</html:p>
                <html:p>
  So eg the stack `a;b;c &gt; e` means "we're in the process of evaluating `e`. Once that's done, evaluate `c e`, then `b (c e)` and so on". On the other hand `a;b;c &lt; e` means "`e` is a value that's done evaluating, pass it to `c`, then `b`, then `a`.
</html:p>
                <html:p>
  Then you need to make up some rules for how to handle these things - which order to evaluate expressions and so on.
</html:p>
                <html:p>
  To augment this language with continuations, you can add expressions like `callcc : (Cont(a) -&gt; a) -&gt; a` and `throw : a -&gt; Cont(a) -&gt; b`, where the meaning of `callcc` is "run this function with a "continuation" pointing the current state - if the continuation is ever "used" by `throw`, just immediately return the value `a` that was supplied".
  Then the dynamics of this stuff is:
</html:p>
                <html:p>
  -   `s &gt; callcc f` evaluates to `s &gt; f [s]`, where `[s] : Cont a` is a representation of the current stack, and
  -   `s' &gt; throw a [s]` evaluates to `s &gt; a`, i.e throwing restores the stack from the time the continuation was created.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2021</fr:year>
                  <fr:month>1</fr:month>
                  <fr:day>30</fr:day>
                </fr:date>
                <fr:title text="Parametricity">Parametricity</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  You might have heard about "free theorems", from Wadler's paper <fr:link href="http://ecee.colorado.edu/ecen5533/fall11/reading/free.pdf" type="external">Theorems for Free!</fr:link>.
  Parametricity is the technical term for those things.
  The basic idea is that a term of polymorphic type has certain properties _purely by virtue of its type_.
  This is the so-called "free theorem" associated to that type.
</html:p>
                <html:p>
  The basic idea behind parametricity is to associate a relation to every type:
</html:p>
                <html:p>
  -   Elements of "primitive" types like <fr:tex display="inline"><![CDATA[\mathrm {Int}]]></fr:tex> and such are equivalent if they're equal (this is just a relation on the type itself)
  -   Elements of the product type <fr:tex display="inline"><![CDATA[A \times  B]]></fr:tex> are equivalent if they have equivalent coordinates (according to the relations associated to <fr:tex display="inline"><![CDATA[A]]></fr:tex> and <fr:tex display="inline"><![CDATA[B]]></fr:tex>)
  -   Elements of function types <fr:tex display="inline"><![CDATA[A \to  B]]></fr:tex> are equivalent if they map equivalent terms to equivalent terms, i.e <fr:tex display="inline"><![CDATA[f \sim  f']]></fr:tex> if <fr:tex display="inline"><![CDATA[a \sim  a']]></fr:tex> implies <fr:tex display="inline"><![CDATA[f(a) \sim  f'(a')]]></fr:tex>.
  -   Let <fr:tex display="inline"><![CDATA[A \mapsto  T(A)]]></fr:tex> be a "type operator" - we can interpret it as an operation on _relations_ - in particular, it can act on relations <fr:tex display="inline"><![CDATA[A \leftrightarrow  A']]></fr:tex> which are not defined on a single set. The relation <fr:tex display="inline"><![CDATA[\forall . A T(A)]]></fr:tex> is the relation on the set <fr:tex display="inline"><![CDATA[\prod _A T(A)]]></fr:tex> defined by <fr:tex display="inline"><![CDATA[g \sim  g']]></fr:tex> if <fr:tex display="inline"><![CDATA[g_A \sim _T(\alpha ) g_A']]></fr:tex> for all relations <fr:tex display="inline"><![CDATA[\alpha : A \leftrightarrow  A']]></fr:tex>.
</html:p>
                <html:p>
  The statement of parametricity is then that <fr:tex display="inline"><![CDATA[x \sim  x]]></fr:tex> for all (well-typed) terms <fr:tex display="inline"><![CDATA[x]]></fr:tex> of closed type.
</html:p>
                <html:p>
  For example, parametricity for <fr:tex display="inline"><![CDATA[id: \forall  A. A \to  A]]></fr:tex> means that for any relation <fr:tex display="inline"><![CDATA[\sim : A \leftrightarrow  B]]></fr:tex>, we have <fr:tex display="inline"><![CDATA[id_A(a) \sim   id_B(b)]]></fr:tex> if <fr:tex display="inline"><![CDATA[a \sim  b]]></fr:tex>.
  Specializing eg to <fr:tex display="inline"><![CDATA[a \sim  b]]></fr:tex> if and only if <fr:tex display="inline"><![CDATA[a = a_0]]></fr:tex> for some fixed element (taking maybe <fr:tex display="inline"><![CDATA[B=()]]></fr:tex>), we see that <fr:tex display="inline"><![CDATA[id]]></fr:tex> must be the identity. The precise version of this is more complicated, because you need to deal with the possibility that there may be free type variables around, and also the fact that a type is not really a set (so you need to work with relations on _terms_ - this is what the book does - or use domain theory - this is what Wadler does).
</html:p>
                <html:p>
  [^fn:1]: Although the quantified definition is more general, because it works even when <fr:tex display="inline"><![CDATA[T]]></fr:tex> is not a functor in <fr:tex display="inline"><![CDATA[a]]></fr:tex>, but just some type that depends on <fr:tex display="inline"><![CDATA[a]]></fr:tex></html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2021</fr:year>
              <fr:month>1</fr:month>
              <fr:day>21</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/numbers/</fr:uri>
            <fr:display-uri>numbers</fr:display-uri>
            <fr:route>/numbers/</fr:route>
            <fr:title text="Where numbers come from">Where numbers come from</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Alternative title: Wolves hate him!! Shepherd compares the size of large sets with this one easy trick!
</html:p>
            <html:p>
Previously: <fr:link href="https://www.lesswrong.com/posts/S6MerYRZw4jDrzGGD/recognizing-numbers" type="external">Recognizing Numbers</fr:link></html:p>
            <html:p>
Let's do a thought experiment.
I place an empty box in front of you. Then, while you're watching, I put these objects into the box:
</html:p>
            <html:img src="/bafkrmiakp54yun64phdgmiroovwncg4i6o5gj2p5ne2crgxpr6wkrmmcri.png" title="2 apples" />
            <html:p>
Then I remove these things from the box:
</html:p>
            <html:img src="/bafkrmic3rvn6pvhfkdfw5imyebryhtnhcpblnz35ftzhyskazmajiz2zbi.png" title="3 apples" />
            <html:p>
You're surprised! Why? Because what I took out is not a subset of what I put in. A new apple appeared.
</html:p>
            <html:p>
You can do this experiment with animals, and small children of various ages, and monitor them carefully to see if they seem surprised. You can also try *larger collections of apples*, to see how large a collection of apples they can keep track of.
</html:p>
            <html:p>
Once children are old enough to talk, you can make the experiment more reliable by simply asking them if the box is empty. But of course, there's a small window of interestingness here - children beyond a certain age rapidly get extremely good at this problem, and from a certain point humans basically never fail at this task, unless the pile of apples gets extremely large. This does not surprise you at all.
</html:p>
            <html:p>
The following picture switches back and forth between two collections of apples. Can you tell whether they're the same size "in one go" - without letting it switch back and forth more than once?
</html:p>
            <html:img src="/bafkrmicc3bso457ywn4uxbkgnee5twifyuboe7uvhqyzy2g2y5dy6eujom.gif" title="apples gif" />
            <html:p>
This, it turns out, is actually very hard. Even grown human brains don't come hardwired with an arbitrarily powerful "compare the size of two collections" module. You can compare the *visual* size, which can give you the answer if the relative difference in size is moderately large. But in a case like the above, it's very hard to tell the size of those two collections apart.
</html:p>
            <html:p>
Here's a simple piece of technology for comparing the size of two collections: pair of the elements one after the other. If the collections are exhausted at the same time, they're the same size. If not, whichever has elements left at the end is bigger.
</html:p>
            <html:p>
Of course, this won't work if the collections are not available *at the same time* to be compared. This could be for a contrived reason like above, the image flashing back and forth. Or it could be for a practical reason - <fr:link href="https://www.lesswrong.com/posts/X3HpE8tMXz4m4w6Rz/the-simple-truth" type="external">a shepherd wants to compare the set of sheep in the pen when he opens the gate in the morning to the set of sheep in the pen before he closes the gate at night.</fr:link></html:p>
            <html:p>
So humans, so long ago that the origins have been completely forgotten, but certainly more than 20.000 years ago, came up with an ingenious technology to solve this problem:
</html:p>
            <html:img src="https://upload.wikimedia.org/wikipedia/commons/thumb/4/42/Os_d%27Ishango_IRSNB.JPG/800px-Os_d%27Ishango_IRSNB.JPG" title="Ishango bone" />
            <html:p>
I will describe it for you now.
We invented a *reference set* of every possible size (infinities had not been invented yet). There are many such families of reference sets, but here is the one you are probably familiar with:
</html:p>
            <html:ul><html:li><fr:tex display="inline"><![CDATA[\{1\}]]></fr:tex></html:li>
  <html:li><fr:tex display="inline"><![CDATA[\{1,2\}]]></fr:tex></html:li>
  <html:li><fr:tex display="inline"><![CDATA[\{1,2,3\}]]></fr:tex></html:li>
  <html:li><fr:tex display="inline"><![CDATA[\dots ]]></fr:tex></html:li>
<html:p /></html:ul>
            <html:p>
Before I let out the sheep in the morning, I *identify the reference set with the same size as the collection of sheep*. I do this by the procedure used above - I match up sheep with elements of the reference sets until I run out of sheep. "1,2,3,4,5,6,7,8,9,10,11". Now I know that the collection of sheep has the same size as the collection
<fr:tex display="inline"><![CDATA[\{1,2,3,4,5,6,7,8,9,10,11\}]]></fr:tex>. This is called *counting*.
In the evening, I compare that collection with the collection of sheep that came back - if they're not the same size, I know about the discrepancy.
</html:p>
            <html:p>
It's important to emphasize that numbers are really a *technology* - it had to be invented. We know this because there exist communities without this technology. You've probably heard about languages without a name for numbers above 2 - "one, two, many". Well, that's more or less real. The most famous are the <fr:link href="https://en.wikipedia.org/wiki/Pirahã_people" type="external">Pirahã</fr:link> of the Amazon rainforest.
Their language has two words "hói" "hoí" (distinguished by tone) - originally taken to mean "one" and "two", but now believed to probably mean something like "small quantity" and "larger quantity". These are the closest thing to numerals in their language. 
Experiments like the one I described at the beginning have been put to them[^2] - even adult humans usually begin to fail at this task even when the number of objects is as low as four or five. They *don't* fail at this task when simply asked to match the number of object placed in a line of the table. They understand what it means for two sets to be *in bijection*, but they lack the technology of numbers to keep track of this information. The Pirahã are quite capable of hunting, gathering, cultivating manioc, crafting bows and arrows, building huts, and generally surviving in the jungle. They're not *stupid*. But they really, truly, do not know how to count.[^3]
</html:p>
            <html:p>
[^3]: Actually, it seems some meddlesome people have started teaching the Pirahã Portugese, including numerals, and basic mathematics. So the world may be about to lose one of the few examples of numberless peoplmay be about to lose one of the few examples of numberless people..
</html:p>
            <html:p>
The main trick here is *abstraction*. We remove all the details of the individual sheep and remember *only* the "number" - the *size* of the collection, its ability to count other things, be in bijection with other things. A mathematician might say "the bijection class of the set", if they did not have the word "number".
</html:p>
            <html:p>
The second trick, also important, is *reification*. You can see how much I fumble for words above, trying to describe the concept "the number of elements in a set" without using the word "number". This is not a quantity you can put inside your brain. So we choose a *simple representative*. Whoever made the Ishango bone, pictured above, choose a set of marks on a bone to represent the bijection class. This is convenient because you can just keep the set of marks, i.e the bone, with you until you need the number again (unlike the set of sheep, which you have to let out to graze, that's the whole point). Another implementation is by creating a set of *words*. The set <fr:tex display="inline"><![CDATA[\{1,2,3\}]]></fr:tex>, or <fr:tex display="inline"><![CDATA[\{\text {one}, \text {two}, \text {three}\}]]></fr:tex>, is a handy set of a given size.
We name this set after its largest element - "three" - and to reconstruct the set from the name, you only need to recall the order of the special size-words[^1]
</html:p>
            <html:p>
[^1]: In mathematics, we might define <fr:tex display="inline"><![CDATA[3]]></fr:tex> to be the set <fr:tex display="inline"><![CDATA[\{0,1,2\}]]></fr:tex> instead - this has the advantage that the definition is not self-referential, and maybe technically convenient for other reasons. But most people count starting from 1, not 0.
</html:p>
            <html:p>
[^2]: See <fr:link href="https://www.sciencedirect.com/science/article/abs/pii/S0010027708001042?via=ihub" type="external">Number as a cognitive technology: Evidence from Pirahã language and cognition</fr:link>. Concretely, the subjects were asked to match the number of objects placed by the experimenter. In one experiment, the experimenter simply put objects down in a line on the table. In another, the objects were dropped one after the other into an opaque container. The subject then had to place the same number of objects on their side of the table. There were a few different versions of this. Maybe it's important to note here that this study was not exactly high-n, and communication with the subjects was unreliable for obvious reasons. There were a few failures even on the "easy" versions of the tasks, so perhaps it's not entirely clear how much of the results should be put down to the subjects having trouble representing cardinalities in their head, and how much should be put down to different versions of the task being harder to understand, or even simply deciding to mess with the experimenters.
</html:p>
            <html:p>
(Thanks to John for inspiring me to write this).
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>12</fr:month>
              <fr:day>31</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/december-2020-links/</fr:uri>
            <fr:display-uri>december-2020-links</fr:display-uri>
            <fr:route>/december-2020-links/</fr:route>
            <fr:title text="December 2020 Links">December 2020 Links</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
A list of some of the things I found interesting in December.
</html:p>
            <html:p><fr:link href="https://www.lowtechmagazine.com/" type="external">Low-Tech Magazine</fr:link>: "Low-tech Magazine questions the blind belief in technological progress, and talks about the potential of past and often forgotten knowledge and technologies when it comes to designing a sustainable society. Interesting possibilities arise when you combine old technology with new knowledge and new materials, or when you apply old concepts and traditional knowledge to modern technology". Sample articles: <fr:link href="https://www.lowtechmagazine.com/2016/11/the-curse-of-the-modern-office.html" type="external">The Curse of the Modern Office</fr:link>, <fr:link href="https://www.lowtechmagazine.com/2014/06/thermal-efficiency-cooking-stoves.html" type="external">Well-tended fires outperform modern cooking stoves</fr:link>, <fr:link href="https://www.lowtechmagazine.com/2015/10/can-the-internet-run-on-renewable-energy.html" type="external">Why we need a speed limit for the internet</fr:link>.
</html:p>
            <html:p>
Evangelia Aleiferi: <fr:link href="https://arxiv.org/abs/1809.06940" type="external">Cartesian Double Categories with an Emphasis on Characterizing Spans</fr:link>.
</html:p>
            <html:p>
Owen Lynch: <fr:link href="https://owenlynch.org/posts/2020-09-16-haskells-children/" type="external">Haskell's Children</fr:link> (Owen's whole blog is worth reading).
</html:p>
            <html:p>
Tobias Fritz has put up some <fr:link href="http://tobiasfritz.science/2020/statistical_experiments.pdf" type="external">slides</fr:link> discussing our <fr:link href="https://arxiv.org/abs/2010.07416" type="external">new preprint</fr:link> about comparison of experiments (with Paolo Perrone and Tomás Gonda).
</html:p>
            <html:p>
I've been rereading <fr:link href="https://arxiv.org/abs/2006.01631" type="external">Bayesian Updates Compose Optically</fr:link> by Toby St Clere Smithe.
</html:p>
            <html:p>
Michael Nielsen: <fr:link href="https://michaelnielsen.org/blog/principles-of-effective-research/" type="external">Principles of Effective Research</fr:link>.
</html:p>
            <html:p>
Applied Divinity Studies: <fr:link href="https://applieddivinitystudies.com/stagnation/" type="external">Isolated Demands for Rigor in New Optimism</fr:link>. "More likely, solar power has been making great strides on a pretty consistent basis for decades, and the only recent break is in how high-status it is to say that out loud."
</html:p>
            <html:p>
Jules Hedges: <fr:link href="https://julesh.com/2017/11/09/compositional-game-theory-reading-list/" type="external">Compositional Game Theory Reading List</fr:link></html:p>
            <html:p>
Jason Collins: <fr:link href="https://behavioralscientist.org/principles-for-the-application-of-human-intelligence/" type="external">Principles for the application of Human Intelligence</fr:link></html:p>
            <html:p>
George on LessWrong: <fr:link href="https://www.lesswrong.com/posts/vxLfja7hmcFifAtYd/machine-learning-could-be-fundamentally-unexplainable" type="external">Machine Learning May Be Fundamentally Unexplainable</fr:link>. "When we say that we “understand” physics what we really mean is that there are a few dozen of thousands of blokes that spent half their lives turning their brains into hyper-optimized physics-thinking machines and they assure us that they “understand” it."
</html:p>
            <html:p>
Amanda Askell: <fr:link href="https://askell.io/posts/2020/12/bad-isnt-good-enough" type="external">In AI Ethics, "Bad" Isn't Good Enough</fr:link>.
</html:p>
            <html:p>
A map of properties of logical theories: &lt;https://forkinganddividing.com/&gt;
</html:p>
            <html:p>
r/math: <fr:link href="https://www.reddit.com/r/math/comments/kkakmi/most_overpowered_theorems_in_math/" type="external">Most overpowered theorems in math?</fr:link></html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>12</fr:month>
              <fr:day>9</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/galois-connections-and-nullstellensatzen/</fr:uri>
            <fr:display-uri>galois-connections-and-nullstellensatzen</fr:display-uri>
            <fr:route>/galois-connections-and-nullstellensatzen/</fr:route>
            <fr:title text="Galois Connections and Nullstellensatzen">Galois Connections and Nullstellensatzen</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
(The idea for this post is due to <fr:link href="https://twitter.com/sarah_zrf/status/1265699700524699650" type="external">this tweet</fr:link> by @sarah_zrf)
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>12</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Hilbert's Nullstellensatz">Hilbert's Nullstellensatz</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Consider the ring of complex polynomials in <fr:tex display="inline"><![CDATA[n]]></fr:tex> variables, <fr:tex display="inline"><![CDATA[\mathbb {C}[x_1,x_2,\dots  x_n]]]></fr:tex>.
  The elements of thing ring can be viewed as _functions_ <fr:tex display="inline"><![CDATA[\mathbb {C}^n \to  \mathbb {C}]]></fr:tex>.
  Given a polynomial <fr:tex display="inline"><![CDATA[f]]></fr:tex>, we can think of it as an _equation_ in <fr:tex display="inline"><![CDATA[n]]></fr:tex> variables - a solution to the equation is a tuple
  <fr:tex display="inline"><![CDATA[(a_1, \dots  a_n) \in  \mathbb {C}^n]]></fr:tex> so that <fr:tex display="inline"><![CDATA[f(a_1,\dots  ,a_n) = 0]]></fr:tex>. Let <fr:tex display="inline"><![CDATA[V(f) \subseteq  \mathbb {C}^n]]></fr:tex> be the set of solutions.
</html:p>
                <html:p>
  Given a _set_ of polynomials <fr:tex display="inline"><![CDATA[S \subset  \mathbb {C}[x_1,\dots  x_n]]]></fr:tex>, let
  <fr:tex display="block"><![CDATA[V(S) = \{(a_1, \dots  a_n) \in  \mathbb {C}^n \mid  f(a_1,\dots  a_n) = 0,\ \forall  f \in  S\}]]></fr:tex> be the set of solutions to the _system_ of equations given by <fr:tex display="inline"><![CDATA[S]]></fr:tex>.
</html:p>
                <html:p>
  This gives a mapping from subsets <fr:tex display="inline"><![CDATA[S \subset  \mathbb {C}[x_1, \dots  x_n]]]></fr:tex> to subsets <fr:tex display="inline"><![CDATA[U \subset  \mathbb {C}^n]]></fr:tex>.
  We can also go the other way - given such an <fr:tex display="inline"><![CDATA[U]]></fr:tex>, let <fr:tex display="inline"><![CDATA[I(U)]]></fr:tex> be the set of <fr:tex display="inline"><![CDATA[f]]></fr:tex> such that <fr:tex display="inline"><![CDATA[f(a) = 0]]></fr:tex> for all <fr:tex display="inline"><![CDATA[a \in  U]]></fr:tex>.
  (We are now writing <fr:tex display="inline"><![CDATA[a := (a_1,\dots  a_n)]]></fr:tex> for brevity).
</html:p>
                <html:p>
  Now <fr:tex display="inline"><![CDATA[V]]></fr:tex> and <fr:tex display="inline"><![CDATA[I]]></fr:tex> enjoy the following very special properties:
</html:p>
                <html:p>
  -   They are both _order-reversing_ - if <fr:tex display="inline"><![CDATA[U \subseteq  U']]></fr:tex> then <fr:tex display="inline"><![CDATA[I(U') \subseteq  I(U)]]></fr:tex>, and the same for <fr:tex display="inline"><![CDATA[V]]></fr:tex>.
  -   <fr:tex display="inline"><![CDATA[S \subseteq  I(V(S))]]></fr:tex> and <fr:tex display="inline"><![CDATA[U \subseteq  V(I(U))]]></fr:tex>.
</html:p>
                <html:p>
  This means that <fr:tex display="inline"><![CDATA[I]]></fr:tex> and <fr:tex display="inline"><![CDATA[V]]></fr:tex> forms a _Galois connection_ (<fr:link href="https://ncatlab.org/nlab/show/Galois+connection" type="external">nlab</fr:link>) - a dual adjunction between two posets.
  This implies a bunch of interesting things. One of the most important is that the mapping <fr:tex display="inline"><![CDATA[S \mapsto  I(V(S))]]></fr:tex> is a _closure operator_, meaning that in addition to the above inequality, <fr:tex display="inline"><![CDATA[I(V(I(V(S)))) = I(V(S))]]></fr:tex>. In fact for anything of the form <fr:tex display="inline"><![CDATA[I(U)]]></fr:tex>, we have <fr:tex display="inline"><![CDATA[I(V(I(U))) = I(U)]]></fr:tex>.
</html:p>
                <html:p>
  This Galois connection is _the_ key to algebraic geometry. It allows us to analyse algebraic things (subsets of a ring) in geometric terms (subsets of a space). So it would be really good if we could understand this thing. In particular, what is the closure operator <fr:tex display="inline"><![CDATA[S \mapsto  I(V(S))]]></fr:tex>?
</html:p>
                <html:p>
  It's pretty clear that <fr:tex display="inline"><![CDATA[I(V(S))]]></fr:tex> must be an _ideal_ - if <fr:tex display="inline"><![CDATA[f(a) = 0]]></fr:tex> for all <fr:tex display="inline"><![CDATA[a \in  V(S)]]></fr:tex>, then <fr:tex display="inline"><![CDATA[f(a)g(a) = 0]]></fr:tex> too (and if <fr:tex display="inline"><![CDATA[f(a) = g(a) = 0]]></fr:tex>, then <fr:tex display="inline"><![CDATA[f(a) + g(a) = 0]]></fr:tex>). So an obvious guess would be that <fr:tex display="inline"><![CDATA[I(V(S)) = (S)]]></fr:tex>, the ideal generated by <fr:tex display="inline"><![CDATA[S]]></fr:tex>.
</html:p>
                <html:p>
  But this turns out not to be true - there's one more thing we need to close off <fr:tex display="inline"><![CDATA[S]]></fr:tex> under to make this work.
  Namely, if <fr:tex display="inline"><![CDATA[(f^2)(a) = f(a)^2 = 0]]></fr:tex>, then also <fr:tex display="inline"><![CDATA[f(a) = 0]]></fr:tex>. So if <fr:tex display="inline"><![CDATA[f^2 \in  I(V(S))]]></fr:tex>, then <fr:tex display="inline"><![CDATA[f \in  S]]></fr:tex> (and similarly for <fr:tex display="inline"><![CDATA[f^n]]></fr:tex>).
  <fr:tex display="inline"><![CDATA[I(V(S))]]></fr:tex> is a _radical ideal_ - specifically, it is the radical <fr:tex display="inline"><![CDATA[\sqrt {(S)}]]></fr:tex> of the ideal generated by <fr:tex display="inline"><![CDATA[S]]></fr:tex>. This statement is _Hilbert's Nullstellensatz_ ("zero locus theorem", see <fr:link href="https://en.wikipedia.org/wiki/Hilbert's_Nullstellensatz" type="external">wikipedia</fr:link>, <fr:link href="https://ncatlab.org/nlab/show/Nullstellensatz" type="external">nlab</fr:link>)
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>12</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Gödel's Nullstellensatz">Gödel's Nullstellensatz</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Let <fr:tex display="inline"><![CDATA[\mathcal {L}]]></fr:tex> be a first-order language, i.e a collection of _function symbols_ <fr:tex display="inline"><![CDATA[f_1,f_2,\dots ]]></fr:tex>, each with a specified arity, and /relation symbols <fr:tex display="inline"><![CDATA[R_1,R_2,\dots ]]></fr:tex>, also each with a specified arity[^fn:1].
</html:p>
                <html:p>
  An <fr:tex display="inline"><![CDATA[\mathcal {L}]]></fr:tex>-structure is a set <fr:tex display="inline"><![CDATA[M]]></fr:tex> equipped with a function <fr:tex display="inline"><![CDATA[[f_i]_M : M^n \to  M]]></fr:tex> for each <fr:tex display="inline"><![CDATA[f_i]]></fr:tex>, where <fr:tex display="inline"><![CDATA[n]]></fr:tex> is the arity of <fr:tex display="inline"><![CDATA[f_i]]></fr:tex>, and a subset <fr:tex display="inline"><![CDATA[[R_i]_M \subset  M^n]]></fr:tex> for each <fr:tex display="inline"><![CDATA[R_i]]></fr:tex>, where <fr:tex display="inline"><![CDATA[n]]></fr:tex> is again the arity.
</html:p>
                <html:p>
  A _first-order formula in <fr:tex display="inline"><![CDATA[\mathcal {L}]]></fr:tex>_ is a formula built up out of the function symbols, variables, and the connectives <fr:tex display="inline"><![CDATA[\forall , \exists , \vee , \wedge , \neg , =]]></fr:tex>.
  A model <fr:tex display="inline"><![CDATA[M]]></fr:tex> satisfies the formula if the formula is true when interpreted in the usual way for the model.
</html:p>
                <html:p>
  A _theory_ is a set of formulas. Given a theory <fr:tex display="inline"><![CDATA[T]]></fr:tex>, let <fr:tex display="inline"><![CDATA[Sat(T)]]></fr:tex> be the set of models that satisfy each formula in <fr:tex display="inline"><![CDATA[T]]></fr:tex>.
  Given a set of models <fr:tex display="inline"><![CDATA[\mathcal {M}]]></fr:tex>, let <fr:tex display="inline"><![CDATA[Tru(\mathcal {M})]]></fr:tex> be the set of formulas that are satisfied by each model.
</html:p>
                <html:p>
  Then it's not hard to see that <fr:tex display="inline"><![CDATA[Sat]]></fr:tex> and <fr:tex display="inline"><![CDATA[Tru]]></fr:tex> form a Galois connection between sets of formulas (theories), and sets of models.
  What is the closure operator on theories induced by this Galois connection?
  In other words: Start with a set of formulas. These formulas pin down a set of models, namely the models that satisfy all those formulas. Now almost certainly some more formulas are going to happen to be true for all these models.
  For example, if <fr:tex display="inline"><![CDATA[\phi  \wedge  \psi ]]></fr:tex> is a formula in <fr:tex display="inline"><![CDATA[T]]></fr:tex>, then also <fr:tex display="inline"><![CDATA[\phi ]]></fr:tex> is going to be true for every model - so <fr:tex display="inline"><![CDATA[\phi  \in  Tru(Sat(T))]]></fr:tex>.
  In general, any formula which is _provable_ using the normal rules of logic from formulas in <fr:tex display="inline"><![CDATA[T]]></fr:tex> is going to be in <fr:tex display="inline"><![CDATA[Tru(Sat(T))]]></fr:tex>. This is because the normal rules of logic are _sound_ - if you can prove something from true premises, it's true.
  And in fact, this suffices! To be precise, <fr:tex display="inline"><![CDATA[Tru(Sat(T))]]></fr:tex> consists _exactly_ of those formulas that are provable using the normal deduction rules of first-order logic from <fr:tex display="inline"><![CDATA[T]]></fr:tex>. This is a celebrated theorem of Gödel (<fr:link href="https://ncatlab.org/nlab/show/completeness+theorem" type="external">nlab</fr:link>, <fr:link href="https://en.wikipedia.org/wiki/Gödel's_completeness_theorem" type="external">wikipedia</fr:link>). Since it has the same formal structure as Hilbert's Nullstellensatz - characterizing the closure operator induced by a Galois connection - we might call it _Gödel's Nullstellensatz_. (It is usually called the completeness theorem).
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>12</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Quillen's Nullstellensatz">Quillen's Nullstellensatz</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Fix a category <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>. Let <fr:tex display="inline"><![CDATA[f: X \to  Y, g: A \to  B]]></fr:tex> be morphisms.
  We say that _<fr:tex display="inline"><![CDATA[f]]></fr:tex> has the left lifting property with respect to <fr:tex display="inline"><![CDATA[g]]></fr:tex>_, and that <fr:tex display="inline"><![CDATA[g]]></fr:tex> has the right lifting property with respect to <fr:tex display="inline"><![CDATA[f]]></fr:tex>, if, for each diagram of this form, if the outer square commutes, there exists a dashed arrow making the triangles commute as well:
</html:p>
                <html:img src="/bafkrmiadydfnvkepvioidqkui3zxd2ttgr3dyuewwnlzqvbozscn6mn2gy.png" title="" />
                <html:p>
  Given a class <fr:tex display="inline"><![CDATA[S]]></fr:tex> of morphisms in <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>, let <fr:tex display="inline"><![CDATA[LLP(S)]]></fr:tex> be the class of morphism with the left lifting property with respect to _all_ morphisms <fr:tex display="inline"><![CDATA[f \in  S]]></fr:tex>, analogously <fr:tex display="inline"><![CDATA[RLP(S)]]></fr:tex>.
</html:p>
                <html:p>
  It is again not hard to see that <fr:tex display="inline"><![CDATA[RLP]]></fr:tex> and <fr:tex display="inline"><![CDATA[LLP]]></fr:tex> form a Galois connection from the collection of subclasses of morphisms in <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> to itself. What is the closure operator <fr:tex display="inline"><![CDATA[LLP(RLP(-))]]></fr:tex>? This is probably a bit harder to motivate than the previous examples, but understanding it is important in model category theory.
</html:p>
                <html:p>
  As before, we can try to find some constructions that <fr:tex display="inline"><![CDATA[LLP(RLP(-))]]></fr:tex> is certainly closed under:
</html:p>
                <html:p>
  -   Pushouts, in the sense that if <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> is in <fr:tex display="inline"><![CDATA[LLP(RLP(-))]]></fr:tex>, and <fr:tex display="inline"><![CDATA[g: X \to  Z]]></fr:tex> is any morphism, the induced <fr:tex display="inline"><![CDATA[Z \to  X+_Y Z]]></fr:tex> is also in there.
  -   Retracts: given a commutative diagram
</html:p>
                <html:img src="/bafkrmibie6ybqbflwsnawsszp4khw2ul4xfbd4rh72qgtqnltmgietsej4.png" title="" />
                <html:p>
  where the horizontal composites are identities, if <fr:tex display="inline"><![CDATA[f]]></fr:tex> is in the class, so is <fr:tex display="inline"><![CDATA[g]]></fr:tex></html:p>
                <html:p>
  -   Transfinite composition: given a sequence <fr:tex display="inline"><![CDATA[X_0 \to  X_1 \to  \dots ]]></fr:tex> with each map in the class, the maps to the colimit <fr:tex display="inline"><![CDATA[\operatorname {colim}_i X_i]]></fr:tex> are also in the class (here this diagram can be indexed by any ordinal).
</html:p>
                <html:p>
  Each of these proofs is essentially by a diagram chase.
</html:p>
                <html:p>
  A class closed under all these constructions is called _saturated_. Then we have _Quillen's Nullstellensatz_ (which is confusingly usually called the _Small object argument_): If <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> is locally presentable, and <fr:tex display="inline"><![CDATA[S]]></fr:tex> is a small set,
  then <fr:tex display="inline"><![CDATA[LLP(RLP(S))]]></fr:tex> is the smallest saturated class containing <fr:tex display="inline"><![CDATA[S]]></fr:tex>.
</html:p>
                <html:p>
  I guess you can actually dispense with the function symbols if you want
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>11</fr:month>
              <fr:day>22</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/demystifying-the-second-law-of-thermodynamics/</fr:uri>
            <fr:display-uri>demystifying-the-second-law-of-thermodynamics</fr:display-uri>
            <fr:route>/demystifying-the-second-law-of-thermodynamics/</fr:route>
            <fr:title text="Demystifying the second law of thermodynamics">Demystifying the second law of thermodynamics</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Thermodynamics is really weird. Most people have probably encountered a bad explanation of the basics at some point in school, but probably don't remember more than
</html:p>
            <html:ul><html:li>Energy is conserved</html:li>
  <html:li>Entropy increases</html:li>
  <html:li>There's something called the ideal gas law/ideal gas equation.</html:li>
<html:p /></html:ul>
            <html:p>
Energy conservation is not very mysterious. Apart from some weirdness around defining energy in general, it's just a thing you can prove from whatever laws of motion you're using.
</html:p>
            <html:p>
But _entropy_ is very weird. You've heard that it measures "disorder" in some vague sense.
Maybe you've heard that it's connected to the <fr:link href="https://en.wikipedia.org/wiki/Entropy_(information_theory)" type="external">Shannon entropy</fr:link> of a probability distribution <fr:tex display="inline"><![CDATA[H(p) = \sum _x - p(x)\ln  p(x)]]></fr:tex>.
Probably the weirdest thing about it is the law it obeys: It's not conserved, but rather it _increases_ with time.
This is more or less the only law like that in physics.
</html:p>
            <html:p>
It gets even weirder when you consider that at least classical Newtonian physics is _time-symmetric_.
Roughly speaking, this means if you have a movie of things interacting under the laws of Newton, and you play it backwards, they're still obeying the laws of Newton. An orbiting moon just looks like it's orbiting in the other direction, which is perfectly consistent. A stone which is falling towards earth and accelerating looks like it's flying away from earth and decelerating - exactly as gravity is supposed to do.
</html:p>
            <html:p>
But if there's some "entropy" quality out there that only increases, then that's obviously impossible! When you played the movie backwards, you'd be able to tell that entropy was decreasing, and if entropy always increases, some law is being violated.
So what, is entropy some artefact of quantum mechanics? No, as it turns out. Entropy is an artefact of the fact that you can't measure all the particles in the universe at once. And the fact that it seems to always increase is a consequence of the fact that matter is stable at large scales.
</html:p>
            <html:p>
The points in this post are largely from E.T. Jaynes' <fr:link href="https://bayes.wustl.edu/etj/articles/macroscopic.prediction.pdf" type="external">Macroscopic Prediction</fr:link>.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>22</fr:day>
                </fr:date>
                <fr:title text="A proof that entropy doesn't always increase">A proof that entropy doesn't always increase</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Let <fr:tex display="inline"><![CDATA[X]]></fr:tex> be the set of states of some physical system. Here I will assume that there is a finite number of states and time advances in discrete steps - there is some function <fr:tex display="inline"><![CDATA[T: X \to  X]]></fr:tex> which steps time forward one step. We assume that these dynamics are time-reversible in the weak sense that <fr:tex display="inline"><![CDATA[T]]></fr:tex> is a bijection - every state is the future of exactly one "past" state.
  Let <fr:tex display="inline"><![CDATA[S: X \to  \mathbb {R}]]></fr:tex> be some function. Assume <fr:tex display="inline"><![CDATA[S(x) \leq  S(Tx)]]></fr:tex> - in other words, <fr:tex display="inline"><![CDATA[S]]></fr:tex> can never decrease.
  Then <fr:tex display="inline"><![CDATA[S]]></fr:tex> is constant, i.e <fr:tex display="inline"><![CDATA[S(x) = S(Tx)]]></fr:tex>.
</html:p>
                <html:p>
  Proof: Assume for contradiction <fr:tex display="inline"><![CDATA[S(x) < S(Tx)]]></fr:tex> for some <fr:tex display="inline"><![CDATA[x]]></fr:tex>. Since <fr:tex display="inline"><![CDATA[X]]></fr:tex> is finite, let <fr:tex display="inline"><![CDATA[\sum _x S(x)]]></fr:tex> be the sum of <fr:tex display="inline"><![CDATA[S]]></fr:tex> over all states. Then clearly <fr:tex display="inline"><![CDATA[\sum _x S(x) = \sum _x S(Tx)]]></fr:tex>, since <fr:tex display="inline"><![CDATA[Tx]]></fr:tex> just ranges over all the <fr:tex display="inline"><![CDATA[x]]></fr:tex>s.
  But on the other hand, we have <fr:tex display="inline"><![CDATA[S(x) \leq  S(Tx)]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x]]></fr:tex>, and <fr:tex display="inline"><![CDATA[S(x) < S(Tx)]]></fr:tex> in at least one case. So we must have <fr:tex display="inline"><![CDATA[\sum _x S(x) < \sum _x S(Tx)]]></fr:tex> - contradiction.
</html:p>
                <html:p>
  This proof can be generalized to the continuous time and space case without too much trouble, for the types of dynamics that actually show up in physics (using <fr:link href="https://en.wikipedia.org/wiki/Liouville's_theorem_(Hamiltonian)" type="external">Liouville's Theorem</fr:link>). The proof above still requires a _bounded_ phase volume (corresponding to the finiteness of <fr:tex display="inline"><![CDATA[X]]></fr:tex>). To generalize to other situations we need some more assumptions - the easiest thing is to assume that the dynamics are time-reversible in a stronger sense, and that this is compatible with the entropy in some way.
</html:p>
                <html:p>
  (You can find easy counterexamples in general, e.g. if <fr:tex display="inline"><![CDATA[X=\mathbb {Z}]]></fr:tex> and the dynamics are <fr:tex display="inline"><![CDATA[T(x) = x+1]]></fr:tex>, then obviously we really do have that <fr:tex display="inline"><![CDATA[S(x) =x]]></fr:tex> is increasing. Nothing to do about that.)
</html:p>
                <html:p>
  Anyways the bounded/finite versions of the theorems do hold for a toy thermodynamic system like particles in a (finite) box - here the phase volume really is bounded.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>22</fr:day>
                </fr:date>
                <fr:title text="The true meaning of entropy">The true meaning of entropy</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Okay, so what the hell is going on? Did your high school physics textbook lie to you about this?
  Well, yes. But you're probably never going to observe entropy going down in your life, so you can maybe rest easy.
</html:p>
                <html:p>
  Let <fr:tex display="inline"><![CDATA[X]]></fr:tex> be the physical system under consideration again. But suppose now that we can't observe <fr:tex display="inline"><![CDATA[x \in  X]]></fr:tex>, but only some "high-level description <fr:tex display="inline"><![CDATA[p(x) \in  Y]]></fr:tex>. Maybe <fr:tex display="inline"><![CDATA[x]]></fr:tex> is the total microscopic state of every particle in a cloud of gas - their position and momentum - while <fr:tex display="inline"><![CDATA[p(x)]]></fr:tex> is just the average energy of the particles (roughly corresponding to the temperature).
  <fr:tex display="inline"><![CDATA[x]]></fr:tex> is called a _microstate_ and <fr:tex display="inline"><![CDATA[y = p(x)]]></fr:tex> is called a _macrostate_.
  Then the _entropy_ of <fr:tex display="inline"><![CDATA[y \in  Y]]></fr:tex> is <fr:tex display="inline"><![CDATA[S(y) = \ln  (p^{-1}(\{y\}))]]></fr:tex> - the logarithm of the number of microstates <fr:tex display="inline"><![CDATA[x]]></fr:tex> where <fr:tex display="inline"><![CDATA[p(x) = y]]></fr:tex>. We say these are the microstates that _realize_ the macrostate <fr:tex display="inline"><![CDATA[y]]></fr:tex>.
</html:p>
                <html:p>
  The connection with Shannon entropy is now that this is exactly the Shannon entropy of the uniform distribution over <fr:tex display="inline"><![CDATA[p^{-1}(y)]]></fr:tex>. This is the distribution you should have over microstates if you know nothing except the microstate.
  In other words, the entropy measures your uncertainty about the microstate given that you know nothing except the macrostate.
</html:p>
                <html:p>
  There are more sophisticated versions of this definition in general, to account for the fact that
</html:p>
                <html:p>
  -   In general, your microstates are probably sets of real numbers, and there are probably infinitely many compatible with the macrostate, so we need a notion of "continuous entropy" (usually called differential entropy, I think)
  -   Your measurement of the macrostate is probably not that certain (but this turns out to matter surprisingly little for thermodynamic systems),
</html:p>
                <html:p>
  but this is the basic gist.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>22</fr:day>
                </fr:date>
                <fr:title text="Why entropy usually goes up">Why entropy usually goes up</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Okay, so why does entropy go up?
  _Because there are more high-entropy states than low-entropy states_. That's what entropy _means_.
  If you don't know anything about what's gonna happen to <fr:tex display="inline"><![CDATA[x]]></fr:tex> (in reality, you usually understand the dynamics <fr:tex display="inline"><![CDATA[T]]></fr:tex> themselves, but have absolutely no information about <fr:tex display="inline"><![CDATA[x]]></fr:tex> except the macrostate), it's more likely that it will transfer to a macrostate with a higher number of representatives than to one with a low number of representatives.
</html:p>
                <html:p>
  This also lets us defuse our paradox from above. In reality, entropy doesn't go down for literally every microstate <fr:tex display="inline"><![CDATA[x]]></fr:tex>.
  It's not true that <fr:tex display="inline"><![CDATA[S(p(Tx)) > S(p(x))]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x]]></fr:tex> - I proved that impossible above.
  What _can_ be true is this: given a certain macrostate, it's more probable that entropy increases than that it decreases.
</html:p>
                <html:p>
  We can consider an extreme example where we have two macrostates <fr:tex display="inline"><![CDATA[L]]></fr:tex> and <fr:tex display="inline"><![CDATA[H]]></fr:tex>, corresponding to low and high entropy.
  Clearly the number of low-entropy states that go to a high-entropy state is exactly the same as the number of high-entropy states that go to a low-entropy state. That's combinatorics.
  But the _fraction_ of low-entropy states that go to high-entropy is then necessarily larger than the fraction of high-entropy states that go to low-entropy states.
</html:p>
                <html:p>
  In other words, <fr:tex display="inline"><![CDATA[P(H(x_{t+1})|L(x_t)) > P(L(x_{t+1})|H(x_t))]]></fr:tex></html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>22</fr:day>
                </fr:date>
                <fr:title text="Why entropy (almost) always goes up">Why entropy (almost) always goes up</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Okay, but that's a lot weaker than "entropy always increases"! How do we get from here to there?
  I could say some handwavy stuff here about how the properties of thermodynamic systems mean that the differences in the number of representatives between high-entropy and low-entropy states are massive - and that means the right-hand probability above can't possibly be non-neglible. And that in general this works out so that entropy is almost guaranteed to increase.
</html:p>
                <html:p>
  But that's very unsatisfying. It just happened to work out that way? I have a much more satisfying answer: entropy almost always increases because matter is stable at large scales.
</html:p>
                <html:p>
  Wait, what? What does that mean?
</html:p>
                <html:p>
  By "matter is stable at large scales", I mean that the macroscopic behaviour of matter is predictable only from macroscopic observations. When a bricklayer builds a house, they don't first go over them with a microscope to make sure the microstate of the brick isn't going to surprise us later. And as long as we know the temperature and pressure of a gas, we can pretty much predict what will happen if we compress it with a piston.
</html:p>
                <html:p>
  What this means is that, if <fr:tex display="inline"><![CDATA[p(x) = p(x')]]></fr:tex>, then _with extremely high probability_, <fr:tex display="inline"><![CDATA[p(Tx) = p(Tx')]]></fr:tex>. It might not be literally certain, but it's sure enough.
</html:p>
                <html:p>
  Now, let's say we're in the macrostate <fr:tex display="inline"><![CDATA[y]]></fr:tex>. Then there is some macrostate <fr:tex display="inline"><![CDATA[y']]></fr:tex> which is _extremely likely_ to be the next one. For very nearly all <fr:tex display="inline"><![CDATA[x]]></fr:tex> so that <fr:tex display="inline"><![CDATA[p(x) = y]]></fr:tex>, we have <fr:tex display="inline"><![CDATA[p(Tx) = y']]></fr:tex>.
  But this means that <fr:tex display="inline"><![CDATA[y']]></fr:tex> must have at least that many microstates representing it, since <fr:tex display="inline"><![CDATA[T]]></fr:tex> is a bijection.
  So the entropy of <fr:tex display="inline"><![CDATA[y']]></fr:tex> can at most be a _tiny_ bit smaller than the entropy of <fr:tex display="inline"><![CDATA[y]]></fr:tex> - this difference would be as tiny as the fraction of <fr:tex display="inline"><![CDATA[x]]></fr:tex> with <fr:tex display="inline"><![CDATA[p(Tx) \neq  y']]></fr:tex>, so we can ignore it.
</html:p>
                <html:p>
  So unless something super unlikely happens and <fr:tex display="inline"><![CDATA[p(Tx) \neq  y']]></fr:tex>, entropy goes up.
</html:p>
                <html:p>
  By the way, this also explains what goes wrong with time-reversibility, and why in reality, you can easily tell that a video is going backwards. The "highly probably dynamics" <fr:tex display="inline"><![CDATA[Y \to  Y]]></fr:tex>, which takes each macrostate the the most probable next state, don't have to be time-reversible. For instance, let's return to the two-macrostate system above.
  Suppose that with 100% certainty, low-entropy states become high-entropy.
  Let there be <fr:tex display="inline"><![CDATA[N_L]]></fr:tex> low-entropy states and <fr:tex display="inline"><![CDATA[N_H]]></fr:tex> high-entropy states.
  Then, just because <fr:tex display="inline"><![CDATA[T]]></fr:tex> is a bijection, there must be <fr:tex display="inline"><![CDATA[N_L]]></fr:tex> high-entropy states that become low-entropy.
  Now if <fr:tex display="inline"><![CDATA[N_H \gg  N_L]]></fr:tex>, then practically all high-entropy states go to other high-entropy states.
  So <fr:tex display="inline"><![CDATA[L \mapsto  H]]></fr:tex> but <fr:tex display="inline"><![CDATA[H \mapsto  H]]></fr:tex>.
</html:p>
                <html:p>
  Of course in reality, if you start with a low-entropy state and watch this unfold for a _really_ long time, you'll eventually see it become a low-entropy state again. It's just extremely unlikely to happen in a short amount of time.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>22</fr:day>
                </fr:date>
                <fr:title text="Entropy is not exactly your uncertainty about the microstate">Entropy is not exactly your uncertainty about the microstate</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The entropy of a given macrostate is the uncertainty about the microstate _of an observer who knows only the macrostate_.
  In general, you have more information than this.
  For example, if the system starts in a low-entropy state, and you let it evolve into a high-entropy state, you know that the system is in one of the very small number of high-entropy states which come from low-entropy states!
  But since you can only interact with the system on macroscales, this information won't be useful.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>11</fr:month>
              <fr:day>18</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/a-response-to-maudlin-on-credence-and-chance/</fr:uri>
            <fr:display-uri>a-response-to-maudlin-on-credence-and-chance</fr:display-uri>
            <fr:route>/a-response-to-maudlin-on-credence-and-chance/</fr:route>
            <fr:title text="A response to Maudlin on credence and chance">A response to Maudlin on credence and chance</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p><fr:link href="http://philsci-archive.pitt.edu/18382/1/Credence (version 2).pdf" type="external">Credence - and chance - without numbers (and with the Euclidean property)</fr:link> is a philosophy paper by Tim Maudlin.
In it, Maudlin discusses the closely related notions of _credence_, the subjective likelyhood that a specific agent associates to some outcome, and _chance_, the objective likelyhood that the event happens. He argues that
</html:p>
            <html:ul><html:li>The traditional approach of measuring these outcomes with numbers is wrong, but</html:li>
  <html:li>this shouldn't trouble us too much, because we can do a lot without them.</html:li>
<html:p /></html:ul>
            <html:p>
As it happens, I have my own serious reservations about the traditional measure-theoretic formulation of probability (due to Kolmogoro). By I still think this paper is more or less terrible. Maudlin displays a Wikipedia-level understanding of the paradoxes surrounding infinity in probability theory. His proposed solution amounts to enumerating a list of properties that an agent's system of credence should satisfy, and arguing that these axioms suffice for the things we usually want to do with "subjective degree of belief". This is actually fine such as it is, but his description of this is also seriously lacking.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Infinity in probability theory">Infinity in probability theory</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  There's the following very classical paradox in probability theory:
  Suppose you toss a dart at a dartboard. For each point <fr:tex display="inline"><![CDATA[p]]></fr:tex> on the dartboard, we can ask for the probability that the dart hits that exact point <fr:tex display="inline"><![CDATA[p]]></fr:tex>. Suppose we have no relevant information about the tossing process, so that each point seems equally likely.
  What is the probability <fr:tex display="inline"><![CDATA[P(p)]]></fr:tex>? Well, it can't be more than zero, because then the total probability, the probability that the dart hits any point, would be, not just greater than <fr:tex display="inline"><![CDATA[1]]></fr:tex>, but infinite! This is because there are infinitely many points on the dartboard, and any positive number added to itself infinitely many times is infinite.
  But hold on, it also can't be <fr:tex display="inline"><![CDATA[0]]></fr:tex>, because that means by a similar argument that the probability that the dart hits any point on the dartboard is also <fr:tex display="inline"><![CDATA[0]]></fr:tex> - but it must hit _some_ point.
</html:p>
                <html:p>
  First I'll note that this problem actually is _not_ entirely resolved by measure theory.
  Measure theory allows for a uniform probability measure on continuous spaces like the interval <fr:tex display="inline"><![CDATA[[0,1]]]></fr:tex> (by, essentially, not allowing us to add probabilities up in every case. More on this later). But if we just suppose a countable dartboard, we're left with the same problem.
</html:p>
                <html:p>
  But, hang on, does a dartboard really have an infinite number of points? And what does it mean for the dart to hit a point?
  Certainly the point of the dart _itself_ has a non-infinitesimal area, so that if we partition the dartboard into "points" of that size, there will be a finite number, each of which we can assign some positive probability without issue. In general, any area on the dartboard, no matter how small, has a positive probability of being struck by the dart, and this remains true no matter how small we make the dart, as well.
</html:p>
                <html:p>
  In other words, this paradox hinges on an infinitesimal dart, as well as an infinitesimally accurate measuring tape with which to measure the coordinates, which presumably has infinitely long numerals on it (presumably the person assigning these credences has an infinitely large brain as well, to be able to hold in their minds the coordinates pointing out a specific point on the dartboard to infinite precision).
</html:p>
                <html:p>
  Any mathematician knows that you have to handle a situation like this _very carefully_. You cannot expect to apply your intuition directly and get consistent results. I am actually kind of surprised to find serious philosophers making this kind of argument in 2020. This is on par with saying that Zeno's paradox proves you can't use numbers to measure space (or time).
</html:p>
                <html:p>
  To be fair to Maudlin here, I do think he has a point: there do seem to be situations where you should be indifferent between a (countably) infinite number of outcomes, and probability theory won't let you do that. Dartboards is just a bad example.
</html:p>
                <html:p>
  Maudlin's shaky relationship with infinity shows up again in his discussion of the classical Kolmogorov approach to probability. He cites the definition of a _finitely additive_ probability measure, and not the <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex>-additive (or countably additive) version used by every probability theorist and statistician in the world. Then he criticizes it for only being finitely additive!
</html:p>
                <html:p>
  He also critizises the use of a <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex>-algebra, arguing that it seems irrational to exclude certain sets from consideration.
  I think Maudlin needs to spend a small amount of time understanding non-measurable sets before arguing they're stupid.
  For one thing, a nonmeasurable subset of <fr:tex display="inline"><![CDATA[\mathbb {R}^2]]></fr:tex> (such as we might ask "will the dart hit a point in this subset or not" of), is _extremely weird_. It's consistent with ZF minus Choice that there exist no such sets.
  Certainly such sets always contain regions of "infinite complexity", in the sense that there are (non-infinitesimal) regions of the dartboard so that, if the dart hits there, no finite amount of measurement will suffice to determine whether it is in the set or out of it. Indeed, it's not too far off the mark to think of the <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex>-algebra as denoting the "determinable" events.
</html:p>
                <html:p>
  The fact that a probability measure is only _countably_ additive is still a bit weird. You can make philosophical arguments for this choice: To check whether <fr:tex display="inline"><![CDATA[a \in  \cup _n A_n]]></fr:tex>, we can check whether <fr:tex display="inline"><![CDATA[a \in  A_n]]></fr:tex> for each <fr:tex display="inline"><![CDATA[a]]></fr:tex> - and this is guaranteed to give you an answer in a finite amount of time, but only if you're taking a finite union. There are reasonable counterarguments to this, but Maudlin doesn't engage with this topic at all - it really seems as if he doesn't realize that mathematicians have been taking infinite disjunctions of events all this time[^fn:1].
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Maudlin's solution">Maudlin's solution</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Maudlin's proposed replacement for numbers is essentially the following idea: it's not required that a person's credences be represented by some definite "thing" - a number or another mathematical object. Instead we should ask about the _structure_ on the system of credences, and what rules this should follow for any "rational" person.
</html:p>
                <html:p>
  This is actually a very good idea! Structuralism! Defining things extrinsically rather than intrinsically! I like this approach.
</html:p>
                <html:p>
  Let's go over the basic principles that Maudlin comes up with. The paper is short on rigor, but since it's a philosophy paper and not a math paper, I won't hold that against it.
</html:p>
                <html:p>
  -   The set of "credences" should have a partial order[^fn:2].
  -   The map <fr:tex display="inline"><![CDATA[\operatorname {Cr}]]></fr:tex> which assigns an event its credence should be order-preserving - in other words, if event <fr:tex display="inline"><![CDATA[P]]></fr:tex> entails the event <fr:tex display="inline"><![CDATA[Q]]></fr:tex>, then <fr:tex display="inline"><![CDATA[\operatorname {Cr}(P) \leq  \operatorname {Cr}(Q)]]></fr:tex>.
  -   There should be a least credence <fr:tex display="inline"><![CDATA[\bot ]]></fr:tex> and a greatest credence <fr:tex display="inline"><![CDATA[\top ]]></fr:tex>, corresponding respectively to the credence in an event which is certain not to happen or certain to happen (say, a contradiction and a tautology).
  -   The map <fr:tex display="inline"><![CDATA[\mathrm {Cr}]]></fr:tex> should have the following property: if <fr:tex display="inline"><![CDATA[P \Rightarrow  Q, \operatorname {Cr}(P) = \operatorname {Cr}(Q)]]></fr:tex>,
</html:p>
                <html:p>
  then <fr:tex display="inline"><![CDATA[\operatorname {Cr}(Q \wedge  \neg  P) = \bot ]]></fr:tex>. This is the so-called "Euclidean property" that Maudlin cannot stop going on about: "the whole is greater than the part", or in this case, if <fr:tex display="inline"><![CDATA[P]]></fr:tex> entails <fr:tex display="inline"><![CDATA[Q]]></fr:tex>, and it's possible that <fr:tex display="inline"><![CDATA[Q]]></fr:tex> but not <fr:tex display="inline"><![CDATA[P]]></fr:tex> (i.e. <fr:tex display="inline"><![CDATA[Q]]></fr:tex> does not entail <fr:tex display="inline"><![CDATA[P]]></fr:tex>), then our credence in <fr:tex display="inline"><![CDATA[Q]]></fr:tex> must be _strictly greater_ than our credence in <fr:tex display="inline"><![CDATA[P]]></fr:tex>.
</html:p>
                <html:p>
  We can define a partial addition operation on credences, denoted <fr:tex display="inline"><![CDATA[\oplus ]]></fr:tex> in the paper,
  by setting <fr:tex display="inline"><![CDATA[\operatorname {Cr}(P) \oplus  \operatorname {Cr}(Q) = \operatorname {Cr}(P \vee  Q)]]></fr:tex> whenever <fr:tex display="inline"><![CDATA[\Cr (P \wedge  Q) = \bot ]]></fr:tex>.
  It's not exactly clear in the paper whether we extend this using the equality on credences - for example, whether we can assign a value to <fr:tex display="inline"><![CDATA[\operatorname {Cr}(P) \oplus  \operatorname {Cr}(P)]]></fr:tex> by finding some other event <fr:tex display="inline"><![CDATA[Q]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\operatorname {Cr}(P) = \operatorname {Cr}(Q), \operatorname {Cr}(P \wedge  Q) = \bot ]]></fr:tex>, and setting  <fr:tex display="inline"><![CDATA[\operatorname {Cr}(P) \oplus  \operatorname {Cr}(P) = \operatorname {Cr}(P \vee  Q)]]></fr:tex>. This seems a harmless enough extension (if we really regard credences as _equal_, and not just equivalent in some sense, it seems inevitable), but Maudlin doesn't really spell it out. Nevertheless the addition is still _partial_, since, for example, when rolling a fair dice, we can't add our credence in the event "The result will be one of 1,2,3,4" to itself, since there is no mutually exclusive event which is equally likely.
  This is not really a bug - indeed, while you can add probabilities and get a number greater than 1, you can't really treat that number _as a probability_.
</html:p>
                <html:p>
  So far, Maudlin's approach differs from the Kolmogorovian approach chiefly in that he lets the poset of credences be any  ordered set, not just numbers, and that he doesn't require the order on credences to be _total_ - we can have no opinion about the relative plausibility of two events without declaring them _equally_ plausible. This is reasonable enough.
  Probably the weirdest thing here is that the "Euclidean property" is _also satisfied by Kolmogorov probability!_
  The reason that adding a point to a set doesn't change the probability that the dart will land there is simply that it's impossible that the dart will land at that precise point. This is obviously counterintuitive (and there are ways of defending it, and counterarguments to those, and so on - but Maudlin does not engage with this at all), but that is the classical approach. It does not seem to violate the Euclidean property at all.
</html:p>
                <html:p>
  Having the addition in hand, we can actually reformulate the Euclidean property simply as "<fr:tex display="inline"><![CDATA[\oplus ]]></fr:tex> is cancellative", i.e if <fr:tex display="inline"><![CDATA[C \oplus  D= C \oplus  D']]></fr:tex> then <fr:tex display="inline"><![CDATA[D = D']]></fr:tex>. This means that <fr:tex display="inline"><![CDATA[\operatorname {Cr}(Q) = \operatorname {Cr}(P) \oplus  \operatorname {Cr}(Q \wedge  \neg  P)]]></fr:tex>, and if this equals <fr:tex display="inline"><![CDATA[\operatorname {Cr}(Q)]]></fr:tex> then <fr:tex display="inline"><![CDATA[\operatorname {Cr}(Q \wedge  \neg  P) = \bot ]]></fr:tex>, since <fr:tex display="inline"><![CDATA[\bot ]]></fr:tex> is the unit of addition.
</html:p>
                <html:p>
  Now Maudlin wants to talk about _relations_ between credences. First of all I have to go on a rant about his whole discussion about ratios. Mathematics has come a long way since Euclid, and citing him like you actually believe his axioms provide a sound formal basis of geometry is not gonna convince anyone that you know what you're talking about.
  Maudlin goes oddly pedantic and says that the ratio of a circle's circumference to its diameter is not <fr:tex display="inline"><![CDATA[\pi ]]></fr:tex>, but rather, the ratio of the number <fr:tex display="inline"><![CDATA[\pi ]]></fr:tex> to the number <fr:tex display="inline"><![CDATA[1]]></fr:tex>, and this is in general what people mean when they identify a ratio with a number. I'm glad to hear that Maudlin has found a solution to the long-standing problem of the identity of mathematical objects (presumably resolving it in favor of a _very_ strong form of Platonism?), but I couldn't find this in the bibliography of the paper or any of his other work. Until I do, I have to insist that "loose talk" is when you insist that two mathematical objects identified under isomorphism cannot possibly be called equal, not the other way around.
</html:p>
                <html:p>
  Okay, rant done. We can define the ratios between credences by addition. For example, we can say that credence <fr:tex display="inline"><![CDATA[C]]></fr:tex> is twice as big as credence <fr:tex display="inline"><![CDATA[D]]></fr:tex> if <fr:tex display="inline"><![CDATA[C = D \oplus  D]]></fr:tex>. Maudlin, quoting Euclid: "Magnitudes are said to have a ratio to one another which can, when multiplied, exceed one another". There is however a serious problem with this: the partiality of addition means that you can't _compare_ these ratios, and many pairs of credences have no ratio to one another, even though Maudlin insists that they do.
</html:p>
                <html:p>
  Let's pull back here a bit. Suppose I have an ordered (commutative) monoid <fr:tex display="inline"><![CDATA[(M,\leq ,+)]]></fr:tex>.
  Then I can say that <fr:tex display="inline"><![CDATA[m,m']]></fr:tex> have a ratio to each other if there exist <fr:tex display="inline"><![CDATA[n,n' \in  \mathbb {N}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[n.m \geq  m']]></fr:tex>, and <fr:tex display="inline"><![CDATA[n'.n' \geq  m]]></fr:tex>. If this is true, we can actually obtain a unique real-numbered ratio "<fr:tex display="inline"><![CDATA[m/m']]></fr:tex>" as the supremum of all <fr:tex display="inline"><![CDATA[n/n' \in  \mathbb {Q}]]></fr:tex> so that <fr:tex display="inline"><![CDATA[n.m' \leq  n'.m]]></fr:tex>.[^fn:3] Here I'm using <fr:tex display="inline"><![CDATA[n.m]]></fr:tex> to denote the <fr:tex display="inline"><![CDATA[n]]></fr:tex>-fold sum <fr:tex display="inline"><![CDATA[m + m + \cdots  + m]]></fr:tex>.
</html:p>
                <html:p>
  Now, this _doesn't_ work for credences - even in situations where it feels like it should[^fn:4]. The increasingly accurate rational approximations to the "true" real ratio requires longer and longer chains of addition, but this is generally impossible to define for credences. We can define what it means for <fr:tex display="inline"><![CDATA[C/C']]></fr:tex> to be an integer - namely that <fr:tex display="inline"><![CDATA[n.C' = C]]></fr:tex>. We can also _sometimes_ define what it means for <fr:tex display="inline"><![CDATA[C/C']]></fr:tex> to be a rational number - for example if <fr:tex display="inline"><![CDATA[2.C = 3.C']]></fr:tex>, we can say <fr:tex display="inline"><![CDATA[C/C' = 2/3]]></fr:tex>.
  But if e.g. <fr:tex display="inline"><![CDATA[C = \top ]]></fr:tex>, there's no way to make this work. And, crucially, we can't usually compare ratios with each other either - otherwise, we might have argued that expecting number representations for each ratio is too much.
</html:p>
                <html:p>
  As it stands, by Maudlin's (or rather, Euclid's) definition of ratio, there is no ratio between <fr:tex display="inline"><![CDATA[\top ]]></fr:tex> and any event with "probability greater than <fr:tex display="inline"><![CDATA[1/2]]></fr:tex>" (speaking informally - of course credences aren't probabilities and so on), in contrast with how Maudlin uses it.
</html:p>
                <html:p>
  This is an area where the paper could really have benefited from some rigor. It's not clear whether Maudlin means to tack on "ratios" as a primitive notion - so that, in addition to having a "more likely than" relation on credences, we have ratios between certain pairs of credences, which can be compared.
</html:p>
                <html:p>
  All these issues could be solved _very easily_, by imposing some extra structure on the model. For instance we could add "formal sums" of credences which don't have a sum, and say that the statement <fr:tex display="inline"><![CDATA[2.P \geq  Q]]></fr:tex> makes sense even when <fr:tex display="inline"><![CDATA[2.P]]></fr:tex> is not defined as a credence.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>18</fr:day>
                </fr:date>
                <fr:title text="Closing">Closing</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  As I mentioned above, I actually, genuinely think it's a good idea to think about replacements for classical probability theory. In some sense my own work on <fr:link href="/zero-one-laws-paper" type="external">Markov categories</fr:link> is a version of this, a sort of "synthetic probability theory". Much like Maudlin, Markov categories start by asking "what structure do we actually need to do the job of probabilities?". They go in a very different direction, not least because we actually care about the job that probabilities do for people in the real world, but the spirit is actually similar.
</html:p>
                <html:p>
  But stress-testing your theory by applying it to situations involving infinity - without working rigorously with infinity _at all_ - is bound to get you into trouble. Frankly, if the only problem your theory solves is that it makes sense of infinite conjunctions, it's basically useless. Infinite conjunctions only come up in abstrac mathematical models, and trust me, those guys aren't really looking for a new theory. In the real world, it's very hard to write down infinitely many statements and think about your credence in the statement "one of these is true".
</html:p>
                <html:p>
  The mathematical idea in this paper - which, again, I actually don't think is a stupid idea - could have fit in a couple of pagers, including a fair amount of exposition and the easy fixes to the problem mentioned above. The philosophical work here seems mainly to be a takedown of traditional probability, which falls woefully flat.
</html:p>
                <html:p>
  [^fn:1]: A less elegant reason for asking for countable composition but not general infinitary composition is that it leads to a useful, theoretically convenient theory, but still allows for measures like the uniform measure on the interval. This is just an argument from practicality - we take these axioms instead of some others because they make the calculations work out - so I won't hold it against Maudlin if he doesn't take this argument very seriously
  [^fn:2]: Maudlin seems to not know this term, which probably could have cut several pages from his exposition
  [^fn:3]: Ironically, in the usual construction of real numbers, they are limits of ratios (between integers), so one could make a convincing argument that a real number really is literally a ratio.
  [^fn:4]: Credences can be "infintesimal, in the sense that we might have <fr:tex display="inline"><![CDATA[n.C \leq  C']]></fr:tex> for ALL <fr:tex display="inline"><![CDATA[n]]></fr:tex>. That's not what I'm talking about."
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>11</fr:month>
              <fr:day>10</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/remarkable-2-review/</fr:uri>
            <fr:display-uri>remarkable-2-review</fr:display-uri>
            <fr:route>/remarkable-2-review/</fr:route>
            <fr:title text="reMarkable 2 review">reMarkable 2 review</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
I recently got a <fr:link href="https://remarkable.com/" type="external">reMarkable 2</fr:link>. I've had it for one week. This is my review of it so far.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="TLDR">TLDR</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  -   It's very very good and I'm happy I bought one. If your relationship with working "on things" is like mine, I recommend it.
  -   It's expensive and you can get an iPad + accessories + Apple Pencil for the same price, which may be better
  -   There are some annoyances
</html:p>
                <html:p>
  Would I buy the reMarkable again? That is, if it was struck by a meteor tomorrow, would I buy a new one? Yes (but see my notes on other options). In my opinion, these devices are now good enough that it's worth paying a premium to get the "paper experience".
  I would not recommend saving up for the reMarkable - that is, if your disposable income is small and you'd need to make an effort over a time period to find the money, it's probably not worth it.
  If you own a laptop and are considering buying a tablet, which you anticipate using largely for reading and writing, the reMarkable is recommendable. If you're in the market for a tablet to use also for laptop tasks, it's not up to the job.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="Paper and Me">Paper and Me</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  My fiancé is one of those stationery nerds. She own several different fountain pens and a metric boatload of ballpoint pens, gel pens, highlighters, markers, and what have you. She buys a specific brand of Japanese calendar (<fr:link href="https://www.1101.com/store/techo/en/" type="external">Hobonichi</fr:link>) each year. She has had the same color-coding system for her notes since we started university&amp;nbsp;[^fn:1]. She meticulously pagemarks and sorts all her notes into plastic sleeves and binders.
</html:p>
                <html:p>
  I am not like my fiancé. My workflow for most of my first five years at university consisted of the following:
</html:p>
                <html:p>
  -   Keep a stack of papers and ballpoint pens in my backpack (along with the books I'm using and my laptop and so on).
  -   When you sit down to work somewhere, get laptop, stack of papers, and a ballpoint pen out.
  -   When you need to think, locate a blank spot on a piece of paper in front of you and write there.
      -   If there's no space, go through the papers until you find some space.
  -   When you stop working, gather all the papers into your backpack.
  -   Periodically go through your papers and throw out any that have writing all over them
  -   Periodically add a fresh dump of blank papers to your backpack.
</html:p>
                <html:p>
  The two points I want to make here is:
</html:p>
                <html:p>
  -   I am a very disorganized person
  -   I fucking love paper
</html:p>
                <html:p>
  Paper is awesome. I am long paper. Whoever you are, you should be using more paper.
  There's absolutely no reason to strain your head to the breaking point, keeping a bunch of things inside it, instead of putting them on paper. Actually, if you take one recommendation from this review, just make sure to keep paper and pen wherever you work and use it all the time. Go to <fr:link href="https://www.amazon.co.uk/HP-Office-A4-gsm-500sh/dp/B000JTKDCW/ref=sr_1_24?dchild=1&amp;keywords=blank paper&amp;qid=1604957654&amp;sr=8-24" type="external">these</fr:link> <fr:link href="https://www.amazon.co.uk/Zebra-01951-Z-Grip-Ballpoint-Pen/dp/B000KN2B4A/ref=sr_1_13?dchild=1&amp;keywords=ballpoint pens&amp;qid=1604957742&amp;sr=8-13" type="external">links</fr:link> to buy some _right now_, they're cheap (but you probably have this stuff already - use it!). See also <fr:link href="https://www.lesswrong.com/posts/GpDjJFeCQCLjpt68b/paper-trauma" type="external">Paper Trauma</fr:link>. I also invite you to consider <fr:link href="http://acritch.com/notepad/" type="external">buying a big notebook</fr:link>, but I haven't tried that yet myself.
</html:p>
                <html:p>
  But paper has some limitations:
</html:p>
                <html:p>
  -   You sometimes run out
  -   If you want to write your notes about something you're reading on paper, the best place is the thing you're reading - but this requires that it be on paper (instead of a computer). This means you have to buy a book (these have a tendency to pile up rapidly, if it even is a book you can buy) or print it out (this tends to be messy, and you might not have a printer. Back at the university of Copenhagen, I used to print out a lot of stuff and spiral-back it, but I can't do this any more).
  -   Sometimes you lose your old paper where you wrote something important (usually, because you didn't know at the time it would be important).
  -   It's easy to make a mess by creating a huge stack of paper. If you're like me, "clean up your big pile of papers" can sometimes become a bit of an "ugh" task that you can't get around to and which sucks up a lot of energy.
</html:p>
                <html:p>
  Enter the <fr:link href="https://remarkable.com/" type="external">reMarkable 2</fr:link>. A "next-generation paper tablet", it promises you that you can "Replace your notebooks and printed documents with the only tablet that feels like paper". Naturally, I was intrigued.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="General experience and thoughts">General experience and thoughts</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The writing experience is _very very good_. It doesn't quite feel like paper - it's not _that_ close - but apart from actually writing on paper it's the best I've tried (having, admittedly, not tried that many). It's leagues ahead of writing on a "normal" tablet using a stylus.
</html:p>
                <html:p>
  Drawing on the reMarkable has the following advantages over paper:
</html:p>
                <html:p>
  -   You can erase things, perfectly
  -   You can undo/redo strokes
  -   You can zoom
  -   You can select and move things
  -   There's layers, like in image editing software.
</html:p>
                <html:p>
  The surface feels a bit too smooth - it doesn't have the same friction as dragging a pen over paper. It's still better than a normal screen (like a iPad) though. You can tell they added some texture to make this more lifelike, but it's not the same.
</html:p>
                <html:p>
  Not surprisingly, it's a bit awkward to hold the tablet with one hand and write with the other. The holding hand doesn't provide quite enough support. You really need to support it with a table or your knees or something.
</html:p>
                <html:p>
  Probably the biggest thing I would like is a bigger screen.
</html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>11</fr:month>
                      <fr:day>10</fr:day>
                    </fr:date>
                    <fr:title text="Notes about the OS">Notes about the OS</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The "OS", as it is, is basically just a folder structure where you can arrange pdfs, EPUBs (I haven't tried this), and "notebooks", which are basically collections of pages of your drawing/writing/scribbling.
    You can also add things to "favorites" and sort by "type" (notebook/pdf/EPUB).
    It's not amazing, especially since it's a bit sluggish to use, but it does the job.
</html:p>
                    <html:p>
    You can get stuff out of and into the reMarkable in a few ways:
</html:p>
                    <html:p>
    -   If you create an account in their server and connect it, it automatically syncs to their cloud, and you can get at this data from a desktop app and a mobile app. These are also how you get stuff into it. The syncing here is pretty slow, so I don't use this a lot.
    -   You can send a mail from the tablet with a collection of pages - either annotated pdf/epub or raw notebook. This is what I do, and it works great!
    -   There's also a browser extension which turns a website into an EPUB and sends it to the tablet. It works okay, about the same as something like Pocket or Instapaper.
    -   You can also have the reMarkable convert you handwriting into text and send it as an email. This is actually surprisingly (to me) good, but probably not quite good enough to send a mail without proofreading (you can check and edit the message on the tablet before sending).
        The first line in the following picture was converted without error, while the second became "The Quick brown tote jumps over the lazy chef".
</html:p>
                    <html:img src="/bafkrmih4opc7yl7hlhhlhwv2vc2e6tyjms4kxbujclmo2eomxgvai5yo6a.png" title="" />
                    <html:p>
        I haven't tested this extensively, and I expect it to do worse on other languages than English (you can switch the language used in the setting menu).
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>11</fr:month>
                      <fr:day>10</fr:day>
                    </fr:date>
                    <fr:title text="The physical feel of things">The physical feel of things</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The pen weighs 19g, and feels about like an ordinary ballpoint pen/fineliner in the hand. I would have liked a bit more weight, but it's not a big deal.
</html:p>
                    <html:p>
    The tablet is pretty light. Holding it in one hand is a bit heavy for me - not TOO heavy to use like that, but I probably won't read like that for, say, multiple hours. This is not a big deal though.
</html:p>
                    <html:p>
    The "Book Folio" cover is fine. It's fairly basic, certainly not "worth" 100 EUR - if there was a market for accesories, you could certainly buy a better one much cheaper. It essentially consists of two pieces of sturdy cardboard (I think), covered on the outside by light grey fabric and on the inside by something that feels like felt. The tablet attached to the backside by magnets - these are not that strong, but they do the job. The pen simply attached to the tablet itself by magnets - again, these do the job, but I would have liked them to be a bit stronger. I am slightly worried about the pen falling off in a bag full of mess and getting into trouble. The front piece also attaches by (weaker) magnets when closed, so it doesn't open by itself.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="Notes about my &quot;workflow&quot;">Notes about my "workflow"</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The basic things I've done with the reMarkable so far breaks down into roughly three categories:
</html:p>
                <html:p>
  -   During video meetings, I've scratched notes on the tablet
  -   I've put things on the tablet to read, and scribbled in the margins while I did so
  -   I've used the blank pages (notebooks) to work on.
</html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>11</fr:month>
                      <fr:day>10</fr:day>
                    </fr:date>
                    <fr:title text="Meeting notes">Meeting notes</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The device doesn't really shine here. The only advantage it has over writing on the computer is that I can keep the window with people's faces visible while writing, which I could do anyway if I had a second monitor.
    There's something nice about paper writing - maybe the flexibility of not being limited to one line after the other? Maybe something physical? That this captures but writing on the computer doesn't, though. But this is a small advantage.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>11</fr:month>
                      <fr:day>10</fr:day>
                    </fr:date>
                    <fr:title text="Reading and scribbling">Reading and scribbling</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    This is the real killer app for me. As noted above, you can put your pdfs on the reMarkable and read them. And while reading them, you can scribble on them. I am one of those people who likes to constantly doodle on things, so the eraser really comes in handy here - I can make a scribble, then erase it, so the margins don't get covered in random noise. This is an advantage I hadn't thought of.
</html:p>
                    <html:p>
    After scribbling and highlighting and so on, I usually send annotated pages to my email. Then they can become part of my diginal notes.
</html:p>
                    <html:p>
    I think the fact that this doesn't browse the internet is probably a huge advantage, because it adds a bit of friction to checking twitter, making me distract myself less. Just having a pdf reader that can't check twitter might contribute a huge amount of value.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>11</fr:month>
                      <fr:day>10</fr:day>
                    </fr:date>
                    <fr:title text="Working on blank paper">Working on blank paper</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    As mentioned above, using blank paper to think on is really important to me. On the reMarkable, there's a distinguished "quick pages" notebook with a permanent shortcut to it on the top. This gives you an infinite supply of blank pages to work on.
    I also use a few other notebooks to collect thoughts about various projects, but this is not very well-organized.
    The biggest drawback here is that the pages are not very large. I think the screen is slightly broader than A6 format (checked by holding up a folded sheet of A4). This is not optimal - I would like to be able to draw bigger things, to keep more thoughts on the page at once. The jury is still out, but I can't imagine the reMarkable will permanently replace paper in this domain for me - at best, it will supplement it.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="Notes on price &amp; comparison to other products">Notes on price &amp; comparison to other products</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The reMarkable 2 device itself costs 400 EUR (473 USD at current rates, but prices may differ by region).
  This price point is severely misleading, since it's more or less useless unless you buy a pen (you can read on it, of course, but if that's all you want to do I would definitely consider it overpriced).
</html:p>
                <html:p>
  The basic "Marker" costs 60 EUR, and the "Marker plus" costs 100 EUR.
  The only difference is that the plus weighs slightly more and that you can use the rear end to erase.
  It's probably best to just consider the base price of the device 460 EUR and ask whether you want to pay 40 EUR for the eraser.
</html:p>
                <html:p>
  Lastly, you can purchase a cover, or "folio".
  Here your options are the basic folio for 80 EUR, which is simply a sleeve that you can slide the reMarkable into,
  and the "Book Folio", which is essentially a folder, which magnetically attaches to the back of the reMarkable and wraps around it.
  This costs 100 EUR for the basic "polymer weave", and 150 EUR for the black or brown "Premium Leather" version.
  These are "overpriced" in the sense that, if there was a market for reMarkable accessories, you would certainly be able to buy much better protective covers for much less. But there isn't, so you're stuck with these, and the question is whether they're worth the money.
</html:p>
                <html:p>
  You can also buy a reMarkable 1 with basic Folio and (non-eraser) Marker for 349 EUR.
</html:p>
                <html:p>
  When I bought my reMarkable, I paid a reduced price because I was buying it early. I bought the Marker Pro and the Polymer Weave Book Folio, and ended up paying 460 EUR.
</html:p>
                <html:p>
  So how much does the reMarkable 2 cost? Based on my experience so far, the built-in eraser is super convenient and well worth the money. You probably want _some_ sort of protective cover, to prevent the screen from getting dings and scratches, but I have to stress that the Folios really seem to be nothing special. If I was buying it again I would probably buy the Book Folio again, just because 20 EUR isn't a lot and it seems a bit incovenient to be taking it in and out of the sleeve all the time.
  On that basis, it costs 600 EUR, or ~710 USD.
</html:p>
                <html:p>
  That's a lot.
  For that money you could buy an iPad (329 USD), Apple Pencil ($129), and a smart cover ($50), and still have money left over.
  You could use that money to buy extra memory for the iPad, cellular web access (not a killer app for me, but the reMarkable lacks it). You could even buy an iPad Air, if you maybe skimped out on the cover. I didn't look into the Android options, but presumably those are even cheaper. So if you're looking for a "general work tablet", you should probably skip the reMarkable.
  If you're looking for the paper feeling, you could consider <fr:link href="https://paperlike.com/" type="external">Paperlike</fr:link>, for just 40 USD (which I have not tried and cannot opine on).
</html:p>
                <html:p>
  reMarkable really has nothing in the way of tablet features. You can't install any apps (actually, there's a small community of hackers, but nobody is seriously developing third-party software). You wouldn't want to install any of the apps you have on other devices even if you could, because the refresh speed is too low for most "normal" software to really be usable.
  You can't browse the internet.
</html:p>
                <html:p>
  What you can do is basically:
</html:p>
                <html:p>
  -   Write and draw with a stylus like you were drawing on blank paper
  -   Read pdfs and ebooks, and write on them.
</html:p>
                <html:p>
  If stuff like that is such an important part of your workflow that getting a significantly better experience than you would doing the same thing on an iPad is worth giving up _all of the iPad's other features_, you should consider the reMarkable. Personally, this is basically the only reason I would really want to own a tablet anyway. In fact, the fact that I can't browse the internet on it is probably a strong feature in its favor, since it makes it harder to distract yourself with twitter.
</html:p>
                <html:p>
  Another comparison is with the line of products from <fr:link href="https://www.boox.com/" type="external">Boox</fr:link>. The most direct comparison is with the <fr:link href="https://www.boox.com/noteair" type="external">Note Air</fr:link>, which has a similar form factor and price point. There is also <fr:link href="https://supernote.com/#/" type="external">Supernote</fr:link>. I have no experience with any of these. It seems that the Boox Note Air is generally more feature-rich than the reMarkable - it actually runs Android, and is thus closer to a "proper" tablet. <fr:link href="https://goodereader.com/blog/reviews/remarkable-2-vs-the-onyx-boox-note-air" type="external">This review</fr:link> may provide some information, and recommends the Note Air.
</html:p>
                <html:p>
  I have to say these products are really tempting me, especially the ones with larger screens. If I was buying a new "paper tablet" today, I would seriously consider them.
</html:p>
                <html:p>
  [^fn:1]: for the record, her opinion of my reMarkable was that it seemed awesome, but it was a nonstarter for her, because it didn't do colors
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>11</fr:month>
              <fr:day>4</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/eulers-method-is-compositional/</fr:uri>
            <fr:display-uri>eulers-method-is-compositional</fr:display-uri>
            <fr:route>/eulers-method-is-compositional/</fr:route>
            <fr:title text="Euler's method is compositional">Euler's method is compositional</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Another day, another post about dynamical systems.
Today, I want to think about _open_ dynamical systems.
You can think of an open dynamical system as a system where
</html:p>
            <html:ul><html:li>The dynamics are parameterized by some variable (which is supposed to vary with time)</html:li>
  <html:li>And some function of the state is exposed (maybe to parameterize other systems).</html:li>
<html:p /></html:ul>
            <html:p>
I want to describe two types of open dynamical systems: continuous ones and discrete ones, and show that Euler's method is a compositional mapping between them.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>4</fr:day>
                </fr:date>
                <fr:title text="Open dynamical systems">Open dynamical systems</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  A _continuous open dynamical system_ consists of the following data:
</html:p>
                <html:p>
  -   An input set <fr:tex display="inline"><![CDATA[\mathbb {R}^I]]></fr:tex>
  -   An output set <fr:tex display="inline"><![CDATA[\mathbb {R}^O]]></fr:tex>
  -   A state set <fr:tex display="inline"><![CDATA[\mathbb {R}^S]]></fr:tex>
  -   A "dynamics" <fr:tex display="inline"><![CDATA[D: \mathbb {R}^{I+S} \to  \mathbb {R}^S]]></fr:tex>.
  -   A "readout" <fr:tex display="inline"><![CDATA[r: \mathbb {R}^{S} \to  \mathbb {R}^O]]></fr:tex>.
</html:p>
                <html:p>
  This is a continous open dynamical system <fr:tex display="inline"><![CDATA[I \to  O]]></fr:tex>. Here <fr:tex display="inline"><![CDATA[I,O,S]]></fr:tex> are natural numbers.
  Note that we are constraining our spaces to being <fr:tex display="inline"><![CDATA[\mathbb {R}^n]]></fr:tex>. Of course we could have made sense of the above definition for any smooth manifold, asking instead for a map <fr:tex display="inline"><![CDATA[I \times  S \to  TS]]></fr:tex> so that for each <fr:tex display="inline"><![CDATA[i]]></fr:tex> the map <fr:tex display="inline"><![CDATA[S \to  TS]]></fr:tex> is a section of the tangent bundle. The reason we're looking only at Euclidean spaces is because, to actually use Euler's method,
  we need a way of "stepping along the derivative". In our case this is given by simply adding the derivative - in general, we need a map <fr:tex display="inline"><![CDATA[TS \to  S]]></fr:tex>.
</html:p>
                <html:p>
  A trajectory of this dynamical system is a pair of functions <fr:tex display="inline"><![CDATA[i(t),s(t)]]></fr:tex> so that <fr:tex display="inline"><![CDATA[s'(t) = D(i(t),s(t))]]></fr:tex>.
</html:p>
                <html:p>
  Given systems <fr:tex display="inline"><![CDATA[I \to  X, X \to  O]]></fr:tex>, we can compose them to obtain a system <fr:tex display="inline"><![CDATA[I \to  O]]></fr:tex>.
  Suppose the state, dynamics and readout of the two systems are respectively <fr:tex display="inline"><![CDATA[S_1,D_1,r_1,S_2,D_2,r_2]]></fr:tex>.
  Then the state of the composed system is <fr:tex display="inline"><![CDATA[S_1 + S_2]]></fr:tex>, the readout is simply <fr:tex display="inline"><![CDATA[(s_1,s_2) \mapsto  r_2(s_2)]]></fr:tex>,
  and the dynamics are <fr:tex display="inline"><![CDATA[D(i,s_1,s_2) = (D_1(i,s_1),D_2(r_1(s_1),s_2))]]></fr:tex>.
  This corresponds to plugging the output of the first system into the input of the second.
</html:p>
                <html:p>
  Note that this does not form a category, because there are no identities - there is no way to simply feed the input into the output.
</html:p>
                <html:p>
  Now for the discrete systems:
  A discrete open dynamical system consists of the following data:
</html:p>
                <html:p>
  -   An input set <fr:tex display="inline"><![CDATA[I]]></fr:tex>
  -   An output set <fr:tex display="inline"><![CDATA[O]]></fr:tex>
  -   A state set <fr:tex display="inline"><![CDATA[S]]></fr:tex>
  -   An update function <fr:tex display="inline"><![CDATA[U: I \times  S \to  S]]></fr:tex>.
  -   A readout function <fr:tex display="inline"><![CDATA[r: S \to  O]]></fr:tex>.
</html:p>
                <html:p>
  Now the composition is pretty much analogous: given systems <fr:tex display="inline"><![CDATA[(S_1,U_1,r_1): I \to  X, (S_2,U_2,r_2) : X \to  O]]></fr:tex>,
  the composite has input <fr:tex display="inline"><![CDATA[I]]></fr:tex>, output <fr:tex display="inline"><![CDATA[O]]></fr:tex>, state space <fr:tex display="inline"><![CDATA[S_1 \times  S_2]]></fr:tex>, readout <fr:tex display="inline"><![CDATA[(s_1,s_2) \mapsto  r_2(s_2)]]></fr:tex>,
  and update <fr:tex display="inline"><![CDATA[U_2(i,s_1,s_2) = (U_1(i,s_1),U_2(r_1(s_1),s_2))]]></fr:tex>.
</html:p>
                <html:p>
  Again, there are no identities.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>4</fr:day>
                </fr:date>
                <fr:title text="Euler's method">Euler's method</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Recall that _Euler's method_ is a way of solving a differential equation <fr:tex display="inline"><![CDATA[y' = F(y)]]></fr:tex>.
  Given a starting condition <fr:tex display="inline"><![CDATA[y(0) = y_0]]></fr:tex>, we fix some step size <fr:tex display="inline"><![CDATA[h]]></fr:tex> and move forward one step at a time,
  approximating <fr:tex display="inline"><![CDATA[y(t + h) \approx  y(t) + hy'(t) = y(t) + hF(y(t))]]></fr:tex>.
</html:p>
                <html:p>
  This is essentially replacing a continuous dynamic system with a discrete dynamical system.
  The state space is the same, and the update function steps forward <fr:tex display="inline"><![CDATA[h]]></fr:tex> by the above method.
  Formally, if <fr:tex display="inline"><![CDATA[(I,O,S,D,r)]]></fr:tex> is a continuous dynamical system, define <fr:tex display="inline"><![CDATA[Eu_h(I,O,S,D,r)]]></fr:tex> to have
</html:p>
                <html:p>
  -   State space <fr:tex display="inline"><![CDATA[\mathbb {R}^S]]></fr:tex> - the same state space, essentially.
  -   Input space <fr:tex display="inline"><![CDATA[\mathbb {R}^I]]></fr:tex>
  -   Output space <fr:tex display="inline"><![CDATA[\mathbb {R}^O]]></fr:tex>
  -   Update function <fr:tex display="inline"><![CDATA[U(i,s) = s + hD(i,s)]]></fr:tex>
  -   Readout simply given by <fr:tex display="inline"><![CDATA[r]]></fr:tex></html:p>
                <html:p>
  Then, we have that <fr:tex display="inline"><![CDATA[Eu_h]]></fr:tex> is _compositional_ - in other words, if <fr:tex display="inline"><![CDATA[X,Y]]></fr:tex> are continuous systems and <fr:tex display="inline"><![CDATA[X;Y]]></fr:tex> their composite, then <fr:tex display="inline"><![CDATA[Eu_h(X;Y) = Eu_h(X);Eu_h(Y)]]></fr:tex>. The proof is essentially just by writing out the definitions.
</html:p>
                <html:p>
  -   The desired identity for in/output, state sets and readout is clear.
  -   For the update, on the left-hand side the update is given by
      <fr:tex display="inline"><![CDATA[U(i,s_1,s_2) = (s_1,s_2) + h(D_1(i,s_1),D_2(r_1(s_1),s_2))]]></fr:tex>.
      On the left-hand side, the update is given by <fr:tex display="inline"><![CDATA[U(i,s_1,s_2) = (s_1 + hD_1(i,s_1), s_2 + hD_2(r_1(s_1),s_2))]]></fr:tex> - these are of course equal.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>11</fr:month>
                  <fr:day>4</fr:day>
                </fr:date>
                <fr:title text="Higher-order methods">Higher-order methods</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  In ODE solving, a "higher-order method" is one that tries to incorporate information about higher derivatives to make a better estimate.
  We can view Euler's method as, essentially, calculating <fr:tex display="inline"><![CDATA[y(t+h)]]></fr:tex> by replacing <fr:tex display="inline"><![CDATA[y]]></fr:tex> with its first-order Taylor approximation <fr:tex display="inline"><![CDATA[T_1y(t+h) = y(t) + hy'(t)]]></fr:tex>, which we can calculate from the differential equation.
  We can often get a better estimate by incorporating higher derivatives - by trying to compute <fr:tex display="inline"><![CDATA[y(t) + hy'(t) + \frac {h^2}{2}y^{(2)}(t)]]></fr:tex>, for example. Essentially, we are incorporating information about how the derivative will change (or how we think it will change) over the interval <fr:tex display="inline"><![CDATA[[t,t+h]]]></fr:tex>. If it's going up, then we'll get a higher value than we expected just from looking at the derivative now. If it's going down, we'll get a lower value.
</html:p>
                <html:p>
  The issue here, of course, is that we can't compute the second derivative directly - the differential equation doesn't tell us what it should be.
  That leaves us with two options
</html:p>
                <html:p>
  -   Derive both sides of <fr:tex display="inline"><![CDATA[y'(t) = F(y(t))]]></fr:tex> to get <fr:tex display="inline"><![CDATA[y''(t) = F'(y(t))y'(t) = F'(y(t))F(y(t))]]></fr:tex>.
</html:p>
                <html:p>
  Of course, this requires that the function <fr:tex display="inline"><![CDATA[F]]></fr:tex> in the equation is actually differentiable, and that you have access to a symbolic representation so that you can compute the derivative explicitly.
  This falls in the general class of methods called _multiderivative methods_.
  It's easy to see how the above also gives a mapping from continuous systems to discrete ones, although I have not checked the details of compositionality.
</html:p>
                <html:p>
  -   Estimate <fr:tex display="inline"><![CDATA[y''(t) \approx  \frac {y'(t)- y'(t-h)}{h} = \frac {F(y(t)) - F(y(t-h))}{h}]]></fr:tex>.
      This can then be calculated from the past two steps.
</html:p>
                <html:p>
  It's not immediately obvious how to make this into a discrete dynamical system. After all, the next state depends not only on the current state, but also on the previous one.
  The idea will be to make a state of the discrete system consist of _two_ points in the space - the transition replaces the first with the second, and computes a new second point by the method.
  Explicitly, given as above a continuous dynamical system:
</html:p>
                <html:p>
  -   The input and output are as Euler's method
  -   The state is <fr:tex display="inline"><![CDATA[\mathbb {R}^S \times  \mathbb {R}^S]]></fr:tex>.
  -   The readout is <fr:tex display="inline"><![CDATA[r(s_1,s_2) = r(s_2)]]></fr:tex> (the readout of the "present") state.
  -   The update is <fr:tex display="inline"><![CDATA[U(i,s_1,s_2) = (s_2, s_2 + hD(i,s_2) + \frac {h}{2}(D(i,s_2) - D(i,s_1)))]]></fr:tex></html:p>
                <html:p>
  Note that in this method, we are updating under the assumption of constant input - it may be more appropriate to remember the last input as well, and use that.
  In any case, I have not verified compositionality of this method either.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>30</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/cofree-dynamical-systems-and-chaos/</fr:uri>
            <fr:display-uri>cofree-dynamical-systems-and-chaos</fr:display-uri>
            <fr:route>/cofree-dynamical-systems-and-chaos/</fr:route>
            <fr:title text="Cofree dynamical systems and chaos">Cofree dynamical systems and chaos</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
This blog post largely retraces ideas from <fr:link href="http://www.ima.umn.edu/sites/default/files/87s.pdf" type="external">Lawvere: Functorial remarks on the general concept of chaos</fr:link>.
I saw this in <fr:link href="https://twitter.com/JadeMasterMath/status/1267230814703464448" type="external">this tweet</fr:link> from Jade Master, which this blog post is basically an extended version of. Hat tip to her.
</html:p>
            <html:p>
Let's try to apply category theory to the study of "dynamical systems".
What is a dynamical system? There are a lot of different versions:
</html:p>
            <html:ul><html:li>A discrete dynamical system is a set <fr:tex display="inline"><![CDATA[S]]></fr:tex> with a map <fr:tex display="inline"><![CDATA[S \to  S]]></fr:tex>.</html:li>
  <html:li>A discrete Markov process if a countable set <fr:tex display="inline"><![CDATA[S]]></fr:tex> equipped with a stochastic <fr:tex display="inline"><![CDATA[S\times  S]]></fr:tex> matrix.</html:li>
  <html:li>A smooth dynamical systsem is a smooth manifold <fr:tex display="inline"><![CDATA[M]]></fr:tex> equipped with a section of the tangent bundle <fr:tex display="inline"><![CDATA[M \to  TM]]></fr:tex>.</html:li>
<html:p /></html:ul>
            <html:p>
Today, we'll take the following general view:
</html:p>
            <html:p>
Let <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> be a symmetric monoidal category, and let <fr:tex display="inline"><![CDATA[(T,+,0)]]></fr:tex> be a commutative monoid in <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>[^fn:1].
Then a <fr:tex display="inline"><![CDATA[T]]></fr:tex>-dynamical system is simply an object <fr:tex display="inline"><![CDATA[S]]></fr:tex> of <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> equipped with an action of <fr:tex display="inline"><![CDATA[T]]></fr:tex>, <fr:tex display="inline"><![CDATA[T \otimes  S \to  S]]></fr:tex>.
</html:p>
            <html:p>
We think of the elements of <fr:tex display="inline"><![CDATA[T]]></fr:tex> as "time-shifts", and the composition adds these together.
Using this, we can recover a wide variety of different types of dynamical systems:
</html:p>
            <html:ul><html:li>Let <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> be the category of sets, equipped with the cartesian monoidal structure. Let <fr:tex display="inline"><![CDATA[T = \mathbb {N}_0]]></fr:tex>.</html:li>
<html:p />
    Then a <fr:tex display="inline"><![CDATA[\mathbb {N}_0]]></fr:tex>-dynamical system is exactly a discrete dynamical system in the previous sense.
</html:ul>
            <html:ul><html:li>Let instead <fr:tex display="inline"><![CDATA[\mathcal {C} = \aleph _0\operatorname {-}\mathsf {Stoch}]]></fr:tex> be the category of countable sets and Markov kernels, and let <fr:tex display="inline"><![CDATA[T]]></fr:tex> be <fr:tex display="inline"><![CDATA[\mathbb {N}_0]]></fr:tex> again (with the usual monoidal structure regarded as a deterministic Markov kernel). Then a <fr:tex display="inline"><![CDATA[\mathbb {N}_0]]></fr:tex>-dynamical system is exactly a discrete Markov process[^fn:2]</html:li>
  <html:li>Let <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> be the category of smooth manifolds with the Cartesian monoidal structure, and let <fr:tex display="inline"><![CDATA[T = \mathbb {R}]]></fr:tex>.</html:li>
<html:p />
    Then an <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex>-dynamical system is _almost_ the same thing as a smooth dynamical system in the above sense.
    A <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex>-dynamical system picks out a smooth trajectory <fr:tex display="inline"><![CDATA[f(-,m) : \mathbb {R} \to  M]]></fr:tex> for each <fr:tex display="inline"><![CDATA[m \in  M]]></fr:tex>, in a compatible way. This gives a smooth vector field (i.e a smooth dynamical system in the above sense) <fr:tex display="inline"><![CDATA[m \mapsto  f'(0,m)]]></fr:tex>.
</html:ul>
            <html:p>
    This is not quite a 1-1 correspondence, for example because even smooth dynamical systems in that sense can experience "finite-time-blowup".
    For example, if we let <fr:tex display="inline"><![CDATA[M = \mathbb {R}]]></fr:tex>, then this a dynamical system is just an ordinary (time-independent) differential equation. If we put <fr:tex display="inline"><![CDATA[f'(t) = f(t)^2]]></fr:tex>, the unique solution given <fr:tex display="inline"><![CDATA[f(0) = y_0]]></fr:tex> is <fr:tex display="inline"><![CDATA[\frac {1}{y_0^{-1}-x}]]></fr:tex>, which goes to <fr:tex display="inline"><![CDATA[\infty ]]></fr:tex> as <fr:tex display="inline"><![CDATA[x \to  y_0^{-1}]]></fr:tex>. So there is no way to find a trajectory, extended for arbitrarily long time, which solves this equation.
    But on the other hand, perhaps equations like this are bad and shouldn't be counted. Anyways, they are not dynamical systems in this sense.
</html:p>
            <html:p>
Let <fr:tex display="inline"><![CDATA[Dyn(T)]]></fr:tex> denote the category of <fr:tex display="inline"><![CDATA[T]]></fr:tex>-dynamical systems - their maps are simply <fr:tex display="inline"><![CDATA[T]]></fr:tex>-equivariant maps.
There is an obvious forgetful functor <fr:tex display="inline"><![CDATA[Dyn(T) \to  \mathcal {C}]]></fr:tex>.
</html:p>
            <html:p>
Suppose <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> is a closed monoidal category. Then the above functor has a right adjoint, which sends <fr:tex display="inline"><![CDATA[M]]></fr:tex> to <fr:tex display="inline"><![CDATA[[T,M]]]></fr:tex>.
<fr:tex display="inline"><![CDATA[T]]></fr:tex> acts on <fr:tex display="inline"><![CDATA[[T,M]]]></fr:tex> simply by "translation", i.e <fr:tex display="inline"><![CDATA[(t.f)(t') = f(t+t')]]></fr:tex>
To be more formal, the map <fr:tex display="inline"><![CDATA[T\otimes  [T,M] \to  [T,M]]]></fr:tex> is adjoint to the map
<fr:tex display="inline"><![CDATA[T \otimes  [T,M] \otimes  T \to  M]]></fr:tex> given by multiplying the 2 <fr:tex display="inline"><![CDATA[T]]></fr:tex>s, then evaluating the hom.
</html:p>
            <html:p>
Proof: We claim that <fr:tex display="inline"><![CDATA[Hom_{Dyn(T)}([M,[T,M']]) \cong  Hom_\mathcal {C}(M,M')]]></fr:tex>.
</html:p>
            <html:p>
Suppose we have a <fr:tex display="inline"><![CDATA[T]]></fr:tex>-equivariant map <fr:tex display="inline"><![CDATA[\phi : M \to  [T,M']]]></fr:tex>.
<fr:tex display="inline"><![CDATA[T]]></fr:tex>-equivariance, of course, means that the diagram
</html:p>
            <html:img src="/bafkrmibfnhl6g3mwsehskxo2arjt2yi4tm47l5kxnkqhjlpas7b7wngt2q.png" title="" />
            <html:p>
commutes.
</html:p>
            <html:p>
The bare map <fr:tex display="inline"><![CDATA[M \to  [T,M']]]></fr:tex> corresponds to a map <fr:tex display="inline"><![CDATA[M \otimes  T \to  M']]></fr:tex>.
The above commutative square means that this square commutes:
</html:p>
            <html:img src="/bafkrmialyultsqnq5ry2kktqsdzk4dekpyo67y2jezs7ov6d44yaw5kz4m.png" title="" />
            <html:p>
The bottom way around is "let <fr:tex display="inline"><![CDATA[T]]></fr:tex> act on <fr:tex display="inline"><![CDATA[M]]></fr:tex>, then use the map".
The other one is "multiply the <fr:tex display="inline"><![CDATA[T]]></fr:tex>s together, then use the map".
</html:p>
            <html:p>
Now let's insert the unit into the right-hand <fr:tex display="inline"><![CDATA[T]]></fr:tex>:
</html:p>
            <html:img src="/bafkrmibshmb3ybiz5u5gstmdv2bl53lrhlomgjqhqwgp4uoudt2bssoqee.png" title="" />
            <html:p>
Both these squares commute. And the top arrow is just the identity.
In other words the classifying map <fr:tex display="inline"><![CDATA[T \otimes  M \to  M']]></fr:tex> must equal the other composite, which is "act, and evaluate at <fr:tex display="inline"><![CDATA[0]]></fr:tex>".
Equationally, if <fr:tex display="inline"><![CDATA[f: M \to  [T,M']]]></fr:tex>, this means <fr:tex display="inline"><![CDATA[f(m)(t) = f(t.m)(0)]]></fr:tex>.
This means the map <fr:tex display="inline"><![CDATA[f:M \to  [T,M']]]></fr:tex> is uniquely determined by the map <fr:tex display="inline"><![CDATA[M \to  M']]></fr:tex> given by evaluation at <fr:tex display="inline"><![CDATA[0]]></fr:tex>.
On the other hand, it's not hard to see that any map <fr:tex display="inline"><![CDATA[M \to  M']]></fr:tex> can be extended to an equivariant map by this method.
This concludes the proof.
</html:p>
            <html:p>
Now, what can we do with these "cofree dynamical systems"[^fn:3]?
Here is a cool thing: We can give a categorical definition of _chaos_.
</html:p>
            <html:p>
Let <fr:tex display="inline"><![CDATA[M]]></fr:tex> be a <fr:tex display="inline"><![CDATA[T]]></fr:tex>-dynamical system. Let <fr:tex display="inline"><![CDATA[o:M \to  X]]></fr:tex> be a map in <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> on the underlying space of <fr:tex display="inline"><![CDATA[M]]></fr:tex>.
We can think of <fr:tex display="inline"><![CDATA[o]]></fr:tex> as an "observable": some property of the state which we can measure.
There is a corresponding map of systems <fr:tex display="inline"><![CDATA[M \to  [T,X]]]></fr:tex> which takes each point in <fr:tex display="inline"><![CDATA[M]]></fr:tex> to its trajectory of observations
We say <fr:tex display="inline"><![CDATA[M]]></fr:tex> is _chaotic_ with respect to <fr:tex display="inline"><![CDATA[o]]></fr:tex> if map <fr:tex display="inline"><![CDATA[M \to  [T,X]]]></fr:tex> is an epimorphism.
</html:p>
            <html:p>
If we think of an epimorphism as a "surjection", this means every possible sequence of observations is possible. In other words, our current observations don't exclude any possible pattern of future observations.
</html:p>
            <html:p>
[^fn:1]: It is not really important that these are symmetric and commutative, but I can't be bothered to keep track of the order, and I don't have any natural non-commutative examples
[^fn:2]: It may have been more natural to consider finite-state Markov processes, but of course <fr:tex display="inline"><![CDATA[\mathbb {N}_0]]></fr:tex> isn't finite, so that wouldn't quite have worked
[^fn:3]: Incidentally, there is also a further left adjoint, the "free dynamical system", given by <fr:tex display="inline"><![CDATA[M \mapsto  T \otimes  M]]></fr:tex></html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>25</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/chu-spaces-and-linear-logic/</fr:uri>
            <fr:display-uri>chu-spaces-and-linear-logic</fr:display-uri>
            <fr:route>/chu-spaces-and-linear-logic/</fr:route>
            <fr:title text="Chu spaces and linear logic">Chu spaces and linear logic</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
A _Chu space over <fr:tex display="inline"><![CDATA[S]]></fr:tex>_ consists of a pair of sets <fr:tex display="inline"><![CDATA[(X,U)]]></fr:tex>, and a function <fr:tex display="inline"><![CDATA[e: X \times  U \to  S]]></fr:tex>.
A map of chu spaces <fr:tex display="inline"><![CDATA[(X,U,e) \to  (Y,V,e')]]></fr:tex> is a pair of maps <fr:tex display="inline"><![CDATA[X \to  Y, V \to  U]]></fr:tex> so that the diagram
</html:p>
            <html:img src="/bafkrmic65hzyhh2qxzijlsrtrnmzphlovtbpy4s7ltz4stqgz7yf7rh3wm.png" title="" />
            <html:p>
commutes.
This defines a category of Chu spaces, called <fr:tex display="inline"><![CDATA[Chu(Set,S)]]></fr:tex>
You can think of a Chu space as a normal-form game.
<fr:tex display="inline"><![CDATA[X]]></fr:tex> is the set of choices available to one player, and <fr:tex display="inline"><![CDATA[U]]></fr:tex> is the set of choices available to the other.
The outcome, given the choices <fr:tex display="inline"><![CDATA[x]]></fr:tex> and <fr:tex display="inline"><![CDATA[u]]></fr:tex>, is <fr:tex display="inline"><![CDATA[e(x,u)]]></fr:tex>.
</html:p>
            <html:p>
You can think of a map of Chu spaces as a way of transforming strategies between the two games.
If you would play <fr:tex display="inline"><![CDATA[x \in  X]]></fr:tex> in the original game, you instead play <fr:tex display="inline"><![CDATA[f(x) \in  Y]]></fr:tex>.
The map in the opposite direction ensures that, no matter what your opponent chooses in the target game, the same outcome could have happened in the domain game - hence your strategy is no worse, in some vague sense (but note that there is no ordering on <fr:tex display="inline"><![CDATA[S]]></fr:tex>, so this does not literally make sense).
</html:p>
            <html:p>
The cool thing is that Chu spaces are also a model of linear logic, in a way that sort of reflects "Game semantics for linear logic", but with some important differences (which we will see).
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>25</fr:day>
                </fr:date>
                <fr:title text="The duality">The duality</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The dual of a chu space is simply given by swapping the two sets, i.e <fr:tex display="inline"><![CDATA[(X,U,e)^\bot  := (U,X,(u,x) \mapsto  e(x,u))]]></fr:tex>.
  This defines a self-duality on the category of Chu spaces, <fr:tex display="inline"><![CDATA[Chu(Set,S) \cong  Chu(Set,S)^{op}]]></fr:tex></html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>25</fr:day>
                </fr:date>
                <fr:title text="The additive connectives">The additive connectives</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The additive connectives <fr:tex display="inline"><![CDATA[\&]]></fr:tex> and <fr:tex display="inline"><![CDATA[\oplus ]]></fr:tex> are simply given by the product and coproduct in the category of Chu spaces.
  Let's describe this explicitly:
</html:p>
                <html:p>
  -   Given Chu spaces <fr:tex display="inline"><![CDATA[A= (X,U,e), B=(Y,V,e')]]></fr:tex>, their product <fr:tex display="inline"><![CDATA[A \& B]]></fr:tex> is given by
      <fr:tex display="inline"><![CDATA[(X \times  Y, U + V, e \& e')]]></fr:tex>, where <fr:tex display="inline"><![CDATA[e\& e'(x,y,u \in  U) = e(x,u)]]></fr:tex>, and <fr:tex display="inline"><![CDATA[e\ampe '(x,y,v\in  V) = e'(y,v)]]></fr:tex>.
</html:p>
                <html:p>
      This corresponds to a game where the other player chooses one of the games to play, and a choice in that game. You have to choose a strategy for both games, not knowing which will be played.
  -   The terminal object is <fr:tex display="inline"><![CDATA[(*,\emptyset ,0)]]></fr:tex>, where <fr:tex display="inline"><![CDATA[0]]></fr:tex> denotes the empty function.
      Interpreting this as a game is slightly weird - it is a game that cannot be played, as the opponent has no moves to make.
      (Hence if given a choice between this and another game, the opponent must move in the other game, so that this is a unit for the product, as it should be).
  -   Given <fr:tex display="inline"><![CDATA[A]]></fr:tex> and <fr:tex display="inline"><![CDATA[B]]></fr:tex> as above, their coproduct <fr:tex display="inline"><![CDATA[A \oplus  B]]></fr:tex> is given by <fr:tex display="inline"><![CDATA[(X + Y, U \times  B, e \oplus  e')]]></fr:tex>, which is exactly dual to the product.
      In other words, here the player chooses a game and a move in it, while the opponent must choose a move in both games.
  -   The initial object is <fr:tex display="inline"><![CDATA[(\emptyset ,*,0)]]></fr:tex> - the player cannot move in this game.
</html:p>
                <html:p>
  The additive connectives, in other words, are much as you would expect from the "game" interpretation.
  The multiplicative connectives are more weird.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>25</fr:day>
                </fr:date>
                <fr:title text="The multiplicative connectives.">The multiplicative connectives.</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The tensor <fr:tex display="inline"><![CDATA[A \otimes  B]]></fr:tex> of two Chu spaces as above is defined by
  <fr:tex display="inline"><![CDATA[(X \times  Y, [X,V] \times _{[X\times  Y,S]} [Y,U], e\otimes  e')]]></fr:tex>,
  where <fr:tex display="inline"><![CDATA[e \otimes  e'((x,y),(f,g)) = e'(y,f(x)) = e(x,g(y))]]></fr:tex>.
  (Here the last equality is exactly the condition that <fr:tex display="inline"><![CDATA[(f,g)]]></fr:tex> lies in the pullback).
  In other words, to play <fr:tex display="inline"><![CDATA[A \otimes  B]]></fr:tex>, the player simply chooses a strategy in each game.
  The opponent must choose a strategy in <fr:tex display="inline"><![CDATA[A]]></fr:tex> which depends on the player's strategy in <fr:tex display="inline"><![CDATA[B]]></fr:tex> - a map <fr:tex display="inline"><![CDATA[Y \to  U]]></fr:tex>,
  and vice versa. These conditional strategies must satisfy the condition that, whether we play <fr:tex display="inline"><![CDATA[A]]></fr:tex> using the strategy matching the player's strategy from <fr:tex display="inline"><![CDATA[B]]></fr:tex>, or vice versa, we get the same result.
</html:p>
                <html:p>
  If you squint a bit, this is somewhat like the tensor product of games from before - the opponent can adjust their strategy based on the player's moves in the other game.
  But it's also very different.
  For example if the two images <fr:tex display="inline"><![CDATA[e(X \times  U)]]></fr:tex> and <fr:tex display="inline"><![CDATA[e'(Y \times  V)]]></fr:tex> are disjoint subsets of <fr:tex display="inline"><![CDATA[S]]></fr:tex>, the opponent has no moves in this game.
</html:p>
                <html:p>
  The tensorial unit is <fr:tex display="inline"><![CDATA[I = (*,S,1_S)]]></fr:tex> - in this game, the opponent simply chooses the outcome.
  Indeed, we have <fr:tex display="inline"><![CDATA[A \otimes  I \cong  A]]></fr:tex> - the player's choice amounts to choosing <fr:tex display="inline"><![CDATA[a \in  X]]></fr:tex>, while the opponent must choose a map <fr:tex display="inline"><![CDATA[* \to  U]]></fr:tex> - a point in <fr:tex display="inline"><![CDATA[U]]></fr:tex>, and a map <fr:tex display="inline"><![CDATA[X \to  S]]></fr:tex>, which has to equal the map <fr:tex display="inline"><![CDATA[x \mapsto  e(x,u)]]></fr:tex> corresponding to their chosen <fr:tex display="inline"><![CDATA[U]]></fr:tex>, so this is no choice at all.
</html:p>
                <html:p>
  There is a canonical map <fr:tex display="inline"><![CDATA[A \otimes  A^\bot  \to  I^\bot  = (S,*,1_S)]]></fr:tex>.
  In <fr:tex display="inline"><![CDATA[A \otimes  A^\bot ]]></fr:tex>, the player must choose a strategy and a counter-strategy.
  The opponent must choose a map <fr:tex display="inline"><![CDATA[X \to  X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y \to  Y]]></fr:tex> - of course the canonical choice is the identity.
  The outcome of this game is exactly the result of playing the player's two chosen strategies against each other - this is the element <fr:tex display="inline"><![CDATA[s \in  S]]></fr:tex> that the player's strategy is taken to.
</html:p>
                <html:p>
  In general, we can identify maps <fr:tex display="inline"><![CDATA[A \to  I^\bot ]]></fr:tex> with choices of strategy for the opponent - the point is sent to that strategy, while the map <fr:tex display="inline"><![CDATA[X \to  S]]></fr:tex> is constrained to being exactly the outcome corresponding to that strategy.
</html:p>
                <html:p>
  Dually, we can identify maps <fr:tex display="inline"><![CDATA[I \to  A]]></fr:tex> with strategies for the player.
  This of course means that a linear logic proof of the sequent <fr:tex display="inline"><![CDATA[\vdash  A]]></fr:tex> identifies a strategy for the player in the game defined by <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>21</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/game-semantics-of-linear-logic/</fr:uri>
            <fr:display-uri>game-semantics-of-linear-logic</fr:display-uri>
            <fr:route>/game-semantics-of-linear-logic/</fr:route>
            <fr:title text="Game semantics of linear logic">Game semantics of linear logic</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Linear logic is a weird sort of logic.
It's most commonly explained by saying that the "weakening" rule: &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_570c4c92abfcb8419f3d26233037e0de1c74aecf.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;
and the "contraction" rule &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_b3da13021d306636a1a258e2de559738f5f41da8.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
In other words - you have to use all the assumptions, and you can't use an assumption more than once.
This is usually interpreted in terms of _resources_ - just because I can make a &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_8582cbf09790ec5906444f9f5df9cd00053cb98e.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; out of two As doesn't mean I can do it with one &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;. And I can't just throw an &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; away that I might not need - I need to find a process for getting rid of it.
</html:p>
            <html:p>
However, there's also another way of thinking about linear logics - in terms of _games_.
The combinators of linear logics become ways of combining games into other games.
The interpretation of the deduction rules is now that a proof of the sequent &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_fbc8e225dbcfabfee571f016d25f90b9b3aca8af.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; should provide a winning strategy for &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
</html:p>
            <html:p>
Let us be a bit more (but not too) precise.
There are two players. Following convention, we call them the _prover_, P, and the _opponent_, O.
It is understood that we are "on the side" of P, although we could equally well do it the other way - the logic is symmetric enough for that.
A game has a starting player (in many treatments, it is assumed the opponent always goes first, but not here).
Play is usually assumed to proceed back and forth, each player making one move at a time, but this is not important - the most important thing is that in each position, there is a well-defined next player.
Each player has a number of possible moves, only some of which may be legal in a given position - by "position", we simply mean the sequence of moves so far. We generally think of a player as losing when they have to move, but have no legal moves.
</html:p>
            <html:p>
The most basic operator is the "dual" or "negation" operator, &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_bc4947b04e7ea496037197a0809d11da55422409.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;. This simply interchanges the position of the players.
The next operator is &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_279df3c8f4a8f9a7e4ae8fbdb05c6f1d880f9c99.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;. This game consist of playing &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; and &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_8582cbf09790ec5906444f9f5df9cd00053cb98e.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; simultaneously - the player must move in whatever game the opponent just moved in, while the opponent can switch games at will.
</html:p>
            <html:p>
Clearly, a winning strategy for this game, for the player, entails a winning strategy for each component game.
In this sense, this game is like logical "and".
</html:p>
            <html:p>
But there's also another operator like "and", which is written &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_cd339c6a9fd60f255d5641e7b67849d12862ec66.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
This is played as follows: the opponent chooses a game, then that game is played to completion, and its winner wins the whole game.
</html:p>
            <html:p>
Here is a difference between these operators: There is a canonical strategy for &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_c224d906e554f6971f4d8beea3fbf24f53936870.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;, but not for &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_c7ea9bf60399dae5f34e826d4f1a8ecc0a4a6030.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
How does this work? To play &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_c224d906e554f6971f4d8beea3fbf24f53936870.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;, we must play the opponent's side in &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_d3860e22107b32eb22a9449fa3807d8f08cea676.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
Assume wlog that the player goes first in &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
We have the player start playing in &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;, then copy this move into &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_bc4947b04e7ea496037197a0809d11da55422409.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
Whatever they play in response, we go to &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; and play that as our response to them, and so on.
We're guaranteed to win (exactly) one of the games, since the two games will be exactly mirrored.
If this doesn't make sense, imagine playing two chess games against another person - one as black, one as white.
Starting with the game in which they're white, they make a move. You copy this move on the other chessboard.
They respond with black, which you also copy on the fist board.
When they mate you at some point on one board, you copy this immediately, winning the other game.
</html:p>
            <html:p>
This strategy won't work for &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_c7ea9bf60399dae5f34e826d4f1a8ecc0a4a6030.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
Here we would have to decide at the beginning which game we have a winning strategy in, then choose that one.
</html:p>
            <html:p>
In logic, this means that the sequent &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_8964387a593f0de3a11f74446080e77066b64d2e.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; is provable, but &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_1e6005344886e5204b0108a5d3703657626bc38c.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; isn't.
</html:p>
            <html:p>
So far, we've only looked at the two forms of conjunction.
There is also two forms of disjunction, given simply by &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_332bfcca70f28fa5e5f48759a18df39665e5212c.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;, &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_b6e991d197297486fb377f8b2f7a71d7df9a0212.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
We could restate the above discussion as "&lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_67c4e3051ed267d97a37f2525aea5d5118ea2b30.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; is not provable, but $is".
This means we have a form of excluded middle, but another form of excluded middle doesn't hold.
</html:p>
            <html:p>
Now what is the meaning of a general sequent of the form &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_b995dd0c8fb474bb2182224fbeab583cfacd8a49.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;, where both &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_82b14cc542ef22dba87993b12dd6d6d310f947d7.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; and &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a33a2d6e25b53b1938ccfc129cc9544b9628375b.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; are multisets.
We can interpret such a sequent as asserting the existence of a strategy for the game &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_3415bd826597d728f3ee0489dbfa6c59ba7f9f84.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
A proof is supposed to identify a specific strategy for the game.
This also means that any sequent can be replaced by a one-sided one, which means linear logic can be expressed all in terms of one-sided sequents (which is indeed true).
</html:p>
            <html:p>
Now we can think about the lack of contraction - we can examine simply the fact that &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_4e379c847bf45683840230c2b93ef93f20c24be8.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; is not a provable sequent.
</html:p>
            <html:p>
To prove this sequent, we would want a strategy for &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_404495e2a205415c8b6fc83ff9a40bce2b9ef3c4.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
We can think of this again in the case where &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_a7d92cc965ef976b84b9370a6f429d98bc7d2fb9.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt; is chess.
Imagine that instead of two games, there are three, two where you are black.
You can only respond on whatever black board where your opponent just moved as white, or move as white on the board where you are white (forcing your opponent to respond there). And when you respond as black, your opponent can switch to the other black board.
You can only mirror one of these onto the game where you're white, so the strategy-stealing trick no longer works.
</html:p>
            <html:p>
On the other hand, weakening _is_ valid in this semantics. We do have a strategy for the game &lt;object type="image/svg+xml" data="/ox-hugo/20200414104653-blog_posts_afddd41d83bccf2bec783f5e313950c75d967c4b.svg" class="org-svg"&gt;
Sorry, your browser does not support SVG.&lt;/object&gt;.
Here you have two white boards and one black, and you can simply ignore the white board you don't need, since you now have full control over which board you move on.
</html:p>
            <html:p>
This is all written out in <fr:link href="https://www.sciencedirect.com/science/article/pii/0168007292900739" type="external">Blass: A game semantics for linear logic</fr:link>.
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>14</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/universal-properties-and-compositionality/</fr:uri>
            <fr:display-uri>universal-properties-and-compositionality</fr:display-uri>
            <fr:route>/universal-properties-and-compositionality/</fr:route>
            <fr:title text="Universal properties and Compositionality">Universal properties and Compositionality</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Continuing the train of thought from <fr:link href="https://twitter.com/AyeGill/status/1217748819682693121" type="external">this tweet</fr:link>, I compare and contrast two perspectives on the philosophy of category theory: that it's about describing how things can be composed of other things ("compositionality"), and that it's about describing things in terms of their transformations into other things ("universal properties").
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>14</fr:day>
                </fr:date>
                <fr:title text="Some uses of category theory">Some uses of category theory</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Category theory is an amazingly successful tool for pure mathematics.
  Since its introduction by Eilenberg and MacLane in <fr:link href="https://web.math.rochester.edu/people/faculty/doug/otherpapers/SESM.pdf" type="external">Generalized Theory of Natural Equivalences</fr:link>, it has completely transformed algebraic topology and algebraic geometry.
</html:p>
                <html:p>
  Let's study some examples of this:
</html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>10</fr:month>
                      <fr:day>14</fr:day>
                    </fr:date>
                    <fr:title text="The Brouwer Fixpoint Theorem">The Brouwer Fixpoint Theorem</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    This well-known theorem says that any continuous map <fr:tex display="inline"><![CDATA[f: D^2 \to  D^2]]></fr:tex>[^fn:1] must have a fixpoint, i.e a point so that <fr:tex display="inline"><![CDATA[f(x) = x]]></fr:tex>.
    The usual way to prove this is to suppose for contradiction that we have a map with no fixpoints.
    Then by drawing a line from <fr:tex display="inline"><![CDATA[f(x)]]></fr:tex> to <fr:tex display="inline"><![CDATA[x]]></fr:tex> and seeing where it intersects the boundary of <fr:tex display="inline"><![CDATA[D^2]]></fr:tex>, we find a continuous map <fr:tex display="inline"><![CDATA[g: D^2 \to  S^1]]></fr:tex> with the property that <fr:tex display="inline"><![CDATA[g(x) = x]]></fr:tex> when <fr:tex display="inline"><![CDATA[x \in  S^1 \subseteq  D^2]]></fr:tex>.
    Now we have to prove that there is no such continuous map.
</html:p>
                    <html:p>
    Luckily, there happens to exist a _functor_, <fr:tex display="inline"><![CDATA[\pi _1: \mathrm {Top} \to  \mathrm {Grp}]]></fr:tex>, with the properties that
    <fr:tex display="inline"><![CDATA[\pi _1(S^1) = \mathbb {Z},\ \pi _1(D^2) = 0]]></fr:tex>.
    If there really was a <fr:tex display="inline"><![CDATA[g]]></fr:tex> as above, so that the composition <fr:tex display="inline"><![CDATA[S^1 \hookrightarrow  D^2 \overset {g}{\to } S^1]]></fr:tex> was the identity, then by applying <fr:tex display="inline"><![CDATA[\pi _1]]></fr:tex> to it we would find a map so that <fr:tex display="inline"><![CDATA[\mathbb {Z} \to  0 \to  \mathbb {Z}]]></fr:tex> was the identity - which is clearly impossible.
</html:p>
                    <html:p>
    If we wanted to summarize this argument, we could say
</html:p>
                    <html:p>
    -   <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> is not a retract of <fr:tex display="inline"><![CDATA[0]]></fr:tex> (algebra)
    -   _Functors preserve retracts_ (category theory)
    -   Therefore <fr:tex display="inline"><![CDATA[S^1]]></fr:tex> is not a retract of <fr:tex display="inline"><![CDATA[D^2]]></fr:tex>. (topology)
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>10</fr:month>
                      <fr:day>14</fr:day>
                    </fr:date>
                    <fr:title text="Idempotent monads, aka localizations">Idempotent monads, aka localizations</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    It's very common in algebraic topology that you have some class of morphisms <fr:tex display="inline"><![CDATA[W]]></fr:tex> in your category <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> that you want to treat as isomorphisms.
    First of all, category theory tells us that there is essentially a unique way to make sense of this:
    The desired category <fr:tex display="inline"><![CDATA[\mathcal {C}[W^{-1}]]]></fr:tex> should have the following universal property: given a functor <fr:tex display="inline"><![CDATA[\mathcal {C} \to  \mathcal {D}]]></fr:tex> which sends every <fr:tex display="inline"><![CDATA[f \in  W]]></fr:tex> to an isomorphism, there should be a unique extension over <fr:tex display="inline"><![CDATA[\mathcal {C}[W^-1]]]></fr:tex>, as in this diagram:
</html:p>
                    <html:img src="/bafkrmic65hzyhh2qxzijlsrtrnmzphlovtbpy4s7ltz4stqgz7yf7rh3wm.png" title="" />
                    <html:p>
    This formalizes the intuition that <fr:tex display="inline"><![CDATA[\mathcal {C}[W^{-1}]]]></fr:tex> is <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex>, with the maps <fr:tex display="inline"><![CDATA[W]]></fr:tex> turned isomorphisms, and nothing else changed.
    Category theory (the Yoneda lemma), applied to the category of categories, tells us that this determines <fr:tex display="inline"><![CDATA[\mathcal {C}[W{-1}]]]></fr:tex> up to equivalence of categories. Under quite weak assumptions, this category can be constructed.
</html:p>
                    <html:p>
    But understanding the category <fr:tex display="inline"><![CDATA[\mathcal {C}[W^{-1}]]]></fr:tex> is usually very difficult.
    However, in good cases, something miraculous happens, and <fr:tex display="inline"><![CDATA[\mathcal {C}[W^{-1}]]]></fr:tex> appears as a subcategory of <fr:tex display="inline"><![CDATA[\mathcal {C}]]></fr:tex> itself!
</html:p>
                    <html:p>
    As a very simple example, we can consider the category <fr:tex display="inline"><![CDATA[\mathrm {Ab}]]></fr:tex> of abelian groups.
    Call a homomorphism a "rational equivalence" if
</html:p>
                    <html:p>
    -   If <fr:tex display="inline"><![CDATA[f(x) = 0]]></fr:tex>, then <fr:tex display="inline"><![CDATA[nx = 0]]></fr:tex> for some <fr:tex display="inline"><![CDATA[n \in  \mathbb {Z}]]></fr:tex>
    -   For each <fr:tex display="inline"><![CDATA[y]]></fr:tex> in the image, there exists <fr:tex display="inline"><![CDATA[x,n]]></fr:tex> so that <fr:tex display="inline"><![CDATA[f(x) = ny]]></fr:tex>.
</html:p>
                    <html:p>
    Call the category of rational equivalences <fr:tex display="inline"><![CDATA[W]]></fr:tex>. Then <fr:tex display="inline"><![CDATA[\mathrm {Ab}[W^{-1}]]]></fr:tex> is equivalent to the subcategory consisting of <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex>-modules - those abelian groups <fr:tex display="inline"><![CDATA[A]]></fr:tex> where each multiplication by <fr:tex display="inline"><![CDATA[n]]></fr:tex> map <fr:tex display="inline"><![CDATA[(n \cdot  -): A \to  A]]></fr:tex> is a bijection.
</html:p>
                    <html:p>
    The way to construct this in general is to consider the subcategory of _<fr:tex display="inline"><![CDATA[W]]></fr:tex>-local objects_ - those objects <fr:tex display="inline"><![CDATA[A]]></fr:tex> where, for every <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> in <fr:tex display="inline"><![CDATA[W]]></fr:tex>, the map <fr:tex display="inline"><![CDATA[\mathcal {C}(A,X) \to  \mathcal {C}(A,Y)]]></fr:tex> is a bijection.
    If every object admits a map <fr:tex display="inline"><![CDATA[\lambda : A \to  \tilde {A}]]></fr:tex> with <fr:tex display="inline"><![CDATA[\lambda  \in  W]]></fr:tex> and <fr:tex display="inline"><![CDATA[\tilde {A}]]></fr:tex> <fr:tex display="inline"><![CDATA[W]]></fr:tex>-local, then the construction <fr:tex display="inline"><![CDATA[A \mapsto  \tilde {A}]]></fr:tex> assembles into a functor, which exhibits the subcategory of <fr:tex display="inline"><![CDATA[W]]></fr:tex>-local objects as <fr:tex display="inline"><![CDATA[\mathcal {C}[W^{-1}]]]></fr:tex>.
</html:p>
                    <html:p>
    In this case, part of the utility of category theory is it lets us ask this question in the first place.
    But beyond that, it gives us access to the idea of, to put it technically, asking for objects that represent functors with certain properties (for example, those that invert certain morphisms) - in general terms, to describe objects in terms of their relations to other objects.
</html:p>
                    <html:p>
    (The really powerful uses of this technique involve doing something more complicated to model categories, or, equivalently, applying it to <fr:tex display="inline"><![CDATA[\infty ]]></fr:tex>-categories. But I won't get into that here - see e.g. <fr:link href="https://erischel.com/documents/bscproject.pdf" type="external">my undergraduate thesis</fr:link> or section 5.2.7 of <fr:link href="https://arxiv.org/abs/math/0608040" type="external">Higher Topos Theory</fr:link>.)
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>10</fr:month>
                      <fr:day>14</fr:day>
                    </fr:date>
                    <fr:title text="ZX Calculus">ZX Calculus</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    ZX calculus is a graphical language for quantum computing, introduced by Coecke and Duncan in a <fr:link href="https://arxiv.org/abs/0906.4725" type="external">2008 paper</fr:link>.
    It is essentially a flavor of string diagrams with special operators and rewriting rules to describe the operations in quantum computing. A diagram in the ZX calculus can be interpreted as a linear map between Hilbert spaces.
    I won't delve too much into the ZX calculus, since I'm not familiar with it beyond a surface level, but I will note that it's probably one of the more successful applications of category theory so far - I count 88 publications listed on &lt;https://zxcalculus.com&gt;.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>10</fr:month>
                      <fr:day>14</fr:day>
                    </fr:date>
                    <fr:title text="Open Reaction Networks">Open Reaction Networks</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p><fr:link href="https://arxiv.org/abs/1704.02051" type="external">Open Reaction Networks</fr:link>, described there by John Baez and Blake Pollard, are a compositional version of reaction networks
    Reaction networks describe various notions of "transition system", where you have a number of different "things" or "species" and various ways those things can be transformed into each other, "transitions".
    An open reaction networks is augmented with the designation of certain places as inputs and outputs.
    The composition operation identifies the outputs of one with the inputs f another, gluing them together in a single reaction network.
    Baez and Pollard construct a compositional semantics for reaction networks, which takes a reaction network to an "open dynamical system" describing the dynamics of the outputs, in terms of a function specifying the inputs over time.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>14</fr:day>
                </fr:date>
                <fr:title text="Compositionality and universal properties">Compositionality and universal properties</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The phrase "universal property"[^fn:2] appears neither in the original ZX calculus paper, nor in <fr:link href="https://arxiv.org/pdf/1611.08012.pdf" type="external">Graphical Structures for Design and Verification of Quantum Error Correction</fr:link>, which is one of the more successful applications (both of the ZX calculus and of category theory in general, outside pure math). Clearly they are not that interested in characterizing objects by their mapping properties - indeed, since the objects in this case are just finite-dimensional Hilbert spaces, hence direct sums of <fr:tex display="inline"><![CDATA[\mathbb {C}]]></fr:tex>, characterizing such a thing is not that interesting.
  The point is that in the classical domains of category theory, the primary thing is the objects, and how they map to one another. When we think about maps, we are usually just looking for an abstract machine that will guarantee the existence of a map with such-and-such properties, not in looking "inside" the map, so to speak, to see what it does.
  This in contrast with the ZX calculus, where the chief point is that we want a method for writing down maps between Hilbert spaces and understanding how they work.
  So also open Petri nets - the interesting structure here is (obviously) the _Petri net_, not the finite sets which serve as objects.
</html:p>
                <html:p>
  In this domain, the chief interest is in the _functors_ - we want to know, for example, that a certain "black-boxing" construction from the category of Petri nets to the category of (say) linear relations preserves the composition.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>14</fr:day>
                </fr:date>
                <fr:title text="Synthesis: Double categories and operads">Synthesis: Double categories and operads</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  As remarked by Jules Hedges <fr:link href="https://twitter.com/_julesh_/status/1277607181156790273" type="external">here</fr:link>, the "compositionality" above is really just about operation-preserving maps between algebras of some operad - the fact that the operad (or a suboperad) is the operad for categories[^fn:3] is not really important.
  So we can consider the operad where
</html:p>
                <html:p>
  -   The types (or colors) are pairs <fr:tex display="inline"><![CDATA[(I,O)]]></fr:tex> of finite sets
  -   The operations are generated by a composition operation <fr:tex display="inline"><![CDATA[(A,B),(B,C) \to  (A,C)]]></fr:tex>, an identity operation <fr:tex display="inline"><![CDATA[() \to  (A,A)]]></fr:tex>, and optionally a "tensor" operation <fr:tex display="inline"><![CDATA[(A,B),(X,Y) \to  (A+X,B+Y)]]></fr:tex> and some more operations for the unitors and associators in the monoidal structure.
  -   Quotiented by the axioms of a monoidal category.
</html:p>
                <html:p>
  Then the _set_ of open petri nets is an algebra for this operad, and we're essentially looking for an algebra homomorphism into a different algebra.
</html:p>
                <html:p>
  This perspective has a number of advantages:
</html:p>
                <html:p>
  -   When mapping into a situation where a slightly different structure exist, we can describe this by adding an operad homomorphism to the mix.
  -   We can take algebras in _categories_ to get categories where the _objects_ are the systems we're interested in.
</html:p>
                <html:p>
  This can give us some interesting universal properties - for example, the initial Petri net (with given input-output sets <fr:tex display="inline"><![CDATA[I,O]]></fr:tex>) would seem to be the net with exactly <fr:tex display="inline"><![CDATA[I+O]]></fr:tex> as places, and no transitions.
</html:p>
                <html:p>
  We can go even further and consider morphisms between systems with different interfaces.
  Presently the best framework for this seems to be double categories, which means we're going back to the operad for categories[^fn:4], but that's fine.
  For example, in <fr:link href="https://arxiv.org/abs/1711.07059" type="external">Morphisms of Open Games</fr:link>, Jules Hedges constructs a double category of open games, and describes limits and colimits in the "vertical category of morphisms" - i.e. in the category where objects are open games and maps are morphisms _between_ them.
</html:p>
                <html:p>
  In fact, various technologies for describing "open systems", like the <fr:link href="https://arxiv.org/abs/1911.04630" type="external">Structured Cospans</fr:link> of Baez and Courser, already output a double category. And in fact the composition in these systems already involves some sort of universal property, being described as a pushout.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>14</fr:day>
                </fr:date>
                <fr:title text="Synthesis: Syntactical categories, Lambda Calculus">Synthesis: Syntactical categories, Lambda Calculus</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Above we have thought about many different situations where we're interested in studying the "behaviour", in some sense, of complex systems, and we try to understand this behaviour as a functor in a category of such systems.
  Perhaps the most famous example of this is the notion of _functorial semantics_ from logic (indeed the term "functorial semantics" seems to describe the black-boxing functor quite well).
  The general pattern is that we have a _syntactical category_ where the morphisms are terms in some syntax, subject to some equivalence relation (often generated by some set of syntactical rewriting rules), and this is mapped into some sort of "semantics" category.
  Here it very often happens that the necessary structure to interpret the syntax corresponds to some more or less natural categorical structure, and the syntactical category is the initial such category (so that there is a well-defined interpretation of the syntax in each suitable category).
</html:p>
                <html:p>
  An example of this is simply typed lambda calculus, or STLC.
  I guess it's well-known that the simply typed lambda-calculus can be interpreted in any cartesian closed category.
  Each type <fr:tex display="inline"><![CDATA[A]]></fr:tex> is mapped to an object <fr:tex display="inline"><![CDATA[ [ [A ] ]]]></fr:tex>, with <fr:tex display="inline"><![CDATA[[ [ A \to  B ] ] = [ [ B ] ]^{[ [ A ] ]}]]></fr:tex>.
  Then a judgment <fr:tex display="inline"><![CDATA[\Gamma  \vdash  e : A]]></fr:tex>, where <fr:tex display="inline"><![CDATA[\Gamma  = x_1 : X_1, x_2 : X_1, \dots  x_n : X_n]]></fr:tex>,
  is mapped to a morphism <fr:tex display="inline"><![CDATA[\prod _i [ [ X_i ] ] \to  [ [ A ] ]]]></fr:tex>, by inducting on the proof of the judgment using the projections
  and the hom-product adjunction.
</html:p>
                <html:p>
  One can show that the _initial_ Cartesian closed category with a certain set of objects and points - we might say the CCC _generated_ by that data - can be described as having objects the contexts, and morphisms the judgments, in STLC with those constants.
  But this is somewhat interesting - the syntax of lambda calculus is "about writing down functions", just as the ZX calculus.
  Yet there are also universal properties in the mix - the fact that the functor <fr:tex display="inline"><![CDATA[A \times  -]]></fr:tex> has a right adjoint for all <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
  Across many areas of categorical logic, similar things happen.
</html:p>
                <html:p>
  [^fn:1]: It actually holds for <fr:tex display="inline"><![CDATA[D^n]]></fr:tex> for all <fr:tex display="inline"><![CDATA[n]]></fr:tex>, but let's keep things simple
  [^fn:2]: A lot of things are described as _universal_, but this refers to the important property that any quantum computation can be described in ZX-calculus
  [^fn:3]: There isn't really an operad for categories - what I describe here is for "categories with a specific set of objects" - but that's not so important
  [^fn:4]: There are ways to generalize this - David Jaz Myers has studied monoidal double functors into a double category of categories, which seems to be a version of this (in some sense, this uses the fact that any operad can be upgraded to a symmetric monoidal category). See eg <fr:link href="https://www.youtube.com/watch?v=50s62D5Ah-M&amp;t=2032s&amp;ab_channel=Topos" type="external">this talk</fr:link>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>13</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/left-adjoints-preserve-colimits/</fr:uri>
            <fr:display-uri>left-adjoints-preserve-colimits</fr:display-uri>
            <fr:route>/left-adjoints-preserve-colimits/</fr:route>
            <fr:title text="Left adjoints preserve colimits.">Left adjoints preserve colimits.</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Let's prove a classical theorem (Emily Riehl's <fr:link href="https://kpknudson.com/my-favorite-theorem/2018/5/21/episode-19-emily-riehl" type="external">favorite</fr:link>!) from category theory: Right adjoint functors preserve limits.
So let's assume we have categories <fr:tex display="inline"><![CDATA[C,D]]></fr:tex>, functors <fr:tex display="inline"><![CDATA[F: C \to  D, G: D \to  C]]></fr:tex>, and a natural bijection
<fr:tex display="inline"><![CDATA[C(G(a),b) \cong  D(a,F(b))]]></fr:tex>.
Let's also fix a diagram <fr:tex display="inline"><![CDATA[X: I \to  C]]></fr:tex> from some index category <fr:tex display="inline"><![CDATA[I]]></fr:tex>.
Now recall that a limit of <fr:tex display="inline"><![CDATA[X]]></fr:tex> is an object <fr:tex display="inline"><![CDATA[\lim  X]]></fr:tex>, equipped with maps <fr:tex display="inline"><![CDATA[\pi _i: \lim  X \to  X(i)]]></fr:tex>, so that every triangle
</html:p>
            <html:img src="/bafkrmifc2ik6k2yizgthobiq23qall4iyvgcixncp72y4vboyepsllgudi.png" title="" />
            <html:p>
commutes, and so that, given another set of data <fr:tex display="inline"><![CDATA[(p, f_i: p to X(i))]]></fr:tex> with the same property, there is a unique map <fr:tex display="inline"><![CDATA[f: p \to  \lim  X]]></fr:tex> so that <fr:tex display="inline"><![CDATA[f_i = \pi _if]]></fr:tex>.
</html:p>
            <html:p>
(I am sort of assuming you already know about limits, and just writing the definition above for convenience).
</html:p>
            <html:p>
The proof idea, very weakly formulated, is that the adjunction lets us control maps into <fr:tex display="inline"><![CDATA[F(b)]]></fr:tex>, and the universal property of the limit is precisely about maps into <fr:tex display="inline"><![CDATA[F(\lim  X)]]></fr:tex>.
</html:p>
            <html:p>
Let's first make completely precise the claim: it is that, supposing <fr:tex display="inline"><![CDATA[(\lim  X, \pi _i)]]></fr:tex> forms a limit of <fr:tex display="inline"><![CDATA[X]]></fr:tex>, then also <fr:tex display="inline"><![CDATA[(F(\lim  X), F(\pi _i))]]></fr:tex> forms a limit of <fr:tex display="inline"><![CDATA[F \circ  X]]></fr:tex>. Note that this makes sense - <fr:tex display="inline"><![CDATA[F(\pi _i)]]></fr:tex> really is a map from <fr:tex display="inline"><![CDATA[F(\lim  X)]]></fr:tex> to <fr:tex display="inline"><![CDATA[FX(i)]]></fr:tex>.
</html:p>
            <html:p>
Now let's fix another cone <fr:tex display="inline"><![CDATA[(p,f_i)]]></fr:tex> on <fr:tex display="inline"><![CDATA[(F\lim  X, F(\pi _i))]]></fr:tex>.
We are attempting to construct a map <fr:tex display="inline"><![CDATA[p \to  F(\lim  X)]]></fr:tex>. This is equivalent to a map <fr:tex display="inline"><![CDATA[G(p) \to  \lim  X]]></fr:tex>.
We're going to construct _that_ map by constructing maps <fr:tex display="inline"><![CDATA[G(p) \to  X_i]]></fr:tex>.
Where do we get those maps? We apply the adjunction again - they are simply the mates of the maps <fr:tex display="inline"><![CDATA[p \to  F(X_i)]]></fr:tex> we started with.
Now we need to confirm that the map <fr:tex display="inline"><![CDATA[p \to  F(\lim  X)]]></fr:tex> actually does make the desired triangles commute.
</html:p>
            <html:p>
This follows from naturality of the adjunction, using the same property for <fr:tex display="inline"><![CDATA[G(p) \to  \lim  X]]></fr:tex>:
Consider the composite <fr:tex display="inline"><![CDATA[p \to  F(\lim  X) \to  F(X(i))]]></fr:tex>.
By naturality of the adjunction (with regard to postcomposition), the mate of this map is the composite <fr:tex display="inline"><![CDATA[G(p) \to  \lim  X \to  X(i)]]></fr:tex>.
By construction, this equals the input map <fr:tex display="inline"><![CDATA[G(p) \to  X(i)]]></fr:tex>, which is the mate of the original <fr:tex display="inline"><![CDATA[f_i: p \to  F(X_i)]]></fr:tex>.
Hence the composite has the same mate as <fr:tex display="inline"><![CDATA[f_i]]></fr:tex>, so equals it.
</html:p>
            <html:p>
The second thing we need to prove is that this map is unique with this property.
We can do this by noting that, given two distinct map with this property, their mates <fr:tex display="inline"><![CDATA[G(p) \to  \lim  X]]></fr:tex> are distinct (because the correspondence is bijective), and both have this property (by the same argument used above).
This establishes the claim.
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>11</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/the-homotopy-theory-of-groups/</fr:uri>
            <fr:display-uri>the-homotopy-theory-of-groups</fr:display-uri>
            <fr:route>/the-homotopy-theory-of-groups/</fr:route>
            <fr:title text="The homotopy theory of groups">The homotopy theory of groups</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Context: <fr:link href="https://uni-muenster.sciebo.de/index.php/s/u8SREy5b5QGCGv0/download?path=/Papers&amp;files=Group theory.pdf" type="external">Krause and Nikolaus: Group Theory for Homotopy Theorists</fr:link> (pdf).
Krause and Nikolaus develop group theory using model categories (well, one model category).
This is obviously a joke, but I think it _is_ a very useful pedagogical joke. So I'm going to go through it and try to explain what's happening.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>11</fr:day>
                </fr:date>
                <fr:title text="Group presentations">Group presentations</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  If you've taken a course on group theory, you've probably learned about _presentations_ of a group.
  Here are some examples:
</html:p>
                <html:p>
  -   <fr:tex display="inline"><![CDATA[\langle  s,r | r^4, s^2 srsr \rangle ]]></fr:tex>
  -   <fr:tex display="inline"><![CDATA[\langle  a, b | \rangle ]]></fr:tex>
  -   <fr:tex display="inline"><![CDATA[\langle  a, b | aba^{-1}b^{-1} \rangle ]]></fr:tex>.
</html:p>
                <html:p>
  On the left of the pipe, we have a set <fr:tex display="inline"><![CDATA[S]]></fr:tex> of _generators_.
  On the right of the pipe, we have a different set <fr:tex display="inline"><![CDATA[R]]></fr:tex> of _relations_ - these are "group words" in the generators, i.e words involving both the generators and their inverses.
  The meaning of such a "presentation" is that it describes a group, namely the quotient of the free group on <fr:tex display="inline"><![CDATA[S]]></fr:tex> by the relations.
</html:p>
                <html:p>
  Every group <fr:tex display="inline"><![CDATA[G]]></fr:tex> has a presentation (in fact, many), for example given by taking <fr:tex display="inline"><![CDATA[S = G]]></fr:tex> and <fr:tex display="inline"><![CDATA[R]]></fr:tex> given by all words which evaluate to <fr:tex display="inline"><![CDATA[1]]></fr:tex> in <fr:tex display="inline"><![CDATA[G]]></fr:tex>. This leads to the idea that one could _define_ group theory out of presentations. This seems to work out well - in fact, given <fr:tex display="inline"><![CDATA[G,H]]></fr:tex> groups, if we take their "canonical" presentations as above, a group homomorphism <fr:tex display="inline"><![CDATA[G \to  H]]></fr:tex> is exactly the same thing as a function <fr:tex display="inline"><![CDATA[G \to  H]]></fr:tex> which takes those words in <fr:tex display="inline"><![CDATA[G]]></fr:tex> which evaluate to <fr:tex display="inline"><![CDATA[1]]></fr:tex> to words in <fr:tex display="inline"><![CDATA[H]]></fr:tex> which evaluate to <fr:tex display="inline"><![CDATA[1]]></fr:tex>.
</html:p>
                <html:p>
  However, this doesn't work in general - most group presentations don't have "enough generators" to represent all group homomorphisms into the presented group. And there are many maps which "should" be group isomorphisms which don't have an inverse on the level of presentations.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>11</fr:day>
                </fr:date>
                <fr:title text="Model categories">Model categories</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The basic things you can do in a model category are:
</html:p>
                <html:p>
  -   Invert certain maps that "should" be isomorphisms (or "equivalences")
  -   Replace an object with a "better behaved" one which is "equivalent" in that sense.
</html:p>
                <html:p>
  Let's take a more classical example from "real" homotopy theory: Simplicial sets.
  In this context, we think of a simplicial set <fr:tex display="inline"><![CDATA[X]]></fr:tex> as a "model" for a topological space, its geometric realization <fr:tex display="inline"><![CDATA[|X|]]></fr:tex>.
  A map <fr:tex display="inline"><![CDATA[X \to  Y]]></fr:tex> is a simplicial homotopy equivalence if the map of spaces <fr:tex display="inline"><![CDATA[|X| \to  |Y|]]></fr:tex> is a homotopy equivalence of spaces.
  However, in many cases, such an equivalence can't be inverted, even up to (simplicial) homotopy.
  Similarly, there are often maps between geometric realizations which can't be represented by maps between the simplicial sets, even up to homotopy.
</html:p>
                <html:p>
  The basic solution to this is to work with certain nice simplicial sets called _Kan complexes_. A Kan complex has "enough simplexes" so that all the maps between them that "should" exist, do.
  Now we _could_ simply work with the category of Kan complexes - but this is an inconvenient category. Its main deficiency is probably that it does not have all colimits. This is compared to the full category of simplicial sets, which is as nice as they come.
</html:p>
                <html:p>
  So we use a powerful piece of technology called a _model structure_, making simplicial sets into a model category.
  (This is usually called the Kan model structure, or the Kan-Quillen model structure).
</html:p>
                <html:p>
  The upshot of this is that every simplicial set is homotopy equivalent to a Kan complex, in a very structured way which lets you use the technically convenient structure of the whole category of simplicial sets to describe "the homotopy theory of Kan complexes".
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>11</fr:day>
                </fr:date>
                <fr:title text="Back to groups">Back to groups</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Now we are going to try to adapt the above to groups.
</html:p>
                <html:p>
  The way to do this is to describe the _trivial cofibrations_ - essentially, these will be those maps which are "morally group isomorphisms".
</html:p>
                <html:p>
  Using the machinery of model categories, we can get away with specifying only a small "generating family".
  These are on page 2 of the paper.
</html:p>
                <html:p>
  Now here's a fun fact: this small list pins down exactly the "proper" presentations of groups, in this sense:
</html:p>
                <html:p>
  **Theorem**: The following two are equivalent for a presentation <fr:tex display="inline"><![CDATA[\langle  S \mid  R \rangle ]]></fr:tex></html:p>
                <html:p>
  -   The map <fr:tex display="inline"><![CDATA[S \to  F(S)/R]]></fr:tex> is bijective, and <fr:tex display="inline"><![CDATA[R]]></fr:tex> contains every word which is zero in <fr:tex display="inline"><![CDATA[F(S)/R]]></fr:tex>.
  -   For every diagram
</html:p>
                <html:img src="/bafkrmic5qkhuiaveuvhzsl3s7dgvlbxfjovurscmte4xi3qdv7pzxd5xyy.png" title="" />
                <html:p>
  if <fr:tex display="inline"><![CDATA[f]]></fr:tex> is in the generating list, there exists an extension like the dashed arrow making the triangle commute.
</html:p>
                <html:p>
  **Proof**:
  First, it's easy to check for each type of generating arrow that this holds:
</html:p>
                <html:p>
  -   <fr:tex display="inline"><![CDATA[a]]></fr:tex> and <fr:tex display="inline"><![CDATA[b]]></fr:tex> must be sent to the same element (by injectivity), so we can simply send <fr:tex display="inline"><![CDATA[c]]></fr:tex> there as well.
  -   We can extend the map by sending <fr:tex display="inline"><![CDATA[a]]></fr:tex> to whatever element <fr:tex display="inline"><![CDATA[w^{-1}]]></fr:tex> evaluates to.
  -   The remaining three maps simply add relations which are derivable from the existing ones - hence their images must already be in <fr:tex display="inline"><![CDATA[R]]></fr:tex>.
</html:p>
                <html:p>
  Now for the other direction, suppose <fr:tex display="inline"><![CDATA[a,b \in  S]]></fr:tex> go to the same element in <fr:tex display="inline"><![CDATA[F(S)/R]]></fr:tex>.
  Then the map <fr:tex display="inline"><![CDATA[\langle  a,b \mid  ab^{-1} \rangle  \to  \langle  S \mid  R \rangle ]]></fr:tex> does not have an extension over the first generating map.
  Hence that map is injective.
  Suppose <fr:tex display="inline"><![CDATA[w \in  F(S)/R]]></fr:tex> is not in <fr:tex display="inline"><![CDATA[S]]></fr:tex>.
  Then the map <fr:tex display="inline"><![CDATA[\langle  S \mid  \emptyset  \rangle  \to  \langle  S \mid  R \rangle ]]></fr:tex> does not extend over <fr:tex display="inline"><![CDATA[\langle  S \sqcup  \{a\} \mid  a w^{-1} \rangle ]]></fr:tex> - there is nowhere to send <fr:tex display="inline"><![CDATA[a]]></fr:tex> (since it must be sent to something that goes to <fr:tex display="inline"><![CDATA[w]]></fr:tex>, for the property to hold).
  The statement that <fr:tex display="inline"><![CDATA[R]]></fr:tex> contains every word that goes to zero means that <fr:tex display="inline"><![CDATA[R]]></fr:tex> is stable under certain operations, which can similarly be proved from the morphisms.
</html:p>
                <html:p>
  It follows from the general theory of model categories that there always exists a map <fr:tex display="inline"><![CDATA[\langle  S \mid  R \rangle  \to  P]]></fr:tex> into a "nice" (in technical terms, fibrant) presentation, which is itself a trivial cofibration.
  Understanding what the trivial cofibrations are in technical terms is more complicated - an argument going in the other direction from the one above will show that they are exactly those which correspond to group isomorphisms, but this might be a bit tricky.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>9</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/category-of-computable-categories-with-runtime/</fr:uri>
            <fr:display-uri>category-of-computable-categories-with-runtime</fr:display-uri>
            <fr:route>/category-of-computable-categories-with-runtime/</fr:route>
            <fr:title text="A category of computable functions with runtime">A category of computable functions with runtime</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
See: <fr:link href="https://golem.ph.utexas.edu/category/2019/08/turing_categories.html" type="external">Giorgios Bakirtzis and Christian Williams: Turing Categories</fr:link>.
Turing Categories describe _computability_.
I want to find a category to work with _complexity_ instead.
This is a stab at it.
Fix a universal Turing machine and an encoding of the natural numbers.
Of course, this lets us speak of _computable_ functions <fr:tex display="inline"><![CDATA[\mathbb {N} \to  \mathbb {N}]]></fr:tex> (and these don't depend on the choice of Turing machine).
But fixing a specific machine also lets us speak of the _runtime_, in steps, of a program <fr:tex display="inline"><![CDATA[p]]></fr:tex> with input <fr:tex display="inline"><![CDATA[n \in  \mathbb {N}]]></fr:tex>.
Write <fr:tex display="inline"><![CDATA[p(n) = m]]></fr:tex> if <fr:tex display="inline"><![CDATA[p(n)]]></fr:tex> eventually terminates with output <fr:tex display="inline"><![CDATA[m]]></fr:tex>, and write <fr:tex display="inline"><![CDATA[T(p,n) = t]]></fr:tex> if it takes <fr:tex display="inline"><![CDATA[t]]></fr:tex> steps.
</html:p>
            <html:p>
Now we want to define a category as follows:
</html:p>
            <html:ul><html:li>The objects are subsets of the natural numbers.</html:li>
  <html:li>The maps <fr:tex display="inline"><![CDATA[A \to  B]]></fr:tex> are equivalence classes of programs under an "asymptotic equivalence" relation.</html:li>
  <html:li>The composition is "the obvious thing".</html:li>
<html:p /></html:ul>
            <html:p>
What I mean by asymptotic equivalence is this: the two programs halt on the same inputs, produce the same outputs, and run in the same amount of time up to a constant factor.
To be more precise, <fr:tex display="inline"><![CDATA[p \lesssim  p' : A \to  B]]></fr:tex> if there exists a constant <fr:tex display="inline"><![CDATA[C]]></fr:tex> so that, when <fr:tex display="inline"><![CDATA[p(n) = m]]></fr:tex> and <fr:tex display="inline"><![CDATA[T(p,n) = t]]></fr:tex>,
<fr:tex display="inline"><![CDATA[p'(n) = m]]></fr:tex> and <fr:tex display="inline"><![CDATA[T(p,n) \leq  Ct]]></fr:tex>.
Then <fr:tex display="inline"><![CDATA[p \sim  p']]></fr:tex> if <fr:tex display="inline"><![CDATA[p \lesssim  p']]></fr:tex> and <fr:tex display="inline"><![CDATA[p' \lesssim  p]]></fr:tex>.
</html:p>
            <html:p>
This corresponds to our natural definition of "same behaviour, and same <fr:tex display="inline"><![CDATA[O]]></fr:tex>-class".
</html:p>
            <html:p>
Now, we want to construct the composition <fr:tex display="inline"><![CDATA[pp']]></fr:tex> simply to have <fr:tex display="inline"><![CDATA[pp'(n) = p(p'(n))]]></fr:tex> and <fr:tex display="inline"><![CDATA[T(pp',n) = T(p',n) + T(p,p'(n))]]></fr:tex>.
(This means that if <fr:tex display="inline"><![CDATA[p'(n)]]></fr:tex> halts with output <fr:tex display="inline"><![CDATA[m]]></fr:tex>, and <fr:tex display="inline"><![CDATA[p(m)]]></fr:tex> halts with output <fr:tex display="inline"><![CDATA[k]]></fr:tex>, then <fr:tex display="inline"><![CDATA[pp'(n)]]></fr:tex> halts with output <fr:tex display="inline"><![CDATA[k]]></fr:tex>, and has the runtime described above, otherwise it doesn't halt).
It's not completely trivial that this is possible - essentially, the "overhead of composition" must be smaller than the runtime of the larger of <fr:tex display="inline"><![CDATA[p]]></fr:tex> and <fr:tex display="inline"><![CDATA[p']]></fr:tex>.
We must add this as a requirement to our Turing machine - luckily, this seems to be satisfied by most sane models of computation.
</html:p>
            <html:p>
Call the category so defined <fr:tex display="inline"><![CDATA[\mathrm {Comp}]]></fr:tex>.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Comp as a restriction category">Comp as a restriction category</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Given a program <fr:tex display="inline"><![CDATA[p: A \to  B]]></fr:tex>, we can define <fr:tex display="inline"><![CDATA[\bar {p}: A \to  A]]></fr:tex> as follows: to compute <fr:tex display="inline"><![CDATA[\bar {p}(n)]]></fr:tex>, run <fr:tex display="inline"><![CDATA[p(n)]]></fr:tex> until completion, then return <fr:tex display="inline"><![CDATA[n]]></fr:tex> no matter what.
</html:p>
                <html:p>
  Certainly any universal Turing machine admits this construction. Does this define a restriction category?
  Recall the axioms of a restriction category:
</html:p>
                <html:p>
  1.  <fr:tex display="inline"><![CDATA[f\bar {f} = f]]></fr:tex>
  2.  <fr:tex display="inline"><![CDATA[\bar {f}\bar {g} = \bar {g}\bar {f}]]></fr:tex>
  3.  <fr:tex display="inline"><![CDATA[\overline {g\bar {f}} = \bar {g}\bar {f}]]></fr:tex>
  4.  <fr:tex display="inline"><![CDATA[\bar {g}f = f\overline {gf}]]></fr:tex></html:p>
                <html:p>
  (If these compositions are well-defined).
</html:p>
                <html:p>
  1.  Clearly <fr:tex display="inline"><![CDATA[f\bar {f}]]></fr:tex> has the same values as <fr:tex display="inline"><![CDATA[f]]></fr:tex>.
      It runs in almost exactly twice the runtime of <fr:tex display="inline"><![CDATA[f]]></fr:tex>, plus whatever the overhead of composition and the <fr:tex display="inline"><![CDATA[\bar {(-)}]]></fr:tex> construction is.
      It is not actually completely obvious that this is small enough for _every_ universal Turing machine.
      Nevertheless, the assumption that <fr:tex display="inline"><![CDATA[T(\bar {p},n) \leq  T(p,n) + C]]></fr:tex> for some constant <fr:tex display="inline"><![CDATA[C]]></fr:tex> seems rather harmless, which suffices here.
  2.  <fr:tex display="inline"><![CDATA[\bar {f}\bar {g}]]></fr:tex> and <fr:tex display="inline"><![CDATA[\bar {g}\bar {f}]]></fr:tex>, again, clearly have the same values. With the assumption from above, the runtime is also asymptotically the same.
  3.  Once again it's easy to see that the two maps have the same values.
      The first one runs in <fr:tex display="inline"><![CDATA[T(g,n) + T(f,n) + 2C]]></fr:tex>, and so does the second one, hence they have the same (asymptotically) runtime.
  4.  Here the claim about equivalent runtimes is a bit more subtle.
      The first one takes <fr:tex display="inline"><![CDATA[T(f,n) + T(g,f(n))]]></fr:tex> time (up to asymptotic equivalence).
      The second one takes <fr:tex display="inline"><![CDATA[T(f,n) + T(g,f(n)) + T(f,n)]]></fr:tex>.
      But these two are equivalent - the second is at most twice the first.
</html:p>
                <html:p>
  Hence <fr:tex display="inline"><![CDATA[\mathsf {Comp}]]></fr:tex> is a restriction category.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Comp as a Cartesian restriction category.">Comp as a Cartesian restriction category.</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Do "restriction products" exist in <fr:tex display="inline"><![CDATA[\mathsf {Comp}]]></fr:tex>.
  This would seem to rely on a _constant-time_ bijection <fr:tex display="inline"><![CDATA[\mathbb {N} \cong  \mathbb {N} \times  \mathbb {N}]]></fr:tex>.
  I am fairly sure this doesn't exist - since the encoding size of a natural number grows as the logarithm, it would seem that such a bijection must have unbounded runtime.
</html:p>
                <html:p>
  This may be remedied by passing to a less restrictive form of equivalence.
  For example, suppose we can find a logarithmic-time implementation of the above bijection.
  Then we can alter the definition of <fr:tex display="inline"><![CDATA[\lesssim ]]></fr:tex> so that <fr:tex display="inline"><![CDATA[p \lesssim  p']]></fr:tex> as long as there exists <fr:tex display="inline"><![CDATA[C]]></fr:tex> so that <fr:tex display="inline"><![CDATA[T(p',n) \leq  CT(p,n)\log (n)]]></fr:tex> (and they have the same values).
  There are other reasons to prefer this equivalence relation.
  It is not in general true that universal Turing machines can simulate each other with _constant_ overhead.
  This means that the choice of UTM made at the beginning of this post is actually significant.
  But it _is_ true that they can simulate each other with _logarithmic_ overhead.&amp;nbsp;[^fn:1]
  This means the choice of machine is unimportant, making for a much nicer theory.
</html:p>
                <html:p>
  The construction of this correspondence does seem to be the only obstruction to equipping <fr:tex display="inline"><![CDATA[\mathsf {Comp}]]></fr:tex> with a Cartesian restriction structure, in the "obvious" way (where <fr:tex display="inline"><![CDATA[A \times  B]]></fr:tex> is the subset of <fr:tex display="inline"><![CDATA[\mathbb {N}]]></fr:tex> which corresponds under this bijection to a pair <fr:tex display="inline"><![CDATA[(a\in  A, b \in  B)]]></fr:tex>.)
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Comp as a traced category">Comp as a traced category</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Can we define a trace operation on <fr:tex display="inline"><![CDATA[\mathsf {Comp}]]></fr:tex>?
  This would be an operation <fr:tex display="inline"><![CDATA[Tr^X_{A,B}: Hom(A \times  X \to  B \times  X) \to  Hom(A,B)]]></fr:tex>.
  The idea would be that to evaluate <fr:tex display="inline"><![CDATA[Tr^X_{A,B}(f)]]></fr:tex> on <fr:tex display="inline"><![CDATA[a \in  A]]></fr:tex>, you run <fr:tex display="inline"><![CDATA[f(a,0)]]></fr:tex> to obtain <fr:tex display="inline"><![CDATA[b_1, x_1]]></fr:tex>, then run <fr:tex display="inline"><![CDATA[f(a,x_1)]]></fr:tex> to obtain <fr:tex display="inline"><![CDATA[b_2,x_2]]></fr:tex> and you keep doing this until you find a fixpoint where <fr:tex display="inline"><![CDATA[x_n = x_{n+1}]]></fr:tex> then the resulting <fr:tex display="inline"><![CDATA[b_{n+1}]]></fr:tex> is your output.
  (If this never terminates, you simply don't halt on that input).
</html:p>
                <html:p>
  The obvious problem is that the choice of <fr:tex display="inline"><![CDATA[0]]></fr:tex> is non-canonical.
  We might want to let <fr:tex display="inline"><![CDATA[Tr^X_{A,B}]]></fr:tex> only be defined when this input doesn't matter - but this property is not obviously computable! (We would have to check every possible <fr:tex display="inline"><![CDATA[n]]></fr:tex>).
  This probably precludes <fr:tex display="inline"><![CDATA[Tr^X_{A,B}]]></fr:tex> from satisfying the axioms of a trace. I'm not sure, but I think the issue will appear in the axiom <fr:tex display="inline"><![CDATA[Tr^X_{A,B}Tr^Y_{A\otimes  X, B \otimes  X}(f) = Tr^{X\otimes  Y}_{A,B}(f)]]></fr:tex>.
  The right-hand side corresponds to applying <fr:tex display="inline"><![CDATA[f(a,0,0)]]></fr:tex>,
  then <fr:tex display="inline"><![CDATA[f(a,x_1,y_1)]]></fr:tex>, then proceeding like that until we find a fixpoint <fr:tex display="inline"><![CDATA[(x_n,y_n)]]></fr:tex>.
  In the second, we first define a function <fr:tex display="inline"><![CDATA[f(a,x)]]></fr:tex> by applying <fr:tex display="inline"><![CDATA[f(a,x,0)]]></fr:tex> to find <fr:tex display="inline"><![CDATA[y_1]]></fr:tex>, then going until we find a fixpoint <fr:tex display="inline"><![CDATA[y_n]]></fr:tex>.
  Then we apply _the function to defined_, call it <fr:tex display="inline"><![CDATA[f']]></fr:tex>, with <fr:tex display="inline"><![CDATA[f'(a,0)]]></fr:tex> to find <fr:tex display="inline"><![CDATA[x_1]]></fr:tex>, and so on.
  In other words, we first find a fixpoint <fr:tex display="inline"><![CDATA[y]]></fr:tex> for <fr:tex display="inline"><![CDATA[f(a,0,y)]]></fr:tex>, and use that fixpoint to produce <fr:tex display="inline"><![CDATA[x_1]]></fr:tex>.
  Then we find a fixpoint for <fr:tex display="inline"><![CDATA[f(a,x_1,y)]]></fr:tex> and so produce <fr:tex display="inline"><![CDATA[y_2]]></fr:tex>, and so on.
  This does eventually produce a pair <fr:tex display="inline"><![CDATA[(x,y)]]></fr:tex> which form a fixpoint for <fr:tex display="inline"><![CDATA[f(a,x,y)]]></fr:tex>, but not necessarily the same one as the "simultaneous" procedure.
  This problem is exactly fixed if we only allow those <fr:tex display="inline"><![CDATA[a]]></fr:tex>s where the starting input doesn't matter - then there is a unique fixpoint, and we are happy.
</html:p>
                <html:p>
  The second problem, of course, is that the two procedures defined above have _very different runtimes_.
  This problem does seem to be baked into the axioms of a traced monoidal category.
  This is perhaps not surprising - these axioms are not saying that both sides are equally fast ways of computing the result, just that the results are equal.
  So perhaps we should look for some alternative "complexity-sensitive" version of these axioms that make sense in our context.
</html:p>
                <html:p>
  On the other hand, the temptation to regard a string diagram with loops as describing a meaningful program is very strong. This would suggest that we need a different version of <fr:tex display="inline"><![CDATA[\mathsf {Comp}]]></fr:tex>, or perhaps a different traced structure, that makes the two sides of the equation equal.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Comp as a Turing category">Comp as a Turing category</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Comp is, first of all, not a Turing category, because undecidable subsets of the natural numbers won't be retracts of them.
  If we fiddle with the definition to fix this issue (we can remove all other objects than <fr:tex display="inline"><![CDATA[\mathbb {N}]]></fr:tex> and <fr:tex display="inline"><![CDATA[\{1\}]]></fr:tex>, for example), it might actually be a Turing category - because of the fact that universal Turing machines can simulate each other with logarithmic overhead.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>9</fr:day>
                </fr:date>
                <fr:title text="Further questions">Further questions</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  -   What is the general definition of which <fr:tex display="inline"><![CDATA[\mathsf {Comp}]]></fr:tex> is an example?
  -   Does this actually help at all?
  -   Is there a (family of) model(s) of computation which allows us to A: make a category with useful internal structure, B: without fiddling with various notions of asymptotic performance.
</html:p>
                <html:p>
  [^fn:1]: See eg <fr:link href="https://en.wikipedia.org/wiki/Universal_Turing_machine#Efficiency" type="external">Wikipedia</fr:link></html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>4</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/localizations-categories-dynamical-systems/</fr:uri>
            <fr:display-uri>localizations-categories-dynamical-systems</fr:display-uri>
            <fr:route>/localizations-categories-dynamical-systems/</fr:route>
            <fr:title text="Localizations of categories of dynamical systems">Localizations of categories of dynamical systems</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
See also: <fr:link href="https://jadeedenstarmaster.wordpress.com/2019/03/31/dynamical-systems-with-category-theory-yes/" type="external">Jade Master: Dynamical Systems With Category Theory? Yes!</fr:link>, <fr:link href="https://twitter.com/AyeGill/status/1294229765365391360" type="external">This tweet by me</fr:link>.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>4</fr:day>
                </fr:date>
                <fr:title text="Discrete dynamical systems">Discrete dynamical systems</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  A discrete dynamical system <fr:tex display="inline"><![CDATA[(S,T)]]></fr:tex> consists of a set <fr:tex display="inline"><![CDATA[S]]></fr:tex> and a time-step function <fr:tex display="inline"><![CDATA[T: S \to  S]]></fr:tex>.
  It's clear that this is exactly the same thing as a <fr:tex display="inline"><![CDATA[\mathbb {N}]]></fr:tex>-set, i.e a set with an action of the monoid <fr:tex display="inline"><![CDATA[(\mathbb {N},+,0)]]></fr:tex>[^fn:1].
  A "morphism of discrete dynamical systems" is just the obvious thing, namely a map which preserves the action - an equivariant map.
</html:p>
                <html:p>
  For now, we will restrict ourselves to those dynamical systems with "time-reversible dynamics" - that is, those where the action <fr:tex display="inline"><![CDATA[T: S \to  S]]></fr:tex> is a bijection.
  The subcategory of such things inside <fr:tex display="inline"><![CDATA[\mathbb {N}-\mathsf {Set}]]></fr:tex> is equivalent to <fr:tex display="inline"><![CDATA[\mathbb {Z}-\mathsf {Set}]]></fr:tex> - a dynamical system is time-reversible if and only if the action of <fr:tex display="inline"><![CDATA[\mathbb {N}]]></fr:tex> extends to an action of <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex>.
</html:p>
                <html:p>
  Now, we will be interested in _localizations_ of the category <fr:tex display="inline"><![CDATA[\mathbb {Z}-\mathsf {Set}]]></fr:tex>.
  One important family of such localizations comes from the group homomorphisms <fr:tex display="inline"><![CDATA[\mathbb {Z} \to  \mathbb {Z}/n]]></fr:tex>.
</html:p>
                <html:p>
  This homomorphism gives a functor <fr:tex display="inline"><![CDATA[\mathbb {Z}/n-\mathsf {Set} \hookrightarrow  \mathbb {Z}-\mathsf {Set}]]></fr:tex>.
  In fact, this functor is fully faithful, and its image is exactly the subcategory of <fr:tex display="inline"><![CDATA[n]]></fr:tex>-periodic dynamical systems - i.e those for which <fr:tex display="inline"><![CDATA[T^n(x) = x]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x \in  S]]></fr:tex>.
  Moreover, this functor admits a left adjoint <fr:tex display="inline"><![CDATA[L_n]]></fr:tex>.
  It takes a dynamical system <fr:tex display="inline"><![CDATA[(S,T)]]></fr:tex> to <fr:tex display="inline"><![CDATA[(S/\sim , \bar {T})]]></fr:tex>, where <fr:tex display="inline"><![CDATA[\sim ]]></fr:tex> is the equivalence relation generated by <fr:tex display="inline"><![CDATA[x \sim  T^nx]]></fr:tex> and <fr:tex display="inline"><![CDATA[\bar {T}]]></fr:tex> is the induced map.
</html:p>
                <html:p>
  The order structure of this family of localizations is exactly the division order.
  By which I simply mean, if <fr:tex display="inline"><![CDATA[n | m]]></fr:tex>, then an <fr:tex display="inline"><![CDATA[n]]></fr:tex>-periodic dynamical system is also <fr:tex display="inline"><![CDATA[m]]></fr:tex>-periodic, and if every <fr:tex display="inline"><![CDATA[n]]></fr:tex>-periodic dynamical system is <fr:tex display="inline"><![CDATA[m]]></fr:tex>-periodic, then <fr:tex display="inline"><![CDATA[n|m]]></fr:tex> (proof of the second implication: consider the dynamical systen <fr:tex display="inline"><![CDATA[(\mathbb {Z}/m, +1)]]></fr:tex>).
</html:p>
                <html:p>
  Using these, we can form a sort of "<fr:tex display="inline"><![CDATA[p]]></fr:tex>-adic completion" of any dynamical system, as the limit
  <fr:tex display="inline"><![CDATA[\lim _n L_{p^n} S =: S^{\wedge }_p]]></fr:tex>. The functor <fr:tex display="inline"><![CDATA[(-)^\wedge _p]]></fr:tex> is a localization.
  The <fr:tex display="inline"><![CDATA[p]]></fr:tex>-adic completion of the integers with translation action is exactly the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-adic integers (with translation action).
  Since each system <fr:tex display="inline"><![CDATA[S/p^n]]></fr:tex> acquires a canonical action of <fr:tex display="inline"><![CDATA[\mathbb {Z}/p]]></fr:tex>, it would seem that probably <fr:tex display="inline"><![CDATA[S^\wedge _p]]></fr:tex> acquires an action of the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-adics <fr:tex display="inline"><![CDATA[\mathbb {Z}^\wedge _p]]></fr:tex>.
</html:p>
                <html:p>
  However, to make sense of this, it's probably best to work in a category of topological spaces with continuous group actions.
  I would guess that the <fr:tex display="inline"><![CDATA[\mathbb {Z}/p]]></fr:tex> actions assemble to a unique _continuous_ <fr:tex display="inline"><![CDATA[\mathbb {Z}_p^\wedge ]]></fr:tex> action, although I have not checked it.
</html:p>
                <html:p>
  The family of localizations <fr:tex display="inline"><![CDATA[(-)^\wedge _p]]></fr:tex> is jointly conservative on _finite_ dynamical systems (since each orbit is an <fr:tex display="inline"><![CDATA[n]]></fr:tex>-period for some <fr:tex display="inline"><![CDATA[n]]></fr:tex>). However this fails in a predictable way in the infinite case, where we can't distinguish between <fr:tex display="inline"><![CDATA[(\mathbb {Z},+)]]></fr:tex> and <fr:tex display="inline"><![CDATA[(\hat {\mathbb {Z}},+)]]></fr:tex>. To remedy this, one would need some sort of "rationalization" of dynamical systems.
  However, there we run into the issue that the functor <fr:tex display="inline"><![CDATA[\mathbb {Q}-\mathsf {Set} \to  \mathbb {Z}\mathsf {Set}]]></fr:tex> is not fully faithful - a <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex> set has a chosen "half action", the action of <fr:tex display="inline"><![CDATA[1/2]]></fr:tex> on <fr:tex display="inline"><![CDATA[S]]></fr:tex>, but this action is not necessarily uniquely determined by the action of <fr:tex display="inline"><![CDATA[1]]></fr:tex>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>4</fr:day>
                </fr:date>
                <fr:title text="Smooth dynamical systems">Smooth dynamical systems</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We take a somewhat unorthodox approach and let a _smooth dynamical system_ be a smooth manifold <fr:tex display="inline"><![CDATA[M]]></fr:tex> with an action of the Lie group <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex>. (Again, we are looking at time-reversible systems).
  Given a discrete subgroup of <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex>, the quotient <fr:tex display="inline"><![CDATA[\mathbb {R}/H]]></fr:tex> is again a Lie group,
  and we obtain a fully faithful inclusion <fr:tex display="inline"><![CDATA[\mathbb {R}/H-\mathsf {Mdf} \hookrightarrow  \mathbb {R}-\mathsf {Mdf}]]></fr:tex>.
</html:p>
                <html:p>
  The discrete subgroups of <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex> all have the form <fr:tex display="inline"><![CDATA[\lambda \mathbb {Z}]]></fr:tex> for some <fr:tex display="inline"><![CDATA[\lambda ]]></fr:tex>, and the quotient is always diffeomorphic to <fr:tex display="inline"><![CDATA[S^1]]></fr:tex>.
  As above, passing to this quotient corresponds to considering <fr:tex display="inline"><![CDATA[&lambda;]]></fr:tex>-periodic systems.
</html:p>
                <html:p>
  In this situation, there no longer exists a left adjoint, for annoying reasons.
  The universal property of the left adjoint, if written out, tells us it should take a manifold <fr:tex display="inline"><![CDATA[M]]></fr:tex> to the quotient <fr:tex display="inline"><![CDATA[M/(\lambda \mathbb {Z})]]></fr:tex> of the action by <fr:tex display="inline"><![CDATA[\lambda \mathbb {Z}]]></fr:tex>.
  Consider the normal additive action of <fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex> on <fr:tex display="inline"><![CDATA[S^1 = \mathbb {R}/\mathbb {Z}]]></fr:tex>.
  If we take <fr:tex display="inline"><![CDATA[\lambda ]]></fr:tex> to be an irrational number, the orbits of the action are dense in <fr:tex display="inline"><![CDATA[S^1]]></fr:tex>,
  and the quotient is not even a topological manifold.
</html:p>
                <html:p>
  One would hope this problem can be solved by something like "derived manifolds", but I haven't looked into that yet.
</html:p>
                <html:p>
  [^fn:1]: My natural numbers include 0
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>10</fr:month>
              <fr:day>2</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/cheap-nonstandard-analysis/</fr:uri>
            <fr:display-uri>cheap-nonstandard-analysis</fr:display-uri>
            <fr:route>/cheap-nonstandard-analysis/</fr:route>
            <fr:title text="Cheap nonstandard analysis">Cheap nonstandard analysis</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Terry Tao: <fr:link href="https://terrytao.wordpress.com/2012/04/02/a-cheap-version-of-nonstandard-analysis/" type="external">A cheap version of nonstandard analysis</fr:link>.
MathOverflow: <fr:link href="https://math.stackexchange.com/questions/454393/does-cheap-nonstandard-analysis-take-place-in-a-topos/" type="external">Does Cheap Nonstandard analysis take place in a topos?</fr:link>
(Answer: Yes, but an elementary topos, not a Grothendieck topos).
</html:p>
            <html:p>
This is partially a summary of Tao's blog post, partially a small discussion of way LEM fails for cheap nonstandard reals.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>2</fr:day>
                </fr:date>
                <fr:title text="What is &quot;nonstandard analysis&quot;?">What is "nonstandard analysis"?</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  In "normal" nonstandard analysis, we consruct the "nonstandard reals" <fr:tex display="inline"><![CDATA[\mathbb {R}^*]]></fr:tex> as an ultrapowwer of the ordinary reals with regards to some nonprincipial ultrafilter <fr:tex display="inline"><![CDATA[\mathfrak {u}]]></fr:tex>.
  This means that a nonstandard real is a sequence <fr:tex display="inline"><![CDATA[(x_n)]]></fr:tex> of reals, quotiented by the equivalence relation which identifies two sequences if the set of naturals where they agree is in the ultrafilter - in symbols, <fr:tex display="inline"><![CDATA[\{n | x_n = y_n\} \in  \mathfrak {u}]]></fr:tex></html:p>
                <html:p>
  This set inherits all the structure of the reals - where addition and multiplication is pointwise, and <fr:tex display="inline"><![CDATA[(x_n) \leq  (y_n)]]></fr:tex> if <fr:tex display="inline"><![CDATA[\{n | x_n \leq  y_n\} \in  \mathfrak {u}]]></fr:tex>. In fact, it is even a totally ordered field, since first-order properties pass to ultrapowers by <fr:link href="https://en.wikipedia.org/wiki/Ultraproduct#Łoś's_theorem" type="external">Łoś's Theorem</fr:link>.
  It also contains a copy of the real numbers, where <fr:tex display="inline"><![CDATA[x \in  \mathbb {R}]]></fr:tex> is identified with a constant sequence. We call these the _standard reals_.
</html:p>
                <html:p>
  (<fr:tex display="inline"><![CDATA[\mathbb {R}^*]]></fr:tex> is not complete, since this is a second-order property.)
</html:p>
                <html:p><fr:tex display="inline"><![CDATA[\mathbb {R}]]></fr:tex> contains "infinitesimals", like the sequence <fr:tex display="inline"><![CDATA[(1/n)]]></fr:tex> - this is a positive nonstandard real number, but less than every positive standard real number. Call this number <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex>.
</html:p>
                <html:p>
  It also contains "infinite numbers", like the sequence <fr:tex display="inline"><![CDATA[(n)]]></fr:tex> - this is a nonstandard real wich is larger than every standard real.
</html:p>
                <html:p>
  Given a function <fr:tex display="inline"><![CDATA[f: \mathbb {R}^* \to  \mathbb {R}^*]]></fr:tex>, we can ask for the value <fr:tex display="inline"><![CDATA[\frac {f(x + \epsilon ) - f(x)}{\epsilon }]]></fr:tex>.
  This is a well-defined nonstandard real, since <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex> is not zero.
  In fact, it is the nonstandard real <fr:tex display="inline"><![CDATA[\left (\frac {f(x + 1/n) - f(x)}{1/n}\right )]]></fr:tex>.
  If <fr:tex display="inline"><![CDATA[f]]></fr:tex> comes from a function <fr:tex display="inline"><![CDATA[\mathbb {R} \to  \mathbb {R}]]></fr:tex> which is differentiable, this sequence converges to <fr:tex display="inline"><![CDATA[f'(x)]]></fr:tex>.
  This means that the difference between the nonstandard derivative and the normal derivative is an infinitesimal, in the sense that it is smaller than every positive and larger than every negative standard real.
  One can show that <fr:tex display="inline"><![CDATA[f'(x)]]></fr:tex> is the only standard real with this property - so this gives a definition of the derivative (which does not depend on the choice of <fr:tex display="inline"><![CDATA[\epsilon ]]></fr:tex>).
</html:p>
                <html:p>
  Nonstandard analysis takes this idea and runs with it to develop various parts of analysis using these infinitesimals.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>10</fr:month>
                  <fr:day>2</fr:day>
                </fr:date>
                <fr:title text="Cheap nonstandard analysis">Cheap nonstandard analysis</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  There are a few problems with this:
</html:p>
                <html:p>
  -   The existence of a non-principal ultrafilter on <fr:tex display="inline"><![CDATA[\mathbb {N}]]></fr:tex> requires some "unfortunate" axiom like the axiom of choice or somesuch. (The existence of non-principal ultrafilters on all infinite sets is called the <fr:link href="https://ncatlab.org/nlab/show/ultrafilter+theorem" type="external">ultrafilter theorem</fr:link>, and is strictly weaker than the axiom of choice, but still considered a bit suspicious - for instance it implies the existence of nonmeasurable sets).
  -   According to Tao, it's sometimes difficult to extract a quantitative bound from an asymptotic theorem proved with nonstandard analysis - he links this to the first point.
</html:p>
                <html:p>
  However, these difficulties disappear if we instead use the Frechet filter, consisting of all cofinite sets, on <fr:tex display="inline"><![CDATA[\mathbb {N}]]></fr:tex>.
  In other words, a cheap nonstandard real is a sequence <fr:tex display="inline"><![CDATA[(x_n)]]></fr:tex> of reals, quotiented by the equivalence relation that <fr:tex display="inline"><![CDATA[(x_n) = (y_n)]]></fr:tex> if <fr:tex display="inline"><![CDATA[x_n = y_n]]></fr:tex> for <fr:tex display="inline"><![CDATA[n]]></fr:tex> sufficiently big.
  Note that the Frechet filter is not an ultrafilter!
  Hence Łós' theorem does not hold, so the cheap nonstandard reals fail to inherit all the good properties of the ordinary reals.
</html:p>
                <html:p>
  The easiest example of this is that they are not a field.
  To see this, consider the cheap nonstandard real <fr:tex display="inline"><![CDATA[(0,1,0,1,0,1,\dots )]]></fr:tex>.
  This is not equal to zero, because there are infinitely many ones.
  On the other hand, it is also not invertible: if we multiply it with the cheap nonstandard real <fr:tex display="inline"><![CDATA[(x_n)]]></fr:tex>, we get <fr:tex display="inline"><![CDATA[(x_1, 0, x_2, 0, \dots )]]></fr:tex>. This is not equal to one, because there are infinitely many zeroes.
</html:p>
                <html:p>
  The way this would work for an ultrafilter is that either the set of even numbers or odd numbers would be in the ultrafilter. So either <fr:tex display="inline"><![CDATA[(0,1,0,1,\dots )]]></fr:tex> is zero or one - in either case, it's clearly invertible.
</html:p>
                <html:p>
  It turns out the parts of Łós' theorem that specifically fails for non-ultra filters are about statements <fr:tex display="inline"><![CDATA[\phi  \vee  \psi ]]></fr:tex> - disjunction, and <fr:tex display="inline"><![CDATA[\neg  \phi ]]></fr:tex> - negation. Hence the statement <fr:tex display="inline"><![CDATA[x = 0 \vee  (\exists  y : xy=1)]]></fr:tex> doesn't hold for the quotiented product, even though it holds for the ultraproduct.
</html:p>
                <html:p>
  However, this shouldn't concern us _too much_, because we can basically view this as a faily of LEM (in a way that I will explain), and LEM is another one of those slightly suspicious axioms.
</html:p>
                <html:p>
  In what sense does LEM fail for cheap nonstandard reals?
  As mentioned, the nonstandard reals are a model of the language of ordered fields.
  The way this works is that any formula <fr:tex display="inline"><![CDATA[\phi (x)]]></fr:tex> in that language can be interpreted for a nonstandard real by asking if <fr:tex display="inline"><![CDATA[\phi (x_n)]]></fr:tex> holds for a set in the ultrafilter - for short, whether <fr:tex display="inline"><![CDATA[\{n \mid  \phi (x_n)\} \in  \mathfrak {u}]]></fr:tex>.
  A priori, this gives two ways of intepreting a formula like <fr:tex display="inline"><![CDATA[x=0 \vee  x=1]]></fr:tex>.
  We can ask whether <fr:tex display="inline"><![CDATA[\{n \mid  x_n = 0 \vee  x_n = 1\} \in  \mathfrak {u}]]></fr:tex>, or we can ask whether <fr:tex display="inline"><![CDATA[\{n \mid  x_n = 0\} \in  \mathfrak {u} \vee  \{n \mid  x_n=0\} \in  \mathfrak {u}]]></fr:tex>.
  The second is the "correct" semantics for first-order logic, but the first is usually more convenient. Luckily, for ultrafilters they are the same.
</html:p>
                <html:p>
  We can try to use this approach with a non-ultrafilter, like the Frechet filter <fr:tex display="inline"><![CDATA[\mathcal {F}]]></fr:tex>. But now there's a difference! If we let <fr:tex display="inline"><![CDATA[(x_n) = (0,1,0,1,\dots )]]></fr:tex>, it's true that <fr:tex display="inline"><![CDATA[\{n \mid  x_n = 0 \vee  x_n = 1\} \in  \mathcal {F}]]></fr:tex>, but not true that <fr:tex display="inline"><![CDATA[\{n \mid  x_n = 0\} \in  \mathcal {F} \vee  \{n \mid  x_n = 1\} \in  \mathcal {F}]]></fr:tex>.
  A similar problem crops up for negation.
</html:p>
                <html:p>
  In this way, LEM fails in some sense, because we can have <fr:tex display="inline"><![CDATA[\phi ,x]]></fr:tex> so that <fr:tex display="inline"><![CDATA[\{n \mid  \phi (x_n)\} \notin  \mathcal {F}]]></fr:tex> and <fr:tex display="inline"><![CDATA[\{n \mid  \neg \phi (x_n)\} \notin  \mathcal {F}]]></fr:tex>.
</html:p>
                <html:p>
  Do observe however that here the "or" is being interpreted _externally_, but the "not" is being interpreted _internally_.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>6</fr:month>
              <fr:day>12</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/jsd-as-enrichment/</fr:uri>
            <fr:display-uri>jsd-as-enrichment</fr:display-uri>
            <fr:route>/jsd-as-enrichment/</fr:route>
            <fr:title text="Jensen-Shannon divergence is compositional">Jensen-Shannon divergence is compositional</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Let <fr:tex display="inline"><![CDATA[\mathsf {FinStoch}]]></fr:tex> be the category of finite sets and stochastic matrices.
Given two stochastic matrices, <fr:tex display="inline"><![CDATA[f_1,f_2: X \to  Y]]></fr:tex>, we can define their
**Jensen-Shannon distance** as <fr:tex display="inline"><![CDATA[d(f_1,f_2) := \sup _x \sqrt {\operatorname {JSD}(f_1(x),f_2(x))}]]></fr:tex>,
where JSD is the <fr:link href="https://en.wikipedia.org/wiki/Jensen–Shannon_divergence" type="external">Jensen-Shannon divergence</fr:link>.
It's a standard result that the root of JSD defines a metric on the space of
probability measures - hence the above defines a metric on the set
<fr:tex display="inline"><![CDATA[\mathsf {FinStoch}(X,Y)]]></fr:tex>. My aim here is to show that
_this gives an enrichment of <fr:tex display="inline"><![CDATA[\mathsf {FinStoch}]]></fr:tex> in the category <fr:tex display="inline"><![CDATA[\mathsf {Met}]]></fr:tex>
of metric spaces and **short**, i.e distance nonincreasing, maps_
</html:p>
            <html:p>
The content of this statement is that the composition map
</html:p>
            <html:p><fr:tex display="block"><![CDATA[\mathsf {FinStoch}(X,Y) \otimes  \mathsf {FinStoch}(Y,Z) \to 
\mathsf {FinStoch}(X,Z)]]></fr:tex> is a short map. The monoidal structure on <fr:tex display="inline"><![CDATA[\mathsf {Met}]]></fr:tex>
that we're considering is given by the "1-metric", i.e
</html:p>
            <fr:tex display="block"><![CDATA[d_{X \otimes  Y}((x,y),(x',y')) = d_X(x,x') + d_Y(y,y')]]></fr:tex>
            <html:p>
This has the convenient property that a map is short if and only if it's "short
in each variable separately". In other words, we must show that the map
</html:p>
            <fr:tex display="block"><![CDATA[f \circ  - :\mathsf {FinStoch}(X,Y) \to  \mathsf {FinStoch}(X,Z)]]></fr:tex>
            <html:p>
is short for each <fr:tex display="inline"><![CDATA[f]]></fr:tex>, and that the map
</html:p>
            <fr:tex display="block"><![CDATA[- \circ  f : \mathsf {FinStoch}(Y,Z) \to  \mathsf {FinStoch}(X,Z)]]></fr:tex>
            <html:p>
is short for each <fr:tex display="inline"><![CDATA[f]]></fr:tex>.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>12</fr:day>
                </fr:date>
                <fr:title text="Fact about \operatorname {JSD}.">Fact about <fr:tex display="inline"><![CDATA[\operatorname {JSD}]]></fr:tex>.</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We will use the following characterization of <fr:tex display="inline"><![CDATA[\operatorname {JSD}(p,q)]]></fr:tex>:
  Let <fr:tex display="inline"><![CDATA[B]]></fr:tex> be a "fair coinflip", i.e a random variable which is <fr:tex display="inline"><![CDATA[0]]></fr:tex> with
  probability <fr:tex display="inline"><![CDATA[1/2]]></fr:tex> and <fr:tex display="inline"><![CDATA[1]]></fr:tex> otherwise.
  Let <fr:tex display="inline"><![CDATA[X]]></fr:tex> be a random variable which is distributed according to <fr:tex display="inline"><![CDATA[p]]></fr:tex> if <fr:tex display="inline"><![CDATA[B=0]]></fr:tex> and
  <fr:tex display="inline"><![CDATA[q]]></fr:tex> if <fr:tex display="inline"><![CDATA[B=1]]></fr:tex>. Then the mutual information of <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[B]]></fr:tex> is exactly the
  Jensen-Shannon divergence of <fr:tex display="inline"><![CDATA[p]]></fr:tex> and <fr:tex display="inline"><![CDATA[q]]></fr:tex></html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>12</fr:day>
                </fr:date>
                <fr:title text="Postcomposition">Postcomposition</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We want to show that <fr:tex display="inline"><![CDATA[d(fg_0,fg_1) \leq  d(g_0,g_1)]]></fr:tex>.
  Clearly we may as well square both sides, so that we're trying to show that
</html:p>
                <fr:tex display="block"><![CDATA[\sup _x \operatorname {JSD}(fg_0(x),fg_1(x)) \leq  \sup _x
  \operatorname {JSD}(g_0(x),g_1(x))]]></fr:tex>
                <html:p>
  It suffices to show that this inequality holds for each <fr:tex display="inline"><![CDATA[x]]></fr:tex>, so let an <fr:tex display="inline"><![CDATA[x]]></fr:tex> be
  given.
  Then <fr:tex display="inline"><![CDATA[\operatorname {JSD}(g_0(x),g_1(x))]]></fr:tex> is the mutual information between a
  fair coin <fr:tex display="inline"><![CDATA[B]]></fr:tex> and a variable <fr:tex display="inline"><![CDATA[Y]]></fr:tex> distributed according to <fr:tex display="inline"><![CDATA[g_B(x)]]></fr:tex>.
  and <fr:tex display="inline"><![CDATA[\operatorname {JSD}(fg_1(x),fg_2(x))]]></fr:tex> is the mutual information between <fr:tex display="inline"><![CDATA[B]]></fr:tex>
  and a variable distributed as <fr:tex display="inline"><![CDATA[f(Y)]]></fr:tex>.
  But "postprocessing" by <fr:tex display="inline"><![CDATA[f]]></fr:tex> can't possible put more information about <fr:tex display="inline"><![CDATA[B]]></fr:tex> into
  the random variable, since it depends on <fr:tex display="inline"><![CDATA[Z]]></fr:tex> only through <fr:tex display="inline"><![CDATA[B]]></fr:tex>.
  Hence we have the desired inequality.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>12</fr:day>
                </fr:date>
                <fr:title text="Precomposition">Precomposition</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We want to show <fr:tex display="inline"><![CDATA[d(g_0f,g_1f) \leq  d(g_0,g_1)]]></fr:tex>
  Again it suffices to show
</html:p>
                <fr:tex display="block"><![CDATA[\sup _x \operatorname {JSD}(g_0f(x),g_1f(x)) \leq  \sup _y
  \operatorname {JSD}(g_0(y),g_1(y))]]></fr:tex>
                <html:p>
  It's enough to show this for each specific <fr:tex display="inline"><![CDATA[x]]></fr:tex>, so let's assume wlog that <fr:tex display="inline"><![CDATA[X=\ast ]]></fr:tex>
  and <fr:tex display="inline"><![CDATA[f]]></fr:tex> is simply a distribution, and we're showing
</html:p>
                <fr:tex display="block"><![CDATA[\operatorname {JSD}(g_0f,g_1f) \leq  \sup _y \operatorname {JSD}(g_0(y),g_1(y))]]></fr:tex>
                <html:p>
  To see this, let <fr:tex display="inline"><![CDATA[Y]]></fr:tex> be distributed according to <fr:tex display="inline"><![CDATA[f]]></fr:tex>, let <fr:tex display="inline"><![CDATA[B]]></fr:tex> be an unbiased
  coin, and let <fr:tex display="inline"><![CDATA[Z]]></fr:tex> be distributed according to <fr:tex display="inline"><![CDATA[g_B(Y)]]></fr:tex>.
  Then <fr:tex display="inline"><![CDATA[\operatorname {JSD}(g_0f,g_1f)]]></fr:tex> is <fr:tex display="inline"><![CDATA[I(Z;B)]]></fr:tex>, and
  <fr:tex display="inline"><![CDATA[\operatorname {JSD}(g_0(y),g_1(y))]]></fr:tex> is <fr:tex display="inline"><![CDATA[I(Z;B | Y = y)]]></fr:tex>.
</html:p>
                <html:p>
  Our claim is that <fr:tex display="inline"><![CDATA[I(Z;B) \leq  I(Z;B | Y=y)]]></fr:tex> for at least one <fr:tex display="inline"><![CDATA[y]]></fr:tex>.
  We insert the entropy formula for mutual information:
</html:p>
                <fr:tex display="block"><![CDATA[H(B) - H(B|Z) \leq  H(B|Y=y) - H(B|Z, Y=y)]]></fr:tex>
                <html:p>
  Since <fr:tex display="inline"><![CDATA[B,Y]]></fr:tex> independent, <fr:tex display="inline"><![CDATA[H(B|Y=y) = H(B)]]></fr:tex> (equals one bit), so we may rearrange
  this as <fr:tex display="block"><![CDATA[H(B|Z,Y=y) \leq  H(B|Z)]]></fr:tex>
  Now that the expected value <fr:tex display="inline"><![CDATA[E_y[H(B|Z,Y=y)]]]></fr:tex> is precisely <fr:tex display="inline"><![CDATA[H(B|Z,Y)]]></fr:tex> by
  definition.
  By a standard inequality <fr:tex display="inline"><![CDATA[H(B|Z,Y) \leq  H(B|Z)]]></fr:tex>.
  Hence we also have the inequality <fr:tex display="inline"><![CDATA[H(B|Z,Y=y)]]></fr:tex> for at least one <fr:tex display="inline"><![CDATA[y]]></fr:tex>, as desired.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>12</fr:day>
                </fr:date>
                <fr:title text="Followup questions">Followup questions</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  1.  Is there a way to build something like this "canonically" - the way entropy
      is characterized by a set of axioms in <fr:link href="https://arxiv.org/abs/1106.1791" type="external">A characterization of Entropy in
      Terms of Information Loss</fr:link>?
  2.  How does this relate to other metrics on probability, i.e the description
      from <fr:link href="https://arxiv.org/abs/1712.05363" type="external">A probability monad as the colimit of spaces of finite samples</fr:link></html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>6</fr:month>
              <fr:day>2</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/compositionality-for-transfer-learning/</fr:uri>
            <fr:display-uri>compositionality-for-transfer-learning</fr:display-uri>
            <fr:route>/compositionality-for-transfer-learning/</fr:route>
            <fr:title text="Compositionality for Transfer Learning">Compositionality for Transfer Learning</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
_Transfer learning_ is the idea that, after a machine learning system (or a non-machine
learning system, for that matter, like a human) has learned to solve some
problem, it should be able to _transfer_ this knowledge to solving similar
problems. Humans are pretty good at this, at least compared to current ML
systems, which tend to suck.
</html:p>
            <html:p>
Why do we expect transfer learning to work? It seems that, in general, we expect
that the solution to a task can be _decomposed_ into several pieces, some of
which will still be useful for the related task.
As an example, suppose we teach a self-driving card to drive to a given place,
using a map of the local area and camera input.
If we could open up the resulting algorithm, we may expect to find "subroutines"
corresponding to
</html:p>
            <html:p>
1.  Breaking down the visual input into objects.
2.  Maintaining/updating an internal memory with this data.
3.  Using this data to locate itself on the map
4.  Plotting a route on the map between two points
5.  Executing a route while driving correctly (i.e not breaking the law, not
    causing crashes).
</html:p>
            <html:p>
If we now want this system, instead, to locate and follow a car with a specific
license plate (or something), we would expect that most of these routines,
except perhaps 3 and 4, would still be useful. It would not have to learn all
over again how to recognize other cars and involve crashes.
</html:p>
            <html:p>
In other words, we expect transfer learning to happen because of
_compositionality_.
To introduce some symbols, we are trying to learn a function <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> from
observations to decisions.
The target behavior is really a function of some high-level description of the
system, as understood by humans, i.e it factors as <fr:tex display="inline"><![CDATA[X \overset {p}{\to } \bar {X} \overset {f'}{\to } Y]]></fr:tex>.
If the system manages to learn <fr:tex display="inline"><![CDATA[p]]></fr:tex> as well as <fr:tex display="inline"><![CDATA[f']]></fr:tex>, then if we swap out the task
with another one, which is also specified on the same abstract level, <fr:tex display="inline"><![CDATA[g': \bar {X} \to  Y]]></fr:tex>, the system will have less to do - a lot of the parameter space
is already in the right configuration.
</html:p>
            <html:p>
Of course, if you already knew how to compute the high-level representation
<fr:tex display="inline"><![CDATA[\bar {X}]]></fr:tex>, you mostly wouldn't need machine learning.
However, when we view the problem from this angle, it seems one way to get more
transfer learning is to look for learning algorithms that output "decomposed"
models, so that we can try to separate the abstraction <fr:tex display="inline"><![CDATA[X \to  \bar {X}]]></fr:tex>, from the
"task-specific logic" <fr:tex display="inline"><![CDATA[f': \bar {X} \to  Y]]></fr:tex>.
</html:p>
            <html:p>
One way to do this is to find a class of related tasks, <fr:tex display="inline"><![CDATA[\{f_i:X \to  Y_i | i
= 1 \dots  n\}]]></fr:tex>,
which we feel share a common abstraction.
Then we can pick some set <fr:tex display="inline"><![CDATA[\bar {X}]]></fr:tex> and try to train <fr:tex display="inline"><![CDATA[n+1]]></fr:tex> models - one going
from <fr:tex display="inline"><![CDATA[X \to  \bar {X}]]></fr:tex>, the others going from <fr:tex display="inline"><![CDATA[\bar {X} \to  Y_i]]></fr:tex>.
We give each of these algorithms the average loss across all the tasks as the
loss. Then the "high-level models" <fr:tex display="inline"><![CDATA[\bar {X} \to  Y_i]]></fr:tex> try to make use of the
low-level data as best they can, while the "abstraction" model <fr:tex display="inline"><![CDATA[X \to  \bar {X}]]></fr:tex>
tries to create an abstraction which is useful to all the high-level models.
</html:p>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>5</fr:month>
              <fr:day>24</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/stochastic-stalks/</fr:uri>
            <fr:display-uri>stochastic-stalks</fr:display-uri>
            <fr:route>/stochastic-stalks/</fr:route>
            <fr:title text="Stochastic Stalks">Stochastic Stalks</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>24</fr:day>
                </fr:date>
                <fr:title text="Stalks and points">Stalks and points</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Recall that a <fr:link href="https://ncatlab.org/nlab/show/point+of+a+topos" type="external">point of a topos</fr:link> <fr:tex display="inline"><![CDATA[\mathcal {E}]]></fr:tex> is a geometric morphism from the topos <fr:tex display="inline"><![CDATA[Set]]></fr:tex>.
  My preferred way to think about this is to consider the sheaf topos <fr:tex display="inline"><![CDATA[Sh(X)]]></fr:tex> on
  some (sober) topological space <fr:tex display="inline"><![CDATA[X]]></fr:tex>.
  Then given <fr:tex display="inline"><![CDATA[x \in  X]]></fr:tex> and a sheaf <fr:tex display="inline"><![CDATA[S]]></fr:tex>, we can form the stalk at <fr:tex display="inline"><![CDATA[x]]></fr:tex></html:p>
                <html:p>
                  <fr:tex display="inline"><![CDATA[S_x := \operatorname {colim}_{x \in  U \subseteq  X \text { open}} S(U)]]></fr:tex>
                </html:p>
                <html:p>
  1.  This determines the point uniquely, i.e if <fr:tex display="inline"><![CDATA[(-)_x \simeq  (-)_y]]></fr:tex> then <fr:tex display="inline"><![CDATA[x = y]]></fr:tex>
  2.  This is a left exact left adjoint <fr:tex display="inline"><![CDATA[Sh(X) \to  Set]]></fr:tex> - i.e part of a geometric
      morphism <fr:tex display="inline"><![CDATA[Set \to  Sh(X)]]></fr:tex>.
  3.  All left exact left adjoints <fr:tex display="inline"><![CDATA[Sh(X) \to  Set]]></fr:tex> have this form.
</html:p>
                <html:p>
  Hence it makes sense to identify literal points of <fr:tex display="inline"><![CDATA[X]]></fr:tex> with points of <fr:tex display="inline"><![CDATA[Sh(X)]]></fr:tex> in
  the above sense.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>24</fr:day>
                </fr:date>
                <fr:title text="Random points">Random points</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We can think of a probability measure on a space <fr:tex display="inline"><![CDATA[X]]></fr:tex> as a sort of "generalized
  point", which has been "smeared out".
  How can we lift this intuition to the level of <fr:tex display="inline"><![CDATA[Sh(X)]]></fr:tex>?
  It seems sort of obvious that we shouldn't expect this to work on the level of
  sets - they are somehow too "discrete" to capture quantitative information about
  probabilities.
  It's actually worth mentioning here that any point of <fr:tex display="inline"><![CDATA[Sh(X)]]></fr:tex> is determined by
  its action on sheaves represented by open sets, which must each be sent to
  either <fr:tex display="inline"><![CDATA[\emptyset ]]></fr:tex> or <fr:tex display="inline"><![CDATA[*]]></fr:tex> (this follows from the "left exact left adjoint"
  assumptions).
  The fact that it's a left exact left adjoint furthermore implies that it must be
  a sort of infinitely-additive <fr:tex display="inline"><![CDATA[\{0,1\}]]></fr:tex>-valued probability measure defined on
  the open sets, and it follows from this that it's a "dirac measure".
  This is how to prove that all points are really represented by a point.
  It seems that one way of considering "random points" would be to let the functor
  take values in a category with objects that can reasonably represent more
  complicated probability measures.
  It also seems unlikely that we can rely completely on universal properties to
  carry the day here.
  If <fr:tex display="inline"><![CDATA[U, V \subset  X]]></fr:tex> are open sets, then <fr:tex display="inline"><![CDATA[U \cap  V]]></fr:tex> is their product, both in
  <fr:tex display="inline"><![CDATA[O(X)]]></fr:tex> and in <fr:tex display="inline"><![CDATA[Sh(X)]]></fr:tex>.
  So if a functor <fr:tex display="inline"><![CDATA[P: Sh(X) \to  C]]></fr:tex> preserves products, <fr:tex display="inline"><![CDATA[P(U \cap  V)]]></fr:tex> depends only
  on <fr:tex display="inline"><![CDATA[P(U)]]></fr:tex> and <fr:tex display="inline"><![CDATA[P(V)]]></fr:tex> - so this clearly can't capture all possible probability
  measures.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>24</fr:day>
                </fr:date>
                <fr:title text="One attempt: Stochastic stalks">One attempt: Stochastic stalks</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  I haven't solved this problem completely (I'm not convinced a good general
  solution exists).
  One approach is to think about _integration of metric spaces over a measure_,
  which I will now explain.
  A _sheaf of metric spaces_ is a functor <fr:tex display="inline"><![CDATA[O(X)^{op} \to  Met]]></fr:tex>, where <fr:tex display="inline"><![CDATA[Met]]></fr:tex> is the
  category of metric spaces and _short_, i.e distance-nonincreasing, maps,
  which satisfies the sheaf axiom.
  We denote the category of such sheaves by <fr:tex display="inline"><![CDATA[Sh(X,Met)]]></fr:tex>.
  By "the sheaf axiom", I mean it preserves limits.
  Since <fr:tex display="inline"><![CDATA[Met]]></fr:tex> does not have all limits, this is a bit subtler than it may appear.
  However, since <fr:tex display="inline"><![CDATA[Met]]></fr:tex> does have finite limits, this difficulty disappears if we
  assume <fr:tex display="inline"><![CDATA[X]]></fr:tex> is compact.
</html:p>
                <html:p>
  Let <fr:tex display="inline"><![CDATA[M]]></fr:tex> be a sheaf of metric spaces and let <fr:tex display="inline"><![CDATA[P]]></fr:tex> be a Radon probability measure
  on <fr:tex display="inline"><![CDATA[X]]></fr:tex>.
  Then we define <fr:tex display="inline"><![CDATA[M_X]]></fr:tex> to be the product <fr:tex display="inline"><![CDATA[\prod _{x \in  X}M_x]]></fr:tex> of all the stalks
  (just considered as a set).
  Equip <fr:tex display="inline"><![CDATA[M_X]]></fr:tex> with a pseudometric <fr:tex display="inline"><![CDATA[d]]></fr:tex> by setting <fr:tex display="inline"><![CDATA[d(a,b) = \int  d(a_x,b_x)P(dx)]]></fr:tex>.
  In other words, we _integrate_ the distances according to the given probability
  measure. If we quotient out with the relation <fr:tex display="inline"><![CDATA[a \sim  b]]></fr:tex> if <fr:tex display="inline"><![CDATA[d(a,b) = 0]]></fr:tex>, this
  gives a proper metric space, <fr:tex display="inline"><![CDATA[M_X/\sim ]]></fr:tex>.
</html:p>
                <html:p>
  Now for each <fr:tex display="inline"><![CDATA[U \subset  X]]></fr:tex> with <fr:tex display="inline"><![CDATA[P(U) = 1]]></fr:tex>, we consider the map <fr:tex display="inline"><![CDATA[M(U) \to 
  M_X/\sim ]]></fr:tex> given by taking all the germs.
  We let <fr:tex display="inline"><![CDATA[M_P]]></fr:tex> be the metric space consisting of the images of all these maps.
</html:p>
                <html:p>
  This defines a functor <fr:tex display="inline"><![CDATA[Sh(X,Met) \to  Met]]></fr:tex>.
  We can recover the probability measure on an open set <fr:tex display="inline"><![CDATA[A]]></fr:tex> by considering a sheaf
  <fr:tex display="inline"><![CDATA[M]]></fr:tex> given
  by two points at distance <fr:tex display="inline"><![CDATA[1]]></fr:tex> if <fr:tex display="inline"><![CDATA[U \subset  A]]></fr:tex> and the singleton otherwise.
  Then <fr:tex display="inline"><![CDATA[M_P]]></fr:tex> consists of two points at distance <fr:tex display="inline"><![CDATA[P(A)]]></fr:tex>.
  At least in the case of compact Hausdorff spaces, this determines the underlying
  measure uniquely.
  (In general, the "measure defined on open sets" that we recover in this way is
  called a valuation, and you can argue that we shouldn't expect to tell the
  difference between different measures with the same valuation).
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>24</fr:day>
                </fr:date>
                <fr:title text="Questions">Questions</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  -   What useful properties characterize functors of the above form?
  -   Is there a good way of doing this for <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex>-algebras instead of topologies?
  -   Is there a good way of doing this for a general topos?
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>24</fr:day>
                </fr:date>
                <fr:title text="Example: Random variables">Example: Random variables</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Let <fr:tex display="inline"><![CDATA[M]]></fr:tex> be any metric space.
  Then we can form a sheaf of metric spaces where <fr:tex display="inline"><![CDATA[M(U)]]></fr:tex> is the set of continuous
  functions <fr:tex display="inline"><![CDATA[U \to  M]]></fr:tex> in the sup metric.
  Then the metric space <fr:tex display="inline"><![CDATA[M_P]]></fr:tex> is the set of <fr:tex display="inline"><![CDATA[M]]></fr:tex>-valued random variables,
  metrized by letting <fr:tex display="inline"><![CDATA[d(A,B) := \mathbb {E}_P(d(A,B))]]></fr:tex> - i.e metrized by
  _expected_ distance.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>5</fr:month>
              <fr:day>17</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/ax-grothendieck-model-theory/</fr:uri>
            <fr:display-uri>ax-grothendieck-model-theory</fr:display-uri>
            <fr:route>/ax-grothendieck-model-theory/</fr:route>
            <fr:title text="The Ax-Grothendieck theorem">The Ax-Grothendieck theorem</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
The Ax-Grothendieck theorem says the following:
Let <fr:tex display="inline"><![CDATA[f: \mathbb {C}^n \to  \mathbb {C}^n]]></fr:tex> be a polynomial function. If it's
injective, then it's surjective as well.
</html:p>
            <html:p>
Here's how to prove it:
</html:p>
            <html:p>
1.  The statement can be formulated as a first-order statement in the language of
    fields
2.  If a statement like that fails for <fr:tex display="inline"><![CDATA[\mathbb {C}]]></fr:tex>, there's a disproof in the
    first-order theory of algebraically closed fields of characteristic zero.
3.  Such a proof is _finite_, so it only uses finitely many of the assumptions
    <fr:tex display="inline"><![CDATA[p \neq  0]]></fr:tex> - hence the theorem also fails in algebraically closed fields of
    sufficiently high characteristic.
4.  Hence it fails in the algebraic closure of <fr:tex display="inline"><![CDATA[\mathbb {F}_p]]></fr:tex>. The specific
    counterexample is in some finite extension of <fr:tex display="inline"><![CDATA[\mathbb {F}_p]]></fr:tex>, which is a
    finite field. But clearly the theorem is _true_ for finite fields, just by counting.
</html:p>
            <html:p>
I think this is a pretty cool proof - it uses model theory in a really
surprising way, and the step where you use the fact that _proofs are finite_ is
just totally bonkers.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>17</fr:day>
                </fr:date>
                <fr:title text="First-order logic and completeness">First-order logic and completeness</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Recall that first-order logic works with statements built up out of the logical
  connectives <fr:tex display="inline"><![CDATA[\wedge , \vee , \neg , \Rightarrow  \bot , \top , \forall , \exists , =]]></fr:tex>.
  The language of _fields_ augments these symbols with <fr:tex display="inline"><![CDATA[+, -, \cdot , 1, 0]]></fr:tex> (it's
  really just the language of commutative rings - being a field just means that
  additional axioms hold).
</html:p>
                <html:p>
  A statement in the first-order language of fields could be something like this:
</html:p>
                <html:p>
                  <fr:tex display="inline"><![CDATA[\forall  a,b: \neg  (a = 0) \Rightarrow  \exists  x: a\cdot  x + b = 0]]></fr:tex>
                </html:p>
                <html:p>
  This statement says that all nonconstant linear polynomials have a solution,
  which is true.
</html:p>
                <html:p>
  We could also write down a statement like
  
  <fr:tex display="block"><![CDATA[\forall  a, b, c, d, e: \neg  (a = 0) \Rightarrow  \exists  x: a x^4 + bx^3 +

  cx^2 + dx + e = 0]]></fr:tex></html:p>
                <html:p>
  This says that all fourth-order polynomials have a root, which is not always
  true, but true sometimes, like in <fr:tex display="inline"><![CDATA[\mathbb {C}]]></fr:tex>.
</html:p>
                <html:p>
  Similarly, we can form a statement <fr:tex display="inline"><![CDATA[R_n]]></fr:tex> for all <fr:tex display="inline"><![CDATA[n \in  \mathbb {N}]]></fr:tex>, saying that
  all <fr:tex display="inline"><![CDATA[n]]></fr:tex>th order polynomials have a root. Note that the conjunction of all these
  statements is _not_ a first-order statement in itself - we can't take
  conjuctions of infinitely many statements, and there's no way to quantify over
  all polynomials in the theory of fields.
</html:p>
                <html:p>
  Similarly, we can form statements like <fr:tex display="inline"><![CDATA[1+1 \neq  0]]></fr:tex>. This is also true in
  <fr:tex display="inline"><![CDATA[\mathbb {C}]]></fr:tex>, but fails in fields of characteristic <fr:tex display="inline"><![CDATA[2]]></fr:tex>. We can form statements
  <fr:tex display="inline"><![CDATA[C_n]]></fr:tex> for all <fr:tex display="inline"><![CDATA[n]]></fr:tex>, saying that <fr:tex display="inline"><![CDATA[n \neq  0]]></fr:tex> - that the field does not have
  characteristic <fr:tex display="inline"><![CDATA[n]]></fr:tex>.
</html:p>
                <html:p>
  The _theory of algebraically closed fields of characteristic zero_ is the theory
  consisting of the axioms of a field augmented with the statements <fr:tex display="inline"><![CDATA[C_n]]></fr:tex> and
  <fr:tex display="inline"><![CDATA[R_n]]></fr:tex> for all <fr:tex display="inline"><![CDATA[n]]></fr:tex>.
  A model of this theory is precisely an algebraically closed field of
  characteristic zero (hence the name).
</html:p>
                <html:p>
  Now here is a highly nontrivial fact about this theory: it is _complete_.
  This means that _any statement expressible in the first-order language of fields
  is either provable or disprovable in it_. This means that, from the perspective
  of first-order logic, there are really no differences between fields of this
  type - even though there are of course many different such fields, they have the
  same first-order properties.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>17</fr:day>
                </fr:date>
                <fr:title text="Ax-Grothendieck in first order">Ax-Grothendieck in first order</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We want to phrase the Ax-Grothendieck theorem as a first-order statement.
  It turns out this isn't quite possible, because we can't quantify over "all
  degree <fr:tex display="inline"><![CDATA[d]]></fr:tex> polynomials" or "all <fr:tex display="inline"><![CDATA[n \in  \mathbb {N}]]></fr:tex>". Therefore we instead
  formulate the statement <fr:tex display="inline"><![CDATA[P(n,d)]]></fr:tex>: "Any polynomial function <fr:tex display="inline"><![CDATA[f : \mathbb {C}^n \to 
  \mathbb {C}^n]]></fr:tex> of degree at most <fr:tex display="inline"><![CDATA[d]]></fr:tex> is surjective if it's injective".
  Then the Ax-Grothendieck statement says that <fr:tex display="inline"><![CDATA[P(n,d)]]></fr:tex> holds for all <fr:tex display="inline"><![CDATA[n \geq  1, d
  \geq  0]]></fr:tex>

  (By the way: by "polynomial <fr:tex display="inline"><![CDATA[\mathbb {C}^n \to  \mathbb {C}^n]]></fr:tex>", I mean a function
  where each coordinate is an <fr:tex display="inline"><![CDATA[n]]></fr:tex>-variable polynomial)
</html:p>
                <html:p>
  How does <fr:tex display="inline"><![CDATA[P(n,d)]]></fr:tex> look as a first-order formula? It's quite complicated - mostly
  because a degree <fr:tex display="inline"><![CDATA[d]]></fr:tex> polynomial like <fr:tex display="inline"><![CDATA[f]]></fr:tex> involves a large number of
  coefficients.
  The main point is that there is a _definite_ number of coefficients, once <fr:tex display="inline"><![CDATA[n]]></fr:tex>
  and <fr:tex display="inline"><![CDATA[d]]></fr:tex> is fixed, and so we can write "for all choices of coefficients for
  <fr:tex display="inline"><![CDATA[f]]></fr:tex>..." in first-order logic.
  For instance, if <fr:tex display="inline"><![CDATA[d = 2, n=1]]></fr:tex>, this looks like
  <fr:tex display="inline"><![CDATA[\forall  a_{11},a_{12},a_{21},a_{22},b_1,b_2 \dots ]]></fr:tex>
  Here <fr:tex display="inline"><![CDATA[a_{12}]]></fr:tex> is the coefficient for <fr:tex display="inline"><![CDATA[x_1]]></fr:tex> in the second coordinate polynomial of
  <fr:tex display="inline"><![CDATA[f]]></fr:tex>, and so on.
</html:p>
                <html:p>
  Now of course we can also make sense of injectivity: it's just the statement
  <fr:tex display="block"><![CDATA[f(x_1,\dots  x_n) = f(x'_1, \dots  x'_n) \Rightarrow  x_1=x'_1 \wedge  \dots  \wedge 
  x_n = x'_n]]></fr:tex> - where the equality on the left of the implication is shorthand
  for a complicated expression involving the coefficients of <fr:tex display="inline"><![CDATA[f]]></fr:tex>.
</html:p>
                <html:p>
  And we can make sense of surjectivity: it just means <fr:tex display="block"><![CDATA[\forall  y_1 \dots  y_n,

  \exists  x_1, \dots  x_n: f(x_1, \dots  x_n) = (y_1, \dots  y_n)]]></fr:tex>
  Hence we have all the ingredients to make sense of <fr:tex display="inline"><![CDATA[P(n,d)]]></fr:tex>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>17</fr:day>
                </fr:date>
                <fr:title text="Finishing up the proof">Finishing up the proof</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We now have most of the ingredients to fill out the proof above.
  Since Ax-grothendieck is a (family of) first-order statements, if it fails,
  there is a disproof in the first-order theory of algebraically closed
  characteristic zero fields.
  To be specific, if Ax-Grothendieck is false, then <fr:tex display="inline"><![CDATA[P(n,d)]]></fr:tex> is false for some
  specific <fr:tex display="inline"><![CDATA[n,d]]></fr:tex>, and hence there is a disproof of that statement, i.e a proof of
  <fr:tex display="inline"><![CDATA[\neg  P(n,d)]]></fr:tex>.
</html:p>
                <html:p>
  Observe that such a proof is finite. Hence it can use at most finitely many of
  the statements <fr:tex display="inline"><![CDATA[C_n]]></fr:tex>.
  Hence for <fr:tex display="inline"><![CDATA[p]]></fr:tex> large enough (larger than any <fr:tex display="inline"><![CDATA[n]]></fr:tex> where <fr:tex display="inline"><![CDATA[C_n]]></fr:tex> is used in the
  proof), Ax-Grothendieck fails for algebraically closed fields of characteristic
  <fr:tex display="inline"><![CDATA[p]]></fr:tex> - like the algebraic closure of <fr:tex display="inline"><![CDATA[\mathbb {F}_p]]></fr:tex>.
  (How do we know it fails? We have a proof that it fails!)
  Hence there exists some polynomial function <fr:tex display="block"><![CDATA[f: \overline {\mathbb {F}_p}^n \to 
  \overline {\mathbb {F}_p}^n]]></fr:tex>
  which is injective and not surjective.
  But now we can take the algebraic extension of <fr:tex display="inline"><![CDATA[F_p]]></fr:tex> by all the coefficientsof
  <fr:tex display="inline"><![CDATA[f]]></fr:tex> and the coordinates of a point <fr:tex display="inline"><![CDATA[y \in  \overline {\mathbb {F}_p}^n]]></fr:tex> which is
  not in the image. Call this extension <fr:tex display="inline"><![CDATA[L]]></fr:tex>.
  Then <fr:tex display="inline"><![CDATA[f: L^n \to  L^n]]></fr:tex> is a well-defined injective polynomial which is not
  surjective.
  And since <fr:tex display="inline"><![CDATA[L]]></fr:tex> is a finite extension of a finite field, it's finite.
  But then we clearly have a contradiction: injective fuctions between finite sets
  of the same cardinality are bijections, just by counting.
</html:p>
                <html:p>
  This concludes the proof.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>5</fr:month>
              <fr:day>10</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/jardine-persistent-htpy/</fr:uri>
            <fr:display-uri>jardine-persistent-htpy</fr:display-uri>
            <fr:route>/jardine-persistent-htpy/</fr:route>
            <fr:title text="Notes from &quot;Persistent Homotopy Theory&quot;">Notes from "Persistent Homotopy Theory"</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
My notes from <fr:link href="https://arxiv.org/abs/2002.10013" type="external">Persistent Homotopy Theory</fr:link> by JF Jardine.
The goal of the paper is to study "filtered spaces". By this is meant in general
something like an assignment <fr:tex display="inline"><![CDATA[s \mapsto  X_s]]></fr:tex> of a "space" or simplicial set to
each nonnegative real <fr:tex display="inline"><![CDATA[s \in  [ 0,\infty  )]]></fr:tex>.
A prototypical example is the <fr:link href="https://en.wikipedia.org/wiki/Vietoris–Rips_complex" type="external">Vietoris-Rips complex</fr:link> of a metric space, <fr:tex display="inline"><![CDATA[V_s(X)]]></fr:tex>.
</html:p>
            <html:p>
The idea being pointed towards is some sort of modification of model category
theory to make ideas from persistent homology work more nicely.
The main example considered is an inclusion of VR-complexes <fr:tex display="inline"><![CDATA[V_s(X) \to  V_s(Y)]]></fr:tex>
coming from an incusion of datasets <fr:tex display="inline"><![CDATA[X \subset  Y]]></fr:tex> where all the points in <fr:tex display="inline"><![CDATA[Y]]></fr:tex>
are "close to" ponts in <fr:tex display="inline"><![CDATA[Y]]></fr:tex>.
In this situatio <fr:tex display="inline"><![CDATA[V_s(X) \to  V_s(Y)]]></fr:tex> is not generally a homotopy equivalence or
anything like tat, but it's still a bit "equivalency" - we would like to
understand howthis works, and how this plays into classical model category theory.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="1 Posets">1 Posets</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Given a finite subset <fr:tex display="inline"><![CDATA[X]]></fr:tex> of a metric space <fr:tex display="inline"><![CDATA[Z]]></fr:tex>, which we think of as a _data
  set_,
  we consider the collection <fr:tex display="inline"><![CDATA[P_s(X)]]></fr:tex> of subsets <fr:tex display="inline"><![CDATA[\sigma  \subset  X]]></fr:tex> where <fr:tex display="inline"><![CDATA[d(x,y)
  \leq  s]]></fr:tex> for all <fr:tex display="inline"><![CDATA[x,y \in  \sigma ]]></fr:tex>. We can order this by inclusion - it is
  exactly the poset of simplices in the Vietoris-Rips Complex <fr:tex display="inline"><![CDATA[V_s(X)]]></fr:tex>.
</html:p>
                <html:p>
  Now we want to work with this combinatorial data as if it were topological data.
  This is generally easiest if we're working with a simplicial set.
  We can make this into a simplicial set by choosing an ordering on <fr:tex display="inline"><![CDATA[X]]></fr:tex>, but this
  is non-canonical.
  We can also consider the nerve <fr:tex display="inline"><![CDATA[B(P_s(X))]]></fr:tex>, but this is somewhat clunky - the
  resulting simplicial structure is really the _subdivision_ of the complex
  <fr:tex display="inline"><![CDATA[V_s(X)]]></fr:tex>.
  (<fr:tex display="inline"><![CDATA[B]]></fr:tex> for the nerve of a category - a simplicial set - it somewhat unusual
  notation, but I've stuck with Jardine's choice of notation.)
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="2 Stability">2 Stability</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Define the <fr:link href="https://en.wikipedia.org/wiki/Hausdorff_distance" type="external">Hausdorff Distance</fr:link> on finite subsets <fr:tex display="inline"><![CDATA[X,Y \subset  Z]]></fr:tex> of a metric space
  as follows:
  <fr:tex display="inline"><![CDATA[d_H(X,Y) < r]]></fr:tex> if and only if for all <fr:tex display="inline"><![CDATA[x]]></fr:tex> there exists <fr:tex display="inline"><![CDATA[y]]></fr:tex> with <fr:tex display="inline"><![CDATA[d(x,y) < r]]></fr:tex>,
  and vice versa.
</html:p>
                <html:p>
  Then a situation of interest is if we have two data sets with "small" Hausdorff
  distance - in this case, the datasets seem to reflect mostly the same underlying
  topology, so we'd like our methods to give mostly the same results.
</html:p>
                <html:p>
  What sort of relation do we have between <fr:tex display="inline"><![CDATA[P_s(X)]]></fr:tex> and <fr:tex display="inline"><![CDATA[P_s(Y)]]></fr:tex>?
  For simplicity let's work with the case where <fr:tex display="inline"><![CDATA[X \subset  Y]]></fr:tex>.
  Then we have an inclusion <fr:tex display="inline"><![CDATA[i: P_s(X) \to  P_s(Y)]]></fr:tex>, and we can ask in what sense this
  is "equivalence-like".
  We can try to cook up an inverse by picking a nearest point <fr:tex display="inline"><![CDATA[\theta (y) \in  X]]></fr:tex>
  for each <fr:tex display="inline"><![CDATA[y \in  Y]]></fr:tex>.
  By assumption <fr:tex display="inline"><![CDATA[d(y,\theta (y)) < r]]></fr:tex>.
  This means we can build a diagram
</html:p>
                <html:img src="/bafkrmia5m3itaa6yil5cvbup6op2xhm6fwzuphs4iarqc6c36rbr3xxmim.png" title="" />
                <html:p>
  The top square commutes - in other words, <fr:tex display="inline"><![CDATA[i]]></fr:tex> almost has a retract, except we
  have to add an extra error of up to <fr:tex display="inline"><![CDATA[2r]]></fr:tex>.
  The bottom square doesn't commute - after all, <fr:tex display="inline"><![CDATA[\theta ]]></fr:tex> does really move around
  some points.
  But it doesn't move around points too much - the set <fr:tex display="inline"><![CDATA[\sigma (t) \cup 
  i(\theta (t))]]></fr:tex> is still in <fr:tex display="inline"><![CDATA[P_{s+2r}(Y)]]></fr:tex>, i.e: the altered points and the
  original points are all within <fr:tex display="inline"><![CDATA[2r]]></fr:tex> of each other.
  The pair of inclusions <fr:tex display="inline"><![CDATA[\sigma (t) \hookrightarrow  \sigma (t) \cup  i(\theta (t))
  \hookleftarrow  i(\theta (t))]]></fr:tex> present a _homotopy_ between <fr:tex display="inline"><![CDATA[i\theta ]]></fr:tex> and
  <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex>, so the bottom square commutes up to homotopy.
  In other words, <fr:tex display="inline"><![CDATA[i]]></fr:tex> and <fr:tex display="inline"><![CDATA[\theta ]]></fr:tex> form a sort of "approximate deformation retract".
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>10</fr:day>
                </fr:date>
                <fr:title text="3 Controlled equivalences">3 Controlled equivalences</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  In this section we encounter some interesting homotopy theory-ish things.
  We consider the category of functors <fr:tex display="inline"><![CDATA[[ 0,\infty  ) \to  sSet]]></fr:tex> (or other
  categories).
  We can equip this with the _projective model structure_, meaning a map is a weak
  equivalence or a fibration iff it is so sectionwise.
  This means the fibrant objects are exactly the functors that land in Kan
  complexes, and the cofibrant objects are precisely those that land in
  monomorphisms (this is a theorem).
</html:p>
                <html:p>
  Now the interesting thing we can do is consider various notions of
  "<fr:tex display="inline"><![CDATA[r]]></fr:tex>-isomorphism".
  The basic motivation for this is that, if <fr:tex display="inline"><![CDATA[X \subset  Y]]></fr:tex> and <fr:tex display="inline"><![CDATA[d_H(X,Y) < r/2]]></fr:tex>, we
  get a diagram like this
</html:p>
                <html:img src="/bafkrmic7vvfxem6hjuxqwcl3qhgxyvc5tobm64jdeem7lfsmu6atkxfilu.png" title="" />
                <html:p>
  where the top triangle commutes, and the bottom commutes up to a homotopy fixing
  <fr:tex display="inline"><![CDATA[NP_s(X)]]></fr:tex> - an "<fr:tex display="inline"><![CDATA[r]]></fr:tex>-interleaving"
</html:p>
                <html:p>
  This tells us that the maps <fr:tex display="inline"><![CDATA[\pi _n(BP_s(X)) \to  \pi _n(BP_{s}(Y))]]></fr:tex> is "almost an isomorphism":
</html:p>
                <html:p>
  -   We can find a preimage for any element in <fr:tex display="inline"><![CDATA[\pi _n(BP_s(Y))]]></fr:tex>, as long as we're willing
      to increase the allowed error by <fr:tex display="inline"><![CDATA[r]]></fr:tex>.
  -   If two elements in <fr:tex display="inline"><![CDATA[\pi _n(BP_s(X))]]></fr:tex> agree in <fr:tex display="inline"><![CDATA[\pi _n(BP_s(Y))]]></fr:tex>, they also agree in
      <fr:tex display="inline"><![CDATA[\pi _n(BP_{s+r}(X))]]></fr:tex></html:p>
                <html:p>
  Let's call something like this an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-isomorphism.
</html:p>
                <html:p>
  We can then ask in general for an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-equivalence, which gives an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-isomorphism on the
  (filtered) homotopy groups.
  These maps have various good properties
</html:p>
                <html:p>
  -   They are stable under composition with weak equivalences
  -   They're not quite stable under composition, rather when composing an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-equivalence and
      an <fr:tex display="inline"><![CDATA[s]]></fr:tex>-equivalence, you get an <fr:tex display="inline"><![CDATA[r+s]]></fr:tex>-equivalence.
  -   They satisfy a similarly modified version of the 2 out of 3 condition.
  -   A pullback of an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-equivalence which is a fibration is a <fr:tex display="inline"><![CDATA[2r]]></fr:tex>-equivalence
      (and a fibration).
  -   If a map is an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-equivalence and a sectionwise cofibration (not the same as
      a cofibration in the projective model structure!), it admits a
      <fr:tex display="inline"><![CDATA[2r]]></fr:tex>-interleaving, in the sense of the diagram above.
</html:p>
                <html:p>
  This gives a sort of bizzarro model structure/homotopy theory for
  <fr:tex display="inline"><![CDATA[r]]></fr:tex>-equivalences.
  In this world, an <fr:tex display="inline"><![CDATA[r]]></fr:tex>-interleaving is a bit like a deformation retract.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>5</fr:month>
              <fr:day>2</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/complexity-theory-probability/</fr:uri>
            <fr:display-uri>complexity-theory-probability</fr:display-uri>
            <fr:route>/complexity-theory-probability/</fr:route>
            <fr:title text="Complexity theory, probability">Complexity theory, probability</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>2</fr:day>
                </fr:date>
                <fr:title text="Computationally bounded probability theory">Computationally bounded probability theory</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Probability theory is about how to manage incomplete information.
  One way to interpret a statement like "the probability of event <fr:tex display="inline"><![CDATA[X]]></fr:tex> is <fr:tex display="inline"><![CDATA[p]]></fr:tex>" is
  in terms of betting odds - you think the probability of <fr:tex display="inline"><![CDATA[X]]></fr:tex> is <fr:tex display="inline"><![CDATA[p]]></fr:tex> if you value
  a lottery ticket that pays out $1 if <fr:tex display="inline"><![CDATA[X]]></fr:tex> happens at <fr:tex display="inline"><![CDATA[p]]></fr:tex> dollars.
  From this interpretation, all the laws of probability theory (except arguably
  those involving infinite conjunctions of events) follow, if we add the
  requirement that your valuation is "inexploitable" - in other words, if we
  require that no smart bookie can get you to make a series of bets that always
  loses money.
</html:p>
                <html:p>
  The big issue with probability theory as a model of how to reason under
  uncertain information is that it doesn't account for agents with
  _limited processing power_ (i.e all of them).
  A way to think about this problem is that, realistically, the best you can
  possible hope for is to not be outsmarted by bookies without too much more
  computing power than you.
  For example, what is the probability that among the first <fr:tex display="inline"><![CDATA[10^{10^10}]]></fr:tex> digits of
  <fr:tex display="inline"><![CDATA[\pi ]]></fr:tex>, there are more even than odd ones?
  If a mortal human is forced to assign this event a probability, we must choose
  more or less blindly - a bookie with an arbitrarily powerful computer could then
  win lots of money off us by calculating a lot of inaccessible digits of <fr:tex display="inline"><![CDATA[\pi ]]></fr:tex>
  and betting us for their parity.
</html:p>
                <html:p>
  This approach to "computationally bounded probability theory" is explored in the
  paper <fr:link href="https://arxiv.org/abs/1609.03543" type="external">Logical Induction</fr:link>. Based on the idea about "computationally limited
  bookies", they build a notion of "logical inductor" - a process which assigns
  gradually updating probabilities to logical statements, and which is "optimal"
  in the sense that it can't be exploited.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>2</fr:day>
                </fr:date>
                <fr:title text="Computationally bounded logic">Computationally bounded logic</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  In some sense, the problem solved by logical induction is that ordinary logic is
  _too expressive_. It can express statements which are hard to verify in a small
  amount of space.
  Interestingly, there are versions of logic that get around this limitation in
  various ways.
  <fr:link href="https://link.springer.com/article/10.1023/B:STUD.0000034183.33333.6f" type="external">Light Affine Set Theory</fr:link> is a version of set theory with the following
  interesting property: the provably total functions are precisely those with a
  polynomial-time algorithm.
  This means that the function which determines the most common parity among the
  first <fr:tex display="inline"><![CDATA[10^{10^n}]]></fr:tex> digits of <fr:tex display="inline"><![CDATA[\pi ]]></fr:tex> is _not provably total_ (assuming of course
  that there is no efficient algorithm for this).
  Of course, this sort of logic is by necessity much more restricted than normal
  logic.
  We can think about this as a sort of ultrafinitism - numbers like <fr:tex display="inline"><![CDATA[10^{10^n}]]></fr:tex>
  are "too big to exist".
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>2</fr:day>
                </fr:date>
                <fr:title text="Synthesis?">Synthesis?</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  What is the unifying thread here? I'm not sure.
  I want to say something like "you can't prove in LAST that a logical inductor is
  inconsistent".
  This is not quite meaningful - a logical inductor is a _sequence_ of probability
  assignments (as they have more time to calculate, they update their
  probabilities),
  and each step along the sequence will generally contain plenty of specific
  verifiable mistakes.
  But there's an idea that I'm trying to grasp at, that the inconsistency of a
  logical inductor "takes superpolynomial resources to detect", and hence it "is"
  a probability measure from the point of view of a polynomial logic.
  Or perhaps we should say that it "isn't not a probability measure", in the sense
  of constructive logic.
  That is, we can't verify that it's a probability measure, but we can't construct
  a counterexample either.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>4</fr:month>
              <fr:day>26</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/zero-one-laws-paper/</fr:uri>
            <fr:display-uri>zero-one-laws-paper</fr:display-uri>
            <fr:route>/zero-one-laws-paper/</fr:route>
            <fr:title text="The zero-one laws of Kolmogorov and Hewitt–Savage in categorical probability">The zero-one laws of Kolmogorov and Hewitt–Savage in categorical probability</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>26</fr:day>
                </fr:date>
                <fr:title text="TLDR">TLDR</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  This is a post about my paper <fr:link href="https://arxiv.org/abs/1912.02769" type="external">The zero-one laws of Kolmogorov and Hewitt-Savage
  in categorical probability</fr:link>, joint with <fr:link href="https://perimeterinstitute.ca/personal/tfritz/" type="external">Tobias Fritz</fr:link>.
  This is a "companion piece" where I try to explain those ideas in a more
  understandable language.
  There are essentially three ideas in this paper:
</html:p>
                <html:p>
  -   "Markov categories for synthetic probability theory" - this is only treated
      briefly, since this is just the background that we're building on top of.
      Tobias has a long paper on this, <fr:link href="https://arxiv.org/abs/1908.07021" type="external">A synthetic approach to Markov kernels,
      conditional independence and theorems on sufficient statistics</fr:link>.
  -   "Kolmogorov products" - a take on tensor products of infinitely many objects.
      These are introduced into the framework to handle probabilistic systems with
      infinitely many variables.
  -   "Zero-One Laws". These are theorems from probability theory of the form "If an
      event <fr:tex display="inline"><![CDATA[A]]></fr:tex> satisfies ..., then <fr:tex display="inline"><![CDATA[P(A) \in  0,1]]></fr:tex>" - i.e either it always happens
      or it never happens. For two classical ones, Kolmogorov's and Hewitt-Savage's,
      we give a way of phrasing them in the categorical language and prove them.
</html:p>
                <html:p>
  In this post, I'll try to give an accessible take on these ideas. I'll assume
  some familiarity with category theory, and a _very_ small amount of familiarity
  with probability theory
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>26</fr:day>
                </fr:date>
                <fr:title text="What do you mean, &quot;synthetic probability theory&quot;">What do you mean, "synthetic probability theory"</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>26</fr:day>
                    </fr:date>
                    <fr:title text="Synthetic vs analytic">Synthetic vs analytic</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    (This is a weird rambly section. Feel free to skip it)
</html:p>
                    <html:p>
    Think about plane geometry for a moment. Let's contrast two approaches:
    In the "Euclidean" approach, we work without any reference to what a point, a
    line, and so on, _is_[^fn:1]. We simply have certain
    axioms which relate lines and points, certain properties (like congruence) which
    things can have or not have, and so on. We could also call this approach
    _formal_, or maybe _syntactical_.
    We can contrast this with how plane geometry might be treated in the modern
    world:
</html:p>
                    <html:p>
    -   A point is an element of <fr:tex display="inline"><![CDATA[\mathbb {R}^2]]></fr:tex>.
    -   A line is a subset of <fr:tex display="inline"><![CDATA[\mathbb {R}^2]]></fr:tex> such that ...
</html:p>
                    <html:p>
    and so on.
    Here a point is really a particular _thing_, so is a line, and the statement
    "The angle <fr:tex display="inline"><![CDATA[ABC]]></fr:tex> equals the angle <fr:tex display="inline"><![CDATA[CBD]]></fr:tex>" is defined in terms of the things that
    <fr:tex display="inline"><![CDATA[A,B,C,D]]></fr:tex> are, rather than being a more or less irreducible notion. We call such
    an approach _analytical_.
    Another way of looking at it is that Euclidean geometry admits several distinct
    models (particularly if we abandon certain axioms, e.g. the parallel postulate).
    On the other hand, the analytical approach of
    <fr:tex display="inline"><![CDATA[\mathbb {R}^2]]></fr:tex> augmented with some structure is a _specific_ model.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>26</fr:day>
                    </fr:date>
                    <fr:title text="Markov categories">Markov categories</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The classical approach to probability theory is analytical - a probability space
    <fr:tex display="inline"><![CDATA[(\Omega ,\Sigma ,P)]]></fr:tex> is a specific thing with a specific structure.
    We want to contrast this to a synthetic approach to probability theory.
    One "model" of our synthetic approach will be "classical probability theory",
    i.e measures and <fr:tex display="inline"><![CDATA[\sigma ]]></fr:tex> algebras.
    Another model will be given by "possibility theory", where each outcome either
    happens or doesn't happen. And there are many other exoctic models like that.
</html:p>
                    <html:p>
    This approach is called Markov categories.
    It is a notion which has been developed by several different authors under
    different names - see the paper by Fritz above for a review of the literature
    (and a much more in-depth treatment of Markov categories).
</html:p>
                    <html:p>
    A Markov category is a symmetric monoidal category <fr:tex display="inline"><![CDATA[(\mathsf {C},\otimes ,I)]]></fr:tex>,
    where the monoidal unit is terminal, where each object <fr:tex display="inline"><![CDATA[X \in  \mathsf {C}]]></fr:tex> carries a distinguished cocommutative
    comonoid structure <fr:tex display="inline"><![CDATA[\operatorname {copy}_X: X \to  X \otimes  X,
    \operatorname {del}_X: X \to  I]]></fr:tex>
    and such that the symmetric monoidal structure isomorphisms
    are homomorphisms[^fn:2].
    See Tobias' paper for an unpacking of this definition.
</html:p>
                    <html:p>
    The interpretation of a Markov category is that the objects are "spaces" that
    our random variables can take values in, and the maps are "stochastic processes"
    or "kernels", i.e functions which produce their output somewhat randomly.
    The tensor product of two objects <fr:tex display="inline"><![CDATA[X \otimes  Y]]></fr:tex> is the "product space" where points are pairs
    of points <fr:tex display="inline"><![CDATA[(x,y)]]></fr:tex> - but note that this is _not_ a product in the categorical
    sense, since, give a random map <fr:tex display="inline"><![CDATA[A \to  X \otimes  Y]]></fr:tex>, we can not in general
    recover it from the "marginals" or "projections" <fr:tex display="inline"><![CDATA[A \to  X]]></fr:tex> and <fr:tex display="inline"><![CDATA[A \to  Y]]></fr:tex>.
    This is because the random values of <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y]]></fr:tex> may be _dependent_.
    On the other hand, we do have "diagonal" maps <fr:tex display="inline"><![CDATA[X \to  X \otimes  X]]></fr:tex> - which
    non-randomly send <fr:tex display="inline"><![CDATA[x]]></fr:tex> to <fr:tex display="inline"><![CDATA[(x,x)]]></fr:tex> - and a "projection" map <fr:tex display="inline"><![CDATA[X \to  I]]></fr:tex>, which is
    actually unique (there is precisely one way to randomly generate an element of
    the one-point space).
</html:p>
                    <html:p>
    A map <fr:tex display="inline"><![CDATA[I \to  X]]></fr:tex> is called a _distribution on <fr:tex display="inline"><![CDATA[X]]></fr:tex>_, and should be thought of as
    the abstract version of a probability measure.
    For instance, if <fr:tex display="inline"><![CDATA[P:I \to  X]]></fr:tex> is a distribution, and <fr:tex display="inline"><![CDATA[f: X \to  Y]]></fr:tex> is a map, then
    we can make sense of this diagram:
</html:p>
                    <html:img src="/bafkrmigioy4kmaje5seq65uwymazjrqpab3z5qw2qxymsgc3p7ncjhvndy.png" title="" />
                    <html:p>
    it is the distribution on
    <fr:tex display="inline"><![CDATA[X \otimes  Y]]></fr:tex> where <fr:tex display="inline"><![CDATA[x \in  X]]></fr:tex> is sampled according to <fr:tex display="inline"><![CDATA[\psi ]]></fr:tex>, then <fr:tex display="inline"><![CDATA[y \in  Y]]></fr:tex> is
    sampled according to <fr:tex display="inline"><![CDATA[f(x)]]></fr:tex>. Note the bullet which denotes the copying operator.
</html:p>
                    <html:p>
    We can define a few different standard terms from probability theory in this
    context.
</html:p>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2020</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>26</fr:day>
                        </fr:date>
                        <fr:title text="Independence">Independence</fr:title>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
      Given a map <fr:tex display="inline"><![CDATA[f: A \to  X \otimes  Y]]></fr:tex>, we can ask whether <fr:tex display="inline"><![CDATA[X,Y]]></fr:tex> are /independent given
      <fr:tex display="inline"><![CDATA[A]]></fr:tex> /. The intuition here is that given some <fr:tex display="inline"><![CDATA[a \in  A]]></fr:tex>, if I sample <fr:tex display="inline"><![CDATA[(x,y)]]></fr:tex> from
      <fr:tex display="inline"><![CDATA[f(a)]]></fr:tex> and tell you what the <fr:tex display="inline"><![CDATA[x]]></fr:tex> was, that gives you no information about the
      <fr:tex display="inline"><![CDATA[y]]></fr:tex> (given that you know what the <fr:tex display="inline"><![CDATA[a]]></fr:tex> was).
      In diagram form, this looks like this:
</html:p>
                        <html:img src="/bafkrmiazpyhiugsq6m2bpabbvjo6yjis65r7owumsvt7lstjw6cs4jorcm.png" title="" />
                        <html:p>
      The basic idea here is that it makes no difference whether we generate <fr:tex display="inline"><![CDATA[(x,y)]]></fr:tex>
      together in one go, or separately (using the same <fr:tex display="inline"><![CDATA[a]]></fr:tex>).
    </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2020</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>26</fr:day>
                        </fr:date>
                        <fr:title text="Determinism">Determinism</fr:title>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
      A map <fr:tex display="inline"><![CDATA[f: A \to  B]]></fr:tex> is _deterministic_ if we have this equality:
</html:p>
                        <html:img src="/bafkrmicgdb7zp3nx6k27efijstsubmzbqx5gbpqaiujzdqam272jnjhic4.png" title="" />
                        <html:p>
      This means if we run <fr:tex display="inline"><![CDATA[f]]></fr:tex> twice with the same <fr:tex display="inline"><![CDATA[a \in  A]]></fr:tex>, we get the same <fr:tex display="inline"><![CDATA[b \in 
      B]]></fr:tex> out. This is a reasonable definition of "deterministic".
</html:p>
                        <html:p>
      Note that in both these cases, the existence of the comonoid structure is
      _exactly_ what we needed to make sense of the probabilistic notion.
    </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                    <fr:tree show-metadata="false">
                      <fr:frontmatter>
                        <fr:authors>
                          <fr:author>
                            <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                          </fr:author>
                        </fr:authors>
                        <fr:date>
                          <fr:year>2020</fr:year>
                          <fr:month>4</fr:month>
                          <fr:day>26</fr:day>
                        </fr:date>
                        <fr:title text="Examples">Examples</fr:title>
                      </fr:frontmatter>
                      <fr:mainmatter>
                        <html:p>
      -   There is a Markov category <fr:tex display="inline"><![CDATA[\mathsf {Stoch}]]></fr:tex> where the objects are measurable
          spaces, and the maps are <fr:link href="https://en.wikipedia.org/wiki/Markov_kernel" type="external">Markov Kernels</fr:link></html:p>
                        <html:p>
      -   There is a Markov category <fr:tex display="inline"><![CDATA[\mathsf {FinStoch}]]></fr:tex> where the objects are finite
          sets and the maps are stochastic matrices. It is a full subcategory of
          <fr:tex display="inline"><![CDATA[\mathsf {Stoch}]]></fr:tex>.
      -   There is a Markov category called <fr:tex display="inline"><![CDATA[\mathsf {SetMulti}]]></fr:tex> where the objects are
          sets and the maps are "total relations", i.e relations <fr:tex display="inline"><![CDATA[X \to  Y]]></fr:tex> where each
          element <fr:tex display="inline"><![CDATA[x \in  X]]></fr:tex> is related to at least one element in <fr:tex display="inline"><![CDATA[Y]]></fr:tex>.
      -   There is a Markov category <fr:tex display="inline"><![CDATA[\mathsf {Gauss}]]></fr:tex> where objects are natural numbers,
          and maps <fr:tex display="inline"><![CDATA[n \to  m]]></fr:tex> are "affine maps <fr:tex display="inline"><![CDATA[\mathbb {R}^n \to  \mathbb {R}^m]]></fr:tex> plus constant Gaussian noise"
</html:p>
                        <html:p>
      For (many) more examples, see Tobias' paper.
    </html:p>
                      </fr:mainmatter>
                    </fr:tree>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>26</fr:day>
                </fr:date>
                <fr:title text="Infinite tensor products">Infinite tensor products</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Most theorems in probability theory involve infinite families of variables.
  To make sense of that in our framework, we need to make sense of "distributions
  on infinite product spaces", which means we need a notion of "infinite tensor
  product".
  The definition goes like this: Let <fr:tex display="inline"><![CDATA[\{X_j\}_{j \in  J}]]></fr:tex> be a collection of
  objects in a markov category <fr:tex display="inline"><![CDATA[\mathsf {C}]]></fr:tex>.
  For each finite subset <fr:tex display="inline"><![CDATA[F \subset  J]]></fr:tex>, we can make sense of the tensor product
  <fr:tex display="inline"><![CDATA[\bigotimes _{j \in  F} X_j]]></fr:tex>[^fn:3]. Since the tensor unit is terminal, we have natural maps
  <fr:tex display="inline"><![CDATA[\bigotimes _{J \in  F'} X_j \to  \bigotimes _{j \in  F} X_j]]></fr:tex> for each inclusion of
  finite sets <fr:tex display="inline"><![CDATA[F \subset  F']]></fr:tex>.
  Then we can ask for a cofiltered limit of this system:
</html:p>
                <fr:tex display="block"><![CDATA[\lim _{F \subset  J} \bigotimes _{j \in  F} X_j]]></fr:tex>
                <html:p>
  This is a reasonable definition of "infinite tensor product",
  which we can denote <fr:tex display="inline"><![CDATA[\bigotimes _{j \in  J} X_j]]></fr:tex>
  However, it turns out we need one more condition.
  The issue is that in a Markov category, having an object defined up to
  isomorphism is not always good enough - we want it up to _deterministic
  isomorphism_, so that the comonoid structure is determined as well.
  The natural condition to add to make sure we pick the "right" limit is that each
  of the projections <fr:tex display="inline"><![CDATA[\bigotimes _{j \in  J} X_j \to  \bigotimes _{j \in  F} X_j]]></fr:tex>, for
  each finite subset, is deterministic.
  Such an infinite tensor product, we called a _Kolmogorov product_.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>26</fr:day>
                </fr:date>
                <fr:title text="Kolmogorov's Zero-One Theorem, abstractly">Kolmogorov's Zero-One Theorem, abstractly</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  With this setup, it turns out it's very easy to prove an abstract version of
  <fr:link href="https://en.wikipedia.org/wiki/Kolmogorov's_zero–one_law" type="external">Kolmogorov's Zero-One Law</fr:link>.
  Informally, the content of the law is this: suppose you have a family <fr:tex display="inline"><![CDATA[(X_n)]]></fr:tex> of
  independent random variables, and some event <fr:tex display="inline"><![CDATA[A]]></fr:tex> which is determined by these
  variables, but is independent of any finite subset of them. Then <fr:tex display="inline"><![CDATA[P(A) \in  \{0,1\}]]></fr:tex></html:p>
                <html:p>
  Here is our abstract version:
  Let <fr:tex display="inline"><![CDATA[(X_j)_{j \in  J}]]></fr:tex> be objects so that the Kolmogorov product <fr:tex display="inline"><![CDATA[\bigotimes _{j \in  K}]]></fr:tex> exists. 
  Let <fr:tex display="inline"><![CDATA[p: A \to  \bigotimes _{j \in  J} X_j]]></fr:tex> be a map, and <fr:tex display="inline"><![CDATA[s :  \bigotimes _{j \in  J}
  X_j \to  T]]></fr:tex> be a deterministic map.
  Suppose <fr:tex display="inline"><![CDATA[p]]></fr:tex> displays the conditional independence of the <fr:tex display="inline"><![CDATA[X_j]]></fr:tex> given <fr:tex display="inline"><![CDATA[A]]></fr:tex>, and
  that for every finite <fr:tex display="inline"><![CDATA[F \subset  J]]></fr:tex>, the joint distribution
</html:p>
                <html:img src="/bafkrmifpshw34l6lru7pmgazssraqgogfhe4acv5jctbvamoymgjz57ifm.png" title="" />
                <html:p>
  displays the independence of <fr:tex display="inline"><![CDATA[X_F]]></fr:tex> and <fr:tex display="inline"><![CDATA[T]]></fr:tex> given <fr:tex display="inline"><![CDATA[A]]></fr:tex>.
  (Here <fr:tex display="inline"><![CDATA[X_F = \bigotimes _{j \in  F} X_j]]></fr:tex>).
  Then the composite <fr:tex display="inline"><![CDATA[sp : A \to  T]]></fr:tex> is deterministic.
</html:p>
                <html:p>
  I will sketch the proof (see the paper for details).
  Essentially, we first prove that <fr:tex display="inline"><![CDATA[T]]></fr:tex> is independent of all the <fr:tex display="inline"><![CDATA[X_j]]></fr:tex>, not just
  the finite subsets.
  To see this, we note that the definition of independence is comparing two maps
  into
  <fr:tex display="inline"><![CDATA[T \otimes  \bigotimes _{j\in  J} X_j]]></fr:tex>.
  This is a limit, so it's enough to show that all the component maps, which are
  the maps for finite <fr:tex display="inline"><![CDATA[F \subset  J]]></fr:tex>, agree - this is true by definition.
  Now it follows by a string diagram manipulation that <fr:tex display="inline"><![CDATA[sp]]></fr:tex> satisfies the
  definition of determinism:
</html:p>
                <html:img src="/bafkrmicxenrkzv2qp3pwamqqcubyjcclnrjal6rjmvvhwyrvplucswjv5u.png" title="" />
                <html:p>
  This concludes the proof.
</html:p>
                <html:p>
  To recover the classical Kolmogorov 0-1 law, we must do a little bit of
  technical work.
  We work in the Markov category <fr:tex display="inline"><![CDATA[\mathsf {BorelStoch}]]></fr:tex> of _standard Borel spaces_.
  This Markov category has countable Kolmogorov products[^fn:4]. We let <fr:tex display="inline"><![CDATA[A = *]]></fr:tex> and let
  our <fr:tex display="inline"><![CDATA[X_j]]></fr:tex> be the _spaces_ that the variables <fr:tex display="inline"><![CDATA[X_j]]></fr:tex> from the theorem take values
  in.
  We let the map <fr:tex display="inline"><![CDATA[p]]></fr:tex> give the joint distribution of the variables.
  We let <fr:tex display="inline"><![CDATA[T = \{0,1\}]]></fr:tex>, and we let <fr:tex display="inline"><![CDATA[s]]></fr:tex> be the indicator for the event.
  Then the theorem says that the composite <fr:tex display="inline"><![CDATA[sp]]></fr:tex> is deterministic.
  So the probability that <fr:tex display="inline"><![CDATA[sp]]></fr:tex> is <fr:tex display="inline"><![CDATA[1]]></fr:tex>, which is the probability that the event
  happens, is either zero or one.
</html:p>
                <html:p>
  [^fn:1]: Euclid actually did try to define notions like lines, points, etc, but we're gonna use his name anyways
  [^fn:2]: Note that we're not assuming all maps, or even all isomorphisms, are homomorphic. This makes Markov categories an evil notion
  [^fn:3]: I am handwaving some non-issues with regards to non-strictness here
  [^fn:4]: It turns out that proving this is significantly harder than proving the abstract theorem, once you have the setup
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>4</fr:month>
              <fr:day>13</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/bivariate-causal-inference/</fr:uri>
            <fr:display-uri>bivariate-causal-inference</fr:display-uri>
            <fr:route>/bivariate-causal-inference/</fr:route>
            <fr:title text="Bivariate Causal Inference">Bivariate Causal Inference</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>13</fr:day>
                </fr:date>
                <fr:title text="TLDR">TLDR</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  I give a very short introduction to the idea of "causality" in statistics, then
  talk about two ways to infer causal structure for two variables - i.e, without
  using conditional independence statements.
  The ideas here are mostly taken from <fr:link href="https://mitpress.mit.edu/books/elements-causal-inference" type="external">Peters, Janzing, and Schölkopf: Elements of
  causal inference: foundations and learning algorithms.</fr:link></html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>13</fr:day>
                </fr:date>
                <fr:title text="What is causality?">What is causality?</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  A "causal statistical model" is something like this:
</html:p>
                <html:img src="/bafkrmiasazdctq7wxvwistm2qlqheqxnevgtd5liyt32tpuhnadowixmni.png" title="" />
                <html:p>
  Or this
</html:p>
                <html:img src="/bafkrmiawfx24b2z4yicfvaamzogjdrembjkenofqlm2xx3xidzgwpdjdby.png" title="" />
                <html:p>
  Where a classical statistical model tells you what the probability of various
  outcomes are, (which you can then use to derive conditional probabilities, etc),
  a causal model gives you more information - it tells you how the distribution
  changes when the system is intervened on.
  For instance, in the first model above, intervening on <fr:tex display="inline"><![CDATA[X]]></fr:tex> has no effect on the
  distribution of <fr:tex display="inline"><![CDATA[Z]]></fr:tex>, whereas in the latter, the distribution of <fr:tex display="inline"><![CDATA[Z]]></fr:tex>
  after the intervention <fr:tex display="inline"><![CDATA[X := x_0]]></fr:tex> is exactly the conditional distribution
  <fr:tex display="inline"><![CDATA[P(Z=z|X=x_0)]]></fr:tex>.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>13</fr:day>
                </fr:date>
                <fr:title text="Causal inference by conditional independence">Causal inference by conditional independence</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We can actually distinguish between the two causal structures above without
  doing interventional experiments.
  This is because in the first model, <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Z]]></fr:tex> are independent, but don't
  (necessarily) remain independent after conditioning on <fr:tex display="inline"><![CDATA[Y]]></fr:tex>.
  For instance, if <fr:tex display="inline"><![CDATA[Y = X+Z]]></fr:tex>, learning that <fr:tex display="inline"><![CDATA[Y]]></fr:tex> has a certain value tells us
  exactly how to compute <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Z]]></fr:tex> from each other.
  On the other hand, in the second model, <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Z]]></fr:tex> are not (necessarily)
  independent, but after conditioning on <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, they _are_. That's because the
  dependency of <fr:tex display="inline"><![CDATA[Z]]></fr:tex> on <fr:tex display="inline"><![CDATA[X]]></fr:tex> only "goes through" <fr:tex display="inline"><![CDATA[Y]]></fr:tex>, so if we already know what <fr:tex display="inline"><![CDATA[Y]]></fr:tex>
  is, learning about <fr:tex display="inline"><![CDATA[X]]></fr:tex> tells us nothing about <fr:tex display="inline"><![CDATA[Z]]></fr:tex>.
</html:p>
                <html:p>
  Why are <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Z]]></fr:tex> independent in the first model? This is because of a basic
  principle of causal modeling, which we can paraphrase as "all (conditional or
  unconditional) dependencies between variables must be explained by causal
  structure".
  (Formally, the distribution has the _markov property_ with respect to the
  graph).
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>4</fr:month>
                  <fr:day>13</fr:day>
                </fr:date>
                <fr:title text="Bivariate causal inference">Bivariate causal inference</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  We can use conditional (in)dependence to try to tell causal graphs apart. But we
  can't always do this. For instance, this graph:
</html:p>
                <html:img src="/bafkrmib35yzudgldvwdnghf32nh46pxt3iwshngw2n3nmd6els2n7skcvu.png" title="" />
                <html:p>
  Gives rise to exactly the same independence statements as graph 2 above.
  (We say they are "Markov equivalent").
  The worst case is the case where we have just two variables - since both graphs
  <fr:tex display="inline"><![CDATA[X \to  Y]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y \to  X]]></fr:tex> are Markov equivalent.
  (And the third possible DAG, <fr:tex display="inline"><![CDATA[X\ Y]]></fr:tex>, corresponds to the statement that <fr:tex display="inline"><![CDATA[X]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y]]></fr:tex> are independent - not very
  interesting).
</html:p>
                <html:p>
  How can we get around this problem, and detect causal structure when we only
  have two variables?
  Let's make it concrete, and say that <fr:tex display="inline"><![CDATA[X]]></fr:tex> is a variable that measures whether or
  not a person smokes, and <fr:tex display="inline"><![CDATA[Y]]></fr:tex> measures cancer. We observe a strong correlation. We have supposed there are no
  confounding variables, but now we still have the question: does smoking cause
  cancer, or does cancer cause smoking?
</html:p>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>13</fr:day>
                    </fr:date>
                    <fr:title text="Do an interventional experiment">Do an interventional experiment</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The easiest way is to just test our theory directly against nature.
    The difference between the statements <fr:tex display="inline"><![CDATA[X \to  Y]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y \to  X]]></fr:tex> is whether or not
    doing the intervention <fr:tex display="inline"><![CDATA[X := x_0]]></fr:tex> will affect <fr:tex display="inline"><![CDATA[Y]]></fr:tex> or not.
    In other words, we can take a large number of people, randomly assign them to
    either smoke or not smoke, then come back a few years later and see whether the
    smokers have more cancer.
    This experiment may not get past the ethics board.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>13</fr:day>
                    </fr:date>
                    <fr:title text="Use domain knowledge">Use domain knowledge</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The idea that cancer causes smoking seems pretty dumb.
    People generally start smoking, then develop cancer many years later.
    We could try to build this idea into a more complicated causal model (with more
    variables), which we could statistically test, but we could also just take
    seriously the fact that the hypothesis "cancer causes smoking" is prima facie
    much less plausible than "smoking causes cancer".
</html:p>
                    <html:p>
    These two solutions are both pretty unsatisfying.
    Fortunately, we also have more sophisticated tools.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>13</fr:day>
                    </fr:date>
                    <fr:title text="Independent mechanisms.">Independent mechanisms.</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    The basic idea is this: if the causal structure is that smoking causes cancer,
    then whatever process turns smoking into cancer is independent of the process
    that makes people smoke.
    This means that learning the conditional distribution
    <fr:tex display="inline"><![CDATA[P(\mathrm {Cancer}|\mathrm {Smoking})]]></fr:tex> tells you nothing about the distribution
    <fr:tex display="inline"><![CDATA[P(\mathrm {Smoking})]]></fr:tex> itself. On the other hand, learning the smoking rates of
    cancer victims and non-cancer victims does in fact tell you something about the
    cancer rate.
    This is called "The principle of independent mechanisms".
    The "mechanisms" in question are the distributions <fr:tex display="inline"><![CDATA[P(\mathrm {Smoking})]]></fr:tex> and
    <fr:tex display="inline"><![CDATA[P(\mathrm {Cancer}|\mathrm {Smoking})]]></fr:tex>. They are "independent" in the sense that
    each contains no information about the other.
    From this principle, we can derive some algorithms for testing the causal
    relationship.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>13</fr:day>
                    </fr:date>
                    <fr:title text="Semi-Supervised Learning">Semi-Supervised Learning</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    Suppose we try to train a machine learning algorithm to predict whether a person
    has cancer based on whether or not they smoke.
    We provide the algorithm with a number of samples <fr:tex display="inline"><![CDATA[(X_i,Y_i)]]></fr:tex>, each consisting
    of a "smoking?" and a "cancer?" measurement.
    We also provide it with a number of _unlabeled_ samples, <fr:tex display="inline"><![CDATA[X_j]]></fr:tex>, with only the
    "smoking?" measurement.
    This is sometimes called "semi-supervised learning".
    Do these extra samples help the algorithm?
    The principle of independent mechanisms says "no". These samples only provide
    information about the distribution <fr:tex display="inline"><![CDATA[P(\mathrm {Smoking})]]></fr:tex>, which gives no
    information on the conditional <fr:tex display="inline"><![CDATA[P(\mathrm {Cancer|Smoking})]]></fr:tex>.
    On the other hand, if we're trying to predic smoking from cancer, knowing
    something about the general cancer rate may actually help.
    Thus we can try to distinguish <fr:tex display="inline"><![CDATA[X \to  Y]]></fr:tex> and <fr:tex display="inline"><![CDATA[Y \to  X]]></fr:tex> from each other by seeing
    whether adding the unlabeled samples helps or not.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
                <fr:tree show-metadata="false">
                  <fr:frontmatter>
                    <fr:authors>
                      <fr:author>
                        <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                      </fr:author>
                    </fr:authors>
                    <fr:date>
                      <fr:year>2020</fr:year>
                      <fr:month>4</fr:month>
                      <fr:day>13</fr:day>
                    </fr:date>
                    <fr:title text="Independent noise">Independent noise</fr:title>
                  </fr:frontmatter>
                  <fr:mainmatter>
                    <html:p>
    Linear models are ubiquitous in statistics. A linear model for <fr:tex display="inline"><![CDATA[X \to  Y]]></fr:tex>, based
    on the principle of independent mechanisms, may look like this:
</html:p>
                    <html:p>
    -   <fr:tex display="inline"><![CDATA[X := a + bN_1]]></fr:tex>
    -   <fr:tex display="inline"><![CDATA[Y := c + dX + eN_2]]></fr:tex>
    -   <fr:tex display="inline"><![CDATA[N_1,N_2 \sim  \mathcal {N}(0,1)]]></fr:tex>
    -   <fr:tex display="inline"><![CDATA[N_1,N_2]]></fr:tex> independent.
</html:p>
                    <html:p>
    In other words, <fr:tex display="inline"><![CDATA[X]]></fr:tex> is normally distributed, then <fr:tex display="inline"><![CDATA[Y]]></fr:tex> is a sum of <fr:tex display="inline"><![CDATA[X]]></fr:tex> times a constant and
    another normal distribution.
    The crucial property of this model is the independence of the noise variables.
    If we run a linear regression to predict <fr:tex display="inline"><![CDATA[Y]]></fr:tex> from <fr:tex display="inline"><![CDATA[X]]></fr:tex>, we will get an error term
    of (on average) <fr:tex display="inline"><![CDATA[eN_2]]></fr:tex> - this is independent of <fr:tex display="inline"><![CDATA[X]]></fr:tex>.
    But in the other direction, we get <fr:tex display="inline"><![CDATA[X = Y/d - c/d]]></fr:tex> with an error term of, on
    average, <fr:tex display="inline"><![CDATA[\frac {e}{d} N_2]]></fr:tex> - which is _not_ independent of <fr:tex display="inline"><![CDATA[Y]]></fr:tex> (since <fr:tex display="inline"><![CDATA[Y]]></fr:tex> depends on
    <fr:tex display="inline"><![CDATA[N_2]]></fr:tex>).
    Hence we can find the causal direction by running two linear regressions and
    seeing when we get an independent noise term.
  </html:p>
                  </fr:mainmatter>
                </fr:tree>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>2</fr:month>
              <fr:day>28</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/2020-02-28-how-to-make-a-website/</fr:uri>
            <fr:display-uri>2020-02-28-how-to-make-a-website</fr:display-uri>
            <fr:route>/2020-02-28-how-to-make-a-website/</fr:route>
            <fr:title text="How to Make A Website">How to Make A Website</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Here's what goes into a website.
</html:p>
            <html:ul><html:li>A server (hardware).</html:li>
  <html:li>The software which runs on the server, also called a server.</html:li>
  <html:li>A domain (optional)</html:li>
  <html:li>An SSL certificate (technically optional but highly recommended)</html:li></html:ul>
            <html:p>
I will explain what these terms mean, and how to get your own stuff set up.
Please note that this is a guide for people who want to do everything from scratch. There are plenty of easier ways to set up a website. For instance:
</html:p>
            <html:ul><html:li>Any of a number of blogging systems, like <fr:link href="https://wordpress.com/" type="external">wordpress.com</fr:link>, which will also help you hook up your own domain.</html:li>
  <html:li><fr:link href="https://nearlyfreespeech.com/" type="external">nearlyfreespeech.com</fr:link> - an extremely cheap option if you want to do some things yourself. If your website is just a collection of static pages, this is an easy way to put it on the internet.</html:li>
<html:p /></html:ul>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="How the internet works">How the internet works</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  When you type "reddit.com" into your browser, here's what happens:
</html:p>
                <html:p>
  - Your computer sends a signal to something called a "DNS server", saying "I need to find 'reddit.com'. Can you tell me where it is?".
  - Since the people who operate reddit have previously left their address at the DNS server, it says, "yes, you can find it at 151.101.193.140".
  - Then your computer sends a new message to 151.101.193.140, saying essentialy "I'd like your home page, please"
      - (if you'd typed in "reddit.com/r/stuff", it would say "I'd like what you have at '/r/stuff', please").
  - Your ISP uses those numbers to find the reddit server, which is just a computer running in a warehouse somewhere.
  - The reddit server sends a message back containing their home page
  - Your browser displays the page.
</html:p>
                <html:p>
  Now, what we want to do is the same thing that reddit is doing. So, let's go over the list of things again:
</html:p>
                <html:p>
  - We need a __domain__, a name for people to find the website. In principle, you can just tell people an IP address like 151.101.193.140, and not use a domain, but that's kind of inconvenient to remember.
  - Basically, to get a domain, you pay the people in charge of domains some money for ownership of it. Then they write down in the big list of domains that  "awesome-website-stuff.xyz" belongs to so and so, and that the IP address is such and such.
      - (In reality, you buy your domain from an intermediary organization, of which there are many)
  - We need an actual server, to send the message to people who ask for it. A server is really just a computer - you could "serve" your website from your desktop computer, if you wanted to. In practice, you'll want your server to be running all the time, so it'll probably be easier to rent one. There are many services to do this.
  - Then you'll need to run a program on the server which can interpret the messages from people who want to see your website and respond with the website. Confusingly, this program is often also called a server.
  - Lastly, for security reasons, you may want your website in HTTPS. This makes sure the contents of your site are secure. If you'll be sending and receiving information which is not public, this is absolutely essential. Even if you just have a public-facing website with nothing secret on it, setting up HTTPS is a good idea - for instance, it ensures that an attacker can't fake messages from your website, so people can trust that it's really you writing what you put on your website.
</html:p>
                <html:p>
  Before we proceed, I should mention that I AM NOT A SECURITY EXPERT. If you're going to be handling any sort of sensitive information, please, PLEASE, do some research, and try to consult with someone who knows what they're doing. If you only follow my advice, you should assume that anything you put on your server is immediately compromised.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Server (hardware)">Server (hardware)</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Basically, we're going to rent a computer from someone for your website to run on. There's a bunch of services to do this, each with their own advantages and problems.
</html:p>
                <html:p>
  My personal website uses <fr:link href="https://linode.com/" type="external">Linode</fr:link>. Their servers start at $5/month for a so-called "nanode". When I need to explain something, I'll use that as the example.
</html:p>
                <html:p>
  I won't say that I have any great familiarity with the market, so do your own research. The important point for this tutorial is that you get full root access to a server running something like Ubuntu linux.
</html:p>
                <html:p>
  A lot of services "manage" you in various ways - providing a standardized webserver (as in, __software__ running on your server), limiting the stuff you can do on the server, etc etc. These are not necessarily bad ideas, but it's not what we're looking for.
</html:p>
                <html:p>
  You can also run whatever OS you want on your server.
  You'll almost certainly want some variation of Linux. I'll use Ubuntu for this guide. If you're using a different version, things will obviously be different.
</html:p>
                <html:p>
  - Buy a server somewhere
  - Set it up to run a recent version of Ubuntu.
  - Make sure you know the root password of your server (you should be able to view or set this on the website of your provider)
  - Then find its IP address.
      - Here's how this looks on Linode:
</html:p>
                <html:img src="https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2FEigilRischel%2F-ZIWgCcytN?alt=media&amp;token=96ceb429-a6cc-43d7-a265-63b57afd1970" title="" />
                <html:p>
  You can see the IP addresses on the right.
</html:p>
                <html:p>
  - Do `ssh root@x.y.z.w`, substituting the actual IP address
  - Log in using the root password
</html:p>
                <html:p>
  Now you're running a terminal on your server.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Server (software)">Server (software)</fr:title>
              </fr:frontmatter>
              <fr:mainmatter><html:p>
  We're gonna use a program called <fr:link href="http://nginx.org/" type="external">nginx</fr:link> to serve our website.
</html:p><html:p>
  - While `ssh`ed into your server, do `apt update` and `apt install nginx` to install nginx.
  - To start nginx, do `/etc/init.d/nginx start`
  - To test that it's working, open up a browser and type your ip into the address bar. Your should see a page like this:
</html:p><html:img src="https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2FEigilRischel%2F1mUuZpp4mb?alt=media&amp;token=8998a9a4-384e-4528-976b-25db5bcf1213" title="" /><html:p>
  Now, I'll explain how to configure nginx to serve your website.
</html:p><html:p>
  - For this basic tutorial, we'll just set up nginx to serve some .html files in a directory. For a more complicated website, you'll probably want __dynamic__ content, i.e content which is generated by a program running on your server, rather than just read from a file. You can set up nginx to do this, but I won't cover that.
  - By default, nginx uses the directory `/var/www/` for websites. We're gonna stick with that. Now would be a good time to make up a domain name for your website. Do `mkdir -p /var/www/example.com/html`
  - Create `/var/www/example.com/html/index.html` using `nano` or another editor. For now, just put this text in it:
</html:p><![CDATA[  <html>
      <head>
          <title>Welcome to example.com!</title>
      </head>
      <body>
          <h1>Success!  The example.com server block is working!</h1>
      </body>
  </html>]]><html:p>
  - Now create the file `/etc/nginx/sites-available/example.com`. Paste this into it:
</html:p><![CDATA[  server{
          listen 80;
          listen [::]:80;
  
          root /var/www/example.com/html;
          index index.html index.htm index.nginx-debian.html;
  
          server_name example.com www.example.com;
  
          location / {
                  try_files $uri $uri/ =404;
          }
  }]]><html:p>
  - Create symlink to this file in the sites-enabled directory:
      - `ln -s /etc/nginx/sites-available/example.com /etc/nginx sites-enabled/`
  - nginx is configured by default to serve out of `/var/www/html` - disable the default configuration by doing `rm /etc/nginx/sites-enabled/default`
      - This will make the directory we've set up the default one. Don't worry, the default configuration file is still available in `sites-available/`
  - Now test that we didn't fuck up by doing `nginx -t` - this scans the configuration files for errors
  - Then restart nginx: `systemctl restart nginx.service`
  - Hopefully going to your server in a browser (by typing in the ip) will now show the page we made.
</html:p></fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="Obtaining a domain">Obtaining a domain</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Now let's buy the `example.com` domain.
</html:p>
                <html:p>
  - As mentioned, there are tons of places to buy a domain. Let's go with <fr:link href="https://hover.com/" type="external">hover</fr:link>
  - Create an account and buy your chosen domain.
  - Now you'll want to point your domain at the linode server.
  - When using Linode, the easiest way to do this to use linode's nameservers. 
  - On the Hover control panel, you can see a list of "Nameservers"
</html:p>
                <html:img src="https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2FEigilRischel%2F2LIWYtNPvB?alt=media&amp;token=c58149c1-9ad0-4902-a83a-86540c7c4e28" title="" />
                <html:p>
  - Click edit, and set these to what you see there - `ns1.linode.com` etc
  - Then log on to Linode, go to "Domains" in the left-hand menu, click "add a new domain", and fill out the information:
</html:p>
                <html:img src="https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2FEigilRischel%2FGTbVkDHWxv?alt=media&amp;token=70a86e84-1872-40e8-a6e5-cd8b6034fe38" title="" />
                <html:p>
  (Obviously you'll type in your domain at the top). Note that you __must__ enter an email address.
</html:p>
                <html:p>
  - The default settings created like this should work.
      - For reference, here's how mine looks:
</html:p>
                <html:img src="https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2FEigilRischel%2FQBBPjZSd6-?alt=media&amp;token=853eaef4-2bce-4026-bfe8-065d05050583" title="" />
                <html:p>
  - Now you should be able to go to `example.com` or `www.example.com` and see your website.
  - If you can't, one possibility is that your browser (sensibly) won't let you connect to an unsecured website. We'll fix that now.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="HTTPs">HTTPs</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Now we'll set up security for your site. Luckily, this is super easy.
</html:p>
                <html:p>
  - `ssh` into your server and do `apt install certbot python3-certbot-nginx`
  - This installs the auto-setup tool `certbot` from the <fr:link href="https://www.letsencrypt.org/" type="external">Let's Encrypt</fr:link> project, as well as the plugin for nginx
  - Now simply do  `certbot --nginx -d example.com -d www.example.com`, and follow the instructions.
  - Look in `/etc/nginx/sites-available/example.com` - you should see that `certbot` has modified it.
  - Restart nginx and try to connect to your website.
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>28</fr:day>
                </fr:date>
                <fr:title text="What now?">What now?</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  Now you're set up! Put any files you want to put on your website into `/var/www/example.com/html`
</html:p>
                <html:p>
  - Look at the <fr:link href="https://www.nginx.com/" type="external">nginx website</fr:link> for more information about configuring it
  - Use static site generators like <fr:link href="https://www.jekyllrb.com/" type="external">Jekyll</fr:link> or <fr:link href="https://jaspervdj.be/hakyll/" type="external">Hakyll</fr:link> to generate your website.
  - Message me to complain about the problems in this guide.
  - If you buy your domain or your server from somewhere else, they probably have their own guides that tell you how to point your domain at the server. Try googling around.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2020</fr:year>
              <fr:month>2</fr:month>
              <fr:day>27</fr:day>
            </fr:date>
            <fr:uri>https://erischel.com/2020-02-27-compositional-frequentism/</fr:uri>
            <fr:display-uri>2020-02-27-compositional-frequentism</fr:display-uri>
            <fr:route>/2020-02-27-compositional-frequentism/</fr:route>
            <fr:title text="Frequentist Statistics and Compositionality">Frequentist Statistics and Compositionality</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <html:p>
Time-saving blurb:
This essay thingy eventually ends without any useful conclusion (I don't manage to figure out how to make something compose).
Also, it's not clear that what's here is particularly deep even if it could be made to work, which it hasn't.
</html:p>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>27</fr:day>
                </fr:date>
                <fr:title text="P-values">P-values</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  For convenience I'll only work with finite sets - I'm not aware of any serious problems extending this to more general spaces, but it would add some technicalities and it's not really germane to what I'm doing.
</html:p>
                <html:p>
  Let's say we have a population, and some attribute of the individuals that can be measured - maybe the population consists of humans, and we're measuring their height.
  Or maybe the population is really "outcomes of an experiment".
</html:p>
                <html:p>
  The simplest sort of model for something like this is just a probability distribution - a probability <fr:tex display="inline"><![CDATA[p(x)]]></fr:tex> for each possible measurement <fr:tex display="inline"><![CDATA[x]]></fr:tex>.
  What we want to do is to take some large number of measurements <fr:tex display="inline"><![CDATA[x_1, x_2, \dots  x_N]]></fr:tex>, and see if our model is plausible.
  How to do this?
  The naive thing would be to calculate the probability of the outcome, which is <fr:tex display="inline"><![CDATA[p(x_1)p(x_2) \cdots  p(x_N)]]></fr:tex>.
  For a plausible model, this should be high.
  One issue is that it's not clear how high is "high enough".
  Obviously, adding more samples will reduce this towards zero, even for a model that's totally correct.
  Moreover, if we're looking at a larger set of possibilities, then the probabilities will have to be smaller - again, even if our model is correct.
</html:p>
                <html:p>
  The classical solution to this question is the "<fr:tex display="inline"><![CDATA[p]]></fr:tex>-value":
  The probability of getting an outcome which is less or equally likely than the one we actually got.
  If you think about it, you'll realize that things with higher probabilities also have higher <fr:tex display="inline"><![CDATA[p]]></fr:tex>-values.
  Moreover, splitting the space of possibilities up doesn't affect the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value, essentially because it also splits all the lower-probability outcomes up.
  Taking more samples may increase or decrease the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value, but tends to decrease it precisely if our model is not exactly right (this is not really trivial).
  For these reasons <fr:tex display="inline"><![CDATA[p]]></fr:tex>-values are the most ubiquitous way of rating models in statistics. Clasically, we reject a model if the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value is less than <fr:tex display="inline"><![CDATA[0.05]]></fr:tex>.
</html:p>
                <html:p>
  (There are many problems with them, but we won't go into that...)
</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>27</fr:day>
                </fr:date>
                <fr:title text="Open models, rejection relations">Open models, rejection relations</fr:title>
              </fr:frontmatter>
              <fr:mainmatter><html:p>
  Now I want to cook up a categorical/compositional version of this.
  What's an "open probability distribution"?
  My best current bet is that it's a stochastic matrix <fr:tex display="inline"><![CDATA[A \to  B]]></fr:tex> (where <fr:tex display="inline"><![CDATA[A,B]]></fr:tex> are finite sets).
  In other words, for each point <fr:tex display="inline"><![CDATA[a\in  A]]></fr:tex>, a probability distribution <fr:tex display="inline"><![CDATA[P(b|a)]]></fr:tex> on <fr:tex display="inline"><![CDATA[B]]></fr:tex>.
  These form a category <fr:tex display="inline"><![CDATA[\mathsf {FinStoch}]]></fr:tex>.
</html:p><html:p>
  How can I do frequentism to this, in a "compositional" way?.
  I came up with this definition:
</html:p><html:p>
  A *plausibility relation* is a function <fr:tex display="inline"><![CDATA[(A \times  B)^* \to  [0,1]]]></fr:tex>.
  Here <fr:tex display="inline"><![CDATA[(A\times  B)^*]]></fr:tex> is the "Kleene star", the set of finite sequences of pairs <fr:tex display="inline"><![CDATA[(a,b) \in  A \times  B]]></fr:tex>.
  The interpretation is that it's a function which sends each sequence to the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value.
  Given a stochastic matrix <fr:tex display="inline"><![CDATA[P: A \to  B]]></fr:tex>, we can define a plausibility relation <fr:tex display="inline"><![CDATA[p_P((a_i,b_i)_{i=0}^N)]]></fr:tex>,
  to be the probability of observing a sequence of <fr:tex display="inline"><![CDATA[b_i]]></fr:tex>s less likely or equally likely to the actual sequence,
  given that each <fr:tex display="inline"><![CDATA[b_i]]></fr:tex> is distributed according to <fr:tex display="inline"><![CDATA[P( |a_i)]]></fr:tex> (holding the <fr:tex display="inline"><![CDATA[a_i]]></fr:tex>s fixed).
</html:p><html:p>
  Now the puzzle: figure out a composition rule for plausibility relations which makes this into a functor.
  A reasonable definition could be this:
</html:p><![CDATA[  \[(p \circ q)((a_i,c_i)_{i=0}^N) = \sup_{b_i \in B^N}q((a_i,b_i))p((b_i,c_i))\]]]><html:p>
  This vaguely mirrors the composition rules for relations.
  Unfortunately it doesn't work.
</html:p><html:p>
  Basically, the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value of the least likely outcome is simply its probability (assuming no two outcomes have exactly the same probability),
  but the formula above isn't the formula for composing stochastic matrices (we should sum instead of taking max).
  To be completely concrete, let <fr:tex display="inline"><![CDATA[A=B=C = \{0,1\}]]></fr:tex>, let <fr:tex display="inline"><![CDATA[f:A \to  B, g: B \to  C]]></fr:tex> both be given by flipping the state with probability <fr:tex display="inline"><![CDATA[1/3]]></fr:tex>.
  Then the probability of passing from <fr:tex display="inline"><![CDATA[0]]></fr:tex> to <fr:tex display="inline"><![CDATA[1]]></fr:tex> after both <fr:tex display="inline"><![CDATA[f]]></fr:tex> and <fr:tex display="inline"><![CDATA[g]]></fr:tex> is <fr:tex display="inline"><![CDATA[4/9]]></fr:tex>, which is also its <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value.
  The "composite of the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-values" for <fr:tex display="inline"><![CDATA[(0,1)]]></fr:tex> is <fr:tex display="inline"><![CDATA[\max  \{p_f(0,1)p_g(1,1), p_f(0,0)p_g(0,1)\} = 1/3]]></fr:tex>.
</html:p><html:p>
  We could also hope that this construction was a "lax functor", i.e that we always had <fr:tex display="inline"><![CDATA[p_{fg} \geq  p_f \circ  p_g]]></fr:tex>.
  This also doesn't hold.
  Here we can find a counterexample where some outcome <fr:tex display="inline"><![CDATA[c]]></fr:tex> is most likely given <fr:tex display="inline"><![CDATA[a]]></fr:tex> (so has <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value <fr:tex display="inline"><![CDATA[1]]></fr:tex>), but the most likely <fr:tex display="inline"><![CDATA[b]]></fr:tex> doesn't make <fr:tex display="inline"><![CDATA[c]]></fr:tex> the most likely
  (so none of the products can be <fr:tex display="inline"><![CDATA[1]]></fr:tex>).
  Again, concretely, let <fr:tex display="inline"><![CDATA[A = *, B = \{1,2,3\}, C = \{0,1\}]]></fr:tex>.
  Define <fr:tex display="inline"><![CDATA[f: A \to  B]]></fr:tex> to be <fr:tex display="inline"><![CDATA[1]]></fr:tex> with probability <fr:tex display="inline"><![CDATA[3/7]]></fr:tex>, and both <fr:tex display="inline"><![CDATA[2]]></fr:tex> and <fr:tex display="inline"><![CDATA[3]]></fr:tex> with probability <fr:tex display="inline"><![CDATA[2/7]]></fr:tex>.
  Let <fr:tex display="inline"><![CDATA[g: B \to  C]]></fr:tex> be defined so that given <fr:tex display="inline"><![CDATA[1]]></fr:tex>, it's always <fr:tex display="inline"><![CDATA[0]]></fr:tex>, and given <fr:tex display="inline"><![CDATA[2]]></fr:tex> or <fr:tex display="inline"><![CDATA[3]]></fr:tex>, it's always <fr:tex display="inline"><![CDATA[1]]></fr:tex>.
  Then the most likely outcome is <fr:tex display="inline"><![CDATA[C]]></fr:tex>, so the <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value <fr:tex display="inline"><![CDATA[p_{fg}(*,1) = 1]]></fr:tex>.
  But for any choice of <fr:tex display="inline"><![CDATA[b]]></fr:tex>, either <fr:tex display="inline"><![CDATA[p_f(*,b)]]></fr:tex> or <fr:tex display="inline"><![CDATA[p_g(b,1)]]></fr:tex> will be less than <fr:tex display="inline"><![CDATA[1]]></fr:tex>, so the composed <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value can't be one.
</html:p></fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/eigil-rischel/" title="Eigil Fjeldgren Rischel" uri="https://erischel.com/eigil-rischel/" display-uri="eigil-rischel" type="local">Eigil Fjeldgren Rischel</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2020</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>27</fr:day>
                </fr:date>
                <fr:title text="Comments">Comments</fr:title>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
  The problem in the last countexample is that the probability is kind of "split up" between <fr:tex display="inline"><![CDATA[2,3 \in  B]]></fr:tex>.
  This gives them a low <fr:tex display="inline"><![CDATA[p]]></fr:tex>-value, even though we don't care about their difference.
  But it's not clear that this sort of thinking could be made compositional.
</html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
      </fr:mainmatter>
    </fr:tree>
  </fr:mainmatter>
  <fr:backmatter>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="References">References</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Context">Context</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Backlinks">Backlinks</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Related">Related</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Contributions">Contributions</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
  </fr:backmatter>
</fr:tree>
