Quantitative continuity and computable analysis in Coq

04/30/2019 ∙ by Florian Steinberg, et al. ∙ 0

We give a number of formal proofs of theorems from the field of computable analysis. Many of our results specify executable algorithms that work on infinite inputs by means of operating on finite approximations and are proven correct in the sense of computable analysis. The development is done in the proof assistant Coq and heavily relies on the Incone library for information theoretic continuity. This library is developed by one of the authors and the paper can be used as an introduction to the library as it describes many of its most important features in detail. While the ability to have full executability in a formal development of mathematical statements about real numbers and the like is not a feature that is unique to the Incone library, its original contribution is to adhere to the conventions of computable analysis to provide a general purpose interface for algorithmic reasoning on continuous structures. The results that provide complete computational content include that the algebraic operations and the efficient limit operator on the reals are computable, that certain countably infinite products are isomorphic to spaces of functions, compatibility of the enumeration representation of subsets of natural numbers with the abstract definition of the space of open subsets of the natural numbers, and that continuous realizability implies sequential continuity. We also formalize proofs of non-computational results that support the correctness of our definitions. These include that the information theoretic notion of continuity used in the library is equivalent to the metric notion of continuity on Baire space, a complete comparison of the different concepts of continuity that arise from metric and represented-space structures and the discontinuity of the unrestricted limit operator on the real numbers and the task of selecting an element of a closed subset of the natural numbers.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Computable analysis is the theory of computing on continuous structures. Its roots are often cited as going back to the very 1936 paper in which Turing introduced his machines

[Tur36]. Turing’s original definitions rely on the binary representation and he adapted them to the ones still used today in his 1937 correction [Tur38] with a pointer to earlier work by Brouwer. The theory of computable functions on the real numbers was further developed in the 1950s by Grzegorczyk and Lacombe in parallel [Grz57, Lac58]. Later on, Kreitz and Weihrauch extended the theory to apply to more general spaces and introduced the formal framework of representations that is standard today [KW85, Wei00, LN15]. The basic idea behind computable analysis is fairly easy to grasp: To make uncountable structures available to computation, one encodes them by infinitary objects that can still be operated on mechanically. Most commonly infinite strings are used, but more conveniently one may use functions between discrete structures: A reasonable encoding for real numbers is to describe them by functions that provide arbitrarily accurate approximations. Since the inputs and outputs of such functions can be chosen rational and thus be described by finite means, this leads to a realistic model of computation. To compute functions on the real numbers, one operates on these encodings and algorithms use a computation model that can handle properly infinite inputs while remaining realistic in the sense of being implementable. The standard references for more detailed information about computable analysis are [PER89, Ko91, Wei00] and the topics are presented in a form that is somewhat closer to how this paper proceeds in [Bau00, Sch02b, Pau16].

The model of computation used in computable analysis must be distinguished from more common ones that operate on functional inputs by encoding them via a Gödel numbering and, from the perspective of computable analysis, the latter can be understood as imposing a more relaxed notion of correctness of algorithms [AB14, LN15]. Neither of these methods of doing real number computation reflects the practices from numerical analysis. For the sake of efficiency, numerical analysts rely on the use of floating point computations in implementations of their algorithms. This is while proofs of correctness use mathematical methods whose underlying notions of algorithms are geometric modes of computation similar to the BSS model [BSS89]

and assume the capability to carry out exact operations on real numbers. In the implementation, real variables are substituted with machine numbers for which basic properties like associativity fail. This leads to a situation where the mathematical proof of correctness of the algorithm need not say anything about the correctness of an implementation even if both are done correctly. On one hand, these problems are well aware to algorithm designers and considered relevant in many applications that demand high reliability of the results. On the other hand they are difficult to overcome as by-hand error estimation of more complicated algorithms quickly becomes infeasible and is error-prone itself.

Recently, with the growing maturity of formal methods for software verification and proof assistants, a new approach to ensure the reliability of floating point computations has become accessible [BM17a]. Over the last decade an active community has formed whose focus is to apply formal methods to floating point algorithms. These efforts have a fairly large coverage of different topics reaching from verification of single algorithms [BCF13, BRT17] to the formalization of methods from numerical analysis [BCF17]. While mathematical development of numerical schemes and implementation are a priori very different tasks in a formal development they come hand in hand: The formalization of the numerical solution schemes has to precede an attempt to prove software that uses this scheme correct. There are a number of proof assistants that are appropriate for such endeavors and one that is particularly popular in this community is Coq [BLM16]. This is because the Coq system is traditionally centered around the interface between proofs and computation. Indeed, Coq uses a type-theoretic setting that favors constructive reasoning and allows for code extraction from proofs, but also provides advanced automation tools for instance for proving inequalities over real numbers. Furthermore, it provides a designated type Prop meant to distinguish proofs with computational content from those that are purely for specification and verification. The recent advances in formal proofs and verified numerics have decreased the gap between the theory of computation and numerical practice and the computable analysis community has shown an increase of interest in these developments [MPPZ16]. In part because the focus of computable analysis is reliability as all algorithms must provide rigorous error bounds, but also since algorithms from computable analysis are notoriously difficult to implement in a way that makes them competitive in terms of speed and memory consumption [Mül01, Bla01, KN17].

1.1 Coq and proofs about continuous structures and computation

Coq is a proof assistant that supports mathematicians in giving fully formal proofs of their results. A typical Coq development consists, just like a mathematical paper, mostly of definitions and lemmas (and some explanations and documentation). The definitions specify the objects that the developer is interested in and the lemmas their properties. Coq automatically checks that definitions are well formed and that only correct proofs are specified for the lemmas. For the definition of a function, for instance, Coq checks that return-values are specified for all possible inputs. This means that only total functions can be defined in Coq by design and this is necessary for theoretical reasons, as Coq heavily relies on the Curry-Howard correspondence. Mathematically one can still reason about partial functions by modeling a partial function from to by a total function from to , where is the extension of with a single object that is understood to stand for “undefined”. Proving a fully constructive result in Coq can be seen as using a high level programming language to specify how a desired result can be obtained from the given inputs. Some of the inputs here may not be traditional input data but instead evidence that the assumptions of the lemma are fulfilled. In principle there is not much difference between such a lemma and a definition of a function. One may even follow a Coq-definition with a proof (that should end in “Defined” instead of “Qed”), providing missing parts in the high level language instead of specifying them by hand.

For code extraction to be possible one needs to restrict to constructive reasoning. A mathematician working with Coq will quickly run into statements that appear to be true but that he can not seem to be able to prove. An example for a restriction of the internal logic of Coq that often causes troubles with mathematicians is functional extensionality: For functions and of the same type mathematicians would assume that the statement (forall a, f(a) = g(a)) -> f = g is true, but this is not provable in Coq. However, Coq allows to assume axioms and one may state additional inference rules as such. Many mathematical developments force the truth of functional extensionality by assuming it as an axiom and other popular axioms are classical reasoning or choice principles. Of course, one has to make sure that the axioms are compatible with Coq’s internal logic and compatible with each other. Coq’s official webpages list some known facts about consistencies of axioms that are often used https://github.com/coq/coq/wiki/The-Logic-of-Coq#axioms. One should also be aware that assuming axioms impedes the ability to extract algorithmic information from proofs.

Even if all reasoning is constructive, many lemmas during a development will have parts whose computational content is only to provide evidence that some correctness statement is fulfilled. This may be that a definition of a function the developer is actually interested in fulfills a specification, i.e. that an algorithm is correct. Typically, if the correct specification was proven, the rest of the development will not rely on specifics of this proof either, so that it can be given a name, marked as correct and its details hidden. Indeed, this is important to allow Coq to efficiently check the later proofs in a big development, i.e. to keep proof terms manageable in size. In Coq there exists a type Prop that can, and is meant to, be used to mark parts of proofs that do not have computational content in the above sense. The distinguishing feature of this type is that a definition of a function cannot depend on the details of the proofs of inputs of type Prop. This rule is what allows the code extraction machinery of the Coq system to disregard all parts that are propositional.

Let’s say that we extract an algorithm from a function with a regular input and an additional propositional input that asserts that the regular input has some property. The computational content of such a function can be thought of as an algorithm that only takes the regular input. The propositional input that is supposed to assert a property of the regular input was removed in the extraction of computational content and the user is assumed to make sure that he only uses the algorithm on valid inputs and is only guaranteed to get a meaningful result in this case. The propagation of propositional correctness can be considered verifying such algorithms. In Coq this propagation is usually done by specification lemmas and included in the development with other lemmas that have computational content. From a practical perspective, it is reasonable to treat the proofs of the specification lemmas differently. As these do not carry computational content, the rules for proving them can be adapted by assuming appropriate axioms: A user might take the stance that it is enough to be sure that no counter-example for correctness can be explicitly given. In this case a specification lemma is justified to use classical reasoning and assume any set of axioms that the user is convinced are consistent. This can vastly increase convenience in verification of algorithms. In cases where it does not cause extensive extra work or impact the comprehensibility of statements, it is still reasonable to keep specification lemmas as constructive as possible to be able to extract information in case it becomes useful.

