This book is a first step in a new direction: to modify existing theory from a constructive point of view and to stimulate the readers to make their own computational experiments. We are thoroughly convinced that their observations will help to build a new basis from which to venture into new theory on algebraic numbers. History shows that in the long run, number theory always followed the cyclic movement from theory to construction to experiment to conjecture to theory.

Consequently, this book is addressed to all lovers of number theory. On the one hand, it gives a comprehensive introduction to (constructive) algebraic number theory and is therefore especially suited as a textbook for a course on that subject. On the other hand, many parts go far beyond an introduction and make the user familiar with recent research in the field. For experimental number theoreticians we developed new methods and obtained new results (e.g., in the tables at the end of the book) of great importance for them. Both computer scientists interested in higher arithmetic and in the basic makeup of digital computers, and amateurs and teachers liking algebraic number theory will find the book of value.

Many parts of the book have been tested in courses independently by both authors. However, the outcome is not presented in the form of lectures, but, rather, in the form of developed methods and problems to be solved. Algorithms occur frequently throughout the presentation.

Introduction

Since the first printing of this book in 1989 algorithmic algebraic number theory has attracted rapidly increasing interest. This is documented, for example, by a regular meeting, ANTS (algebraic number theory symposium), every two years whose proceedings give a good survey about ongoing research. Also there are several computer algebra packages concentrating on number theoretical computations. At present the most prominent ones, which are available for free, are KANT, PARI and SIMATH. KANT comes with a data base for algebraic number fields, already containing more than a million fields of small degree. KANT is developed by the research group of the author at Berlin and will be presented in some detail in this chapter. We note that almost all of KANT and PARI is also contained in the MAGMA system.

In the sequel we shortly discuss the improvements which were obtained for the computation of the important invariants of algebraic number fields. On the other hand, in computational algebraic number theory the interest has gradually turned from absolute extensions to relative extensions of number fields and we will sketch the important developments in that area. If subfields exist, the information about the invariants of those subfields can be lifted and used in the field under consideration. This relative point of view permits computations in fields of much larger degrees and has important applications, for example to class field computations.

A large proof should be organized as a collection of theories. An LCF theory has a signature: its type constructors, constants, infixes, predicates. It may have parent theories, inheriting all their symbols and axioms. This rich environment may be extended by new axioms. Theorems may be proved and recorded in the theory.

Existing theories may become the parents of a new theory if their signatures are disjoint. Names of types, constants, infixes, and predicates cannot be hidden or renamed to avoid clashes. Each theory has separate name spaces for its axioms and theorems. An axiom is designated by the pair (theory name, axiom name), a theorem by (theory name, theorem name).

Theories do not have a tree structure: sharing always occurs. In Figure 6.1, the theory T has parents T1 and T2. They both have T4 as a parent. Both the theories T3 and T4 have T5 as a parent; both T4 and T5 have PPλ as a parent. Symbols declared in a common ancestor are shared. If the symbol + is declared in T4 then it is visible in both T1 and T2 and does not cause a clash between the two theories. But if it were declared in both T2 and T3 then T1 and T2 would clash during the construction of T.

Every theory is ultimately descended from PPλ. A theory is the child of its parents.

When representing a logic on a computer, how should we treat inference rules? A rule, given appropriate premises, delivers a conclusion, so LCF represents an inference rule by a function from theorems to theorems. Theorems of PPλ are represented by the ML data type thm. Axioms and rules of PPλ are predefined identifiers. Each axiom is a theorem; applying rules to axioms computes new theorems.

This chapter lists the axioms, inference rules, and predefined theorems of PPλ. The examples include formal proofs from previous chapters, performed in LCF.

The representation of inference rules

A rule may hold only if its premises have a certain form; otherwise the corresponding ML function fails, raising exception rule of type string × thm list. The exception includes an error message and the offending premises.

In certain inference rules, the premises do not contain enough information to completely determine the conclusion. The corresponding function takes additional arguments, giving parts of the conclusion or even a formula stating the conclusion itself.

