A Verified ODE Solver and the Lorenz Attractor
Abstract
A rigorous numerical algorithm, formally verified with Isabelle/HOL, is used to certify the computations that Tucker used to prove chaos for the Lorenz attractor. The verification is based on a formalization of a diverse variety of mathematics and algorithms. Formalized mathematics include ordinary differential equations and Poincaré maps. Algorithms include low level approximation schemes based on Runge–Kutta methods and affine arithmetic. On a high level, reachability analysis is guided by static hybridization and adaptive stepsize control and splitting. The algorithms are systematically refined towards an implementation that can be executed on Tucker’s original input data.
Keywords
Isabelle/HOL Ordinary differential equation Rigorous numerics Poincaré map Lorenz attractor1 Introduction
Computer assisted proofs, i.e., mathematical proofs that rely on the output of a computer program, depend crucially on the correctness of the program. Important computer assisted proofs for e.g., the Kepler conjecture or the Four Color Theorem, have therefore been formally verified. In this article, we consider the Lorenz attractor—perhaps one of the most prominent examples of deterministic chaos—and its computer assisted proof by Warwick Tucker. The proof relies on a rigorous numerical ordinary differential equation (ODE) solver. In this article, we describe the longterm project of formally verifying (in Isabelle/HOL [39]) an ODE solver that is capable of certifying Tucker’s computations.
1.1 History
In 1963, meteorologist Edward Lorenz [31] introduced a system of ODEs as a simplified model for atmospheric dynamics. He observed that even the smallest perturbation in initial values would lead to completely different longterm behavior of the system. Referring to the original motivation, he asked: “Does the Flap of a Butterfly’s Wings in Brazil Set Off a Tornado in Texas?” and the term butterfly effect entered popular culture. The Lorenz system tends to evolve to a complicated structure (Fig. 2), which became an iconic example of deterministic chaos: According to Sparrow [45] “the number of man, woman, and computer hours spent on [the Lorenz equations ...] must be truly immense”. Despite its popularity and the amount of effort put into its study, nobody managed to prove that the Lorenz attractor is chaotic in a rigorous mathematical sense. The problem of rigorously proving chaos in the Lorenz attractor even made it into a list of 18 important problems for the twentyfirst century that Field’s medalist Stephen Smale composed in 1998 [43].
Shortly after, Warwick Tucker managed to give an affirmative answer by presenting a computerassisted proof [47, 48]. Tucker’s programs were written in C\({++}\) and are not formally verified. Tucker even discovered (and fixed) some bugs in it [46, 49]. Formal verification of the numerical results needed for the proof is therefore a worthwhile goal.
1.2 The Lorenz Attractor
Figure 1 depicts the numerical simulation of the evolution of a particle starting at (0.1, 0, 0): It moves to right (\(x \approx 15\)) and up (\(z \approx 50\)) at time \(t\approx 0.5\), then down to about \(z = 27\) and oscillates with increasingly larger amplitude around \(z=27\). Figure 2 depicts the trace of a longterm evolution in the three dimensional phase space, it indicates Property 1:
Property 1
Solutions remain in a bounded region of the phase space.
Particles that approach the origin (0, 0, 0) from above exhibit a very sensitive dependence on initial conditions: a slight perturbation can make the particle flow to either the left or right branch of the Lorenz attractor, which we call Property 2:
Property 2
Solutions exhibit sensitive dependence on initial conditions.
1.3 Tucker’s Proof
How does Tucker go about proving those properties? First of all, he uses a standard technique: he introduces a socalled Poincaré section. This is a distinguished set in the phase space, in this case a square on the plane \(z = 27\), namely \({\varSigma }= [6, 6] \times [6, 6] \times \{27\}\). Compare also Fig. 2.
On a Poincaré section \({\varSigma }\), one defines the socalled Poincaré map P: For a particle \(x_0 \in {\varSigma }\), the Poincaré map \(P(x_0)\) is the point where the flow first returns to \({\varSigma }\). This reduces the threedimensional, continuous dynamics \(\phi \) to (discrete) iterations of the twodimensional map P. Tucker then analyzes the dynamics of P.
Trapping Region Regarding Property 1, Tucker proves that there is a (compact) trapping region \(N \subseteq {\varSigma }\), such that solutions starting in N will remain in N. He does so by subdividing N into a large number of small rectangles. For every small rectangle, Tucker’s program computes safe numeric bounds for all solutions evolving from the small rectangle. In a number of timediscretization steps, the evolution is followed until it eventually returns to \({\varSigma }\). Upon return, the program checks that the returned enclosure is contained in N. If this process succeeds for every small rectangle, one can conclude the following theorem.
Theorem 1
(Trapping Region) \( \forall x \in N  {\varGamma }.~P(x) \in N \)
Note that there exists a set \({\varGamma }\) on which P is not defined: \({\varGamma }\) is the set of points, from which solutions tend to the origin in infinite time. \({\varGamma }\) is therefore explicitly excluded in the above theorem.
Sensitive Dependence Regarding Property 2, sensitive dependence on initial conditions can be quantified with the help of the derivative: A deviation in the direction of a vector \(v \in \mathbb {R}^{2}\) is propagated (in linear approximation) like the derivative at x, i.e., \(P(x + v) \approx x + \mathsf {D}P_{x}\cdot v\). Here \(\mathsf {D}P_{x}\cdot v\) is the matrix of partial derivatives of P (the Jacobian matrix) at the point x, multiplied with the vector v.
A mathematically precise notion of chaos is given by the class of singular hyperbolic systems [36]. The term singular denotes the special case where the system contains a hyperbolic fixed point (which renders P undefined on \({\varGamma }\)). A hyperbolic system contracts deviations in stable directions and expands deviations in unstable directions. Both are relevant for the dynamics of the attractor: Stable directions make solutions tend to the attractor, whereas unstable directions lead to sensitive dependence on initial conditions.
Tucker proves that the Lorenz attractor is hyperbolic (in fact singular hyperbolic, we discuss how the hyperbolic fixed point is addressed with normal form theory in the next paragraph) by providing safe overapproximations for the unstable direction: Every \(x \in N\) is equipped with a cone \(\mathfrak {C}(x)\) (compare Fig. 3), which contains the unstable direction. This is also verified by Tucker’s computer program: In addition to the Poincaré map, the program keeps bounds on its matrix of partial derivatives. The program tracks how initial deviations (inside the cone associated to an initial rectangle) are propagated by the derivative \(\mathsf {D}P\). The cone field needs to be forward invariant (otherwise it would not contain the unstable direction) and the expansion needs to be large enough that the enclosed directions are actually expanding. Tucker’s program establishes factors \(\mathcal {E}(x)\) and \(\mathcal {E}^{1}(x)\), which quantify the expansion properties of P:
Theorem 2
 1.
\(\forall x \in N  {\varGamma }.~\forall v \in \mathfrak {C}(x).~\mathsf {D}P_{x}\cdot v \in \mathfrak {C}(P(x))\)
 2.
\(\forall x \in N  {\varGamma }.~\forall v \in \mathfrak {C}(x).~\left\ \mathsf {D}P_{x}\cdot v\right\ \ge \mathcal {E}(x)\left v\right \)
 3.