The Coq system supports its users in keeping the distinction between computational and non-computational content up and prevents them from using non-computational content definitionally. Many of the axioms from the Coq system are formulated propositionally so that the user is prompted for incorrect use. This is for instance true for the choice principles in the standard library. The mechanism is not foolproof but generally works well. Unfortunately, the same mechanism appears as a major hurdle to users who do classical mathematics, where more liberal definitional thinking is common practice. Consider for instance the function that is part of the axiomatization of the reals in standard library and is supposed to return the least integer bigger than its input. The existence of such a function cannot be proven constructively in reasonable constructive instantiations of the real numbers. The existence of this function is still stated definitionally and not hidden behind an existential quantifier to make it a proposition. The motivation behind this is clear: it avoids many instances of having to resolve an existential quantifier and uses of a uniqueness lemma. I.e., Coq does no longer attempt to forbid the use of this function in definitions. A maybe even more prominent example is the boolean-valued inequality relation that allows branching over inequalities of reals. As a consequence, the use of Coq’s code-extraction is very limited for obtaining algorithmic information from statements about the real numbers in the standard library. At best, geometric algorithms can be extracted and a replacement of the real number type by a realistically implementable one leads to an almost guaranteed loss of correctness.

Nonetheless, there exists a vast body of work building on the classical axiomatization of the reals in the standard library. For instance the Coquelicot library [BLM15] as a widely used library for real analysis that is conservative over this axiomatization. More recent developments in Coq’s community for formalization of results from analysis take an even clearer stance on these topics and assume the full strength -axiom to marry the Coquelicot library with the mathematical components library [ACR18]. Computational content is restored in an additional step by using the mathematical libraries to prove floating-point algorithms correct [BM17b]. Computable analysis fits well into these developments: it traditionally uses classical reasoning on the mathematical structures and the algorithmic content is considered extra information about data representation that should follow the mathematical understanding.

The Incone library is an attempt to implement computable analysis and its backwards approach in Coq and use it and synergy with the developments in the verified numerics community to complement the forwards approach of working completely constructive. It stays faithful to Coq’s propositions but additionally uses an internal construction that achieves a similar goal in a different context. For this it relies on the Rlzrs library that reflects some concepts similar to the mechanisms behind the code extraction and investigates them as a mathematical construction in Coq. The main reason for this reflection is that computable analysis is the piece of mathematics that we want to formally reason about. We want it to be possible to specify algorithms on a level of abstraction as this is usually done in computable analysis. However, another welcome consequence is that we obtain a separation into a mathematical layer and a computational layer on each of which the appropriate tools can be used. Currently our most used tool on the computational level is the Mathematical Components library and for mathematics it is the standard library and Coquelicot in combination with the Rstruct file. For mathematical analysis we hope to soon be able to move to mathcomp analysis. On the computational level use of coq-Interval seems promising in the future.

The reflection using the Rlzrs library leads to a loss of the ability to extract algorithms from fully constructive proofs about the mathematical structures. However, some of these capabilities can be recovered, for instance, by proving induction principles for represented spaces. The use of such induction principles in computable analysis becomes subtle if computability is taken into consideration. This is related to uniformity issues and to the failure of the category of represented spaces with computable functions to have countable products, which is one of the most commonly encountered problems in obtaining computability versions of continuity results. Proofs of some restricted induction principles and some applications can be found in Incone’s sister library CoqRep. However, in our experience, general purpose induction principles are prone for being unreasonably inefficient on this level and Incone does not provide any. In concrete cases a better idea is to try to substitute them with induction principles on the level of discrete data by a change of representation or to design the corresponding algorithms by hand.

The C-CoRn library for constructive analysis is by far the most advanced fully computational Coq development that deals with real numbers [CFGW04]. It achieves the executability by restricting to constructive proofs and the relation of our work to this should be clear from the previous paragraphs. The C-CoRn library provides a wide range of results about functions on real numbers and some about operators on function spaces. It includes an exhaustive treatment of metric spaces and uniformly continuous functions between metric spaces [O’C09]. The C-CoRn library is inspired by, and roughly follows the development of constructive analysis by Bishop and Bridges [BB12]. Our treatment of the real numbers rarely goes beyond what is already content of C-CoRn and many parts are inspired by it. This said, it should also be noted that the constructive nature may make the C-CoRn library and the publications related to it difficult to access for some classically trained mathematicians. Some of our results about reals are also covered by a smaller project that implemented Cauchy reals to use them and the mathematical components library to give a definition of the algebraic real numbers in Coq [Coh12]. While our treatment of computation on the real numbers rarely leaves the shadow other developments, in particular the C-CoRn library, some of the results about metric spaces do. To the best of our knowledge most of the rest falls outside of the scope of any other formal development in Coq, or in other proof assistants for that matter.

None of our results are mathematically original, but all formalize well-known facts from computable analysis. In our opinion this is an instance where many parts of the formalization itself are creative contributions. This is reflected in our presentation of the contents that regularly diverges from the standard approaches. We feel that most of these deviations are beneficial for the understandability and some are improvements due to new insights we gained through the formalization. The applications presented in this paper are pure computable analysis and the specified algorithms are far from being competitive by means of speed or memory consumption. We currently use rational numbers for approximating reals, no kind of efficiency can be expected before these are not at least replaced by arbitrary precision floating-point numbers. However, it should be kept in mind that this is possible in principle and we believe the framework we use to have realistic applications. Indeed, the long term goal behind the development of the Incone library is to provide an environment in which the intersection of formal proofs, computable and numerical analysis can conveniently be investigated in Coq and their merits can be combined in attempts to prove efficient algorithms with practical relevance correct.

1.2 Realizability approach to computation on finite and infinite data

Fix some set of data, some set of abstract objects and a relation on that specifies which pieces of data describe (or approximate) which abstract objects. For now let us call such a relation a realizability relation if each abstract object is described by at least one piece of data. Realizability relations are ubiquitous in the theory of computation, constructive mathematics and proof theory. Depending on the field, realizability relations may be interpreted as a specification of a function in either direction and, depending on this choice, the condition that is imposed on a realizability relation can be formulated as being surjective or total. A priori, a realizability relation does not have a preferred direction and some fields even decide to omit the abstract objects completely and only talk about partial equivalence relations on the set of data.

The convention in computable analysis is to interpret a realizability relation as a specification of a function from data to abstract objects and to pick Baire space as the space of data. This leads to the notion of a multi-representation where a piece of data gives a description of an abstract object by means of providing on demand information about it. The description of real numbers via functions that take rational accuracy requirements and return rational approximations is an example. As in this case, it is most common that each of these descriptions uniquely identifies the abstract object, and in this case the relation is called single-valued. Any single-valued realizability relation can be identified with a partial surjective function that is then called a representation and is the central object of computable analysis.

In other applications it can be useful to interpret a realizability relation as a specification of a function in the other direction. One may take the fact that any abstract object is hit by the relation as indication that a choice function through the relation that goes from abstract objects to data is an important concept and call such a function a “representative function”. Such a function is for instance useful for the sake of making quotients usable in Coq [Coh13] and particularly often encountered in the Mathematical Components library [mat]. Consider, for instance, the case of rational numbers. Here, the data would be pairs of integers, the abstract objects would be rational numbers, which may be thought of as equivalence classes of pairs of integers. The representative function could in this case pick from an equivalence class the unique fully canceled pair of integers. A multitude of further examples can be found in the Mathematical Components library. Due to the change in directions, where computable analysis restricted to single-valued representations, representative functions are often required to be injective. Indeed, in their above use for quotients this can be seen as a consequence of the definitions.

From the perspective of computable analysis the concept of a representative function is rarely useful. Picking a unique reference description from the continuous Baire space is highly ineffective for most representations that do not allow reformulation using a discrete data set. The difference in applicability of this concept between computable analysis and the Mathematical Components library can be attributed to the difference in scope: The Mathematical Components library is mostly concerned with operating on objects that can be encoded by finite means efficiently while in computable analysis the focus of interest is on operating on objects from sets of continuum cardinality where this is not possible anymore. Indeed, the reader may go through the concretely specified representations from this paper and verify that a computable representative function exists exactly for the discrete example spaces.