To implement quantifier rules, the abstract syntax functions of Chapter 5 perform substitution and enforce the provisos on eigenvariables. If a proviso is violated, the rule fails.

In the sequent Γ ├ A, the assumptions Γ are usually regarded as a set. ML represents a set of PPλ formulae as a list without repetitions. The LCF user need not be concerned with the order of the assumptions in the assumption list.

In conclusion, we see that proving whether particular exponential diophantine equations have finitely or infinitely many solutions, is absolutely intractable (Theorem D). Such questions escape the power of mathematical reasoning. This is a region in which mathematical truth has no discernible structure or pattern and appears to be completely random. These questions are completely beyond the power of human reasoning. Mathematics cannot deal with them.

Nonlinear dynamics [FORD (1983) and JENSEN (1987)] and quantum mechanics have shown that there is randomness in nature. I believe that we have demonstrated in this book that randomness is already present in pure mathematics, in fact, even in rather elementary branches of number theory. This doesn't mean that the universe and mathematics are lawless, it means that sometimes laws of a different kind apply: statistical laws.

More generally, this tends to support what TYMOCZKO (1986) has called a “quasi-empirical” approach to the foundations of mathematics. To quote from CHAITIN (1982b), where I have argued this case at length, “Perhaps number theory should be pursued more openly in the spirit of experimental science!” To prove more, one must sometimes assume more.

I would like to end with a few speculations on the deep problem of the origin of biological complexity, the question of why living organisms are so complicated, and in what sense we can understand them. I.e., how do biological “laws” compare with the laws of physics?

We have seen that Ω is about as random, patternless, unpredictable and incomprehensible as possible; the pattern of its bit sequence defies understanding.

Tactics accomplish backwards proof. You begin with a goal — a statement of the desired theorem — and reduce it to simpler subgoals, forming a proof tree. A tactic reduces a goal to a list of subgoals such that if every subgoal holds then the goal holds also. If the list of subgoals is empty then the tactic has proved the goal. The standard tactics allow reasoning about logical connectives, substitution, induction, and rewriting. A tactic is a higher order function. It not only reduces a goal to subgoals, but returns a proof function to justify its action.

It is worthwhile to develop tactics specifically for the theory at hand. Operations called tacticals, which treat tactics as data, construct sophisticated tactics from simple ones. It is seldom necessary to code a tactic in low-level ML: the standard tactics and tacticals form a language of proofs. Constructing a tactic from simpler ones promotes readability and avoids many kinds of error. The tactic steps of a proof can be composed to form a single tactic, giving a surprisingly readable synopsis of the proof. Tacticals are a prime example of higher order functions in LCF.

The subgoal package provides commands for backwards proof. It manages the subgoal tree, presenting the user with unsolved goals. When the last subgoal has been solved, it produces the final theorem.

Growing numbers of computer scientists recognise the importance of formal methods of system design [48]. LCF and ML are often mentioned, seldom understood. There is a wide literature, as the bibliography attests. Gordon, Milner, and Wadsworth [41] describe Edinburgh LCF, with a few remarkable examples. The present book aims to make Cambridge LCF accessible to a wide audience.

Serious students of LCF are of several kinds. Some would like an introduction to formal reasoning about computable functions. Others are interested in the principles of the machine implementation. And a few want to perform large proofs in Cambridge LCF, and require a comprehensive description.

Cambridge LCF is not the answer to all problems in formal methods. Like Edinburgh LCF its concern is denotational semantics, domain theory, and functional programming. Related systems support other formal methods, but none supports Z, VDM, CSP, CCS, or Hoare-style verification. Some ‘formal’ methods lack a precise meaning, making machine implementation impossible. However the goal of formal methods — introducing rigor into computer system design — can be achieved in LCF.

How to read this book