\(\forall x \in N  {\varGamma }.~\forall v \in \mathfrak {C}(x).~\left\ \mathsf {D}P_{x}\cdot v\right\ \ge \mathcal {E}^{1}(P(x))\left\ v\right\ \)
This theorem states that 1., the cone field \(\mathfrak {C}\) is forward invariant under the action of the derivative of P: the image of every cone is slimmer than the cones onto which they are mapped. 2., the vectors v satisfy lower bounds on how much they are expanded: the length \(\left\ \mathsf {D}P_{x}\cdot v\right\ \) of the return of the deviation vector v is lower bounded by its length \(\Vert v\Vert \) times an expansion factor \(\mathcal {E}(x)\). They also satisfy a preexpansion bound \(\mathcal {E}^{1}(x)\) (this does not denote \(\frac{1}{\mathcal {E}}\)) for the preimage of x, which is required for technical reasons in Tucker’s proof.
Normal Form Theory For the Lorenz equations, the origin (0, 0, 0) is a hyperbolic fixed point. The origin is a fixed point, because the ODE evaluates to 0. It is hyperbolic, because solutions tend to it in the two stable directions given by the y and z axis and expands in the unstable direction given by the xaxis.
This hyperbolic fixed point poses problems for the aforementioned approach of using rigorous numerical methods: there are solutions that tend to the origin as time goes to infinity. In such a situation, a timediscretization algorithm is at a loss, because it would need infinitely many steps. To remedy this problem, Tucker’s program interrupts computations in a small cube \(L = [0.1, 0.1] \times [0.1, 0.1] \times [0.1, 0.1]\) around the origin. Inside the cube, where the numerical methods would fail, the evolution of solutions can be described with classical, analytical means: more than half of Tucker’s thesis is devoted to accurate analytical expressions for the flow inside the cube L. These expressions can be used to provide explicit bounds on how solutions exit the cube L and continue with numerical computations.
Informal Theorem 3
There is an explicit form that bounds the dynamics inside the cube \(L = [0.1, 0.1] \times [0.1, 0.1] \times [0.1, 0.1]\).
1.4 Outline of This Article
This article is about the formalization of a rigorous ODE solver that computes the Poincaré map P and its derivative \(\mathsf {D}P\). It is sufficiently efficient and precise to certify Tucker’s numerical results. In particular, computing with the verified algorithm proves Theorems 1 and 2. In fact, also Fig. 3 was created from the output of this verified algorithm.
As a matter of course, since the ODE solver computes Poincaré maps and derivatives thereof, it is proved correct with regard to a formalization of these concepts in Isabelle/HOL. This formalization, as well as the verified algorithms are generic: they are independent of the underlying ODE or dimension.
This article summarizes previous work of the author (and contributions by Johannes Hölzl and Christoph Traut) [18, 19, 20, 21, 22, 23, 24, 25, 26] and describes the state of the formalization to which it evolved over time. It shows how the various parts fit together for the final result of certifying Tucker’s computations. The following explains how this article is structured and details on the relation to earlier publications.
The abstract mathematics needed for the formalization is a theory of ODEs and Poincaré maps together with their (differentiable) dependence on initial conditions. This is presented in Sect. 2, which summarizes a more comprehensive journal article [25], in which the author extends the conference paper [26] with a formalization of Poincaré maps. The foundations, in particular existence and uniqueness of solutions was proved in [24].
Tucker used the library Profil/BIAS for an implementation of the Euler method in interval arithmetic. Our approach to rigorous numerics is at first agnostic about the concrete type of enclosures (Sect. 3). The main instantiation, affine arithmetic, is presented in Sect. 3.4. Parts of this section were part of earlier publications [18, 21].
When working with affine arithmetic, the enclosures are zonotopes (centrally symmetric polytopes) instead of intervals. Because zonotopes are a more complex than intervals, geometric operations like intersections with the Poincaré section \({\varSigma }\) are more challenging. The verification leads to a digression into computational geometry in Sect. 4, which is based on an earlier publication [19].
Tucker’s program adaptively splits reachable sets and therefore maintains a collection of sets. Section 5 describes how we formalize generic data structures to maintain such collections and use stepwise refinement from nondeterministic abstract specifications to a concrete deterministic implementation. This has not been published before.
A more adhoc formalization of similar algorithms has been described in earlier work [21], which forms the basis of Sect. 6. Here the presentation is w.r.t. the new, generic framework and extended for derivatives of Poincaré maps.
Section 7 is a novel contribution: it describes how the trapping region N, the cone field \(\mathfrak {C}\) and the expansion estimates \(\mathcal {E}, \mathcal {E}^{1}\) are defined formally and how the verified ODE solver is set up to certify the results of all of Tucker’s computations. Earlier work [20] was not capable of handling derivatives, and had no formalization of Poincaré map.
All of the development described here is available for Isabelle2017 in the Archive of Formal Proof [22, 23]. In particular everything displayed as Theorem possesses a formal counterpart.
2 Mathematics
The required mathematical background consists of mostly standard results which can be found in every textbook on ODEs and dynamical systems. Thanks to a sufficient background theory, the formalization can mostly follow the presentations in such textbooks. We therefore focus on peculiarities of our formalization which are due to Isabelle/HOL and its type system, in particular the use of type classes and the lack of dependent types. Because of the type class based formalization of topological structures, type definitions are used to formalize function spaces, where the Transfer and Lifting tools [15] provide excellent support. Moreover, there are no dependent types in Isabelle/HOL. In situations where this would be more natural, an encoding (e.g., \({{\textsf {\textit{extcont}}}}\,\) in the following Sect. 2.1.2) is necessary.
2.1 Type Classes for Mathematics in Isabelle/HOL
In Isabelle/HOL, many of the mathematical concepts (in particular spaces with a certain structure) are formalized using type classes. Isabelle/HOL features axiomatic type classes [11, 38]. The purpose of an axiomatic type class is to specify operations which satisfy given properties for a class of types. The advantage of type class based reasoning is that most of the reasoning is generic: formalizations are carried out in the context of type classes and can then be used for all types inhabiting that type class.
For generic formalizations, we use Greek letters \(\alpha , \beta , \gamma \) and name their type class constraints in prose. I.e., when we write that we “consider a topological space” \(\alpha \), then this result is formalized generically for every type \(\alpha \) that fulfills the properties of a topological space.
The spaces we consider are topological spaces with \({{\textsf {\textit{open}}}}\,\) sets, (real) vector spaces with addition \(+: \alpha \rightarrow \alpha \rightarrow \alpha \) and scalar multiplication \((\_)(\_): \mathbb {R}\rightarrow \alpha \rightarrow \alpha \). Normed vector spaces come with a norm \((\_) : \alpha \rightarrow \mathbb {R}\). Complete normed vector spaces are called Banach spaces. Much of the theory has been ported from Harrison’s theory of Euclidean space [12] and has been generalized to the hierarchy of type classes for mathematics in Isablle/HOL [14].
2.1.1 Vectors in Euclidean Space
Because of Isabelle/HOL’s restrictive type system (no dependent types), the abstract concept of vectors is notorious for demanding workarounds. In Isabelle/HOL, one tends to use a type class based encoding. We work with a type class for Euclidean space that fixes an order on the Basis elements and therefore enables operations \({{\textsf {\textit{eucloflist}}}}\,:\mathbb {R}\,{{\textsf {\textit{list}}}}\,\rightarrow \alpha \) and \({{\textsf {\textit{listofeucl}}}}\,:\alpha \rightarrow \mathbb {R}\,{{\textsf {\textit{list}}}}\,\) if \(\alpha \) is a Euclidean space.
All (finite) vectors of real numbers are instances of the class Euclidean space. This includes real numbers \(\mathbb {R}\), complex numbers \(\mathbb {C}\), tuples \(\alpha \times \beta \) for Euclidean spaces \(\alpha , \beta \), and Harrisonstyle^{2} [12] vectors \(\alpha ^\iota \) for a finite type \(\iota \).
2.1.2 Bounded Continuous Function
In order to formalize this in Isabelle/HOL, there are two obstructions to overcome: First, the concept of Banach space is a type class in Isabelle/HOL, so we need to introduce a type for the mappings \(\phi : [t_0, t_1] \rightarrow \mathbb {R}^{n}\) from above. But this poses the second problem: functions in Isabelle/HOL are total and types must not depend on term parameters like \(t_0\) and \( t_1\).
Definition 1
Bounded continuous functions form a normed vector space. The norm on \(\alpha \rightarrow _{{{\textsf {\textit{bc}}}}\,}\beta \) is the supremum of the range and the vector space operations \({+}\), \({\cdot }\) are defined pointwise.
Definition 2
The type \(\rightarrow _{{{\textsf {\textit{bc}}}}\,}\) with the above operations forms a complete normed vector space (a Banach space). This allows us to use the Banach fixed point theorem for operators on this type.
The usage of the type \(\rightarrow _{{{\textsf {\textit{bc}}}}\,}\) caused minor technical obstructions, but otherwise enabled a natural and abstract proof.
2.1.3 Bounded Linear Functions
Similar to the type of bounded continuous functions, we also introduce a type of bounded linear functions (also known as continuous linear functions)
Definition 3
In the Isabelle/HOL formalization, \({{\textsf {\textit{continuous}}}}\,\) is defined for functions \(f : \alpha \rightarrow \beta \) for topological spaces \(\alpha \) and \(\beta \). If \(\alpha \) and \(\beta \) are normed vector spaces, the above equality for \({{\textsf {\textit{continuous}}}}\,\) holds in Isabelle/HOL, too. And indeed, the norm of bounded linear functions is defined using \({{\textsf {\textit{onorm}}}}\,\) such that \({{\textsf {\textit{onorm}}}}\,(\lambda v.~(f'~x)\cdot _{{{\textsf {\textit{bl}}}}\,}v  (f'~y) \cdot _{{{\textsf {\textit{bl}}}}\,}v) = \Vert f' x  f' y\Vert \) holds. Then, continuity of a derivative \(f' : \alpha \rightarrow (\alpha \rightarrow _{{{\textsf {\textit{bl}}}}\,}\beta )\) can simply be written as \(({{\textsf {\textit{continuous}}}}\,~f'~({{\textsf {\textit{at}}}}\,~x))\), which is a better abstraction to work with and also avoids redundant formalizations for different kinds of continuity.
2.2 Dynamical Systems
An ODE induces a continuous dynamical system via the notion of flow. A standard technique to reason about such systems is its Poincaré map. We keep the presentation at a high level, since details can be found in the publications [25, 26].
2.2.1 The Flow
Definition 4
(Flow) The flow \(\phi (x_0, t)\) is the (unique) solution of the ODE \(\dot{x}(t) = f(x(t))\) with initial condition \(\phi (0) = x_0\)
The flow is only welldefined on the socalled existence interval of the solution, which depends on the initial value.
Definition 5
(Existence Interval) \(t \in {{\textsf {\textit{exivl}}}}\,(x_0) \implies \dot{\phi }(x_0, t) = f(\phi (x_0, t))\)
The flow \(\phi \) and the existence interval \({{\textsf {\textit{exivl}}}}\,\) provide a clean interface to talk about solutions of ODEs. The property of the generic notion of flow makes it possible to easily state composition of solutions and to algebraically reason about them. Flowing from \(x_0\) for time \(s + t\) is equivalent to first flowing for time s, and from there flowing for time t:
Theorem 4
For Tucker’s proof, one needs to study how sensitive the flow depends on perturbations of the initial value. We use two main results: One, the flow depends continuously on initial values. Two, if the ODE f is continuously differentiable, then so is the flow. We first take a look at the domain \({\varOmega }= \left\{ (x, t)\mid ~t \in {{\textsf {\textit{exivl}}}}\,(x)\right\} \subseteq X \times T\) of the flow. \((t, x) \in {\varOmega }\) means that we can flow a point starting at x for at least time t. Intuitively, solutions starting close to x can be followed for times that are close to t. In topological parlance, the state space is open.
Theorem 5
(Open State Space) \({{\textsf {\textit{open}}}}\,{\varOmega }\)
One can show that solutions deviate at most exponentially fast: \(\exists K.~\Vert \phi (x, t)  \phi (y, t)\Vert < \Vert x  y\Vert e^{Kt}\) (using Grönwall’s lemma). Therefore, by choosing x and y close enough, one can make the distance of the solutions arbitrarily small. In other words, the flow is a continuous function on the state space:
Theorem 6
(Continuity of Flow) \({{\textsf {\textit{continuouson}}}}\,~{\varOmega }~\phi \)
Continuity states that small deviations in the initial values result in small deviations of the flow. One can be more precise on the way initial deviations propagate. The propagation of initial deviations through the flow (\(\phi _t {:}= \lambda x.~\phi (x, t)\)) can be approximated by a linear function, the derivative \(\mathsf {D}\phi _{x} \cdot v \approx \phi (x, t)  \phi (x + v, t)\).
We formalize the fact that the derivative of the flow is the solution of a differential equation in the space of bounded linear mappings, the socalled variational equation.
Theorem 7
Solving this ODE numerically gives a means to obtain numerical bounds on the derivative, which is the approach that we pursue in our algorithms.
2.2.2 The Poincaré Map
The Poincaré map is an important tool for studying dynamical systems. Whereas the flow describes the evolution of a continuous system with respect to time, it is the Poincaré map that allows us to study the evolution with respect to some space variables. A Poincaré section is a subset \({\varSigma }\) of the state space, which is in general given as an implicit surface \({\varSigma }= \{x \mid s(x) = c\}\) with continuously differentiable s. For Tucker’s proof, one chooses \(s(x, y, z) = z\) and \(c = 27\).
The Poincaré map P(x) is defined as the point where the flow starting from x first hits the Poincaré section \({\varSigma }\). It is defined with the help of the first return time \(\tau (x)\). \(\tau \) depends on the flow \(\phi \) (and therefore on the ODE f) and the Poincaré section \({\varSigma }\), but we keep those dependencies implicit.
Definition 6
(First Return Time) \(\tau (x)\) is the least \(t>0\) such that \(\phi (x, t) \in {\varSigma }\).
Obviously, \(\tau \) is only welldefined for values that actually return to \({\varSigma }\), which we encode in the predicate \({{\textsf {\textit{returnsto}}}}\,\):
Definition 7
The return time can then be used to define the Poincaré map as follows:
Definition 8
It is interesting to note that this way of defining the return time and Poincaré map differs from the usual approach in textbooks. Textbooks study Poincaré maps in a neighborhood around a periodic point \(x \in {\varSigma }\), i.e., \(P(x) = x\). This makes it easy to directly apply the implicit function theorem and transfer continuity and differentiability from the flow to the Poincaré map while guaranteeing that \(\tau \) and P are welldefined. Also, one views P as a mapping on \({\varSigma }\), i.e. \(P : {\varSigma }\rightarrow {\varSigma }\).
Tucker’s proof, however, requires a more flexible notion of Poincaré map and our notion of \(\tau \) is more flexible: it is welldefined also for values outside of \({\varSigma }\). This enables reasoning about intermediate sections: Tucker, e.g., composes a sequence of local Poincaré maps between intermediate sections \({\varSigma }, {\varSigma }_1, \cdots , {\varSigma }_n, {\varSigma }\) in order to get bounds on the global Poincaré map \({\varSigma }\rightarrow {\varSigma }\).
The goal of Tucker’s computations is a sensitivity analysis of the flow of the Lorenz system and of its Poincaré map. Its derivative can be given in terms of the derivative of the flow and the function s defining the implicit surface for \({\varSigma }= \{x \mid s(x) = c\}\).
Theorem 8
For a rough intuition, the derivative \(\mathsf {D}P_{x}\cdot h\) of the Poincaré map is related to the derivative of the flow \(\mathsf {D}\phi _{(x, \tau (x))}\cdot h\). But it needs to corrected in the direction f(P(x)) in which the flow passes through \({\varSigma }\), because P varies only on \({\varSigma }\) and not through it. This correction factor also depends on the tangent space \(\mathsf {D}s_{P(x))}\) of the section \({\varSigma }\) at P(x).
3 Rigorous Numerics
3.1 Expressions for Vectors
3.2 A Runge–Kutta Method
Theorem 9
In order to use this theorem for rigorous numerical computations, we produce a deep embedding of the expressions for \({{\textsf {\textit{rk}}}}\,_h\) and \({{\textsf {\textit{rkremainder}}}}\,_h\). We do so for an arbitrary ODE \(f:\mathbb {R}^{n}\rightarrow \mathbb {R}^{n}\) with deep embedding Open image in new window . Expressions for \(f'\) and \(f''\) are computed symbolically from \(f_e\) via \(D^{1,2}_e\) from the previous Sect. 3.1.
3.3 Straight Line Programs
The expression for \({{\textsf {\textit{rkremainder}}}}\,\) from the previous Sect. 3.2 contains common subexpressions. This is not desirable because one would need to perform redundant computations. We therefore follow Dorel and Melquiond’s [34] approach and use straightline programs with static single assignment instead of plain expressions.
At runtime (this is important to be able to use the ODE solver as a standalone tool), in an initialization phase, the ODE solver computes symbolically the derivatives in the expression for \({{\textsf {\textit{rk}}}}\,_h\) and \({{\textsf {\textit{rkremainder}}}}\,\), does constant propagation (as derivatives can produce 0 constants, this is beneficial) and then compiles the resulting expression with \({{\textsf {\textit{slpof}}}}\,\) into a straightline program, which is then used in the course of approximating the ODE in a series of steps.
3.4 Affine Arithmetic
Up to now, we have kept the discussion on the level of expressions, let us now motivate affine arithmetic as a concrete approximation scheme.
The most basic data structure to represent sets is closed intervals \([a, b] = \{ x \mid a \le x \le b \}\), but those suffer from the wrapping effect: rotated boxes cannot be represented without large overapproximations. Moreover dependencies between variables are lost, e.g. for an enclosure \(x \in [0, 2]\), the expression \(x  x\) evaluates to \([2, 2]\) in interval arithmetic whereas the exact result would be representable as the interval [0, 0].
During longer computations more and more noise symbols will be added to the affine form, impairing performance in the long run. The number of noise symbols can be reduced by summarizing (or condensing) several noise symbols into a new one. This process discards the correlation mediated by the summarized noise symbols, so a tradeoff needs to be found between precision and efficiency. We consider a list of affine forms AS and use the notation \(AS_i {:}= {{\textsf {\textit{map}}}}\,~(\lambda A.~A_i)~AS\). We call total deviation \(AS{:}= {{\textsf {\textit{map}}}}\,~(\lambda A.~\sum _i A_i)~AS\) the componentwise sum of absolute values. We summarize all symbols i with \(AS_i \le rAS\) for a given summarization threshold r. We found that it is important to perform the above comparison componentwise and not take (like proposed for other implementations of affine arithmetic [6, 42]) the infinity norm on both sides. This is of particular importance when components differ a lot in magnitude.
4 Computational Geometry
An important step for Tucker’s proof is the reduction to a Poincaré map: intersecting the flow of the ODE with a plane in the state space. In our algorithms, the flow is approximated with affine arithmetic expressions, therefore enclosed by zonotopes.
In order to compute where the flow intersects the hyperplane, one needs to compute the intersection of the enclosing zonotope with the hyperplane (see Fig. 5).
This is an interesting geometric problem and we verified an approximative algorithm due to Girard and Le Guernic [7]. At its core, the algorithm is similar to convex hull computations. We can build on a nice abstraction to reason about it, namely Knuth’s theory of counterclockwise (ccw) systems [27]. We needed, however, to extend Knuth’s theory from discrete to continuous sets of points.
4.1 Girard and Le Guernic’s Algorithm
The complexity for computing the exact intersection of a zonotope with a hyperplane grows exponentially with the number of generators. An overapproximation of the zonotope before computing the intersection is possible but can lead to overly coarse approximations. Therefore Girard and Le Guernic [7] proposed a way to directly compute overapproximations to the intersection.
Lemma 1
Computing the intersection of a twodimensional zonotope like the one given in Fig. 6 and a vertical line \(L_c\) can by done by computing bounds on the intersection of the vertical line \(L_c\) with every edge. This is easy and intuitive. The more challenging part is to compute the set of edges of a twodimensional zonotope, which we sketch in the following.
4.2 Computing the Set of Edges.
First of all, one can assume that all generators point upwards. One then starts at the lowest corner (\(c_0\) in Fig. 6) and appends to it the “rightmost” generator \(a_1\) (twice) to reach \(c_1\). One then continues with the “rightmost” of the remaining generators, \(a_2\) and is in the process essentially “wrapping up” the hull of the zonotope.
In order to verify such a process, we need a way to reason about “rightmost” vectors (a total order). Similar ideas of “wrapping up” a set of points also occur for convex hull algorithms.
4.3 Knuth’s CCW System
In order to verify geometric algorithms, one needs a formal notion of the geometric concepts involved. For convex hull algorithms, Knuth [27] has given a small theory that axiomatizes the notion of orientation of points. The intuition is that for three points p, q, r in the plane, visiting them in order requires either a counterclockwise (ccw) turn (written pqr) or clockwise (\(\lnot pqr\)) turn. Knuth observed that already few of the properties fulfilled by the ccw predicate pqr suffice to define a theory rich enough to formalize many concepts in computational geometry.

Cyclic Symmetry: \(pqr \implies qrp\)

Antisymmetry: \(pqr \implies \lnot prq\)

Nondegeneracy: \(pqr \vee prq\)

Interiority: \(tpq \wedge tqr \wedge trp \implies pqr\)

Transitivity: \(tsp \wedge tsq \wedge tsr \wedge tpq \wedge tqr \implies tpr\)
 Dual Transitivity:$$\begin{aligned} stp \wedge stq \wedge str \wedge tpq \wedge tqr \implies tpr \end{aligned}$$
4.3.1 Total Order from CCW
As sketched earlier, in order to compute the edges of a zonotope, we need to be able to select a “rightmost” element of a set of vectors. With the transitivity relation presented before, we can obtain a total order on vectors which allows us to do just that: Given a center t and another point s, the orientation predicate tpq can be used to define a total order on points p, q in the halfplane left of ts, i.e., \(p < q\) iff tpq. From Antisymmetry and Nondegeneracy of the ccw system, we get antisymmetry and totality for the order <. Transitivity of the order < follows from the axiom Transitivity of the ccw system and the assumption that all points are in the halfplane left of ts. This ordering is then used to sort the list of generators such that they actually “wrap up” the zonotope.
4.3.2 Instantiation for Points in the Plane
4.3.3 CCW on a Vector Space
Knuth presented his axioms with a finite set of discrete points in mind, in our case we need to talk about orientation of arbitrary points in a continuous set. We therefore require consistency of the orientation predicate when vector space operations are involved.

Translation: \((p + s)(q + s)(r + s)^> = pqr^>\)

Scaling: \(\alpha> 0 \implies 0(\alpha \cdot q)r^> = 0qr^>\)

Reflection: \(0(p)q = 0qp\)

Addition: \(0pq \implies 0pr \implies 0p(q + r)\)
5 Program and Data Refinement
We use two different approaches to turn abstract formalizations into executable constructs: In situations where abstract operations directly correspond to concrete, executable ones, we use lightweight data refinement via the code generator. In more demanding situations, we employ a dedicated framework for nondeterministic specifications and stepwise program refinement, namely the Autoref tool.
5.1 LightWeight Data Refinement
For lightweight data refinement [10] via the code generator, abstract operations need to be mapped directly to concrete, executable ones. Examples of such abstract types are affine forms and real numbers.
Affine forms are abstractly a subtype of functions \(\mathbb {N}\rightarrow \mathbb {R}\). They are implemented using a type of association lists \((\mathbb {N}\times \mathbb {R})\,{{\textsf {\textit{list}}}}\,\) that are (reverse) strictly sorted according to the keys. This sparse representation is useful because the largest index of a nonzero generator can be directly read off by inspecting only the first element. Adding a fresh generator can be done by simply prepending the new element. Binary operations are efficiently and easily implemented by merging the two lists of generators.
5.2 Autoref
We use Lammich’s framework Autoref for (automatic) refinement [29, 30] in Isabelle/HOL. Autoref allows the user to specify algorithms on an abstract level and provides tool support for stepwise refinement [1] to concrete, executable implementations.
In this section we present a setup of Autoref for rigorous numerical algorithms: We provide abstract specifications for elementary operations of common rigorous numerical algorithms as well as suitable implementations.
5.2.1 Nondeterministic Specifications
An important insight when verifying algorithms that use rigorous numerical enclosures is the fact that, for correctness, any enclosure of the real quantity suffices. We model this with appropriate nondeterministic specifications.
This allows one to specify correctness, e.g, of a program f whose inputs x satisfy the precondition P and every possible value y in its nondeterministic result satisfies the postcondition Q: \(\forall x.~P~x \implies f~x \le {{\textsf {\textit{spec}}}}\,(\lambda y.~Q~y)\).
In this setting, we specify a set of operations that are useful in the context of verifying rigorous numerical algorithms, i.e., algorithms that manipulate enclosures. These operations are best modeled nondeterministically, because one is often only interested in some safe result.
5.2.2 Refinement Relations
6 Reachability Analysis
Overall, we design an algorithm that computes a Poincaré map with a list of intermediate Poincaré sections. The global idea (illustrated in Fig. 9) is as follows: starting from a set \(X_0\), perform a series of single time discretization steps. If reachable sets grow above a given threshold, subdivide them (Sects. 6.3 and 6.4). Stop before an intermediate (or the final) section would be hit, then resolve the Poincaré map at that section (Sect. 6.5). For Tucker’s proof, it is important to also track the matrix of partial derivatives together with the solution. To this end, one can encode the derivative as a higherdimensional ODE and use essentially the same algorithms as before. This instrumentation is presented in Sect. 6.7.
6.1 The Framework

\(({{\textsf {\textit{approxslp}}}}\,, {{\textsf {\textit{approxslpspec}}}}\,) \in {{\textsf {\textit{slp}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,{{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,\langle \langle {{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rangle {{\textsf {\textit{option}}}}\,_{{\textsf {\textit{r}}}}\,\rangle {{\textsf {\textit{nres}}}}\,_{{\textsf {\textit{r}}}}\,\)

\((\lambda x~y.~{{\textsf {\textit{enclofivl}}}}\,~x~y, \lambda x~y.~[x, y]) \in {{\textsf {\textit{lvrel}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,{{\textsf {\textit{lvrel}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,{{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\)

\(({{\textsf {\textit{infencl}}}}\,, {{\textsf {\textit{Infspec}}}}\,) \in {{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,\langle {{\textsf {\textit{lvrel}}}}\,\rangle {{\textsf {\textit{nres}}}}\,_{{\textsf {\textit{r}}}}\,\)

\(({{\textsf {\textit{supencl}}}}\,, {{\textsf {\textit{Supspec}}}}\,) \in {{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,\langle {{\textsf {\textit{lvrel}}}}\,\rangle {{\textsf {\textit{nres}}}}\,_{{\textsf {\textit{r}}}}\,\)

\(({{\textsf {\textit{splitencl}}}}\,, {{\textsf {\textit{splitspec}}}}\,_{\subseteq }) \in {{\textsf {\textit{real}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,nat_rel \rightarrow _{{\textsf {\textit{r}}}}\,{{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,\langle {{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\times _{{\textsf {\textit{r}}}}\,{{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rangle {{\textsf {\textit{nres}}}}\,_{{\textsf {\textit{r}}}}\,\)

\(({{\textsf {\textit{interenclplane}}}}\,, {{\textsf {\textit{interspec}}}}\,_2) \in {{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,\langle {{\textsf {\textit{lvrel}}}}\,\rangle {{\textsf {\textit{plane}}}}\,_{{\textsf {\textit{r}}}}\,\rightarrow _{{\textsf {\textit{r}}}}\,\langle {{\textsf {\textit{encl}}}}\,_{{\textsf {\textit{r}}}}\,\rangle {{\textsf {\textit{nres}}}}\,_{{\textsf {\textit{r}}}}\,\)
6.2 The Specification
Our algorithms are supposed to compute enclosures for solutions of the ODE. We formalize the enclosure of an evolution from an initial set X to some other set Y with the ternary predicate \(\curvearrowright \), where \(X \curvearrowright _{C} Y\) holds if the evolution flows every point of \(X \subseteq \mathbb {R}^{n}\) to some point in \(Y\subseteq \mathbb {R}^{n}\) and does not leave the set C in the meantime. We call C the flowpipe from X to Y.
Definition 9
6.3 Single Step
In order to compute enclosures for a single step, one needs to first certify that a solution exists, which is the case for an initial value \(x_0\) and stepsize h if the iteration given by the Picard iteration from Sect. 2.1.2 has a unique fixed point. This is the standard approach from Bouissou et al. [4], also described in the setting of Isabelle [18]. The idea is that the expression \(Q_h(X) = X_0 + [0,h]\cdot f(X)\), which we can evaluate using \({{\textsf {\textit{approxslpspec}}}}\,\), is an overapproximation of the Picard iteration and a postfixed point certifies existence and a crude enclosure for solutions up to time h. This crude enclosure can be used as an overapproximation for the terms \(x (hs_1 + t)\) in the Runge–Kutta approximation scheme from Sect. 3.2. The function \({{\textsf {\textit{rkstep}}}}\,\) implements this and actually evaluates the Runge–Kutta approximation scheme twice: once for time h and once for the time interval [0, h], because this gives a much better enclosure for the flowpipe up to time h than the crude overapproximation from the Picard iteration. We prove the following specification.
Theorem 10
\({{\textsf {\textit{rkstep}}}}\,~X~h \le {{\textsf {\textit{spec}}}}\,(\lambda (\varepsilon , C, Y).~X \curvearrowright _C Y)\)
The returned value \(\epsilon \) is an estimate for the approximation error. This is used for an adaptive step size control. Algorithm 1 shows an example how to use this heuristic (and another heuristic to split large sets), while (almost trivially, because the additional operations are either vacuous, the identity or overapproximations) satisfying the same specification.
Theorem 11
\({{\textsf {\textit{singlestep}}}}\,~X~h \le {{\textsf {\textit{spec}}}}\,(\lambda (C, Y). X \curvearrowright _C Y)\)
6.4 Continuous Reachability
Note that \({{\textsf {\textit{singlestep}}}}\,\) returns (from an implementation point of view) a collection of enclosures, so we need some sort of worklist algorithm to resolve all currently reachable sets. Algorithm 2 does so. It maintains three kinds of sets (see also Fig. 9): X is the collection of currently “live” sets. C is the collection of all flowpipes explored so far. I is the collection of sets where reachability analysis has stopped because of an intersection with a Poincaré section from sctns. The algorithm takes one element out of the “worklist” X by splitting the collection of enclosures using \({{\textsf {\textit{splitspec}}}}\,_{=}\), performs a single step, checks for an intersection with one of the Poincaré sections and updates X, C, and I accordingly.
Theorem 12
\({{\textsf {\textit{reachcont}}}}\,(sctns, X_0) \le {{\textsf {\textit{spec}}}}\,(\lambda (C, I).~X_0 \curvearrowright _{C} I \wedge C \cap sctns = \emptyset )\)
6.5 Resolve Intersection
Algorithm 2 performs reachability analysis until each enclosure is just about to intersect an hyperplane. We compute the intersection from an enclosure X with a hyperplane H again in an iteration: continuous reachability steps are repeated as long as flowpipes intersect the hyperplane. The intersection of the individual flowpipes is computed with the geometric algorithm from Sect. 4.
When the intersection is computed by flowing the reachable set through the hyperplane step by step, we get a set \(\mathcal {I}\) consisting of individual intersections \(I_i\). Many of the sets \(I_i\) usually overlap, in order to avoid redundant enclosures, the overlap is resolved with an overapproximative operation: all of the sets \(I_i\) are covered with an interval, which is repeatedly subdivided and shrinked to a given precision (see also section 3.6 in [21] for a more detailed discussion).
6.6 Intermediate Poincaré Maps
The overall algorithm repeats the alternation of continuous reachability and resolution of Poincaré sections. When there is a sequence \(H_1, \cdots , H_n\) of intermediate Poincaré maps to be computed, it is important to ensure that, while flowing towards or resolving section \(H_i\), one must not intersect with any of the \(H_j\) with \(j>i\). Otherwise the later computation of the Poincaré map \(H_j\) might be incorrect because the actual first return time was reached before.
6.7 Derivatives
For Tucker’s proof, it is necessary to compute not only the Poincaré map, but also its derivative. The derivative of the flow can be encoded as a higher dimensional ODE according to the variational equation (Theorem 7).
For an ODE with right hand side \(f:\mathbb {R}^{n}\rightarrow \mathbb {R}^{n}\), a new ODE of type \(\mathbb {R}^{n} \times \mathbb {R}^{n*n}\) with right hand side \((x, W) \mapsto (f~x, \mathsf {D}f_{x} \cdot W)\) is constructed. Here the first component contains the solution, and the second component its matrix of derivatives.
We first extend the flowsto predicate \(\curvearrowright \) to a predicate \(\curvearrowright '\) which also takes derivatives into account.
Definition 10
With this extended predicate for reachability, we can show that \({{\textsf {\textit{reachcont}}}}\,'\), i.e., \({{\textsf {\textit{reachcont}}}}\,\) for the extended ODE satisfies the specification \({{\textsf {\textit{reachcont}}}}\,'~sctns~X_0' \le (\lambda (C, Y).~X \curvearrowright '_{C} Y )\).
6.8 Correctness Theorem
We call the main algorithm that we outlined in the beginning of this Sect. 6 \({{\textsf {\textit{poincare}}}}\,\): It resolves a sequence of intermediate Poincaré maps (together with their derivative). It is verified to compute guaranteed enclosures for Poincaré maps and their derivative. The algorithm \({{\textsf {\textit{poincare}}}}\,\) takes as arguments an initial set \(X:\mathbb {R}^{n}\,{{\textsf {\textit{set}}}}\,\), and initial matrix of partial derivatives \(DX:\mathbb {R}^{n*n}\,{{\textsf {\textit{set}}}}\,\) and a target Poincaré section \({\varSigma }:\mathbb {R}^{n}\,{{\textsf {\textit{set}}}}\,\). It is further parameterized by a list of intermediate Poincaré sections, but they are irrelevant for the final correctness theorem. We formally verify partial correctness: If the algorithm returns a result, then this result encloses the Poincaré map P(x) and its derivative \(\mathsf {D}P_{x} \cdot DX\) for every \(x \in X\) and \(DX:\mathbb {R}^{n*n}\,{{\textsf {\textit{set}}}}\,\).
Theorem 13
7 Application to Lorenz Attractor
In this section, we present how the verified algorithm \({{\textsf {\textit{poincare}}}}\,\) of the previous section is used to certify Tucker’s computations. We show in particular how we formally prove the Theorems 1 and 2. It helps to recall the roles of the forward invariant set N, the cone field \(\mathfrak {C}\) and the expansion estimates \(\mathcal {E}\) in Tucker’s proof, as outlined in Sect. 1.3.
7.1 The Input Data and its Interpretation
It is not necessary to verify precisely the set N that Tucker used, but coming up with a forward invariant set is slightly more involved than certifying one. We therefore use the output of Tucker’s program as a starting point to set up the input for our ODE solver. Since any other forward invariant with suitable cone field and expansion estimates would do just, we are free to modify Tucker’s data slightly. The output of Tucker’s program is available online^{3} as a file containing 7258 lines. We preprocessed this file by merging the information of some of the lines and slightly coarsening some of the numerical bounds. The coarsening accounts for slight differences between Tucker’s and our approximations.
This results in a list of 400 elements, which we call \({{\textsf {\textit{inputdata}}}}\,\) and will be the basis for all further interpretations:
Definition 11
Elements res of type \({{\textsf {\textit{result}}}}\,\) are interpreted as initial rectangles as follows. The properties \({{\textsf {\textit{gridx}}}}\,^{}, {{\textsf {\textit{gridx}}}}\,^{+}, {{\textsf {\textit{gridy}}}}\,^{}\), and \({{\textsf {\textit{gridy}}}}\,^{+}\) encode a rectangle on the Poincaré section \({\varSigma }\) (recall Fig. 2), which we denote by N(res). The union of all elements of \({{\textsf {\textit{inputdata}}}}\,\) represents the upper branch \(N^+\) of the forward invariant set N. It is plotted in Fig. 10.
Definition 12
Definition 13
There \({{\textsf {\textit{rad}}}}\,~x = \frac{x\cdot \pi }{180}\) is the radian of the angle given in degrees, \({{\textsf {\textit{segment}}}}\,~x~y\) is the line segment \(\{(1  u) \cdot a + u \cdot b \mid u \in [0, 1]\}\), and \({{\textsf {\textit{cone}}}}\,~{{\textsf {\textit{hull}}}}\,~S = \{c \cdot x \mid 0 \le c \wedge x \in S\}\) the conic hull of a set S.
The elements in \({{\textsf {\textit{inputdata}}}}\,\) also encode a conefield \(\mathfrak {C}\) and expansion estimates as follows. \({{\textsf {\textit{resultsat}}}}\,(x)\) yields the set of result elements that cover a point x (the rectangles overlap at the boundary). We need to respect this to ensure that \(\mathfrak {C}\), \(\mathcal {E}\), and \(\mathcal {E}^{1}\) are well defined.
Definition 14
One last property is \({{\textsf {\textit{invokenf}}}}\,\), which encodes if the numerical computations need to be interrupted and the results of the normal form need to be invoked. First, we define abstractly when this is necessary, namely on the stable manifold of the origin. That is, the set of all points, which tend to the origin in infinite time. We restrict our attention to the part of the stable manifold whose trajectories do not intersect \({\varSigma }\) for positive time.
Definition 15
Assumption 14
7.2 Checking the Input Data
In the previous section, we only defined what the \({{\textsf {\textit{inputdata}}}}\,\) encodes. Now we check if the numerical bounds prescribed by the \({{\textsf {\textit{inputdata}}}}\,\) are actually correct. This involves three steps: First, we need to find a suitable setup to be able to use the algorithm \({{\textsf {\textit{poincare}}}}\,\), which computes derivatives and not cones. Second, we set up the check that a single element of the \({{\textsf {\textit{inputdata}}}}\,\) is correct. Third, we check all elements of the \({{\textsf {\textit{inputdata}}}}\,\), from which we conclude the formal counterparts of Theorems 1 and 2.
7.2.1 Representation of Cones
Concerning the checking of cone conditions, first note that \(\mathfrak {C}~res\) is an infinite cone, i.e., an unbounded set of vectors. In contrast to that, all of our numerical algorithms are tailored towards bounded enclosures. We therefore perform the computations with the line segment connecting the two tangent vectors with unit length. \({{\textsf {\textit{matrixsegment}}}}\,~x_1~y_1~x_2~y_2~e\) encodes a line segment (parameterized by e) in a matrix (such that it can be used as matrix initial condition DX of \({{\textsf {\textit{poincare}}}}\,\), compare Theorem 13). \({{\textsf {\textit{matsegofdeg}}}}\,\) uses this to define the line segment between the endpoints of unit vectors with given angles u, v to the x axis. A cone can therefore represented with the help of \({{\textsf {\textit{matsegofdeg}}}}\,\):
Lemma 2
7.2.2 Checking a Single Result Element
Theorem 15
The theorem follows rather directly from the definition of algorithm 3 and the specifications and definitions of the occurring functions.
7.2.3 Checking All Results
We have indeed the theorem that all \({{\textsf {\textit{inputdata}}}}\,\) is correct:
Theorem 16
We prove formally that under the Assumption 14, Theorem 16 implies Theorems 1 and 2, which is the main result of this article. It follows from combining the individual instances of Theorem 15 in a suitable way.
Figure 11 shows the plot of an enclosure for the Lorenz attractor resulting from the verified computation. The plot hints at the intermediate Poincaré sections that were manually set up (for some initial rectangles) at about \(z=27\), \(z=30\), \(x=\pm 5\), \(x=\pm 1.5\), \(x=\pm 1\), \(x=\pm 0.75\), \(x=\pm 0.1\), and \(z=0.1\). The black part of Fig. 10 is an enclosure for \(P(N^+)\) resulting from these computations, and it is as expected and verified contained in N.

Threads: 22

Elapsed Time: 6 h 33 min 9 s

CPU Time: 131 h 52 min 40 s

Parallelization Factor: 20.13

Garbage Collection Time: 42 min 36 s
8 Conclusion
This article presented an overview of the diversity of algorithms, abstract results and techniques for the formal verification of a generalpurpose ODE solver and its application to the rigorous numerical part of Tucker’s proof.
8.1 Future Work
Future work would be to lift the assumption 14 on the normal form theory to formal foundations. This involves in particular multivariate formal power series and a number of analytic estimations, proving existence and convergence of specifically constructed formal power series. This involves more than 24 pages of Tucker’s article and is therefore a larger formalization effort. It also includes computer assisted parts: smalldiv.cc and coeffs.cc help devising the normal form, but neither their specification nor their implementation is particularly challenging; they essentially only evaluate a large number of fixed arithmetic expressions.
Another direction for future work would be to formally conclude from the numerical results that the Lorenz equations support a robust singular hyperbolic attractor. One part would be to prove (similar to Tucker’s expansion.cc) that the expansion estimates given by \(\mathcal {E}\) are sufficiently large to guarantee the locally eventually onto property. We validated this with a nonverified computation for the expansion estimates prescribed by our \({{\textsf {\textit{inputdata}}}}\,\). Further mathematical foundations are required in order to conclude from the computed forward invariant conefield \(\mathfrak {C}\) and the expansion bounds that there exists a stable foliation, and that this foliation can be used to reduce the twodimensional dynamics on \({\varSigma }\) to a onedimensional map. This requires in particular the formalization of differentiable manifolds, and theorems like the existence of differentiable invariant sections for fiber contractions [41].
8.2 Size of Code
Size of code and formalization
8.3 Trust Base
We use the evaluation oracle eval in Isabelle/HOL. This is common practice to speed up rewriting. Isabelle/HOL equations are mapped to function definitions in Standard ML. These are compiled and evaluated in PolyML.^{5} We also use the common extension (HOLLibrary.Code_Target_Numeral in Isabelle2017) of the code generator that maps Isabelle/HOL integers to the integer type IntInf.int of PolyML, which can be based on either PolyML’s own implementation of arbitrary precision integers or GMP [8].
This setup means that the trusted code base is increased: The translation of Isabelle/HOL terms to SML code is not verified. One needs to trust PolyML and its compiler, but PolyML is Isabelle’s implementation language and therefore anyhow part of the trusted code base.
Reducing the trusted code base is an orthogonal issue: there is ongoing work [16, 17] for verified code generation to CakeML [28], a verified implementation of ML.
Isabelle/HOL’s eval speeds up evaluation by translating terms to the implementation language of the proof checker (PolyML). In view of this, it is more similar to Coq’s native_compute [2], which evaluates terms after translation to Coq’s implementation language OCaml, than to Coq’s virtual machine [9].
8.4 Related Work
Integrals and Differential Equations in Proof Assistants Spitters and Makarov [33] implement Picard iteration to calculate solutions of ODEs in the interactive theorem prover Coq, but restricted to relatively short existence intervals. Boldo et al. [3] approximate the solution of one particular partial differential equation with a Cprogram and verify its correctness in Coq. Mahboubi and SibutPinote [32] compute rigorous approximations of integrals with Taylor models.
Rigorous Numerics in Proof Assistants Rigorous numerical approximation of arithmetic expressions has been done in Coq [34] for different types of enclosures (Taylor models, intervals, centered forms). Muñoz and Lester [37] use rational interval arithmetic in PVS. Rigorous numerics with first order interval approximations has been implemented by Solovyev for the Flyspeck project [44] in HOL Light. This work is remarkable in that it is not relying on code generation but uses only primitive inference rules of HOL Light’s kernel.
Computational Geometry Pichardie and Bertot [40] were the first to formalize the ccw system and verify a functional convex hull algorithm in Coq. Meikle and Fleuriot [35] formalized an imperative algorithm and verified it using Hoare logic in Isabelle/HOL. Brun et al. [5] verify an algorithm based on hypermaps to compute the convex hull.
Footnotes
 1.
That is, Lorenz’ original equations for the classical parameters \(\beta = \frac{8}{3}, \sigma =10, \rho = 28\) in Jordan normal form using \(\tau {:}= \sqrt{(\sigma + 1)^2 + 4 \sigma (\rho  1)}\), \(k_1 {:}= \frac{\sigma }{\tau }\), \(k_2 {:}= \frac{\sigma  1 + \tau }{2 \sigma }\), \(k_3 {:}= \frac{\sigma  1  \tau }{2 \sigma }\), \(\lambda _1 {:}= \frac{ \sigma  1 + \tau }{2}\), \(\lambda _2 {:}= \frac{ \sigma  1  \tau }{2}\), and \(\lambda _3 {:}=  \beta \).
 2.
Vectors of length n are represented by a type of functions \(\iota \rightarrow \alpha \), where n equals the cardinality of the finite type \(\iota \).
 3.
 4.
Intel\(\circledR \) Xeon\(\circledR \) CPU E52699 v4 @ 2.20 GHz.
 5.
Notes
Acknowledgements
I would like to thank Jeremy Avigad for drawing my attention to this particular application of rigorous ODE solving. I am very grateful to Tobias Nipkow for encouraging and supporting me to pursue this multifaceted project. The anonymous reviewers provided helpful and constructive feedback. This research was financially supported by DFG RTG 1480 (PUMA) and DFG Koselleck Grant NI 491/161. I would like to thank Johannes Hölzl for supervising my student project on the Picard–Lindelöf theorem. I thankfully acknowledge Christoph Traut’s work for his student project on formalizing the variational equation.
References
 1.Back, R.J., Wright, J.: Refinement Calculus: A Systematic Introduction. Springer, New York (2012)zbMATHGoogle Scholar
 2.Boespflug, M., Dénès, M., Grégoire, B.: Full reduction at full throttle. In: International Conference on Certified Programs and Proofs, pp. 362–377. Springer, New York (2011)Google Scholar
 3.Boldo, S., Clément, F., Filliâtre, J.C., Mayero, M., Melquiond, G., Weis, P.: Wave equation numerical resolution: a comprehensive mechanized proof of a C program. Journal of Automated Reasoning 50(4), 423–456 (2013). https://doi.org/10.1007/s1081701292554 MathSciNetCrossRefzbMATHGoogle Scholar
 4.Bouissou, O., Chapoutot, A., Djoudi, A.: Enclosing temporal evolution of dynamical systems using numerical methods. In: Brat, G., Rungta, N., Venet, A. (eds.) NASA Formal Methods, LNCS, vol. 7871, pp. 108–123. Springer, New York (2013). https://doi.org/10.1007/9783642380884_8 CrossRefGoogle Scholar
 5.Brun, C., Dufourd, J.F., Magaud, N.: Designing and proving correct a convex hull algorithm with hypermaps in Coq. Computational Geometry 45(8), 436–457 (2012). https://doi.org/10.1016/j.comgeo.2010.06.006. (Geometric Constraints and Reasoning)
 6.de Figueiredo, L., Stolfi, J.: Affine arithmetic: concepts and applications. Numerical Algorithms 37(1–4), 147–158 (2004)MathSciNetCrossRefzbMATHGoogle Scholar
 7.Girard, A., Le Guernic, C.: Zonotope/hyperplane intersection for hybrid systems reachability analysis. In: Egerstedt, M., Mishra, B. (eds.) Hybrid Systems: Computation and Control, LNCS, vol. 4981, pp. 215–228. Springer, New York (2008). https://doi.org/10.1007/9783540789291_16 CrossRefGoogle Scholar
 8.Granlund, T., et al.: GNU MP 6.0 Multiple Precision Arithmetic Library. Samurai Media Limited, Hong Kong (2015)Google Scholar
 9.Grégoire, B., Leroy, X.: A compiled implementation of strong reduction. ACM SIGPLAN Not. 37(9), 235–246 (2002)CrossRefzbMATHGoogle Scholar
 10.Haftmann, F., Krauss, A., Kunčar, O., Nipkow, T.: Data Refinement in Isabelle/HOL, pp. 100–115. Springer, Berlin (2013). https://doi.org/10.1007/9783642396342_10 zbMATHGoogle Scholar
 11.Haftmann, F., Wenzel, M.: Constructive type classes in Isabelle. In: International Workshop on Types for Proofs and Programs, pp. 160–174. Springer, New York (2006)Google Scholar
 12.Harrison, J.: A HOL theory of Euclidean space. In: Hurd, J., Melham, T. (eds.) 18th International Conference on Theorem Proving in Higher Order Logics (TPHOLs 2005), Lecture Notes in Computer Science, vol. 3603, pp. 114–129 (2005)Google Scholar
 13.Hölzl, J.: Proving inequalities over reals with computation in Isabelle/HOL. In: Reis, G.D. Théry L. (eds.) Programming Languages for Mechanized Mathematics Systems (ACM SIGSAM PLMMS’09), pp. 38–45 (2009)Google Scholar
 14.Hölzl, J., Immler, F., Huffman, B.: Type classes and filters for mathematical analysis in Isabelle/HOL. In: Blazy, S., PaulinMohring, C., Pichardie, D. (eds.) ITP 2013, pp. 279–294. Springer, New York (2013)Google Scholar
 15.Huffman, B., Kunčar, O.: Lifting and transfer: a modular design for quotients in Isabelle/HOL. In: International Conference on Certified Programs and Proofs, pp. 131–146. Springer, New York (2013)Google Scholar
 16.Hupel, L.: Dictionary Construction. Archive of Formal Proofs (2017). http://isaafp.org/entries/Dict_Construction.html, Formal proof development
 17.Hupel, L., Nipkow, T.: A verified compiler from Isabelle/HOL to CakeML. Springer LNCS (2018). https://lars.hupel.info/pub/isabellecakeml.pdf
 18.Immler, F.: Formally verified computation of enclosures of solutions of ordinary differential equations. In: Badger, J.M., Rozier, K.Y. (eds.) NFM 2014, pp. 113–127. Springer, New York (2014)Google Scholar
 19.Immler, F.: A verified algorithm for geometric zonotope/hyperplane intersection. In: CPP 2015, pp. 129–136. ACM (2015)Google Scholar
 20.Immler, F.: A verified enclosure for the Lorenz attractor (rough diamond). In: Urban, C., Zhang, X. (eds.) ITP 2015, pp. 221–226. Springer, Berlin (2015)Google Scholar
 21.Immler, F.: Verified reachability analysis of continuous systems. In: Baier, C., Tinelli, C. (eds.) TACAS 2015, pp. 37–51. Springer, Berlin (2015)Google Scholar
 22.Immler, F.: Affine Arithmetic. Archive of Formal Proofs (2017). http://isaafp.org/entries/Affine_Arithmetic.shtml, Formal proof development
 23.Immler, F., Hölzl, J.: Ordinary Differential Equations. Archive of Formal Proofs (2017). http://isaafp.org/entries/Ordinary_Differential_Equations.shtml, Formal proof development
 24.Immler, F., Hölzl, J.: Numerical analysis of ordinary differential equations in Isabelle/HOL. In: International Conference on Interactive Theorem Proving, pp. 377–392. Springer, New York (2012)Google Scholar
 25.Immler, F., Traut, C.: The flow of ODEs: Formalization of variational equation and Poincaré map. J. Autom. Reason. (2018). https://doi.org/10.1007/s1081701894495
 26.Immler, F., Traut, C.: The flow of ODEs. In: Blanchette, J.C., Merz, S. (eds.) ITP 2016, pp. 184–199. Springer, Cham (2016)Google Scholar
 27.Knuth, D.: Axioms and Hulls. Springer, Berlin (1992). Number 606 in Lecture Notes in Computer ScienceGoogle Scholar
 28.Kumar, R., Myreen, M.O., Norrish, M., Owens, S.: CakeML: a verified implementation of ML. In: ACM SIGPLAN Notices, vol. 49, pp. 179–191. ACM (2014)Google Scholar
 29.Lammich, P.: Refinement for monadic programs. Archive of Formal Proofs (2012). http://afp.sf.net/entries/Refine_Monadic.shtml, Formal proof development
 30.Lammich, P.: Automatic data refinement. In: International Conference on Interactive Theorem Proving, pp. 84–99. Springer, Heidelberg (2013)Google Scholar
 31.Lorenz, E.N.: Deterministic nonperiodic flow. J. Atmos. Sci. 20(2), 130–141 (1963). https://doi.org/10.1175/15200469(1963)020%3c0130:DNF%3e2.0.CO;2 CrossRefzbMATHGoogle Scholar
 32.Mahboubi, A., Melquiond, G., SibutPinote, T.: Formally Verified Approximations of Definite Integrals, pp. 274–289. Springer, Cham (2016). https://doi.org/10.1007/9783319431444_17 zbMATHGoogle Scholar
 33.Makarov, E., Spitters, B.: The Picard algorithm for ordinary differential equations in Coq. In: Blazy, S., PaulinMohring, C., Pichardie, D. (eds.) Interactive Theorem Proving, LNCS, vol. 7998, pp. 463–468. Springer, Berlin (2013)CrossRefGoogle Scholar
 34.MartinDorel, E., Melquiond, G.: Proving tight bounds on univariate expressions with elementary functions in Coq. J. Autom. Reason. 57(3), 187–217 (2016). https://doi.org/10.1007/s1081701593504 MathSciNetCrossRefzbMATHGoogle Scholar
 35.Meikle, L., Fleuriot, J.: Mechanical theorem proving in computational geometry. In: Hong, H., Wang, D. (eds.) Automated Deduction in Geometry, Lecture Notes in Computer Science, pp. 1–18. Springer, Berlin (2006). https://doi.org/10.1007/11615798_1 Google Scholar
 36.Morales, C., Pacifico, M., Pujals, E.: Singular hyperbolic systems. Proc. Am. Math. Soc. 127(11), 3393–3401 (1999)MathSciNetCrossRefzbMATHGoogle Scholar
 37.Muñoz, C., Lester, D.: Real number calculations and theorem proving. In: Hurd, J., Melham, T. (eds.) Theorem Proving in Higher Order Logics (TPHOLs 2005), LNCS, pp. 195–210 (2005)Google Scholar
 38.Nipkow, T.: Ordersorted polymorphism in Isabelle. In: Logical Environments, pp. 164–188. Cambridge University Press (1993)Google Scholar
 39.Nipkow, T., Paulson, L.C., Wenzel, M.: Isabelle/HOL: A Proof Assistant for HigherOrder Logic, LNCS. Springer, Heidelberg (2002)CrossRefzbMATHGoogle Scholar
 40.Pichardie, D., Bertot, Y.: Formalizing convex hull algorithms. In: Boulton, R., Jackson, P. (eds.) Theorem Proving in Higher Order Logics, Lecture Notes in Computer Science, vol. 2152, pp. 346–361. Springer, Berlin (2001). https://doi.org/10.1007/3540447555_24 CrossRefGoogle Scholar
 41.Robinson, C.: Dynamical Systems—Stability, Symbolic Dynamics, and Chaos. CRC Press, Boca Raton (1999). https://doi.org/10.1007/9781461300038 zbMATHGoogle Scholar
 42.Rump, S.M., Kashiwagi, M.: Implementation and improvements of affine arithmetic. Nonlinear Theory Appl. IEICE 6(3), 341–359 (2015). https://doi.org/10.1587/nolta.6.341 CrossRefGoogle Scholar
 43.Smale, S.: Mathematical problems for the next century. Math. Intell. 20(2), 7–15 (1998). https://doi.org/10.1007/BF03025291 MathSciNetCrossRefzbMATHGoogle Scholar
 44.Solovyev, A., Hales, T.C.: Formal verification of nonlinear inequalities with Taylor interval approximations. In: NASA Formal Methods Symposium, pp. 383–397. Springer, New York (2013)Google Scholar
 45.Sparrow, C.: The Lorenz Equations: Bifurcations, Chaos, and Strange Attractors. No. 41 in Applied Mathematical Sciences. Springer. New York. https://doi.org/10.1007/9781461257677
 46.Tucker, W.: My thesis: The lorenz attractor exists. http://www2.math.uu.se/~warwick/main/pre_thesis.html
 47.Tucker, W.: The Lorenz attractor exists. Comptes Rendus de l’Académie des SciencesSeries IMathematics 328(12), 1197–1202 (1999)MathSciNetCrossRefzbMATHGoogle Scholar
 48.Tucker, W.: A rigorous ODE solver and Smale’s 14th problem. Found. Comput. Math. 2(1), 53–117 (2002)MathSciNetCrossRefzbMATHGoogle Scholar
 49.Viana, M.: What’s new on Lorenz strange attractors? Math. Intell. 22(3), 6–19 (2000)MathSciNetCrossRefzbMATHGoogle Scholar
Copyright information
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.