The Incone library follows the ideas from computable analysis closely to provide a formal definition of represented spaces in Coq. However, as implicitly done in the example of real numbers above, it adds an additional layer of abstraction, where the inputs and outputs of a description need not always be explicitly encoded as natural numbers but are allowed to use any countable and inhabited types. If Coq’s types are interpreted as sets and a classical setting is assumed, computable analysis is recovered. In a constructive setting or if one wants to reason about computability as refinement of continuity, more care has to be taken with the input and output types. One way to ensure that everything works out fine is to guarantee that the types are either finite or allow an effective bijection with the natural numbers. This may be forced by requiring the construction of Mathematical Components countType structure for the input and output types. Attempts to give a computability theoretic treatment of Incone’s input and output types such that stability under change of the level of abstraction can be guaranteed seem to lead back to concepts very similar to representative functions. This is far from a rigorous argument but may explain our empirical observation that the types from the Mathematical Components library are often a good fit for use as input and output types for descriptions in our examples. The reason why the Incone library does not globally require the input and output types to be countTypes is for the sake of providing a better interface with data-types outside of the math-comp ecosystem. While the Mathematical Components library is very efficient in preserving its structures through the most common type-constructions, it can be tedious to construct new instances for custom data-types. For example, in our development the rational numbers from the standard library were preferred over the corresponding math-comp type because they provide a better interface with the reals from the standard library. Proving the rationals from the standard library to be countable was a matter of minutes. The construction of an appropriate countType would have been possible, but it would have been a considerably bigger effort at least for someone not native to the math-comp system.

The formulation of concepts from computable analysis in the Incone library relies on the Rlzrs library, which in turn is based on the mf library for manipulation of multivalued functions. Multifunctions are a very popular tool for specification and classification of problems in computable analysis [BKMP16, BGP17, BG11, BDBP12, PS18]. Within this field, multifunctions form a topic of research of their own [Pau12, PZ13]. This is not to say that this concept was invented for computable analysis, multifunctions have been popular in other branches for a long time. For instance in computational complexity, in particular the theory of promise problems and non-deterministic computation [Sel94, ASBZ13], and even in the treatment of non-smooth and non-linear problems in functional analysis [EM46, Dei92].

Due to their many potential applications outside of the Incone library, the development of a convenient environment for manipulation of multifunctions was exported and can be obtained separately as the mf-library [Ste19d]. Already the Incone library uses multifunctions for several different purposes: Through the Rlzrs library for the formulation of realizability, but for instance also for dealing with partiality issues in Coq

. Our last example even features multifunctions in the role they traditionally play in computable analysis: A popular topic is to prove mathematical problems computable or, if this is impossible, classifying their degree of incomputability. Here, mathematical problems are formulated as multifunctions between represented spaces and the comparison is carried out by means of Weihrauch reductions. A class of examples of mathematical problems, or computational tasks that often appear in such classifications is closed choice on some space

, where the task is “given a non-empty closed set select an element ”. A closed subset of a represented space is given by specifying positive information about its complement. Thus, for most choices of , this task is uncomputable and even discontinuous. We give a formal proof of this statement for the special case that turns up in classifications especially often.

1.3 Outline of the paper and its relation to the Incone library

The paper describes the Incone library in detail and hopefully it is possible to use it as an introduction or as a manual. We selectively mention the important notations and whenever the name of a concept in the paper diverges from its name in the library, we point this out. One major point where paper and the library diverge is that Incone uses the phrase “continuity space” for what is referred to as “represented space” in this paper. This is because the library is derived from the CoqRep library which attempts to talk about computability more directly. Since represented spaces are tied to computability theory, which the Incone library avoids apart from on the meta-level, we decided to switch from represented space to continuity space. Detailed instructions for installation and for verifying the content of this paper can be found on the paper’s project page https://holgerthies.github.io/continuity and in the references [Ste19d, Ste19c, Ste19e, Ste19b, Ste19a]. The treatment of abstract realizability, which may be useful in more general settings, has been exported to a separate library called Rlzrs. The Rlzrs library uses a somewhat different language and we refrain from describing it in detail here.

The main contributions of this paper are mostly listed in Section 4 with some exceptions that already pop up in Section 3. All theorems, propositions and lemmas in this paper have been formally proven in Coq and have explicit pointers to their name in the Incone library. Many of the claims that are stated in the plain text, as corollaries or as examples are also supported by formal proofs and the references to the Incone library are put in brackets after the statement. The major milestones in the development of the Incone library were an appropriate formulation of continuity, the construction of a continuous universal, of finite and countable products, function spaces and a duality operator. The formal proofs that we consider the main contributions are that the countably infinite product of a space with itself is isomorphic to a space of functions (Theorem 7), that the algebraic operations and the efficient limit operator on the reals are computable (Examples 3.1 and 3.2), compatibility of the enumeration representation of subsets of natural numbers with the abstract definition of the space of open subsets of the natural numbers (Theorem 11), and that continuous realizability implies sequential continuity (Theorem 2). The previous results are fully algorithmic, but we also describe many non-computational theorems. These include numerous specification results for the constructions the Incone library (in particular Theorems 3, 5, 6 and Proposition 3.2), a proof that the information theoretic notion of continuity used in the library is equivalent to the metric notion of continuity on Baire space (Theorem 9), a complete comparison of the different concepts of continuity that arise from metric and represented-space structures (Theorems 4.2 and 4.2) and the discontinuity of the unrestricted limit operator on the real numbers (Example 3.2) and the task of selecting an element of a closed subset of the natural numbers (Theorem 4.3).

In Section 2 we introduce the concept of continuity of partial operators on Baire space. As a preparation for a proper treatment of partiality in Coq, the introduction describes Incone’s sub library mf for specification of functions through relations. The first part discusses how we reflect computability of functions and operators in Coq. A relativization of this construction is one of the core concepts that is revisited many times throughout the rest of the paper. This construction also provides a very smooth transition to considerations about continuity. The second part gives an information theoretic description of continuity on Baire space and an overview over the formalization of this notion in the Incone library. The third part presents the universal that the Incone library uses to implement the function space construction from computable analysis. These three parts together cover most of what can be found in the baire_space folder of the Incone library.

Section 3 deals with the basic concepts from computable analysis, explains how they are realized in the library and introduces the real numbers as an example that is used through the rest of the section. The first part of the section explicitly describes how a few of the simple type constructions like products are automatized in the library. It presents some examples that use these constructions to prove the algebraic operations on the real numbers and polynomial evaluation computable. The second part describes how countably infinite products can be constructed and considers point-wise operations on spaces of sequences and the limit operator on the real numbers as concrete examples. From a category theoretical point of view, infinite products are of particular interest as their existence is only guaranteed in the case where all continuous functions are considered as morphisms and fail to exist if one restricts to computable ones. The final third part builds exponentials using a construction that is known to work for both these categories. It presents a formal proof that the countably infinite products can be recovered as certain exponentials. As a whole the section roughly corresponds to the content of the folder continuity_spaces in the Incone repository.

The final section (Section 4) starts with a brief description of the metric library and a comparison to other formalizations that have a similar purpose. The first part presents a formal proof that information theoretic notion of continuity that the Incone library uses internally is equivalent to the more traditional approach of equipping Baire space with an appropriate metric. The second part presents formal proofs about the relation of different concepts of continuity. The final part introduces Sierpiński space as a space that can be used to abstractly reason about open and closed subsets of represented spaces. It then shows that certain enumeration representations are a concrete instantiation of the structure that the power set of the natural numbers can be given when its elements are interpreted as the open or closed subsets. It uses this to give a formal proof that the task of closed choice on the naturals is discontinuous, i.e., that the multivalued function that corresponds to this task does not have a continuous realizer. The Weihrauch-degree that corresponds to this task is called and is very commonly encountered in classifications of the computational content of mathematical theorems.

2 Multifunctions and partial operators on Baire space

Computable analysis transfers the computability and topological structure of Baire space to more general spaces by means of encodings that are called representations. Before we go into detail about how this can be done, this chapter describes the structure on Baire space that we need. Classically, Baire space is the space of all total functions from natural numbers to natural numbers, i.e., functions of type . We use a more general setting and refer to any space of the form as Baire space if and are countable and inhabited types (or non-empty countable sets from a set-theoretical point of view). Classically these assumption imply that the types are either finite or bijectively related to the natural numbers. Of course, constructively this is far from true. Indeed, if computability considerations come in, that is, if the surjection whose existence is guaranteed by the countability is considered an encoding of the elements of the type, more care has to be taken. The critical reader may in the following replace any occurrence of and their dashed variants by and assume that the difference in naming is merely for convenience in type-checking. In the applications that we look at, these substitutions can always be carried out by hand. Readers not familiar with Coq and the treatment of functions in proof assistants may go further and replace any mentioning of “Coq functions without axioms” by “functions definable in Gödels system ” or in the absence of functional inputs even by “primitive recursive functions”. This correspondence is well known to be imperfect but happens to work out in all examples that we look at.