People find LCF difficult to approach because it requires familiarity with a mass of background material. The book consists of two parts. Part I outlines the mathematical preliminaries: elementary logic and domain theory. Many advocates of formal methods have a lamentably weak grasp of this fundamental material. Part II describes Cambridge LCF in enough detail to serve as a reference manual, though operating instructions should be supplied with the software.

More than half a century has passed since the famous papers GÖDEL (1931) and TURING (1937) that shed so much light on the foundations of mathematics, and that simultaneously promulgated mathematical formalisms for specifying algorithms, in one case via primitive recursive function definitions, and in the other case via Turing machines. The development of computer hardware and software technology during this period has been phenomenal, and as a result we now know much better how to do the high-level functional programming of Godel, and how to do the low-level machine language programming found in Turing's paper. And we can actually run our programs on machines and debug them, which Gödel and Turing could not do.

I believe that the best way to actually program a universal Turing machine is John McCarthy's universal function EVAL. In 1960 McCarthy proposed LISP as a new mathematical foundation for the theory of computation [McCARTHY (I960)]. But by a quirk of fate LISP has largely been ignored by theoreticians and has instead become the standard programming language for work on artificial intelligence. I believe that pure LISP is in precisely the same role in computational mathematics that set theory is in theoretical mathematics, in that it provides a beautifully elegant and extremely powerful formalism which enables concepts such as that of numbers and functions to be defined from a handful of more primitive notions.

Simultaneously there have been profound theoretical advances. Gödel and Turing's fundamental undecidable proposition, the question of whether an algorithm ever halts, is equivalent to the question of whether it ever produces any output.

Cambridge LCF is an interactive theorem prover for reasoning about computable functions. The terms of its logic, PPλ, constitute a tiny functional programming language. Cambridge LCF can be used for experimenting with first order proof; studying abstract constructions in domain theory; comparing the denotational semantics of programming languages; and verifying functional programs. It can reason about both strict and lazy evaluation.

There are many theorem provers in the LCF family. Each is descended from Edinburgh LCF and retains its fundamental ideas:

• The user interacts with the prover through a programmable meta language, ML.

• Logical formulae, theorems, rules, and proof strategies are ML data.

• The prover guarantees soundness: it checks each inference and records each assumption.

Edinburgh LCF was developed in order to experiment with Scott's Logic of Computable Functions [41]. It performed many proofs involving denotational semantics and functional programming.

Cambridge LCF extended the logic of Edinburgh LCF with ∨, ∃, ⇔, and predicates, improved the efficiency, and added several inference mechanisms. It has been used in proofs about functional programming and several other theorem provers have been built from it.

LCF_LSM was developed for reasoning about digital circuits in a formalism related to CCS [32]. It verified some realistic devices [39], but is now obsolete.

HOL supports Church's Higher Order Logic [37], a general mathematical formalism. It is mainly used to prove digital circuits correct.

Another system supports a higher order Calculus of Constructions that can represent many other calculi.

Reasoning about functional programs requires the ability to define interesting data structures in PPλ. In Scott's original calculus the only type constructor is function space: if σ and τ are types then so is the function type σ → τ. A fundamental data structure is the Cartesian product, the type σ × τ. Other data type constructors are the strict product, various sums, and lifting. Starting from atomic types, many data structures can be expressed. Each type constructor has constructor functions for creating elements of the type. For taking elements apart it may have destructor functions or else an eliminator functional.

Furthermore recursive type constructors are definable. Domain theory allows the solution of recursive domain equations involving sum, product, function space, and several other type constructors. Cambridge LCF provides a mechanism for defining PPλ types in a style similar to Standard ML datatype definitions: LCF can generate axioms to define a PPλ type recursively as the sum of products of types, with one constructor function for each summand of the type.

The constructor functions determine whether a type is strict or lazy. If a constructor function is not strict in all arguments then it can construct partial objects: objects that have undefined parts. The resulting type, if recursive, also contains infinite objects. An example is the type of lazy lists, which contains partially defined and infinite lists. If every constructor is strict in every argument, then the resulting strict type contains only finite objects.