<divid="doc"class="markdown-body container-fluid"><h1id="Modularity-in-Mathematical-Computation"style=""><aclass="anchor hidden-xs"href="#Modularity-in-Mathematical-Computation"title="Modularity-in-Mathematical-Computation"><spanclass="octicon octicon-link"></span></a>Modularity in Mathematical Computation</h1><p>Nicolas M. Thiéry et al.</p><p>Tetrapod: Modular Knowledge workshop</p><p>FLoC 2018, Oxford, July 13th of 2018</p><h2id="A-collaborative-document"style=""><aclass="anchor hidden-xs"href="#A-collaborative-document"title="A-collaborative-document"><spanclass="octicon octicon-link"></span></a>A collaborative document</h2><p><strong>Please connect to:</strong></p><p><ahref="https://tinyurl.com/tetrapod-2018-computation"target="_blank">https://tinyurl.com/tetrapod-2018-computation</a></p><hr><h2id="Participants"style=""><aclass="anchor hidden-xs"href="#Participants"title="Participants"><spanclass="octicon octicon-link"></span></a>Participants</h2><ul>
<li>Georges Gonthier (Inria Saclay)</li>
<li>Florian Rabe (FAU Erlangen-Nürnberg, LRI, Univ. Paris Sud)</li>
<li>Dennis Müller (FAU Erlangen-Nürnberg)</li>
<li>Jeremy Gibbons (University of Oxford), local observer and gate-crasher</li>
<li>Jacques Carette (McMaster University) System designer and developper</li>
<li>Nicolas M. Thiéry (LRI, Univ. Paris Sud) Practionner, SageMath dev</li>
</ul><hr><h2id="Abstract"style=""><aclass="anchor hidden-xs"href="#Abstract"title="Abstract"><spanclass="octicon octicon-link"></span></a>Abstract</h2><p>Over the last decades, a huge amount of computational software was
developed for pure mathematics, in particular to support research and
education. As for any complex ecosystem of software components, the
ability to compose them has a multiplier effect on the expressive
power, flexibility, and range of applications.</p><p>The purpose of this session is to share experience on the many
barriers to composability in computational mathematics, and how they
are being tackled in various communities. Of particular interest will
be the exploitation of knowledge to leverage some of the barriers.
feedback from neighbor fields (proofs, data, knowledge) will be most
welcome.</p><hr><h2id="Composability"style=""><aclass="anchor hidden-xs"href="#Composability"title="Composability"><spanclass="octicon octicon-link"></span></a>Composability?</h2><p>For this session we focus on the ability to transfer data
and run procedures across “systems” (two different software, two instances of the same software on different machines, two libraries within a system, …).</p><hr><h3id="Data-transfers"style=""><aclass="anchor hidden-xs"href="#Data-transfers"title="Data-transfers"><spanclass="octicon octicon-link"></span></a>Data transfers</h3><ul>
<li>
<p><strong>Goal</strong>: Transfer an object O from system <code>A</code> to system <code>B</code></p>
</li>
<li>
<p><strong>Requirements</strong>:</p>
<ul>
<li>
<p><strong>A communication channel</strong>: shared memory, disk, pipe, (web)socket, …</p>
</li>
<li>
<p><strong>A communication protocol</strong></p>
</li>
<li>
<p><strong>Serialization / Deserialization</strong>: conversion to/from a string of bytes</p>
</li>
<li>
<p><strong>A format specification</strong>; e.g. XML (syntax) + OpenMath content dictionary (semantic)</p>
<p><strong>An API specification</strong>: syntax and semantic of <code>f</code> in <code>A</code>?</p>
</li>
<li>
<p><strong>Adapting the API in B to the API in A</strong>: <code>Size(A)</code><-><code>A.cardinality()</code></p>
<p>Idealy: applying a theory morphism to guarantee semantic preservation</p>
</li>
</ul>
</li>
</ul><hr><h2id="Barriers-faced-by-the-computational-pure-maths-community"style=""><aclass="anchor hidden-xs"href="#Barriers-faced-by-the-computational-pure-maths-community"title="Barriers-faced-by-the-computational-pure-maths-community"><spanclass="octicon octicon-link"></span></a>Barriers faced by the computational pure maths community?</h2><hr><h3id="Semantic-barriers"style=""><aclass="anchor hidden-xs"href="#Semantic-barriers"title="Semantic-barriers"><spanclass="octicon octicon-link"></span></a>Semantic barriers</h3><ul>
<li>
<p><strong>Many kinds of objects</strong>:</p>
<p>E.g. thousands in Sage, compared to “matrices of floats” in Matlab</p>
</li>
<li>
<p><strong>Many data representations</strong>, with very different algorithmic complexity</p>
<p>E.g. for polynomials: sparse, dense, recursive, straight line
program, evaluation, …</p>
</li>
<li>
<p>Objects at different levels of abstraction</p>
</li>
<li>
<p><strong>Few core concepts</strong></p>
<p>addition, multiplication commutativity</p>
</li>
<li>
<p>… but <strong>many interesting ways to combine them</strong>:</p>
</ul><hr><h4id="The-good-news"><aclass="anchor hidden-xs"href="#The-good-news"title="The-good-news"><spanclass="octicon octicon-link"></span></a>The good news</h4><ul>
<li>
<p>Formal level: <strong>best effort is ok</strong></p>
<p><strong>Closed science</strong> and the <strong>Montaigu-Capulet syndrome</strong></p>
<p>(won’t use code from / share code with XXX for political reasons)</p>
</li>
<li>
<p><strong>Tight man power resources</strong></p>
<p>Severel hundreds of thousands use computer algebra; hundreds implement it; a handful are
officially paid full time for it.</p>
</li>
<li>
<p><strong>Mastering math & computer science</strong>?</p>
</li>
<li>
<p><strong>High level of math specialization required when writing code</strong></p>
<p>E.g. thousands of people use Gröbner bases; a handful know how to
implement them right</p>
</li>
<li>
<p>Pieces of software that took decades to develop</p>
<p>We can’t afford to reimplement them; yet we can’t afford to not reimplement them (to learn from one’s mistakes and benefit from technology advances!)</p>
<p>lots of <strong>technical debt</strong>; <strong>slow evolution</strong></p>
</li>
<li>
<p><strong>Lack of modularity</strong>, <strong>large dependencies</strong></p>
<p>E.g. having to install SageMath to use just a few of its lines</p>
</li>
</ul>
</li>
</ul><hr><h2id="Some-case-studies-and-tentative-solutions"style=""><aclass="anchor hidden-xs"href="#Some-case-studies-and-tentative-solutions"title="Some-case-studies-and-tentative-solutions"><spanclass="octicon octicon-link"></span></a>Some case studies and tentative solutions</h2><hr><h3id="OpenMath"style=""><aclass="anchor hidden-xs"href="#OpenMath"title="OpenMath"><spanclass="octicon octicon-link"></span></a>OpenMath</h3><ul>
<li>
<p><strong>Goal</strong>: standardized serialization format to exchange data across systems</p>
</li>
<li>
<p><strong>Syntax</strong>: XML, json, binary</p>
</li>
<li>
<p><strong>Semantic</strong>: defined by content dictionaries (CD)</p>
</li>
<li>
<p><strong>Hard problem</strong>: agreeing on CD’s for polynomials was already hard; scaling?</p>
</li>
</ul><p>After twenty years, little adoption</p><hr><h3id="The-Math-in-the-Middle-approach"style=""><aclass="anchor hidden-xs"href="#The-Math-in-the-Middle-approach"title="The-Math-in-the-Middle-approach"><spanclass="octicon octicon-link"></span></a>The Math-in-the-Middle approach</h3><ul>
<li>
<p><strong>Goals</strong>:</p>
<ul>
<li>
<p>Separate <strong>serialization</strong> from <strong>adaptation</strong></p>
</li>
<li>
<p>Separate <strong>binding</strong> from <strong>adaptation</strong></p>
</li>
<li>
<p>Separate the treatment of each system</p>
</li>
</ul>
</li>
<li>
<p><strong>Approach</strong>:</p>
<ul>
<li>
<p>A central math ontology</p>
</li>
<li>
<p>Formalize each systems by aligning to the central ontology</p>
</li>
</ul>
</li>
</ul><hr><h3id="Categories-in-GAP-Axiom-MuPAD-SageMath"style=""><aclass="anchor hidden-xs"href="#Categories-in-GAP-Axiom-MuPAD-SageMath"title="Categories-in-GAP-Axiom-MuPAD-SageMath"><spanclass="octicon octicon-link"></span></a>Categories in GAP, Axiom, MuPAD, SageMath</h3><ul>
<li>
<p><strong>Barrier</strong>: compose building blocks <code>A1</code> and <code>A2</code> into modular generic code <code>B</code>: <code>f(a1, a2)</code></p>
<p>Remember: few core concepts, hundreds of interesting combinations</p>
</li>
<li>
<p><strong>Approaches</strong>:</p>
<ul>
<li>
<p>Axiom, MuPAD: OOP with large hierarchies of abstract classes (categories)</p>
</li>
<li>
<p>SageMath:</p>
<ul>
<li>same, but even larger</li>
<li>based on standard OOP (Python) + infrastructure to scale</li>
<li>embed semantic knowledge at single point of truth;
exploit it to automatically generate the class hierarchy</li>
</ul>
</li>
<li>
<p>GAP: bespoke method resolution mechanism</p>
</li>
</ul>
</li>
</ul><hr><h3id="Case-Study-libsemigroups-a-library-for-computing-with-semigroups"style=""><aclass="anchor hidden-xs"href="#Case-Study-libsemigroups-a-library-for-computing-with-semigroups"title="Case-Study-libsemigroups-a-library-for-computing-with-semigroups"><spanclass="octicon octicon-link"></span></a>Case Study: libsemigroups:, a library for computing with semigroups</h3><p>Author: James B. Mitchel et al.</p><ul>
<li>
<p><strong>Problems</strong></p>
<ul>
<li>
<p>Speeding GAP’s semigroup package while increasing its availability</p>
</li>
<li>
<p>Use a low-level library <code>A</code> from a system <code>B</code> written in a different language</p>
</li>
</ul>
</li>
<li>
<p><strong>Approach</strong></p>
<ul>
<li>
<p>Rewrite as a standalone templated C++ library</p>
</li>
<li>
<p>API: many iterations until converging to a natural API (no memory management, …)</p>
</li>
<li>
<p>Bindings: from Python: on-the-fly binding using cppyy (also tried Cython, Pybind11, …)</p>
</li>
<li>
<p>Adaptation: a thin layer for now; could use alignments</p>
</li>
</ul>
</li>
</ul><hr><h3id="Case-Study-the-Sage--GAP-interface"style=""><aclass="anchor hidden-xs"href="#Case-Study-the-Sage--GAP-interface"title="Case-Study-the-Sage--GAP-interface"><spanclass="octicon octicon-link"></span></a>Case Study: the Sage / GAP interface</h3><ul>
<li>
<p><strong>Problem</strong></p>
<p>Use funtionalities from a system <code>A</code> in a system <code>B</code> written in a different language</p>
</li>
<li>
<p><strong>Data exchange</strong></p>
<ul>
<li>
<p>Objects returned as references (handles):</p>
<ul>
<li>Few conversions</li>
<li>Reduced overhead</li>
<li>Manipulate from B objects of A with no native representation in B</li>
</ul>
</li>
</ul>
</li>
<li>
<p><strong>Binding</strong></p>
<ul>
<li>
<p>Originally: a pexpect interface</p>
</li>
<li>
<p>Now: ABI (direct calls at the C level)</p>
</li>
</ul>
</li>
</ul><hr><ul>
<li>
<p><strong>Adapting</strong></p>
<ul>
<li>
<p>Currently:</p>
<ul>
<li>monolithic adapters for some cases (groups, …)</li>
</ul>
</li>
<li>
<p>In progress:</p>
<ul>
<li>
<p>modular adapters, exploiting the category hierarchy and semantic alignments</p>
</li>
<li>
<p>objects returned as reference + semantic</p>
</li>
<li>
<p>alignment <code>B.cardinality() -> Size(A)</code> attached to the category of sets</p>
</li>
<li>
<p>alignment <code>B.conjugacy_classes() -> ConjugacyClasses(A)</code> attached to the category of groups</p>
<p>How to foster a sustainable and agile ecosystem where (sub)components have their own life cycle, explore new approaches, compete, and happily die when no more relevant.</p>
</li>
<li>
<p>What other barriers do you identify in Computational Math?</p>
</li>
<li>
<p>How do the barriers differ from other areas</p>
<aid="tocLabel"class="ui-toc-label btn btn-default"data-toggle="dropdown"href="#"role="button"aria-haspopup="true"aria-expanded="false"title="Table of content">
<divclass="toc"><ulclass="nav"><liclass=""><ahref="#Modularity-in-Mathematical-Computation"title="Modularity in Mathematical Computation">Modularity in Mathematical Computation</a><ulclass="nav"><li><ahref="#A-collaborative-document"title="A collaborative document">A collaborative document</a></li><li><ahref="#Participants"title="Participants">Participants</a></li><li><ahref="#Abstract"title="Abstract">Abstract</a></li><li><ahref="#Composability"title="Composability?">Composability?</a><ulclass="nav"><li><ahref="#Data-transfers"title="Data transfers">Data transfers</a></li><li><ahref="#Procedure-calls"title="Procedure calls">Procedure calls</a></li></ul></li><li><ahref="#Barriers-faced-by-the-computational-pure-maths-community"title="Barriers faced by the computational pure maths community?">Barriers faced by the computational pure maths community?</a><ulclass="nav"><li><ahref="#Semantic-barriers"title="Semantic barriers">Semantic barriers</a></li><li><ahref="#Social-barriers"title="Social barriers">Social barriers</a></li><li><ahref="#Technical-barriers"title="Technical barriers">Technical barriers</a></li></ul></li><li><ahref="#Some-case-studies-and-tentative-solutions"title="Some case studies and tentative solutions">Some case studies and tentative solutions</a><ulclass="nav"><li><ahref="#OpenMath"title="OpenMath">OpenMath</a></li><li><ahref="#The-Math-in-the-Middle-approach"title="The Math-in-the-Middle approach">The Math-in-the-Middle approach</a></li><li><ahref="#Categories-in-GAP-Axiom-MuPAD-SageMath"title="Categories in GAP, Axiom, MuPAD, SageMath">Categories in GAP, Axiom, MuPAD, SageMath</a></li><li><ahref="#Case-Study-libsemigroups-a-library-for-computing-with-semigroups"title="Case Study: libsemigroups:, a library for computing with semigroups">Case Study: libsemigroups:, a library for computing with semigroups</a></li><li><ahref="#Case-Study-the-Sage--GAP-interface"title="Case Study: the Sage / GAP interface">Case Study: the Sage / GAP interface</a></li></ul></li><li><ahref="#Open-discussion"title="Open discussion">Open discussion</a></li></ul></li></ul></div><divclass="toc-menu"><aclass="expand-toggle"href="#">Expand all</a><aclass="back-to-top"href="#">Back to top</a><aclass="go-to-bottom"href="#">Go to bottom</a></div>
<divclass="toc"><ulclass="nav"><liclass=""><ahref="#Modularity-in-Mathematical-Computation"title="Modularity in Mathematical Computation">Modularity in Mathematical Computation</a><ulclass="nav"><li><ahref="#A-collaborative-document"title="A collaborative document">A collaborative document</a></li><li><ahref="#Participants"title="Participants">Participants</a></li><li><ahref="#Abstract"title="Abstract">Abstract</a></li><li><ahref="#Composability"title="Composability?">Composability?</a><ulclass="nav"><li><ahref="#Data-transfers"title="Data transfers">Data transfers</a></li><li><ahref="#Procedure-calls"title="Procedure calls">Procedure calls</a></li></ul></li><li><ahref="#Barriers-faced-by-the-computational-pure-maths-community"title="Barriers faced by the computational pure maths community?">Barriers faced by the computational pure maths community?</a><ulclass="nav"><li><ahref="#Semantic-barriers"title="Semantic barriers">Semantic barriers</a></li><li><ahref="#Social-barriers"title="Social barriers">Social barriers</a></li><li><ahref="#Technical-barriers"title="Technical barriers">Technical barriers</a></li></ul></li><li><ahref="#Some-case-studies-and-tentative-solutions"title="Some case studies and tentative solutions">Some case studies and tentative solutions</a><ulclass="nav"><li><ahref="#OpenMath"title="OpenMath">OpenMath</a></li><li><ahref="#The-Math-in-the-Middle-approach"title="The Math-in-the-Middle approach">The Math-in-the-Middle approach</a></li><li><ahref="#Categories-in-GAP-Axiom-MuPAD-SageMath"title="Categories in GAP, Axiom, MuPAD, SageMath">Categories in GAP, Axiom, MuPAD, SageMath</a></li><li><ahref="#Case-Study-libsemigroups-a-library-for-computing-with-semigroups"title="Case Study: libsemigroups:, a library for computing with semigroups">Case Study: libsemigroups:, a library for computing with semigroups</a></li><li><ahref="#Case-Study-the-Sage--GAP-interface"title="Case Study: the Sage / GAP interface">Case Study: the Sage / GAP interface</a></li></ul></li><li><ahref="#Open-discussion"title="Open discussion">Open discussion</a></li></ul></li></ul></div><divclass="toc-menu"><aclass="expand-toggle"href="#">Expand all</a><aclass="back-to-top"href="#">Back to top</a><aclass="go-to-bottom"href="#">Go to bottom</a></div>