In Coq functions are always total. To find an appropriate notion of partiality, which is important for a proper treatment of continuity, we first need to discuss how functions can be specified through relations. Throughout the whole paper we use a happy mix of type-theoretic, set theoretic and mathematical notation. In particular we identify subsets of a given type with functions of type and borrow the element-hood notation from set theory, i.e., we write for (the corresponding notation _ \from _ in the library is unfortunately very unstable and often not printed). We also use the mathematical notation for subsets, subset inclusion and partial functions. Finally, we avoid the use of the colon for typing when referring to element-hood of Baire spaces. This is because of the confusing ambiguity in interpretation of function types. For our purposes it is more natural to consider elements of Baire-spaces as mathematical functions and not elements of a function type. This is also reflected in common applications of the functional extensionality axiom to elements of Baire space and in a regular use of choice principles on the level of Baire spaces.

A multivalued function (notation _ ->> _ in the library) is a function that assigns to each a possibly empty subset of . While this gives the type or equivalently and one could identify with a binary relation, the intuition behind a multivalued function is different as is treated as input type and as output type. The domain of a multifunction is given by and for the set should be interpreted as the set of eligible return values. A multivalued function is called total if its domain is all of , and single-valued if each has at most one element.

Any multivalued function can be considered a specification for functions: A function fulfills the specification if for all . In this case we say that is a choice for (icf in the library with notation _ \is_choice_for _). The operations on multivalued functions are chosen such that they behave well with the interpretation as specifications. For instance, the composition of two multivalued functions and is given by

(notation _ \o _ in the library.) This is an associative operation and the second half of the requirement, namely , is what is commonly used as composition for relations. The domain condition is a modifier that addresses the difference in interpretations and in particular leads to a loss of the symmetry under exchange of the input and output types.

There are two very straightforward ways to generate multifunctions from functions or partial functions. Namely, for a function just use the specification that uniquely determines it, i.e. . Clearly, this multifunction is always total and single-valued (F2MF_tot and F2MF_sing) and assuming that is not empty and an appropriate choice principle, each total single-valued multifunction arises in this way (fun_spec). This construction can easily be extended to partial functions, i.e., by assigning to the function

which is still single-valued (PF2MF_sing) but need not be total anymore. Again, assuming some choice axioms, one can show that any single-valued multifunction arises from some partial function (pfun_spec). Due to the setting of this paper, where we are mostly interested in operators on function types, coding a partial function as a function to an option type is often unnatural as it may be understood to indicate that the domain of the function should be decidable. We therefore choose the mathematical notation for partial functions to avoid mentioning option types and in the Incone library they are usually treated as single-valued multifunctions right away.

The assignments F2MF and PF2MF are compatible with the multifunction composition:

Lemma (F2MF_comp and PF2MF_comp)

Composition of functions translates to multifunction composition, i.e.  and .

Indeed in the previous Lemma the multifunction composition could have been replaced with the relational composition, as the two compositions coincide if the function that is applied last is total (comp_rcmp) resp. the first one is single-valued (sing_comp). Since the internal logic of Coq does not imply propositional extensionality, and we prefer not to assume it globally, the equality of multivalued functions is handled as equivalence relation in our implementations (equiv in the library with notation _ =~= _). To be able to still conveniently manipulate multivalued functions, the setoid-rewrite mechanism of Coq is used.

Note that in contrast to functions, any multifunction can be assigned a reverse multifunction where the input and output is simply switched. All properties of a multifunction have a co-version that requires the same property for the reverse multifunction. Many of the co-properties have nice characterizations for the special cases of functions. For instance, a function is injective if and only if is co-single-valued (mfinv_inj_sing). Readers familiar with representations will not be surprised that we list the following as a lemma:

Lemma (PF2MF_cotot)

A partial function is surjective if and only if is co-total.

Another operation on multivalued functions that is important for our purposes is the notion of a tightening (tight in the library with notation _ \tightens _). For multifunctions we say that tightens if it is more restrictive as a specification. That is, if

Indeed, under appropriate assumptions tightens if and only if being a choice for implies being a choice for (icf_tight and tight_icf). A function is a choice for a multifunction if and only if tightens (icf_spec) and if tightens we say that is partial choice for . Many properties of multifunctions are proven in the library and we just pick an example:

Lemma (tight_comp)

If tightens and tightens then tightens .

An exhaustive overview over the concepts and notations for multifunctions the mf library provides can be found in the preamble of the mf.v file.

2.1 Capturing the computable multifunctions and relativization

For another, more involved but for the purposes of this paper important construction recall that for a type the option type has for each an inhabitant and an additional one called . Given a function of type define a multifunction via

The idea behind this (also called the Kleene normal-form theorem [Soa78]) is that in the special case where the specification of any partial computable function can be expressed in this way with a primitive recursive function. This is in particular interesting to us since any primitive recursive function has a definition in Coq that is closed under the global context [O’C05]. Note that a priori, the multifunction need neither be total nor single-valued. A single-valued tightening of can be obtained by setting to on input and run on inputs and return first value returned by (a definition and formal proof of correctness can be found in the CoqRep library). This construction actually forces more than single-valuedness, as the functions it produces are all monotone in the sense that if they return something they neither ever go to another value nor back to . Thus, under the reasonable assumption that any function that has an axiom free definition in Coq is computable, each specification that can be produced without axioms has a computable partial choice function.

The correspondence makes it possible to talk about computable functions in Coq at least on a meta-level. Since we are interested in specification of partial operators, we relativize the construction. First recall that we use the notations and . We consider a function to specify the operator such that

(operator in the library with notation \F_( _ )). In the same way as was done for the unrelativized case, one may force single-valuedness.

Example (examples/continuous_search.v)

If is taken to be the function that returns if is the smallest number no bigger than such that and if no such exists, then is the search operator whose domain are the functions that eventually hit zero and whose value is the constant function returning the minimal such number.

As a word of warning, and an additional motivation for the next section, let us briefly look into composition of computable functions and operators. First consider the assignment . Given functions and one may define a new function via

where is the Cantor (or any standard) paring function. This captures the relational composition in the sense that which in turn tightens . Under the assumption that is monotone, one may even simplify the construction and avoid the need to use a pairing function (the construction is included in the CoqRep library).

In the relativized case we are interested in composing operators and in obtaining a tightening of from and . To understand why we cannot simply use an analogue of above construction, fix some and . Due to the definition of the assignment, we can recover from finite approximations to possible functional inputs to . However, to get any information about the return value of the composition it is necessary to extend these finite approximations to a total function that can be used as input to and without further information it is not clear why the return values of on an extension should have anything to do with a return-value of the composition. In particular it is not clear that it can be made independent of how we extend. Of course, since Coq is consistent with functional extensionality and any function in Coq can be evaluated in a finite amount of time, one might tend to believe that if can be defined without use of axioms, its value on fixed inputs only relies on a finite number of the return values of its functional input. The additional information that is needed about for being able to carry out the composition is exactly what is introduced as a modulus of continuity in the upcoming section.

2.2 Continuity of partial operators between Baire spaces

This section presents an information theoretic development of a notion of continuity of operators between Baire spaces. The Incone library provides proofs that the definitions presented here are equivalent to more traditional notions of continuity, but the discussion of these equivalences is postponed to Section 4 since it requires some background about metric spaces and topology that are not necessary for the presentation in the current section. For the following fix some types , , and and set and .

Figure 1: A continuous operator.

Intuitively continuity means that the return-values of an operator interpreted as functional of type do only depend on finite information about the values of the functional input from and thus can be thought of as being represented by a diagram as depicted in Figure 1. Mathematically, continuity can be described as follows: A function is continuous if for any element of and any there exists a certificate, i.e., a finite list such that for any that coincides with on it holds that . Here, two functions are said to coincide on a finite list if for any contained in . A partial operator is continuous if for all and there exists a certificate, i.e., a finite list such that the above statement holds for any .

Example (examples/continuous_search.v)

Functions that can be defined in Coq without mentioning any axioms are usually easy to prove continuous. For instance consider the function defined by . Then obviously, for any inputs and the finite list will do. For the operator the list is appropriate.

The meta-level explanation of the behavior described in this example is that any function definable in Coq without axioms is computable and therefore continuous.

