To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure no-reply@cambridge.org
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
Why study formal methods? This chapter describes the predicament that formal methods were invented to solve and presents a vision of what programming should be.
Software frequently disappoints us. As users, we find that many programs are a poor match to our real needs and frustrate us with unrepaired defects. As programmers, our disappointment is especially keen. We expect to find the joy of creation in our work and the satisfaction of providing something useful. But all too often our expectations are dashed, our joy is spoiled, and our job becomes a dispiriting slog, churning out shapeless code and patching up bugs.
What's wrong? Is there something inherent in the nature of software that makes our troubles as inevitable as bad weather?
I argue that creating software is not intrinsically more difficult than any other kind of engineering. Many of our difficulties result from avoidable mistakes and poor programming practices.
A central problem is that people feel it is acceptable to create software without fully understanding what they are doing — they believe they can produce software and then understand it later by running tests and observing users' experience. It is this attitude, rather than any inherent difficulty in the task, that results in so many software problems.
This error can be made at any stage. Designers specify products when they don't fully understand customers' real needs. Programmers write code when they don't fully understand what it will do, and so on.
This chapter introduces the three basic constructs that appear everywhere in Z texts: declarations, expressions, and predicates. Declarations, introduce variables. Expressions describe the values that variables might have. Predicates express constraints that determine which values the variables actually do have.
Sets and types, declarations, and variables
The systems that we need to model might contain vast numbers of things. How can we possibly deal with them all? We gather similar objects into collections and treat each collection as a single object in its own right. These collections are called sets. Sets are central in Z.
Displaying sets
The obvious way to describe a set is to list or enumerate all of its members or elements. This is called a set display. In Z we follow the ordinary mathematical convention and write sets with braces, separating elements by commas. Here is a display of the set of lamps in a traffic light:
{red, yellow, green}
Elements in a set are not ordered, so the order you write elements in a set display is not significant. Here is another (equally good) display of the same set:
{yellow, red, green}
Sets contain no duplicate elements, and mentioning the same element more than once is redundant but innocuous.
At last we reach code. This chapter shows how to derive code from formulas taken from a Z specification and demonstrate that the code does what the formulas require. Program derivation is the systematic derivation of code from a formal specification. A proof of correctness demonstrates agreement between code and its specification. Such a proof is a by-product of every program derivation. It is also possible to attempt a formal verification to prove the correctness of an already completed block of code.
Almost all code in use today was produced by traditional informal methods, which are based on adapting code from previously solved problems and making modifications guided by programmers' intuitions about what happens when a computer executes a program. Thinking about what happens in the computer is called operational reasoning (in contrast to formal reasoning, which only considers the program text). Operational reasoning is fallible because it requires programmers to imagine how the values of variables evolve through time as execution takes one path or another through the code. For any but the smallest programs, there are far too many variables, values, and paths to consider, so programmers often resort to running their code to see if it behaves as they intend. This is a trial-and-error process, so it can take a great deal of effort to produce an acceptable product.
Formal program derivation proposes a radical alternative: A program is a formula. It can be derived from a specification, and its properties can be checked by calculation.
Z can describe data structures. In this chapter we'll use Z to define the fundamental objects of computer graphics and computational geometry: points, line segments, contours, and polygons.
Consider the distinction between a contour, which is any sequence of connected line segments, and a polygon, which is a closed contour that has an inside and an outside (Figure 19.1). Your eye can see the difference immediately, and the distinction is vital for many computations of great practical importance.
Figure 19.2 is a computer graphic that shows a view of a patient's anatomy and radiation beam geometry, used to plan this patient's radiation treatment for cancer. Cross-sections of anatomical structures must be polygons, not just contours, and the physics calculations that compute the radiation dose depend on this. If some contours are not closed, or cross over themselves, the dose calculations may be incorrect.
The difference between contours and polygons is vital, but there is no way to express this distinction in most programming languages: You have to represent both as mere sequences (arrays or lists) of points. Data types in programming languages correspond closely to the way data are represented in computer memory: If two objects are stored in the same format, they belong to the same data type. Z is far more expressive because we can distinguish data types based on their values and constraints between the values of their components. This enables us to define data types that capture such requirements as “a closed contour that doesn't cross over itself.”
This chapter is of central importance since it contains various fundamental properties of finite fields and a description of methods for constructing finite fields.
The field of integers modulo a prime number is, of course, the most familiar example of a finite field, but many of its properties extend to arbitrary finite fields. The characterization of finite fields (see Section 1) shows that every finite field is of prime-power order and that, conversely, for every prime power there exists a finite field whose number of elements is exactly that prime power. Furthermore, finite fields with the same number of elements are isomorphic and may therefore be identified. The next two sections provide information on roots of irreducible polynomials, leading to an interpretation of finite fields as splitting fields of irreducible polynomials, and on traces, norms, and bases relative to field extensions.
Section 4 treats roots of unity from the viewpoint of general field theory, which will be needed occasionally in Section 6 as well as in Chapter 5. Section 5 presents different ways of representing the elements of a finite field. In Section 6 we give two proofs of the famous theorem of Wedderburn according to which every finite division ring is a field.
Many discussions in this chapter will be followed up, continued, and partly generalized in later chapters.
CHARACTERIZATION OF FINITE FIELDS
In the previous chapter we have already encountered a basic class of finite fields—that is, of fields with finitely many elements.
Most modern algebra texts devote a few pages (but no more) to finite fields. So at first it may come as a surprise to see an entire book on the subject, and even more for it to appear in the Encyclopedia of Mathematics and Its Applications. But the reader of this book will find that the authors performed the very timely task of drawing together the different threads of development that have emanated from the subject. Foremost among these developments is the rapid growth of coding theory which already has been treated in R. J. McEliece's volume in this series. The present volume deals with coding theory in the wider context of polynomial theory over finite fields, and also establishes the connection with linear recurring series and shift registers.
On the pure side there is a good deal of number theory that is most naturally expressed in terms of finite fields. Much of this—for example, equations over finite fields and exponential sums—can serve as a paradigm for the more general case; and the authors have gone as far in their treatment as is reasonable, using elementary algebraic methods only. As a result the book can also serve as an introduction to these topics.
But finite fields also have properties that are not shared with other types of algebra; thus they (like finite Boolean algebras) are functionally complete. This means that every mapping of a finite field can be expressed as a polynomial.
This introductory chapter contains a survey of some basic algebraic concepts that will be employed throughout the book. Elementary algebra uses the operations of arithmetic such as addition and multiplication, but replaces particular numbers by symbols and thereby obtains formulas that, by substitution, provide solutions to specific numerical problems. In modern algebra the level of abstraction is raised further: instead of dealing with the familiar operations on real numbers, one treats general operations —processes of combining two or more elements to yield another element—in general sets. The aim is to study the common properties of all systems consisting of sets on which are defined a fixed number of operations interrelated in some definite way—for instance, sets with two binary operations behaving like + and · for the real numbers.
Only the most fundamental definitions and properties of algebraic systems—that is, of sets together with one or more operations on the set—will be introduced, and the theory will be discussed only to the extent needed for our special purposes in the study of finite fields later on. We state some standard results without proof. With regard to sets we adopt the naive standpoint. We use the following sets of numbers: the set ℕ of natural numbers, the set ℤ of integers, the set ℚ of rational numbers, the set ℝ of real numbers, and the set ℂ of complex numbers.
GROUPS
In the set of all integers the two operations addition and multiplication are well known.
Any nonconstant polynomial over a field can be expressed as a product of irreducible polynomials. In the case of finite fields, some reasonably efficient algorithms can be devised for the actual calculation of the irreducible factors of a given polynomial of positive degree.
The availability of feasible factorization algorithms for polynomials over finite fields is important for coding theory and for the study of linear recurrence relations in finite fields. Beyond the realm of finite fields, there are various computational problems in algebra and number theory that depend in one way or another on the factorization of polynomials over finite fields. We mention the factorization of polynomials over the ring of integers, the determination of the decomposition of rational primes in algebraic number fields, the calculation of the Galois group of an equation over the rationals, and the construction of field extensions.
We shall present several algorithms for the factorization of polynomials over finite fields. The decision on the choice of algorithm for a specific factorization problem usually depends on whether the underlying finite field is “small” or “large.” In Section 1 we describe those algorithms that are better adapted to “small” finite fields and in the next section those that work better for “large” finite fields. Some of these algorithms reduce the problem of factoring polynomials to that of finding the roots of certain other polynomials. Therefore, Section 3 is devoted to the discussion of the latter problem from the computational viewpoint.
The theory of finite fields is a branch of modern algebra that has come to the fore in the last 50 years because of its diverse applications in combinatorics, coding theory, and the mathematical study of switching circuits, among others. The origins of the subject reach back into the 17th and 18th century, with such eminent mathematicians as Pierre de Fermat (1601–1665), Leonhard Euler (1707–1783), Joseph-Louis Lagrange (1736–1813), and Adrien-Marie Legendre (1752–1833) contributing to the structure theory of special finite fields—namely, the so-called finite prime fields. The general theory of finite fields may be said to begin with the work of Carl Friedrich Gauss (1777–1855) and Evariste Galois (1811–1832), but it only became of interest for applied mathematicians in recent decades with the emergence of discrete mathematics as a serious discipline.
In this book, which is the first one devoted entirely to finite fields, we have aimed at presenting both the classical and the applications-oriented aspect of the subject. Thus, in addition to what has to be considered the essential core of the theory, the reader will find results and techniques that are of importance mainly because of their use in applications. Because of the vastness of the subject, limitations had to be imposed on the choice of material. In trying to make the book as self-contained as possible, we have refrained from discussing results or methods that belong properly to algebraic geometry or to the theory of algebraic function fields.