Figure 2: A computable operator
Example (examples/continuous_search.v)

The same remains true for operators whose specification can be given as for some function such that has a Coq-definition that is closed under the global context. For instance for the search operator from Example 2.1 the function can be defined in Coq without axioms and the list is a certificate for functional input and discrete input . The search operator does not have a continuous total extension. The fairly vague argument that any Coq function is computable and total, and that any computable function is continuous makes it reasonable to assume that no choice function for this specification can be defined in Coq without relying on axioms.

Indeed, from a meta-level many of the proofs of continuity that can be found in the Incone library proceed by specifying an axiom-free Coq-function interpreted either through the F2MF or through the assignment and may thus be understood as proofs of computability whenever the open types are instantiated appropriately (at the very least if all input and output spaces are set to be the natural numbers). All claims of computability in the rest of the paper should be understood in this sense.

The definition of continuity in the Incone library follows the mathematical definition given earlier mostly literally. The only difference being that instead of a separate list for each a Skolem-function is used, which switches the order of the corresponding existential and universal quantification. This is equivalent to the above definition whenever an appropriate choice principle is available (choice_cont) and avoids assuming any choice principles in the proof that the composition of continuous operators is continuous.

Partiality is treated by using multifunctions and the statement of continuity of a multifunction is chosen in such a way that continuity implies the function to be single-valued (cont_sing). The notion of a certificate is made sense of for general multivalued functions (we mention this because it is used below). Continuity for multifunctions on Baire space should not be confused with the notion of continuous realizability that is introduced in Section 3 as it is different in character. Still it works well with the composition of multivalued functions, as that reproduces the usual composition of partial functions.

Theorem 1 (cont_comp)

Let and be continuous partial operators. The operator is continuous.

The idea behind the proof is that the certificate functions and whose existence is guaranteed by the continuity of and can be interpreted as multivalued functions and composed relationally to obtain a certificate function for the composition of the operators. Furthermore, the needed relational composition can be realized constructively on the level of combining lists.

As we compare different notions of continuity in the later chapters, let us briefly discuss sequential continuity on Baire spaces. An element of a Baire space is said to be the limit of a sequence in if for each fixed argument the sequence is eventually constantly . Formally

If a sequence in Baire space has a limit, this limit is uniquely determined (lim_sing) and thus the above defines a partial function .

A partial operator is called sequentially continuous if for any and any sequence from the domain of the operator such that it also holds that . It is well known that the topological structure of Baire space is such that sequential continuity is equivalent to continuity and the Incone library includes a formal proof of this. However, this is a classical fact and a constructive proof of sequential continuity provides strictly less information than a proof of continuity, thus the library separates the equivalence into two implications.

Theorem 2 (cont_scnt and scnt_cont)

A partial operator between Baire spaces is continuous if and only if it is sequentially continuous.

Section 4.1 equips Baire space with the structure of a metric space and recovers the notions of a limit and continuity discussed here from the metric notions. Thus, the formal proofs that continuity and sequential continuity are identical to what is described in Section 4.2 imply the above theorem. However, metric spaces use real numbers, which leads to the axioms of the real numbers appearing in the assumptions printed when inspecting the proofs. This is even though the proofs do not use these axioms in an essential way. Thus, the above statement is given a separate proof in the Incone library.

2.3 Construction of a universal and proofs of some of its properties

Let and be Baire spaces in the sense of the previous sections. A continuous universal, or just universal, is a pair of a Baire space and an operation such that for each continuous there exists an element such that tightens

. That is: a universal provides a way to code any continuous operator between Baire spaces by an element of another Baire space. To motivate the name, note that a universal Turing machine fulfills a modification of the above, where all the Baire spaces are replaced by the set of finite binary strings and the word “continuous” by “computable”. While the construction of a universal Turing machine takes some effort, continuous universals can be chosen very simple: Well-known continuous universals are the Kleene-Kreisel associate construction

[Kle59, Kre59] and Weihrauch’s operator [Wei00]. The former of these is conceptually more well adapted to our setting and there are several excellent sources to read up about its background [LN15, EX16]. Our first implementation of a universal followed the Kleene-Kreisel construction very directly and is still used in the CoqRep library.

The universal that is currently used in the Incone library is a slight modification of the original construction for the sake of efficiency. Namely it uses lists as a simple way of avoiding the need to take too many loops through the universal that may lead to reevaluation and are generally a waste of time. An exact specification is the following (compare Figure 3): for fixed and set and , that is use . That is a Baire space, i.e., that and are countable and inhabited, follows directly from and being Baire spaces. Assign to a function from the Baire space the multifunction defined as follows: if and only if for any there exists a finite sequence of lists such that for it holds that for some (where denotes the left inclusion in the sum) and and (where denotes the right inclusion of the sum).

update list

Figure 3: The universal used in the library.

The notation we used for continuous universals heavily implies that the universal can be specified by means of a function where the universal as described above can be recovered using the interpretation described in the first subsection via . Indeed, such a function U is specified in the library and its Coq-definition is closed under the global context. We refrain from writing out the exact definition of here and point the interested reader to the Incone library, where the definition can be printed and a formal proof that it fulfills the above specification can be found (FU_spec). Furthermore, is always monotone in the sense of the previous section (U_mon) and in particular is always single-valued (FU_sing).

Define the multivalued modulus of continuity of an operator (continuity_modulus in the library) by

The definition of makes sense for any multifunction and is continuous, if and only if the domain of is a super-set of the domain of (cont_spec). If is continuous, then we call any partial choice function of a modulus of continuity of . Note that the multivalued modulus of continuity of a modulus of continuity has the same type as . Thus it makes sense to call a modulus of continuity of self-modulating if it is its own modulus of continuity.

Whenever is such that tightens , a self-modulating modulus of can readily be obtained by tracking the queries in the evaluation of the universal. The same can be done for the values that the universal calls the function on and one defines such functions and (queriesM and shapesM in the library with definitions that are closed under the global context) such that and are the corresponding operators.

Theorem 3 (FqM_mod_FU, FqM_mod_FqM and FqM_mod_FsM)

For any fixed the operator is a modulus of continuity of , of itself and of .

The universal is used in the library to construct function spaces, that is exponentials, in the category of represented spaces. It should be reasonable that the above is essential for proving the evaluation procedure on the constructed space of functions to be a continuous operation. It also implies that for any the operator is continuous (FU_cont). The functions and are of more theoretical than practical importance. For the purpose of inspecting the behavior of an associate the library provides additional functions gather_queries and gather_shapes that return the queries done up to the -th loop of the universal (see examples/KleeneKreisel.v).

The library also provides a full proof that specifies a universal:

Theorem 4 (U_universal)

For any countable and non-empty types , , and and for any continuous operator there exists some such that tightens .

While we do not repeat the proof given in the library here, let us sketch the most important parts and point out some interesting details. Fix some enumeration of , let be a function that chooses through the multivalued modulus of continuity of and let be a function that chooses through . For any fixed enumeration of , one can attempt to define an associate (psiF in the library) for as follows: On input interpret the list as a partial function by assuming that its elements are the return values on the first elements mentioned in the enumeration of . Extend this function to a total function that is from the domain of if this is possible. Check whether each element of is contained in the first elements mentioned in the enumeration of . If this is so return , otherwise ask for the -st element mentioned in the enumeration.

Without further assumptions about the function defined above might fail to be an associate of as the extensions that is called on can change in each iteration and may return a properly bigger list each time, such that the run of diverges on valid inputs for . Since it is always possible to extract a self-modulating modulus from an associate it may not be surprising that what is needed to complete the proof is indeed to construct a self-modulating modulus. In the library the existence of such a modulus is proven by picking to be minimal with respect to subset inclusion under the additional condition that it can only return initial segments with respect to the enumeration of .

Lemma (mod_minmod)

A minimal modulus is always self-modulating.

The reason for the indefinite article in this lemma is that it is well know, that the existence of a minimal modulus is not constructively provable [TvD88], and indeed our Coq-proof of its existence is classical.

Lemma (exists_minmod)

Any continuous operator has a minimal modulus of continuity.

The Incone library makes some efforts to decompose the proof of Theorem 4 into components, such that the main parts are constructive and can be used to extract an associate from additional information that has to be provided explicitly. Currently, this additional information is a choice function for the operator, and a self-modulating modulus of the operator together with a choice function for it and a function that extends a partially defined input to a total input that is from the domain of the operator if this is possible. It is reasonable to assume that the amount of information can be minimized quite a bit more, as the above can be interpreted as a partial recovery of one implication of the well-known fact that there exists a computable if and only if is computable.

The other implication, that if is computable then so is , can indeed be fully recovered with respect to our meta-level notions of computability from Section 2.1: Whenever can be defined in Coq without axioms, the term is also axiom-free and evidence that is computable. The assumption that is expressible in axiom free Coq is a priori stronger than computability, but if an axiom free is given such that , a Coq-definition of a function such that can be recovered: Let be the witnesses that is inhabited and let map a pair to the phantom query if , where is a modified list where the values corresponding to previous phantom queries are removed, and to if .

Even though inconsequential for the rest of the paper, we feel that it is worth mentioning that the Incone library defines a function that exchanges the arguments of the universal.

Theorem 5 (D_spec)

For all and it holds that .

Here, the types have been purposefully omitted, details can be found in the library. The important point is that the function is defined axiom-freely. Note that, while has the more complicated type and is interpreted using as , the operator can be realized by a Coq-function directly. Indeed, is definable in Gödels system T and the operator should be considered primitive recursive. The above theorem is interesting because it is related to the Cartesian closure of the category of represented spaces (see Section 3 for details on the category). However, it falls slightly short in strength as it only considers a special case in which it is not necessary to talk about tupling of elements of Baire spaces.

Corollary (FsM_mod_FU, FsM_mod_FsM and FsM_mod_FqM)

Theorem 3 remains true if and are exchanged and and are exchanged.

The above two cases where it was possible to eliminate the more complicated meta-level notion of computability in favor of a direct interpretation as a function are not coincidental. They can be understood as a consequences of the fact that the function space construction from computable analysis is such that it equips any space of functions with a very specific kind of representation [KP14, Ste17, NS17]. In particular the representation of a space of functions is always pre-complete [KW85], but in this context it seems that pre-completeness is not exactly the appropriate notion.

3 Represented spaces and continuous realizability

Recall that a realizability relation is a relation between data and abstract objects that assigns to each abstract object a nonempty set of data points that implement it. Computable analysis picks Baire space as the set of data and interprets a realizability relation as a specification of a function from data to abstract objects. Thus, computable analysis reasons about co-total multifunctions called multi-representations. Most of computable analysis is only concerned with the special case where these multifunctions are single-valued. A representation of a space is a partial surjective mapping . The from such that are called the -names, or just names, of . A pair of a set and a representation of that set is called a represented space.

The definition in the Incone library replaces the Baire space from the definition used in computable analysis with some space , where and should be countable inhabited types, i.e., with a Baire space in the sense in which the phrase was used throughout Section 2. Thus, a represented space is defined as a record containing a type (with a coercion from to that explains the special notation without index) together with types and and proofs that these are countable and inhabited and additionally a multivalued function and proofs that it is single-valued and co-total (which is equivalent to being surjective by Lemma 2). We use the notation (names in the library).

As an example let us equip the real numbers with a representation that is used for motivation and as benchmark throughout this section.

Example (examples/Q_reals.v)

Choose , i.e., . It is straight forward to prove that the type for rational numbers provided by Coq’s standard library is countable and inhabited. Furthermore, the multifunction (rep_RQ in the library) given by:

is a representation. Indeed, using the axiomatization of the real numbers provided by Coq’s standard library can be proven single-valued and surjective (rep_RQ_sing and rep_RQ_sur) and we refer to the represented space (RQ in the library) simply by .

X [r]^f & Y

B[r]_F [u]^δ_X & B’ [u]_δ_Y

Figure 4: is a realizer of

The topological and computability structure of Baire space can be pushed forward through a representation: A partial operator on Baire space is a realizer of a function between represented spaces if it assigns to each name of a name of (compare Figure 4). A function between represented spaces is continuous if it has a continuous realizer and computable if it has a computable realizer. In computable analysis it is well-known that the represented spaces form a Cartesian closed category both if the continuous functions are used as morphisms, as well as if the computable functions are used.

With little effort, the definition of being a realizer can be made sense of if both operators on Baire space and functions between represented spaces are multivalued and can even be generalized to multi-representations. For the full definitions we point the interested reader to the Rlzrs library, in the case where the representations are single-valued, the appropriate definitions can also be recovered from the following characterization:

Lemma (rlzr_spec)

let and be represented spaces, realizes if and only if tightens .

The above lemma can be used backwards to express the notion of tightening as a special case of realizability by using the identity function on the spaces as realizability relation (id_rlzr_tight). For concrete proofs other lemmas that simplify the realizer relation in the case where additional information about the realizing or the realized multifunction is available are often more useful (sing_rlzr_F2MF, F2MF_rlzr_F2MF, etc.).

While we are mostly interested in continuous, and therefore single-valued realizers, the case where is multivalued is of interest to us as it is needed for the concrete example of closed choice on the natural numbers that we discuss in Section 4.3. We call a multifunction between represented spaces continuously realizable if there exists a continuous realizer in this sense (hcr in the library with notation _ \has_continuous_realizer). A standard example where the use of a multifunction instead of a function can be used to recover continuity is that while the sign function is discontinuous, it can be approximated by the family of continuous -sign multifunctions whose value is allowed to be either or whenever is smaller than or a similar -equality test to account for the undecidability of equality on the real numbers. That continuity and continuous realizability is preserved under composition follows from content of the Rlzrs library together with the fact that continuity of operators on Baire-space is preserved under composition from Theorem 1.

Lemma (comp_cont and comp_hcr)

The composition of continuous functions is continuous and the composition of continuously realizable multifunctions is continuously realizable.

The notion of continuous realizability of a multifunction between Baire-spaces equipped with the identity representations does only coincide with continuity as introduced in Section 2.2 if restricted to single-valued functions. While a partial function is continuously realizable if and only if it is continuous, there are many multivalued functions that are continuously realizable but not continuous. This is because continuity implies single-valuedness and continuous realizability, to the contrary, is stable under increasing the set of eligible return values. The -sign and -equality test from above can be used to see that a continuously realizable multifunction need not always have a continuous choice function for represented spaces that are not equipped with the identity representation.

3.1 Finite products, sums, lists and basic examples

Now that we can talk about continuity and computability on the real numbers, a reasonable next step is to attempt to prove addition and multiplication computable. Both of these functions are of type and to make sense of continuity of functions of these types we need to specify how should be made a represented space. The Incone library automatically generates such a represented space from arbitrary represented spaces and by using the query type , the answer type and the representation defined by

This can be decoded as follows: A name of the pair should be a pair of a name for and a name for . Since the set of pairs does not have the type that we required a Baire space to have, we embed it into the Baire space . There are several possible choices for and the one we picked is not the minimal one. However, for our pick the projection functions on the Baire space can particularly naturally be expressed by the natural operations on the input and output spaces, namely by the first one by and the other one analogously.

Proposition (prod_rep_sing, prod_rep_sur and prod_uprp_cont)

For any represented spaces and the space is a represented space and it is the product of and in the category of represented spaces.

That the projections are computable is a sub-task of proving the universal property (fst_cont and snd_cont). Some other basic functions on product spaces are proven computable in the Incone library, most notably it provides the possibility to glue continuous functions on two factors to a continuous function between products (fprd_cont).

Example (examples/Q_reals.v)

Addition and multiplication of real numbers is computable (Rplus_cont and Rmult_cont). As described in more detail in Section 2.1 this should be taken to mean that the operations are continuous and the realizers can explicitly be specified as Coq-functions whose definitions contain no axioms. Indeed, the realizers are defined not through the more complicated assignment but more directly using the F2MF correspondence. Furthermore, their definition only uses very simple tools and the operations should therefore even be considered primitive recursive.

As another basic example of a represented space that is needed below let be any countable and inhabited type. Set and . Then the function makes a represented space that is discrete in the following sense:

Lemma (cs_id_dscrt)

For any countable, inhabited type the represented space described above is discrete in the sense that any function that has as its domain is continuous.

Moreover, any multivalued function with as input space is continuously realizable. In particular, the natural numbers can be assigned a discrete represented space that we denote by in the following.

The Incone library proves that the represented space constructed from the unit type as above is a terminal object in the category of represented spaces. This constructions lacks good use cases so far and we omit the details. For the same reasons we omit the construction of the sum space from represented spaces and which is for the most part analogous to the product and of the option type construction. The only application of these construction that the Incone library provides so far is a proof that is always isomorphic to . Instead of giving details about the above we describe how one could construct a represented space of finite lists of elements from a given represented space . Set , and consider the representation defined by

This representations is not defined in the Incone library and has not been proven correct. A similar representation is defined in the CoqRep library and while it is equivalent to the one given here, its definition is more complicated for historical reasons.

The reason why we still go into details about lists is that the CoqRep library proves custom-made and not fully general induction principles for and for lists. It also define a represented space of polynomials and uses the induction principles to prove polynomial evaluation computable as function of type . The expected performance of the resulting algorithm is very poor: While it does use the Horner scheme, which at least avoids that approximations to the same real number are computed a quadratic number of times, it still computes a linear number of approximations to the same number. In this case computing a single approximation with the highest accuracy requested during the computation would have been sufficient. For spaces different from the real numbers it might be necessary to ask many different questions. Clearly, this is something that is difficult to figure out for a general purpose induction principle that is not provided with additional information about the representation. In many cases it may be reasonable to handcraft the algorithms. For the real numbers there exist general purpose tools to better the performance of algorithms based on arithmetic operations [Mül01].

Thus, even-though it is possible to prove induction principles at this point, it is questionable whether one wants to make such available as general purpose tools for generating algorithms. It may be a good idea to first understand in which cases they are prone to introduce inefficiencies and how this can be avoided [NS17].

3.2 Infinite products, limits and point-wise operations

Let be a countable inhabited type and let be a represented space. Define a represented space whose underlying set are the functions of type by setting , and

where is short for the function .

Proposition (rep_Iprod_sing, rep_Iprod_sur and cprd_uprp_cont)

For countable inhabited the space is a represented space. The space is the countably infinite product in the category of represented spaces and continuous functions.

The use of the symbol instead of is to differentiate the space of sequences (notation _ \^w in the library) from the space of functions from the natural numbers to that is discussed in the next section. The proof of single-valuedness assumes functional extensionality and the proof of surjectivity needs a choice principle over . Since is by far the most common use-case and is assumed to be countable anyway, this will usually boil down to the axiom of countable choice. The proof of the universal property relies on stronger choice principles, classical reasoning and proof irrelevance. Since the category of represented spaces with computable functions fails to have countably infinite products, the universal property should not be provable without axioms. In how far our use of axioms can be optimized in this case is difficult to tell at the this point in time since the current proof uses a part of the library that has not yet been optimized in terms of axiom use. Since it is more a sanity result than something that may actually be of use, optimizations here are not our highest priority.

An example of a partial function whose natural domain is a subset of the space of sequences is the limit operator. Consider the multivalued function where if and only if there is a convergent sequence of names and some such that is a name of , each is a name for and the sequence converges to in , i.e., where the limit in is taken point-wise as explained in Section 2.2. While the limit operator on Baire space is single-valued, this need not be true for the limit operator on a general represented space, as can be seen at the example of Sierpiński space that is discussed in Section 4.3. In most spaces that are relevant for numerical analysis, the limit operator is single-valued but discontinuous. It is often the case that computability of the limit operator can be recovered by restricting it to an appropriate set of efficiently convergent sequences.

Example (examples/Q_reals.v)

The limit operator where is represented as in Example 3.1 is discontinuous (lim_not_cont and Section 4.2). Its restriction to those sequences that are efficiently Cauchy in the sense that is computable (lim_eff_hcr and Section 4.2).

A function between represented spaces is called sequentially continuous if it preserves limits, i.e., if implies that . In computable analysis it is well known that in general sequential continuity is a weaker notion than continuous realizability in the sense that for some represented spaces and there exist sequentially continuous functions that are not continuously realizable. This difference can be eliminated by assuming admissibility of the underlying representations [Sch02a]. We do not go into detail about the notion of admissibility here, but the relation between sequential continuity and continuous realizability is discussed in more detail in Section 4.2.

The Incone library proves some further lemmas about infinite products that might be useful in applications and should thus not go unmentioned. Two represented spaces and are isomorphic, in symbols (notation _ ~=~ _ in the library) if there exists a continuous bijection with continuous inverse. The spaces are computably isomorphic if there exists a computable bijection with computable inverse.

Lemma (cprd_prd)

For any represented spaces and and for any countable inhabited it holds that , the spaces are even computably isomorphic.

The realizers are defined using very limited means and interpreted using the F2MF assignment, thus they should be considered primitive recursive.

Any function can be extended to a function defined by (ptw in the library).

Lemma (ptw_cont)

The function is continuous whenever is a continuous function.

This lemma has a multivalued variant (ptw_hcr). Additionally it can be extended to talk about computability on a meta-level. If the realizer of can be expressed as a Coq-function through the F2MF interpretation, then so can . The details of this are carried out in the CoqRep library but were lost in the transition to the Incone library due to the design-decision not to talk about computability internally. The same should hold true if a realizer of can be expressed via a Coq function through the interpretation, although we never carried out the details.

Another common situation is that an operation is used to construct an operation via (ptw_op in the library) and a proof that this extension also preserves continuity can be directly obtained from the previous two lemmas.

Corollary (cptw_op_cont)

The operation is continuous whenever is continuous.

Of course, the functions ptw and ptw_op in the library take proofs that is countable, inhabited and of an appropriate choice principle as additional arguments that where suppressed in the above. For instance, point-wise addition and multiplication are continuous operations on .

3.3 Function spaces and their connection to infinite products

Let and be represented spaces and denote by the collection of all continuously realizable functions from to . Recall that in Section 2.3 we gave an explicit description of a continuous universal. The construction of the universal suggests the choice and and to consider the multivalued function defined by

From the formal proof that describes a universal (i.e. Theorem 4) it follows that this multivalued function is co-total. Since functions (as opposed to partial or multifunctions) are uniquely determined by each of their realizers, is also single-valued and thus a representation.

Proposition (fun_rep_sing and fun_rep_sur)

For any represented spaces and the space described above is a represented space.

The proof of single-valuedness assumes proof irrelevance and functional extensionality. In the library the represented space is denoted by cs_fun with the notation _ c-> _. It should be pointed out that the definition in the library differs slightly from what was presented here in that the underlying set is taken to be the functions to be the co-domain of the function representation. This way, the proof of surjectivity is axiom free and the number of axioms assumed automatically whenever function spaces are mentioned is kept low. That the set underlying the function space are exactly the continuous functions is proven retroactively (ass_cont).

The following can be derived from the continuity properties of the universal from Theorem 3 and the product construction from Section 3.1.

Theorem 6 (eval_cont)

Evaluation as operation is computable.

The function space construction overlaps in its scope with the infinite product construction: For a countable, inhabited index set and a represented space , the set underlying the space is the set of functions from to . The space generated from as was done in Section 3.1 is discrete by Proposition 3.1. This means that all functions starting from are continuous and that the sets underlying and are identical. Indeed these spaces are well known to be computably isomorphic and the Incone library provides a formal proof of this fact.

Theorem 7 (sig_iso_fun)

For any represented space and any countable inhabited type the space from the last section is computably isomorphic to the function space , where the canonical discrete space as described in of Section 3.1.

A realizer that translates a name of a sequence to a name of the corresponding function can directly be specified via

Again, this realizer should be considered primitive recursive. Furthermore, it should be noted that it relies on the implementation of the universal which may be attributed to the fact that the above theorem need not be true in an arbitrary Cartesian closed category. The construction of a continuous function from the space of functions proceeds by using a variation of the realizer of evaluation. On one hand this means that it is independent of the implementation of the universal. On the other it means that the universal has to be executed and thus it is an instance where a realizer uses the more complicated assignment. An axiom-free definition of a realizer using the F2MF assignment is likely to be impossible for reasons similar to those given for the continuous search operator in Example 2.1. This is also related to the fact that the construction of the reals from Dedekind cuts and Cauchy sequences are not fully equivalent in a constructive setting [LR08] and the discussion at the end of Section 2.3.

4 Metric spaces and closed choice on the naturals

A function is called a pseudo-metric on a set if it is positive, symmetric and fulfills and the triangle inequality

It is called a metric if implies . A pair is called a pseudo-metric space if is a pseudo-metric on and a metric space if is a metric. Every pseudo-metric space comes with a topology that is generated by the open balls with respect to the pseudo-metric and therefore with notions of continuity of functions between and limits of sequences in pseudo-metric spaces. The latter is of particular importance since any pseudo-metric space is first-countable and thus knowing the limits of sequences is sufficient for characterizing continuity. A more accessible definition of continuity can be given using the well-known --criterion that does not require any knowledge about topology. A function between pseudo-metric spaces and is called continuous in if

The function is called continuous if it is continuous in any point of . An element of a pseudo-metric or metric space is said to be the limit of a sequence in , in symbols , if

and a function between pseudo-metric spaces is said to be sequentially continuous if implies .

The notion of a metric captures the properties that one expects a notion of distance to have in a very general fashion. Metric spaces are a widely applicable tool for talking about continuity on many spaces of practical interest and a common sight in many branches of mathematics. As such, metric spaces have received considerable attention in their formal treatment. In particular there exists a definition of the concept of a metric space and continuity of functions between metric spaces in the standard library of Coq.

Several external libraries come with their own versions of metric spaces and continuity. Metric spaces and uniformly continuous functions are some of the core concepts of the C-CoRn library and developed in a way that avoids mentioning real numbers [O’C09]. Another example is the Coquelicot library [BLM15], a widely used conservative extension of the classical formalization of the real numbers provided by Coq’s standard library. Coquelicot uses a concept it refers to as uniform space, but which is actually more restrictive than the mathematical notion of a uniform space and closely resembles pseudo-metric spaces. The definitions of limits and continuity used in Coquelicot rely on filters instead of sequences. Most of these design choices are not arbitrary but for good reasons. The avoidance of real numbers in the treatment of metric spaces in C-CoRn can be attributed to the existence of different real number objects in a fully constructive setting. For Coquelicot the choice of pseudo-metric spaces over metric spaces is due to neither Coq, nor the axioms of the real numbers, proving functional extensionality. This makes it challenging to define a metric on any kind of space of functions. A pseudo-metric can often be defined in a straight forward manner. As the “uniform spaces” are Coquelicot’s most general structure and are first-countable, the definitions via filters are equivalent to those using sequences, however, it is not clear whether equivalence of derived concepts can always be proven in the setting that Coquelicot works in.

The Incone library comes with its own version of metric spaces that is kept close to the classical mathematical treatment and is thus most similar to the metric spaces that can be found in Coq’s standard library. It provides interfaces with both the standard library of Coq (MS2M_S, M_S2MS, Uncv_lim, cont_limin, etc.) and the Coquelicot library (US2MS, MS2US, cntp_cntp, etc.) so that it is possible to reuse results proven there (the lemmas limD, limM, R_cmplt and many more are proven this way). In contrast to the Coquelicot library, the metric library does not attempt to be conservative over the background theory of the real numbers. The main advantage of working constructively is the ability to extract computational content and this ability is lost as soon as the real numbers from the standard library enter the stage. The metric library further diverges from Coquelicot by using sequences instead of filters. This makes the comparison to represented spaces easier and is more appropriate for easy accessibility of computational content.

For an easy back and forth between convergence statements quantifying over real numbers and versions that quantify over integers instead, a line of lemmas is provided that contain the phrase “tpmn” (for “two to the power minus ”) in their name (tpmnP, lim_tpm, dns_tpmn, etc.). For instance tpmnP proves that the propositional on real numbers reflects the boolean on the math-comp natural numbers and lim_tpmn says that in the definition of the limit one may replace by and thereby quantification over by quantification over . This reduces the descriptive complexity quite a bit for the price of introducing an additional type. For the rational numbers a similar set of lemmas and additionally a constructive instantiation of the restriction of the up function is provided (upQ, limQ, archimedQ, etc.). The rational up function is useful for recovering computational content from proofs in the standard library, as it can often be supplemented for the up function that cannot be defined as a function on a constructive instantiation of the real numbers.

While the naming of notions for metric spaces is identical to what we used for represented spaces, there are some conceptual differences. First off, it is well known that a function between metric spaces is continuous if and only if it is sequentially continuous, where for represented spaces the backward implications can fail and admissibility of the involved representations is a sufficient condition to recover it. Secondly, in the case of metric spaces both continuity and its sequential variant can be recovered from point-wise such notions while for represented spaces this is only the case for sequential continuity. Indeed, the point-wise notions introduce subtle problems in the treatment of sub-spaces. Even in the most well-behaved cases as for a closed interval as a subspace of the real numbers there is a difference between a function on the reals being continuous in each point of the interval and the restriction of the function to the interval being continuous. The characteristic function of the interval has a continuous restriction but is not continuous in either end-point. This leads the statements of important theorems from the standard library (for instance the mean value theorem) to be slightly different from what a mathematician would expect. We choose to assume proof-irrelevance which allows for a treatment of sub-spaces as dependent types. It should be noted that this comes with its own problems and inconveniences.

4.1 Recovering continuity on Baire space from a metric structure

Let be a Baire space. Since is countable there exists a surjective function . For each such function define a mapping (baire_distance in the library) by

Proposition (dst_pos, dst_sym, dstxx, dst_trngl, dst_eq)

is a metric space.

For the proof a function named search was implemented, this function is a version of the find function from the standard library but acts on lists of natural numbers instead of arbitrary lists and thus it is possible to prove lemmas that are not meaningful in general. This function was used earlier: It is what is behind the implementation of the search operator from Example 2.1

. It may have further applications but it is probable that better implementations can be found in other places.

Theorem 8 (lim_lim)

Whenever is surjective, then .

Here is the limit operator of point-wise convergence on Baire spaces as it was introduced in Section 2.2 while is the metric limit operator introduced earlier in this section. The following can be easily deduced from the previous theorem and uses the notion of sequential continuity on Baire spaces that was introduced in Section 2.2.

Corollary

An function between Baire spaces is sequentially continuous if and only if it is sequentially continuous as function between the corresponding metric spaces.

A stronger version of this corollary for partial operators can be proven. We omit it here and instead formulate a theorem about the non-sequential version of continuity.

Theorem 9 (cont_cont)

Whenever and are Baire spaces and and are appropriate surjective functions then is continuous in the sense of Section 2.2 if and only if it is continuous as function from to .

Just like for the previous theorem, the proof is very straightforward and a special case was proven as an example before the metric space structure on Baire-space was available.

Example (examples/continuous_search.v)

The regular notion of continuity on the original Baire space is captured by the continuity introduced in Section 2.2 if all of the types are substituted with the natural numbers.

4.2 Comparing continuity in represented and in metric spaces

@!C@C+15ex@R1exmetric spaces & represented spaces

sequentially

continuous@¡1ex¿@=¿[ddddd]^non-constructive@¡1ex¿@=¿[r]^non-constructive & sequentially

continuous @¡1ex¿@=¿[l]^non-constructive

ε-δ continuous @¡1ex¿@=¿[r]^non-constructive @¡1ex¿@=¿[uuuuu]^constructive & continuously

realizable @=¿[uuuuu]_constructive @¡1ex¿@=¿[l]^constructive

Figure 5: Implications between different notions of continuity on metric spaces

Metric spaces are well investigated in computable analysis [Wei93]. In particular in the case where is a metric space and is a designated dense sequence in , it is well known that the multifunction defined by

defines a representation of (mrep_sing and mrep_sur) and we denote the corresponding represented space by . Note that this representation is very close to how real numbers were represented: A name of an element of a metric space produces an index of an approximation from an accuracy requirement. The above fixes the query and answer types to be . Since a query about an element of any metric space is a precision requirement it is reasonable to fix it to be a natural or a rational number. For the answer type it would be better to be more general in the formulation. While the Incone library does currently not do that, we plan to soon allow any countable and inhabited type. The reason for this is that for metric spaces like the continuous functions on the unit interval with the metric induced by the supremum norm, candidates for dense sub-sequences are the rational polynomials. Thus it is desirable to use the Mathematical Components type directly instead of taking the detour of enumerating the rational polynomials.

It is well known that a sequence in converges to a limit from with respect to the metric space structure if and only if they converge as elements of the represented space , or for short that . Furthermore, if is another metric space with dense sequence , then a function is continuous as a function between metric spaces if and only if it is continuously realizable as a function . This section describes our formal proofs about the comparisons of the two continuity notions and with their sequential versions (compare Figure 5). The proofs have been kept as constructive as possible. Since the definition of a metric space relies on the axiomatic reals, only one of the implications is fully constructive, the others are constructive over the background theory of real numbers and do not rely on the axioms of the real numbers in an essential way. A metric space is called separable if there exists a dense sequence and even though the sequence goes into the definition of the corresponding Cauchy representation, we decide to not mention it explicitly in the following. This is justified in a continuity setting as it is well known that different choices of dense sequences lead to isomorphic represented spaces. As always, the situation is more complicated if computability is considered and in this case one should assume that for the following two metric spaces with dense sequences are fixed.

Let us first describe the proof of the equivalence of the notions of sequential continuity. The main part of the proof is that the notions of limit in the metric space and the corresponding represented space coincide.

Theorem 10 (lim_mlim)

Whenever is a separable metric space and as above then

The proof that the convergence in the represented space implies the convergence in the metric space is straight forward. The idea behind the other direction can be sketched as follows: If converges to in the metric space then there exists a modulus of convergence, i.e. some such that

From an arbitrary sequence of names of the