While computer algebra systems have dealt with polynomials and rational ... series of footnotes, which can be found in a separate appendix, detailing .... or adopts a distributed representation, operations such as the initial synthetic division, ..... \integral domain" an algorithmic avour by using the following corollary to the ...
Scratchpad's View of Algebra I: Basic Commutative Algebra J.H. Davenport School of Mathematical Sciences University of Bath BA2 7AY Claverton Down Bath England
and
B.M. Trager Department of Mathematical Sciences IBM Thomas J. Watson Research Center P.O. Box 218 Yorktown Heights 10598 NY, U.S.A.
Abstract. While computer algebra systems have dealt with polynomials and rational
functions with integer coecients for many years, dealing with more general constructs from commutative algebra is a more recent problem. In this paper we explain how one system solves this problem, what types and operators it is necessary to introduce and, in short, how one can construct a computational theory of commutative algebra. Of necessity, such a theory is rather di erent from the conventional, non-constructive, theory. It is also somewhat di erent from the theories of Seidenberg [1974] and his school, who are not particularly concerned with practical questions of eciency.
Introduction
This paper describes the constructive theory of commutative algebra which underlies that part of Scratchpad which deals with commutative algebra. We begin by explaining the background that led the Scratchpad group to construct such a general theory. We contrast the general theory in Scratchpad with Reduce{3's theory of domains, which is in many ways more limited, but is the closest approach to an implemented general theory to be found outside Scratchpad. This leads us to describe the general Scratchpad view of data types and categories, and the possibilities it o ers. We then digress a little to ask what criteria should be adopted in choosing what types to de ne. Having discussed the philosophical issues, we then discuss commutative algebra proper, breaking this up into the sections \up to Ring", \Integral Domain", \Gcd Domain" and \Euclidean Domain". It should be noted that, while most of the decisions taken in Scratchpad have a sound mathematical foundation, some, such as the decision not to de ne various devleopments of semi-groups, such as quasi-groups, are not so soundly based, and re ect the authors' prejudices as much as anything else. We will endeavour to distinguish these decisions from those with a more mathematical foundation. This brings us to the heart of the matter: the de nitions used in Scratchpad. Since we are more interested in the theory than in the practical details of Scratchpad, we will often simplify the details of implementation, leaving the truth to a numbered series of footnotes which can be found in an Appendix to this paper. The material relegated to this appendix will typically be points unrelated to the theory of this paper, but which appear in the code of Scratchpad, or cases where the authors of Scratchpad have chosen, for reasons of eciency, to implement several operators where one would logically be sucient. These notes should typically be read by people who have the source of Scratchpad to hand, and wish to compare this paper with the actual code. In the course of writing this paper, the authors have made some changes to the details of Scratchpad: people with access to earlier versions of Scratchpad might wish to look at the roman-numberedi series of footnotes, which can be found in a separate appendix, detailing changes from previous versions. Do we need a new theory? Why can't Scratchpad just use the conventional de nitions of, say, \ring", \ eld", \integral domain" or \unique factorisation domain" found in any text-book on 1
abstract algebra? The reason is that these de nitions are fundamentally non-constructive. They say that things exist, but do not give any algorithms for constructing them. Furthermore, such algorithms may well not exist. For example, it is well-known in abstract algebra that, in the presence of noetherianity, the existence of greatest common divisors is equivalent to the existence of unique factorisation. However, as was rst shown by Frohlich & Shepherdson [1956], there exist domains with algorithms for computing greatest common divisors, but for which there cannot exist algorithms for computing unique factorisation. Their example made use of a recursively enumerable, non-recursive sequence to generate a eld K which might be Q or Q[i], but such that one couldn't tell which. K [x] is certainly noetherian, since K is a eld. Then it is certainly possible to compute greatest common divisors in K [x], since Euclid's algorithm is purely rational in its inputs. But, computing the factorisation of x2 + 1 is equivalent to deciding what K is, and so is impossible. We will make use of several such constructions as we show why we need to make certain distinctions which the non-constructive theory doesn't make.
The Problem The handling of polynomials with integer coecients is one of the oldest problems of computer algebra [Collins, 1966]. The diculties encountered in the implementation of polynomials with integer coecients were largely ones of eciency, especially for the computation of greatest common divisors and the factorisation of polynomials. While improvements continue to be made in these areas, it is fair to say that these problems are largely solved in principle, though the algorithms are not as easy to implement as one would like: We found that, although the Hensel construction is basically neat and simple in theory, the fully optimised version we nally used was as nasty a piece of code to write and debug as any we have come across [Moore & Norman, 1981]. Once Z[x1; : : :; xn ] has been implemented, it is possible to implement Q(x1 ; : : :; xn ) as the quotient eld of Z[x1 ; : : :; xn ]. To ensure canonical forms, we need merely verify that there is no common factor between the numerator and the denominator (hence one major use of the computation of gcds) and that the leading coecient of the denominator is positive. Q[x1 ; : : :; xn ] is generally treated as a special case of Q(x1 ; : : :; xn ), in other words, a global denominator is used rather than local denominators. This is generally justi ed by arguing that the cost of repeated gcd calculations between the numerators and denominators of the rational numbers greatly outweighs the cost of carrying the lcm of the individual denominators as a global denominator. Hence, in principle, all questions of algebra with rational coecients are solved. In practice, things are not so simple. Let us consider Hermite's algorithm [Hermite, 1872] for the integration of a rational function f (x) in Q(x) (or, more precisely, for nding the rational part of the integral of such a function). The algorithm is normally expressed as follows: 2
Perform synthetic division of the numerator of f by the denominator of f , so as to write f = p + rq with p; q; r 2 Q[x], degree(q ) < degree(r) and q; r relatively prime. Integrate p term-by-term, to give an \answer-so-far" I . Perform a square-free decomposition of r: n Y r = rii:
[1] [2] [3]
i=1
Perform a partial fraction decomposition of q=r: n q q =X i: r ri
[4]
i=1 i
[5] Let L := q1 =r1 , the derivative of the non-rational part of the integral. [6] For i := 2; 3; : : :; n do [6.1] Solve the equation Ari0 + Bri = 1 for A; B 2 Q[x]. [6.2] For j = i; i ? 1; : : :; 2 do [6.2.1] Let s := ?qi A=(j ? 1) (mod ri). [6.2.2] Let I := I + s=rij ?1 . [6.2.3] Let qi := ?qi B (mod ri0 ) ? s0 . [6.3] Let L := L + qi =ri. Step [6.2] is justi ed by the equation Z qi = Z ?(j ? 1)ri0 s ? ri (qi B (mod ri0 )) = s + Z s0 ? (qiB (mod ri0 )) : j j j ?1 j ?1
ri
ri
ri
ri
This algorithm is fundamentally based on the algebra of Q[x]: the division of step [1], the partial fraction decomposition of step [4], the solution of Bezout's equality in step [6.2] and the remainder calculations in steps [6.2.1] and [6.2.3] all take place in Q[x] rather that in Z[x]. This is not to say that the algorithm cannot be implemented over Z[x]: many authors have done that in many algebra systems. But the implementation becomes much more complicated: every variable must be replaced by a pair consisting of a polynomial in Z[x] and a denominator in Z, and a twelve-line algorithm becomes several pages of code. Worse, consider what happens when we have a parametric integral, so that Q[x] is replaced by Q(y)[x]. We have to embed Q(y)[x] in Q(y; x), the quotient eld of Z[y; x]. If our system insists on treating y as the main variable, rather than x, in some recursive polynomial representation, or adopts a distributed representation, operations such as the initial synthetic division, which are mathematically trivial in K [x] for any eld K , become software nightmares, since the data structure is not representing the underlying mathematics. More generally, there are many rings between Z[x1 ; : : :; xn ] and Q(x1 ; : : :; xn ), and many algorithms which are naturally set in one of these intermediate rings rather than in either of the extremities. Furthermore, there are quotients of these intermediate elds, such as algebraic number elds. Davenport [1981] describes the diculty of trying to manipulate algebraic extensions in a system (Reduce-2) which was essentially purely polynomial. Before we proceed much further in this direction, we should sound a note of warning. It is certainly true that the ability to talk about objects like Q(x1 ; : : :; xn )[y ] is useful when it comes to expressing algorithms. However, these algorithms may not be the most ecient possible. For example, it is possible to use Euclid's algorithm to compute greatest common divisors in Q(x1 )(x2) : : : (xn )[y ], regarding each extension (xi) as the eld of fractions of the polynomial extension [xi ], and using Euclid's algorithm to calculate greatest common divisors every time fractions have to be added 3
or multiplied. But it is far more ecient to clear denominators, and to use a modular or p-adic algorithm in Z[x1 ; : : :; xn ][y ].
System Requirements
The two major computer algebra systems in which this has been treated are Scratchpad [Jenks & Trager, 1985] and Reduce{3 with its theory of domains [Bradford et al., 1986]. These systems di er substantially in their approach to the problem: Scratchpad is a system designed ab initio to handle this view as abstractly as possible, whereas the theory of domains in Reduce{3 (more precisely Reduce{3.3) was intended as an extension to an existing successful system to enable it to handle a wider range of ground objects: earlier versions of Reduce were limited to polynomials (and rational functions) with integer or (machine-precision) oating-point coecients, and the theory of domains extends this to allow user-de ned types, as well as system-de ned types such as \arbitrary-precision
oating-point numbers", rational numbers, Gaussian integers (or Gaussian rationals, or Gaussian
oating-point numbers or : : :) and algebraic numbers. In the Reduce model, domains are either rings or elds, the sole di erence being that division is always possible in elds, but not in rings. The whole of the \polynomial arithmetic" part (and packages which are based on it, such as the matrix manipulation package) of Reduce works with respect to any domain (except that the g.c.d. algorithm, which is sub-resultant based [Hearn, 1979] has severe problems with inexact domains, such as oating-point numbers), but packages such as factorisation and integration work with only a subset of the domains, with special-case code for each domain | for example, factorisation works directly with integers as the domain, converts rationals to integers rst, and reduces Gaussian problems to non-Gaussian ones by taking the norm [Trager, 1976]. Scratchpad, on the other hand, allows any set of operators (and corresponding axiomsii;iii ) to form a de nite class of types (the Scratchpad phrase is category), of which there are over 100 named ones currently de ned in Scratchpad. Categories can in fact be parametrised by other types | the rst instance of this in this paper is the de nition of LeftModule, where the concept is explained. These are viewed as forming a multiple-inheritance hierarchy: a new category is de ned as being the union of the operators and axioms of certain previously-de ned categories, together with some new operators and axioms (of course, any of these components may be empty). We say that this category is the direct descendant of these previously-de ned categories, which are the direct ancestors of the category just de ned. The concepts descendant and ancestor are the re exive-transitive closure of direct descendant and direct ancestor respectively. New types (or domains: the two words are used almost interchangably in Scratchpad, but we will use \type" to avoid confusion with Reduce's theory of domains) are constructed by means of functors: functions which take some (possibly none) parameters, which may themselves be types, and return a new type. The parameters of a functor are themselves typed, so that an object is de ned to come from some type, and a type from some category. For example, the type Z is created by applying the functor Integer (a function with no parameters), the type Q is created by applying the functor Fractioniv to the type Z (belonging to the category IntegralDomain), and the type* Z[x] is created by applying the functor UnivariatePolynomial to two arguments: the object x (belonging to the type Symbol) and the type Z (belonging to the category Ring). A functor de nes the implementation of the various operators that are de ned on the resulting type. In general, the resulting type is de ned to belong to a nonce category, generally a named one with some additional operations. For example, Integer could be de ned to return an object that belonged to the category EuclideanDomain with an additional operator positivep that said * More precisely, one of the many types in Scratchpad which is abstractly isomorphic to the abstract mathematical type Z[x]. Other types can be created by using DenseUnivariatePolynomial, or by creating multivariate polynomials in only one variable, or in many other ways. 4
whether or not the integer was positive (the actual de nition is far more complicated). Hence the body of Integer would have to de ne operations such as +, / and gcd as well as positivep. With such a rich language available, how do we decide which categories to de ne, and what functors should be available, and what categories should their arguments belong to? It is this question that this paper addresses, for that part of Scratchpad which implements commutative algebra. First, we must ask ourselves what criteria we should use to choose among the various possibilities.
A Little Philosophy
Why does \abstract algebra" insist so much on the de nition and use of concepts (algebras in the sense of the subject Universal Algebra: categories would be another word, and is the word Scratchpad has borrowed) such as \ring", \integral domain" and \ eld"? One answer, it seems to us, is economy of e ort: for example, rather than proving many di erent theorems, such as \polynomials in one variable over the integers have a unique factorisation property", \polynomials in two variables over the integers have a unique factorisation property", \polynomials in two variables over the integers modulo 7 have a unique factorisation property" and so on, we need only prove one theorem | \polynomials in one variable over a unique factorisation domain form a unique factorisation domain". We will ask later whether this particular piece of generality can in fact be achieved constructively. There are other reasons as well, which explain why a particular category is \successful". The rst reason is one of interest: there must be some signi cant interest in various objects which belong to this category. Furthermore, the interest must have something to do with the property: for example, Z is interesting, as is Z=nZ for odd n, but one is unlikely to nd much interest in a theory of \rings which, when viewed as abelian groups, have an involution with precisely one xed point". Another reason is what we will call functoriality: there should be operations (functors) which construct new objects of the category from old objects of this category, or maybe from old objects of another category. For example, the functor [x] (construct polynomials in one indeterminate over) takes integral domains into integral domains, and takes elds into Euclidean domains. How does this translate into the computational setting? We certainly want economy of e ort, by which we mean now that one implementation of an algorithm will work over several di erent types: for example one sorting algorithm working over all types belonging to the category OrderedSet. This is provided to some extent by the Reduce model, since the whole of polynomial arithmetic is provided over all domains by one piece of code (with the occasional dependence on whether the domain in question at the moment is a eld or not). This would be easy to provide in Scratchpad, if all that was wanted were polynomial and rational function calculations over constant domains. But, as was pointed out in the introduction, we would like to see polynomials and rational functions de ned over other domains, in particular over domains which are themselves polynomial or rational function domains. We also want interest: it should be possible to implement dicult algorithms over many di erent types. For example, we would like to implement polynomial factorisation as few times as possible, and then have it operate over as wide a range of di erent types as possible. Hence we need to de ne a category such that: a) It is possible to implement polynomial factorisation over this category; b) As many types as possible belong to this category. Such a goal may not be easy, but it is surely worth aiming for. 5
The types up to Ring
Scratchpad implements a fundamental category SetCategory1;v , of which almost all other categories are descendants. Two operations are de ned on types $ (the standard Scratchpad notation for the type one is de ning at the moment) belonging to this category = : $ $ 7! Boolean coerce : $ 7! OutputForm
where Boolean is a built-in type of truth values, and OutputFormvi is a built-in type which is used in printing and other general-purpose expression-manipulation tasks. The assumption that almost all types contain an equality operator is extremely convenient for most purposes, though it could be argued that it is too restrictive. Note that we do not require that mathematical equality be represented by Lisp equality, though it will generally be more ecient if this is the case. Domains in which Lisp equality is the same as mathematical equality are said to be canonically represented, and are declared to have the attribute canonicalvii. This attribute is useful when it comes to considering the use of hashing, to quote but one example, since the hashing functions built into a Lisp system will not give the correct results unless the domain is canonically represented. Another way of viewing this attribute is to say that it asserts that objects that print (in terms of the coercion to OutputForm) di erently really are di erent. We discuss the propagation of this attribute further in the section \What does it mean to be an Integral Domain?". From this we can develop a straight-forward sequence which covers elementary commutative algebra: SetCategory
#
&
#
&
#
&
#
&
AbelianSemiGroup AbelianMonoid CancellationAbelianMonoid AbelianGroup
&
OrderedSet
#
OrderedAbelianSemiGroup
#
OrderedAbelianMonoid
#
OrderedCancellationAbelianMonoid
#
OrderedAbelianGroup
where the arrows indicate a \direct descendant" relationship. AbelianSemiGroup is de ned to have one new operator: + : $ $ 7! $ satisfying the associative and commutative axioms:
a + (b + c) = (a + b) + c a + b = b + a: AbelianMonoid
introduces a new nullary operator2; 3 0 :7! $ 6
satisfying the obvious axiom iom:
0 + a = a:
CancellationAbelianMonoidviii is the category of abelian monoids with the cancellation ax-
a + b = a + c ) b = c:
Constructively, this is represented by a partial subtraction operator, whose signature is de ned as:
? : $ $ 7! Union($; "failed"): The right-hand side of 7! is Scratchpad's notation for what other languages sometimes call a \disjoint union". "failed" is a distinguished symbol, which can be tested for by seeing which branch of the union is returned. While such an operation could be de ned for any AbelianMonoid, or even any AbelianSemiGroup (as was indeed done in some earlier versions of Scratchpad), it is the cancellation axiom that ensures that ? has a unique value. This operator is subsumed in the ? operation de ned on AbelianGroups, so is not of immediate interest in the development of commutative algebra. When we come to de ne polynomial data types, we will rely on the existence of this operation in the exponent domain. AbelianGroup adds one further unary operator4 :
? : $ 7! $: This operator satis es the axiom The rst & introduces an operatorix
a + (?a) = 0:
< : $ $ 7! Boolean satisfying the usual axioms:
a < b^b < c ) a < c :(a < b) ^ :(b < a) ) a = b a < b ) :(b < a):
Subsequent & in this diagram introduce no new operators, but one more axiom is introduced, when OrderedAbelianSemiGroup is de ned:
a < b ) a + c < b + c: This is typical of what happens when two categories are merged to form a new named category: we keep the same operators, but are interested in the interaction between them, which requires the introduction of new axioms to de ne this interaction. Subsequent & in the chain represent the straight-forward merging of ancestors. In Scratchpad, we have also de ned types SemiGroup and Monoid, with the obvious multiplicative operations5 . We can now start de ning ring-like objects properly. There is substantial disagreement (at the notational level) amongst mathematicians as to whether a ring need or need not contain a unity: we have chosen to require that a Ring needs to. Hence our rst de nition is of a Rng, which is de ned to be both an AbelianGroup and a SemiGroup, with two additional axioms:
a (b + c) = a b + a c (b + c) a = b a + c a: 7
If this domain has the property that the product of two non-zero elements is always non-zero, then we assert the additional attribute noZeroDivisorsx. It would be pleasant to proceed now to the de nition of a Ring, but we are caught here by a con ict between the Scratchpad requirement that a category be de ned in terms of previouslyde ned categories, and the mathematical statement that a ring is a (left-)module over itself. We break the dilemma by de ning a NaiveRing6 ;xi to be both a Rng and a Monoid, with operations7
7! NonNegativeInteger recip : $ 7! Union($; "failed"):
characteristic :
The right-hand side of the last 7! again includes a \disjoint union" and the distinguished symbol
"failed".
For an arbitrary NaiveRing, characteristic8 is de ned as being the least positive integer n, if one exists, such that 1 added to itself n times is 0, otherwise 0. recip satis es the axiom
x) 6= "failed" ) x recip(x) = recip(x) x = 1:
recip(
Clearly recip cannot be de ned any earlier than this, since we need to have a de nition of 1. It could be argued that the de nition should be later, but it seems in practice to be convenient to de ne it here. If R is any NaiveRing, we can de ne the category LeftModule(R) of all left-R-modules*;xii to be sets $ which are members of the category AbelianGroup equipped with an extra operation
: R $ 7! $ and the corresponding axioms:
(a b) x = a (b x) (a + b) x = a x + b x a (x + y) = a x + a y:
The category Ring is then both a NaiveRing and a LeftModule over itself. A Module over a R is then9 both a LeftModule and a RightModule. A CommutativeRing is both a Ring and a BiModule over itself, with the additional axiom that multiplication is commutative.
Ring
What does it mean to be an Integral Domain?
The usual de nition of an Integral Domain is rather non-constructive:
6 9a; b 6= 0 : ab = 0: Another way of saying this is to regard it as a property of multiplication: a; b 6= 0 ) ab 6= 0. A third way is to see that it is much the same as \cancellation" in the type CancellationAbelianMonoid, since if pq = pr, then p(q ? r) = 0, and if p 6= 0, then q = r. Knowing this property may well help in implementing an operation: for example the de nition of multiplication of a sparse polynomial * We could equally well have chosen to work in terms of right-R-modules. 8
by an element of the underlying ring is de ned as if R has noZeroDivisors then r * x == r = 0 => 0 r = 1 => x [[u.k,r*u.c] for u in x] else r * x == r = 0 => 0 r = 1 => x [[u.k,a] for u in x | (a:=r*u.c) ^= 0$R]
where the knowledge of the noZeroDivisors property obviates the test to see whether any product has become zero. A Ring with this property is an EntireRing. However, this is far from realising the full power of integral domains. For example, we would like to be able to implement Bareiss' [1968] fraction-free matrix algorithms, which are only valid over integral domain, not over general rings, and we would like to be able to implement quotient elds of integral domains. None of the de nitions given above is very helpful from this point of view, though we can be inspired by the algorithmic rendering we gave \cancellation". We choose to give \integral domain" an algorithmic avour by using the following corollary to the usual de nitions: if R is an integral domain, then a=b, if it exists at all, is unique. Hence we choose to de ne an IntegralDomain to be a CommutativeRing, an EntireRing and an Algebra over itself, with an (in x) operator exquo: exquo : $ $ 7! Union($; "failed"): In this context, a exquo b = "failed" should be interpreted as meaning \there is no element c of the current domain such that bc = a, but there's no reason why one shouldn't enlarge the domain to add one". For many domains, in particular euclidean domains, exquo could be de ned in terms of a \quotient and remainder" operation, but it is often not very ecient to calculate an enormous remainder and then discover that it is non-zero*. exquo gives a hard error if the second argument is zero, since then there is no legal enlargement of the IntegralDomain to permit the division. There are various axioms10 associated with this aspect of being an integral domain: ab = ba a; b 6= 0 ) a b 6= 0 b 6= 0 ^ a exquo b 6= "failed" ) b (a exquo b) = b a = b c ) a exquo b 6= "failed": As we remarked earlier, there is no very good reason why we have forced all integral domains to be commutative: it is just that we haven't seen any need for a category of non-commutative integral domains with exquo. It would certainly not be dicult to add such a category, but one would have to be careful as to whether one meant left-division or right-division. Whether or not this is done, the exquo operator is quite powerful. Proposition. In any IntegralDomain, it is possible to determine if two elements are associates or not. The proof is obvious11 . * This is discussed by Davenport & Padget [1985a,b] and by Abbott et al. [1985]. The latter introduced the concept of \early abort" trial division. 9
But, from a computational point of view, there's more to being an integral domain than the existence of the exquo operator. We have already discussed the importance of functoriality in the abstract and here we have a good concrete example: there ought to be a functor Fraction, taking any IntegralDomain into its eld of fractions (we describe this functor later). The obvious representation for such a functor is to represent a fraction by its numerator and denominator. What would it mean for this eld of fractions to be canonically represented? (1) The IntegralDomain itself must clearly be canonically represented. (2) We must be able to suppress common divisors from the numerator and denominator of a fraction. This question is discussed in the next section: \Greatest Common Divisors". (3) We must be able to choose which associate of the denominator to use, since a fraction is the same whatever unit we multiply the numerator and denominator by. It is this last point that concerns us for the moment. We will require some form of operator which returns a distinguished associate of any element. Such operators are sometimes easy to nd, and sometimes very dicult. For example, the normal choice for the integers would be \absolute value", and the normal choice for a polynomial domain is to ensure that the leading coecient is, recursively, canonical. For the Gaussian integers we could choose one quadrant of the Argand diagram, say x > 0; y 0. Theorem. There exist integral domains such that there cannot exist an algorithm for computing a canonical associate of every element. Proof. As Frohlich & Shepherdson [1956] did, we construct a domain D which may be either Z or Z[p2; 1=p2]. If it ispZ, then p 1 and 2 are not associates, and the canonical form for 2 must be 2. If, however, it is Z[ 2; 1= 2], then 1 and 2 are associates, and so must have the same canonical form. Asking the question \do 1 and 2 have the same canonical form" is equivalent to deciding on the nature of D, which is impossible. We note that D is not an IntegralDomain in the Scratchpad sense, since it doesn't possess an exquo algorithm either, since knowing the value of 1 exquo 2 would determine D. In fact, using Brown's trick [Brown, 1969], we can equip any IntegralDomain with a canonical associate operator: we keep a list of every canonical element encountered, and, every time the \canonical associate" question is asked of x, we return the rst element of this list which is an associate of x. If there is no such element, x is deemed to be canonical, and is added to the list of canonical elements. Algorithms such as this, while in some sense they work, are not to be regarded favourably: partly because of their expense, but also because of their fundamentally non-canonical nature | organising a calculation in a di erent way, or a di erent choice of random numbers, can change the de nition of \canonical", which is not particularly helpful. Hence, from the point of view of ecient algorithms, we can see that some IntegralDomains will have ecient algorithms for nding canonical associates, and some will not. It turns out to be more practical in Scratchpad to say that all IntegralDomains should have an operator canonical12;xiii , which always satis es the axiom
x; canonical(x) are associates; but that the truly canonical nature of this, viz. that
x and y are associates ) canonical(x) = canonical(y) should be optional | if we know that this holds in a particular domain, we declare the attribute canonicalUnitNormal in that domain. 10
There is an additional question that has to be considered here: are the canonical elements closed under multiplication? This can be expressed axiomatically in the following way:
x) canonical(y)) = canonical(x) canonical(y):
canonical(canonical(
Some domains have this property, e.g. the integers with the usual de nition of canonical as \absolute value". The Gaussian integers don't have this property with the choice of a quadrant of the Argand diagram, but it is possible to nd de nitions of canonical which do have this property | choose, once and for all, a canonical associate for each prime of the Gaussian integers (for example, this could be in a particular quadrant), and then de ne the canonical associate of an arbitrary element to be the product of the canonical associates of its prime factors. This set of canonical associates is then closed under multiplication, but the algorithm for nding them is hardly ecient. Hence the axiom mentioned above is given a name | canonicalsClosedxiv, and some domains assert its validity, while others don't. It is only asserted in the presence of canonicalUnitNormal. It is a consequence of this axiom that
x exquo y 6= "failed" ) canonical(x) exquo canonical(y) is canonical:
Proof. Let z = canonical(x) exquo canonical(y). Since z canonical(y) = canonical(x), z y is an associate of x. Hence
x) = canonical(z y) = canonical(canonical(z) canonical(y)) = canonical(z ) canonical(y );
canonical(
so canonical(x) exquo canonical(y ) = canonical(z ). Since the result of the exquo operator is unique, z = canonical(z ).
Greatest Common Divisors
As was explained in the introduction, we have to distinguish between the existence of algorithms for the computation of greatest common divisors and the existence of algorithms for the computation of unique factorisation. A GcdDomain is de ned to be an IntegralDomain with an additional operator13 gcd : $ $ 7! $ satisfying the following axioms:
x exquo gcd(x; y) 6= "failed" y exquo gcd(x; y) 6= "failed" x exquo z 6= "failed" ^ y exquo z = 6 "failed" ) gcd(x; y) exquo z 6= "failed" canonicalUnitNormal ) gcd(x; y ) = canonical(gcd(x; y )): It is a consequence of these axioms that gcd(x; y ) and gcd(y; x) are associates, and hence that canonicalUnitNormal
) gcd(x; y) = gcd(y; x)
but this condition is not imposed more generally, since without canonicalUnitNormal, it is hard to ensure that the correct associate of the gcd has been found. This question can be seen as another illustration of the importance of associates in the constructive multiplicative theory. 11
It follows from the classical theory that, in a GcdDomain, factorisations into irreducible elements are unique (up to order and up to choice of associates). Such factorisations will exist if the domain is Noetherian, but we have not found any useful algorithmic categorisation* of \Noetherian". There isxv an attribute Noetherian, which is asserted by some domains, and propagated by some functors (e.g. SparseUnivariatePolynomial).
The Functor Fraction We are now able to describe the structure of the functor Fraction14. The declaration of Fraction requires an IntegralDomain D as input, and essentially returns a Field15 . The representation chosen is that of an ordered pair: numerator and denominator. If x belongs to the quotient eld then these are referred to within the functor as x.num and x.den: conversely, if n and d are two elements of D, then the fraction n=d in $ is denoted [n,d]. In fact, operations for accessing these components, known as numer and denom are exported. This is in fact the triumph of pragmatism over purism, since these are not necessarily algebraic operations (in the sense of $ being canonical). By this we mean that a = b does not necessarily imply that numer(a) = numer(b), as can be seen from the following Scratchpad example, where the type BROKEN is a version of the integers in which every element is canonical.
* One could imagine an operator increase which, given an ideal, either returned a larger ideal, or the word "failed", indicating that the ideal was maximal. The axiom of Noetherianity would then translate into the assertion that the loop
while I 6= "failed" do
I := increase(I )
always terminates (at least if I isn't the whole domain). However, this requires the introduction of \ideal" as a type (one might restrict oneself to nite-generated ideals from the point of view of representation, though the axiom should certainly apply to in nitely-generated ideals), and it's not clear how to turn this and the GcdDomain properties into an ecient algorithm for the factorisation of elements, rather than ideals. Of course, there is no problem in principal ideal domains. 12
)lo BROKEN library BROKEN has been loaded and is now exposed. a,b:BROKEN Type: Void a:=2 (2) 2 Type: BROKEN b:=-2 (3) - 2 Type: BROKEN c,d:FRAC BROKEN Type: Void c:=a/b 1 (5) --- 1 Type: FRAC BROKEN d:=b/a (6) - 1 Type: FRAC BROKEN (c=d)$(FRAC BROKEN) (7) true Type: B numer c (8) 1 Type: BROKEN numer d (9) - 1 Type: BROKEN c-d 0 (10) --- 1 Type: FRAC BROKEN (0=%)$(FRAC BROKEN) (11) true Type: B
If D is a GcdDomain, then one de nes auxiliary functions cancelGcd and normalize, both with signature $ 7! $. The rst makes use of the gcd operation, while the second16 ensures that the denominator is canonical (of course, if the attribute canonicalUnitNormal is not present, this doesn't mean very much). Both operators update their argument, and return it as result. The propagation of canonical isxviii dealt with by a clause: if D has canonical and D has GcdDomain and D has canonicalUnitNormal then $ has canonical
in the declaration of the functor. The basic arithmetic operators come in two varieties: for domains which aren't GcdDomains, and for those which are. The de nitions of the second variety cancel common divisors and use the 13
function. These are stated as separate operations, since it is generally more ecient to cancel greatest common divisors during an operation, rather than at the end, while this is not true for normalisation. Thus multiplication for GcdDomains is de ned17 as
normalize
x * y == xx := [x.num,y.den] yy := [y.num,x.den] cancelGcd xx cancelGcd yy normalize [xx.num*yy.num,xx.den*yy.den]
making two small gcd calculations rather than one large one. The canonicalsClosed attribute would render the call to normalize unnecessary, but the extra complexity of a further set of conditional de nitions seems too high for the small gain in run-time eciency. Of course, this decision could be changed at any time just by changing the code of the functor Fraction. The rest of the arithmetic operations are not worth considering in detail, but there are a couple of operations whose de nitions are worth looking at. The rst is =, de ned as x = y == x.num = y.num & x.den = y.den
if D is a GcdDomain with canonicalUnitNormal, otherwise* as x = y == x.num * y.den = y.num * x.den
The second is the operator retractIfCan with signature $ 7! Union(D; "failed"), satisfying the axiom x = n1 ; n 2 D , retractIfCan(x) = n: If D is a GcdDomain with canonicalUnitNormal, the de nition is retractIfCan x ==
if
x.den = 1
then x.num else "failed"
If D is a GcdDomain, but without canonicalUnitNormal, the de nition is retractIfCan x == (z:=recip x.den) z * x.num
case
"failed"=> "failed"
If D is not a GcdDomain, then the de nition is retractIfCan x == x.num exquo x.den
* It could be argued that we should nd a better default de nition, since doing two large multiplications may well be unnecessary. For example, we could verify things like degree compatibility if the underlying domain were a polynomial domain. 14
Unique Factorisation Domains
If R is any IntegralDomain, we de ne the functor Factoredxix to map R onto another structure, which can be viewed as \partially-factored elements of R"18 . We then de ne a UniqueFactorisationDomain to be a GcdDomain with the following additional operators: prime : $
7! Boolean
squareFreexx : $ 7! Factored($) factor : $
7! Factored($);
satisfying the obvious axioms, viz. that prime is true only if the element is prime (in the sense that it is not a unit, but any factorisation of it must contain a unit), squareFree and factor return elements with the same value, containing relatively prime square-free factors in the rst case, and non-associate prime factors in the second, with the additional proviso that, if $ has the canonicalUnitNormal attribute, then the factors are canonical. Mathematically speaking, the operator factor would suce, since prime could test whether the result of factoring its argument had length 1 or not, and squareFree could call factor and then regroup all factors having the same multiplicity. But this would be over-kill. It might also seem surprising that squareFree is not de ned earlier: surely for polynomial domains (though not for the integers) this is equivalent to the computation of greatest common divisors. Regrettably, this is not true for two reasons: the rst is that, for polynomials over a ring, we should compute the square-free decomposition of the content as well as of the primitive part, and this is not necessarily equivalent to greatest common divisor calculations. The second is that, even for polynomials over a ring, the problem of computing square-free decomposition may be insoluble, even though greatest common divisors can be computed. Proof. Let K be (Z=pZ)[y]. As Frohlich and Shepherdson [1956] did, we construct a domain L which might be K , or might be K [y 1=p], and the consider the factorisation of xp ? y in L[x]. If L? is K , this is irreducible, and a fortiori square-free. The other possibility is that this factors as x ? y 1=p p , in which case it is not square-free.
Euclidean Domains
In the normal development of commutative algebra, the sequence of re nement goes Unique Factorisation Domain ?! Principal Ideal Domain ?! Euclidean Domain: In practice, there are few examples of principal ideal domains which are not Euclidean domains, and in fact there are no such domains in Scratchpad. The example of Frohlich & Shepherdson shows that it is possible to have constructive Euclidean domains which are not constructive unique factorisation domains, so that our hierarchy will look like GcdDomain UniqueFactorisationDomain
.
&
PrincipalIdealDomain
#
EuclideanDomain PrincipalIdealDomain is de ned to be a GcdDomain with an operator principalIdeal which, given a list of elements, nds a generator of the ideal they de ne19 This only ensures that nitely generated ideals are principal, but there are (non-constructive) axioms asserting that all ideals are principal. 15
The conventional de nition of a Euclidean domain involves a function from the domain to some ordered (abelian) monoid, with the property that
x; y 6= 0 ) (xy ) (x); (y): If one declares that (0) is not de ned, one can regard the non-negative integers as the range of . EuclideanDomains are de ned to be extensions of GcdDomain with two additional fundamental operators20 ;xxi: euclideanSize : $ 7! NonNegativeInteger div : $ $ 7! $ $; where div is in x, and the two components of the return type are called quotient and remainder. These satisfy the axioms:
y 6= 0 ) x = y (x div y):quotient + (x div y):remainder y 6= 0 ) (x div y):remainder = 0 _ euclideanSize((x div y):remainder) < euclideanSize(y) x; y = 6 0 ) euclideanSize(xy) euclideanSize(y); In such a domain, there are obvious default de nitions for the functions exquo* and gcd: x exquo y == qr:=x div y qr.remainder = 0 => qr.quotient "failed"
and gcd(x,y) == x:=canonical(x) y:=canonical(y) while y ^= 0 repeat (x,y) = (y,(x div y).remainder) y:=canonical(y) x
Proposition. This algorithm does in fact compute the greatest common divisor of its inputs. Proof. The partial correctness (i.e. the fact that, if the algorithm terminates, then it computes the correct result) of the algorithm follows exactly as in the classical case. If z is a common divisor, then it divides x and y initially, and hence it divides x and y throughout the running of the algorithm, and in particular it divides the nal value of x, which is the result. On the other hand, the result divides the last pair (x; y ) (since y = 0). But each pair is a linear combination of the elements of the next pair, so by induction, the result divides the elements of every pair. Hence we need merely show that the algorithm terminates, which is obvious since (y ) is strictly decreasing. Furthermore, the guard y 6= 0 ensures that the division always succeeds. Inside EuclideanDomain, we can give principalIdeal a default de nition in terms of the extended Euclidean algorithm.21 * As was remarked earlier, this may well not be the most ecient de nition for exquo. 16
The Functor SparseUnivariatePolynomial
We are now able to describe the structure of the functor SparseUnivariatePolynomial22. This is de ned to take as parameter a ring R, and the return the ring of polynomials in one \anonymous" variable over this ring. In fact, the return type is not simply a ring, rather it is at least23 a Ring and an Module over R, with various other properties24 : (1) If R is an IntegralDomain, then so is $; (2) If R is a GcdDomain, then so is $; (3) If R is a Field, then $ is a EuclideanDomain; (4) If R has the canonicalUnitNormal attribute, then so does $; (5) If R has the canonicalsClosed attribute, then so does $; (6) If R is a CommutativeRing, the so is $, which is also an Algebra over R. (7) If R has the canonical attribute, then so does $; (8) If R has the Noetherian attribute, then so does $; The representation chosen is that of a List of objects called Terms, each of which is a record with a component from R (known as c) and a non-negative integer (known as k). In the terminology of Stoutemyer [1984], the representation is sparse, and implicit in variables. Of course, R could itself be the result of calling SparseUnivariatePolynomial, so the representation is also capable of being recursive. Given this representation, most of the algorithms are fairly obvious (though a little care has to be taken, since it is not assumed that R is always commutative): the important point for this paper is to note how the correct properties of R let us de ne the correct operations for $. For example, the function canonical for $ is de ned to return 0 if the input is 0, otherwise25 (canonical(lc(x)) exquo lc(x)) x, where lc is the \leading coecient" operator. Of course, this is not the only choice possible, but it is both natural and fairly ecient. It certainly does ensure the correctness of the propagation of the attribute canonicalUnitNormal, and indeed that of canonicalsClosed.
Conclusions
We see that, up to the category IntegralDomain, the conventional theory and the constructive theory are pretty much in step. When it comes to IntegralDomain, we have to convert a none ective axiom into an operation, the uniqueness of whose result is guaranteed by the non-e ective axiom. Every IntegralDomain can be extended to a quotient eld, and the functor Fraction does precisely this. In order to get an ecient extension, and in particular to ensure that domains with the canonical attribute extend to elds with the canonical attribute, we require that the domain should be a GcdDomain, and that it should have the canonicalUnitNormal attribute. The rst of these is fairly obvious, the second is a feature of the constructive theory. With these de nitions, we have a general functor which has all the eciency of the special cases \rational number" and \rational function" of traditional computer algebra systems, where this is possible. From the constructive point of view, the categories GcdDomain and UniqueFactorisationDomain are very di erent. This is partly due to the fundamental di erence between the operations: gcd depends only on its inputs (at least up to the choice of associates), whereas factor depends also on the ambient domain, and, as the example of Frohlich and Shepherdson shows, this di erence is crucial when it comes to questions of e ectivity. The di erence is also partly due to the fact that we do not have an e ective formulation of \Noetherian". We can formulate this as a question for future research: Does \Noetherian" have a useful constructive de nition? The major di erence from the classical theory follows from the previous paragraph: a EuclideanDomain is not necessarily a UniqueFactorisationDomain. With this, we can build a successful 17
abstract functor SparseUnivariatePolynomial, which models the classical theory, with one signi cant exception. The classical theorem polynomials over a unique factorisation domain form a unique factorisation domain has no part in the constructive theory we have elaborated. There are two obvious reasons for this. The rst is that it is false: in the Frohlich{Shepherdson example, K is a eld, hence a UniqueFactorisationDomain, but K [x] cannot be a UniqueFactorisationDomain. The second is that it is unreasonable: the ecient algorithms that we know for factoring polynomials over the integers don't rely on the factorisation of integers (unless one insists that the content be completely factored), but do rely on other properties of polynomials over the integers (reduction modulo p; Hensel's Lemma) which our formulation does not capture at all. We can set this as a future research topic: Find a formulation of \unique factorisation" such that polynomials over a unique factorisation domain become a unique factorisation domain. It may be useful to consider condition (F) of Seidenberg [1974] in this context. There are other topics that need investigation. We have not made many special extensions in algebraic number theory, and yet there is a rich theory of algebraic number elds and their integers. Produce a ner classi cation of algebraic number rings. De ne a better constructive setting for \principal ideal domain", with some useful domains belonging to this type, but not to EuclideanDomain. Gianni et al. [1988] de ne a general condition of linear equations being soluble, by which they mean that belonging to a nitely generated ideal, and nding the syzygies of a nite set of elements, are both decidable. We should nd some way to incorporate this in our framework, and, especially, to make it functorial.
Acknowledgements.
Both authors are grateful to many past and present members of the Scratchpad group for their input to the theory described in this paper. Many of the orignial ideas were worked out in conjunction with D.R. Barton. The stimulus for writing the rst version of this paper was provided by the Computer Algebra Group of Nice/Antipolis. Much discussion of this material took place while the authors enjoyed the hospitality of Mrs. Barbara Gatje.
References [Abbott et al., 1985] Abbott, J.A., Bradford, R.J. & Davenport, J.H., A Remark on Factorisation. SIGSAM Bulletin 19 (1985) 2, pp. 31{33, 37. [Bareiss, 1968] Bareiss, E.H., Sylvester's Identity and Multistep Integer-preserving Gaussian Elimination. Math. Comp. 22 (1968) pp. 565{578. [Bradford et al., 1986] Bradford, R.J., Hearn, A.C., Padget, J.A. & Schrufer, E., Enlarging the REDUCE Domain of Computation. Proc. SYMSAC 86 (ACM, New York, 1986) pp. 100{106. [Brown, 1969] Brown, W.S., Rational Exponential Expressions, and a conjecture concerning and e. Amer. Math. Monthly 76 (1969) pp. 28{34. [Collins, 1966] Collins, G.E., PM, a system for polynomial multiplication. Comm. ACM 9 (1969) pp. 578{589. [Davenport, 1981a] Davenport, J.H., On the Integration of Algebraic Functions. Springer Lecture Notes in Computer Science 102, Springer-Verlag, Berlin-Heidelberg-New York, 1981 [Russian ed. MIR, Moscow, 1985]. [Davenport, 1981b] Davenport, J.H., E ective Mathematics | the Computer Algebra viewpoint. Proc. Constructive Mathematics Conference 1980 (ed. F. Richman) [Springer Lecture Notes in Mathematics 873, Springer-Verlag, Berlin-Heidelberg-New York, 1981], pp. 31{43. 18
[Davenport & Padget, 1985a] Davenport, J.H. & Padget, J.A., HEUGCD: How Elementary Upperbounds Generate Cheaper Data. Proc. EUROCAL 85, Vol. 2 (Springer Lecture Notes in Computer Science 204, Springer-Verlag, Berlin-Heidelberg-New York, 1985) pp. 18{28 [Davenport & Padget, 1985b] Davenport, J.H. & Padget, J.A., On Numbers & Polynomials. Computers and Computing (ed. P. Chenin, C. Dicrescenzo, F. Robert), Masson and Wiley, 1985, pp. 49{53. [Frohlich & Shepherdson, 1956] Frohlich, A. & Shepherdson, J.C., E ective Procedures in Field Theory. Phil. Trans. Roy. Soc. Ser. A 248 (1955{6) pp. 407{432. [Gianni et al., 1988] Gianni, P., Trager, B.M. & Zacharias,G., Grobner Bases and Primary Decomposition of Polynomial Ideals. J. Symbolic Comp. 6 (1988) pp. 149{167. [Hearn, 1979] Hearn,A.C., Non-Modular Computation of Polynomial Gcd Using Trial Division. Proc. EUROSAM 79 (Springer Lecture Notes in Computer Science 72, Springer-Verlag, BerlinHeidelberg-New York) pp. 227{239. [Hermite, 1872] Hermite, E., Sur l'integration des fractions rationelles. Nouvelles Annales de Mathematiques, 2 Ser., 11 (1872) pp. 145{148. Ann. Scienti ques de l'E cole Normale Superieure, 2 Ser., 1 (1872) pp. 215{218. [Jenks & Trager, 1981] Jenks, R.D. & Trager, B.M., A Language for Computational Algebra. Proc. SYMSAC 81 (ACM, New York, 1981) pp. 6{13. Reprinted in SIGPLAN Notices 16 (1981) No. 11, pp. 22{29. [Moore & Norman, 1981] Moore, P.M.A. & Norman, A.C., Implementing a Polynomial Factorization and GCD Package. Proc. SYMSAC 81 (ACM, New York, 1981) pp. 109{116. [Seidenberg, 1974] Seidenberg, A., Constructions in Algebra. Trans. AMS 197 (1974) pp. 273{ 313. [Stoutemyer, 1984] Stoutemyer, D.R., Which Polynomial Representation is Best: Surprises Abound. Proc. 1984 MACSYMA Users' Conference (ed. V.E. Golden), G.E., Schenectady, pp. 221{243. [Trager, 1976] Trager,B.M., Algebraic Factoring and Rational Function Integration. Proc. SYMSAC 76 (ACM, New York, 1976) pp. 219{226.
Appendix 1: Technical Notes 1. Page 6.
is not quite fundamental, but rather is de ned in terms of Object, which has no operations. Nevertheless, nearly every type which Scratchpad manipulates is a descendant of SetCategory. The coerce function comes because SetCategory is a descendant of CoercibleTo(OutputForm). 2. Page 6. Technically speaking, it is a constant, rather than a nullary operator, which means that the value is computed once and for all when the type is created. The di erence is essentially one of eciency, and we will not discuss it further here. 3. Page 6. It also introduces a multiplication operator SetCategory
: NonNegativeInteger $ 7! $ satisfying the obvious axioms, which could also be its default de nition, 0t = 0 (n + 1) t = n t + t: 19
When we come to AbelianGroup, this operator extends to a multiplication operator
: Integer $ 7! $: These operators are de ned as they are for reasons of eciency, since there are often better ways of performing this operation than the repeated addition implied by the de nition, or even analysis of the binary representation of the integer, which is actually the default de nition used in Scratchpad. A typical use for these operations is in the de nition of di erentiation for polynomials. In fact, there is also such an operation in AbelianSemiGroup, from PositiveInteger and $ to $. 4. Page 7. In practice, it also adds a binary operator
? : $ $ 7! $ satisfying the axiom
a ? b = a + (?b):
From a logical point of view, the binary operator is redundant. It is present in Scratchpad for two reasons. The rst is legibility of programs: a ? b is easier to read than a + (?b). The second is eciency: while the binary operator can always be implemented in terms of the unary operator, and indeed has a default de nition implementing it this way, it is not necessarily very ecient to do so. For example, if $ is a matrix type, implementing the binary operator in terms of the unary operator causes two new matrices to be allocated instead of one. 5. Page 7. More precisely, SemiGroup has operators
: $ $ 7! $ : $ PositiveInteger 7! $ and Monoid adds operators (actually, 1 is a constant) 1 :7! $ : $ NonNegativeInteger 7! $: 6. Page 8. In fact, it is called a NaiveRingInternalUseOnly, in order to discourage casual use of what is only an implementation mis-feature. 7. Page 8. There is also an operation coerce : Integer 7! $ coerce satis es axioms that ensure that it is a ring-homomorphism (it suces to know that coerce(1) = 1 and coerce(m + n) = coerce(m) + coerce(n)). 8. Page 8. One might think that characteristic could be a constant, like 0 and 1. Unfortunately, there are domains in Scratchpad, such as MutableGaloisField, which can change their characteristic on the y. 20
9. Page 8. The true hierarchy is more complex: Rng
:
LeftModule
RightModule
LeftUnitaryModule
RightUnitaryModule
# (1)
Ring : Ring :
# (2)
& (3)
BiModule
. (3)
#
CommutativeRing :
Module
CommutativeRing :
Algebra
# (4)
(the column on the left indicates what each of these types is de ned over | in the case of a BiModule the two Rings need not be the same). The various arrows introduce additional axioms: 1m = m m1 = m r (m r0 ) = (r m) r0 R = A;
(1) (2) (3) (4)
where the last line indicates that all operations of the ring R, when viewed as operations of the R-algebra A, are the same as the restrictions of the corresponding operations of A. 10. Page 9. And various secondary operators and de nitions. We can give recip, which is an operator inherited from NaiveRing, a default de nition: recip x == if x = 0
then "failed" else 1 exquo x.
We can also de ne a unary predicate unit? | \is this a unit", whose default de nition is :(recip(x) = "failed"). Again, there may well be more ecient de nitions in particular cases, and we certainly don't always want to compute the value of recip just to discover that it has a value other than "failed". 11. Page 9. In fact, Scratchpad provides the category IntegralDomain with a binary predicate associates?, whose default de nition in the absence of the canonicalUnitNormal attribute is essentially the proof of this proposition:
x,y) == if x = 0 _ y = 0 then x = y else x exquo y 6= "failed" ^ y exquo x 6= "failed"
associates?(
In the presence of the attribute, we can check for being associates by checking that the results of calling canonical are the same. 12. Page 10. The actual de nition is more complicated. If one wants to know the canonical associate, one generally also wishes to know the conversion factors in the two directions. These are generally 21
13. 14.
15.
16.
discovered as a by-product of the computation of the canonical associate, so shouldn't be wasted. Hence the true Scratchpad operation is unitNormal : $ 7! $ $ $; where the three components of the result are called unit, canonical and associate, and satisfy the following axioms: unitNormal(x):unit = 1=unitNormal(x):associate unitNormal(x):canonical exquo x = unitNormal(x):associate (from which it follows that x; unitNormal(x) are associates and several other useful properties). In the body of this paper, we will use canonical(x) where actual Scratchpad would use the construction unitNormal(x).canonical. Page 11. In practice, there is also an lcm operator, with the default de nition that lcm(x; y ) = x y= gcd(x; y): Page 12. The true functor is based on extending other functors such as Localize. This would complicate the description unduly, so we shall describe a \stand-alone" version of this functor. While the inheritance from Localize complicates the structure of the code, almost all the de nitions we present here can be found in Fraction or one of its ancestors Page 12. In fact, the returned type is rather more complex. It is de ned to be a QuotientFieldCategory over D, which is de ned to be a Field, an Algebra over D and a type which is RetractableTo over D, with additional operators: = : D D 7! $ numer : $ 7! D denom : $ 7! D map : (D 7! D) $ 7! $ differentiate : $ (D 7! D) 7! D where the last function takes two arguments: one is an element of $, and the other is a function from D to D. This function is used in extending di erential operators from D to $. Furthermore, if D is an OrderedRing, then so is $, if D is a DifferentialRingxvi, then so is $, and if D is a PartialDifferentialRingxvii with respect to certain expressions, then so is $. The rst of these points is not as obvious as it might be: the de nition a=b < c=d , ad < bc only works if b and d are greater than 0. This brings us back to the question of canonical choices of associates for the denominator again. Page 13. The precise de nition of normalize for Fraction is interesting, since it explains why we chose the use of unitNormal, rather than a simple canonical function. The de nition actually is normalize(x) == uca:=unitNormal(x.den) (x.den:=uca.canonical) = 0 => error "division by zero" x.num:=x.num*uca.associate x
22
where we rely on the associate eld of the result of unitNormal to compute the appropriate normalization factor for the numerator, viz. uca.canonical/x. 17. Page 14. In principle. In practice, special checks are made for the arguments being 0 or 1. 18. Page 15. More precisely, such an object x is a record consisting of an element of R (x.unit) and a list (x.ffe) of records, each of which (say y ) consists of an element of R (y.elem), a non-zero integer (y.mult) and a ag (y.flag), which may take any of the values sqfr, prime or nil, and is an assertion about what is known about this element. The \value" of x is then
:
x unit
Y
y2x:ffe
y elemy:mult
:
:
Note that the ag sqfr indicates that the element is square-free: there is no way of indicating that the entire decomposition is square-free, i.e. that the elements are also relatively prime. 19. Page 15. In fact, the signature is more complicated: principalIdeal : List($)
7! Record(coef : List($); generator : $)
where the generator component returns a generator of the ideal (having applied the canonical function to it), and the coef component returns a list of cofactors, enabling one to express the generator as a linear combination of the input elements. 20. Page 16. In practice, we add (in x) binary operators quo and rem, with default de nitions of x quo y == (x div y).quotient x rem y == (x div y).remainder
since it is often more ecient to calculate just one of these rather than both the quotient and the remainder. This also aids readability of the Scratchpad programs. 21. Page 16. There are several other operations in EuclideanDomain. One is a binary operation extendedEuclidean, which is like principalIdeal, but applies only to two-generator ideals. There is also a ternary version of extendedEuclideanxxii: extendedEuclidean :
$ $ $ 7! Union($ $; "failed");
which evaluates to "failed" if the third argument is not in the ideal generated by the rst two (i.e. if it not divisible in the sense of exquo by the gcd of the rst two), otherwise extendedEuclidean(x; y; z ) = (a; b) with a x + b y = z . There is an operator of signature: expressIdealMember : List($) $ 7! Union(List($); "failed"); which expresses its second argument as a member of the ideal generated by the rst argument, if possible. Related to this, but di erent, is the operator multiEuclidean : List($)
$ 7! Union(List($); "failed")
whose answer (say the expresses the second argument (say y ) in terms of the rst argument P zi )Q (say the xi ) as y = i zi j 6=i xj , and yields "failed" if this is not possible. 23
22. Page 17. The actual structure is rather more complicated, since it is based on previous functors such as PolRing. For the sake of simplicity, we will describe a \stand-alone" version. 23. Page 17. The true de nition proceeds via various intermediate categories up to PolynomialCategory and UnivariatePolynomialCategory, to the point where there can be up to 72 operations de ned for a SparseUnivariatePolynomial type. 24. Page 17. And many more. For example, if R is a Field, then $ is a VectorSpace. There are also many operators which are \convenient", e.g. an exquo operator with signature $ R 7! Union($; "failed") if R is an IntegralDomain. 25. Page 17. In fact, the operator canonical is more complicated, as explained in note 12. Hence the true de nition is more like unitNormal(lc(x)):associate x.
Appendix 2: Compatibility Notes
The version of Scratchpad described in this paper, which correpsonds to versions built on the le CATDEF SPAD prepared by the authors in January 1990, contains various di erences from earlier versions of Scratchpad, introduced in the process of making Scratchpad t as closely as possible to the theory outlined in this paper. This Appendix outlines these di erences in order to help authors convert code to the new version of Scratchpad. i. Page 1. Such as this. In addition to those discovered as a direct result of this paper, the following other changes have been made: (a) GaussianPackage1 has been absorbed in Gaussian: the function eval exists directly in Gaussian. (b) there has been a substantial restructuring of RetractableTo and the operations like retractIfCan | in particular the operation retractable? has been abolished, since it is ambiguous as to which retraction is being tested for, if there are multiple retractions in scope; (c) the question of retractions to Integer and RationalNumber is being studied, and will probably form the subject of a separate publication. ii. Page 4. Some earlier versions of Scratchpad followed the philosophy outlined by Davenport [1981b] and stated as \attributes" of a category all the axioms that were intended to be true in that category. The current version only uses attributes for additional information that is not necessarily present in the category. For example, AbelianSemiGroup does not assert that it possesses the attribute commutative, since all elements of this category are commutative. Conversely, an element of the category SemiGroup might assert this attribute, since some semigroups are commutative, but not all are. An example of this is the functor Group2AbelianGroup, which converts a Group (written multiplicatively) into an AbelianGroup (written additively), provided that the group is commutative. This is handled in the following way: Group2AbelianGroup (G:Group): AbelianGroup == add Rep:= G if G has commutative("*":($,$)->$) then ... else error "Attempt to convert Group not known to be commutative ..."
24
iii. Page 4. There have been various ways of writing attributes used in the past in the Scratchpad project. We have standardised on the following notation: when an attribute refers to an operation, then that operation should be quoted as a signature , i.e. a name and its type. This means that the commutative attribute has to be referred to as commutative("*":($,$)->$). All uses of attributes should be checked to ensure that they have this syntax. The attributes currently used in the category de nitions are listed below. a) canonical: to state that Lisp equality is the same as Scratchpad equality. b) commutative("*":($,$)->$): used to indicate that the operation * is commutative. c) canonicalUnitNormal to indicate that the result of calling the unitNormal operator will return the same item in the canonical slot for all associates of a given element. d) canonicalsClosed, which indicates that the product of two canonical elements is itself canonical. e) Noetherian, which indicates that the domain in question is mathematically Noetherian, i.e. no in nite ascending sequence of ideals. f) noZeroDivisors, which indicates that the product of two non-zero elements is always non-zero. This is always asserted in EntireRing, and hence in IntegralDomain, but may be asserted in other domains, e.g. some Rngs. iv. Page 4. The functor Fraction was called QuotientField until recently. A simple name change should suce to make old code deal with the change of name. v. Page 6. SetCategory used to be called Set, but it was felt that this caused confusion with the common notion of \a set of objects". vi. Page 6. OutputForm used to be called Expression. OutputForm is a richer type than the old Expression, and is less hard-wired into the system than Expression was. vii. Page 6. An intensive e ort has been made to keep track of this attribute. Authors are requested to see that their code propagates it when correct. Note that, for a data type produced by a parameterised functor to be canonical, it is normally necessary for all the types that make up the representation to be canonically represented. viii. Page 7. CancellationAbelianMonoid is new. The partial operation ? used to be de ned in AbelianSemiGroup, even though it didn't really belong there. This means that various uses of AbelianSemiGroup or AbelianMonoid will have to be replaced by CancellationAbelianMonoid. Similarly (and more frequently) occurrences of OrderedAbelianMonoid or OrderedAbelianSemiGroup will have to be replaced by OrderedCancellationAbelianMonoid. ix. Page 7. The domain OrderedSet also introduces two binary operators: max : $ $ 7! $ min : $ $ 7! $ satisfying the obvious axioms, and with the obvious default de nitions. These de nitions could probably be replaced by some kind of macro-like mechanism, since the default de nitions are never over-ridden. A proper mechanism such as this would also allow us to de ne >, etc. properly, whereas at the moment they are \de ned" by the parser. The problem with this is that a b becomes :b < a, which is correct for total orders, but not for partial orders. 25
x. Page 8. The attribute noZeroDivisors used to be known as noZeroDivs, but the longer name was felt to be more meaningful. Scratchpad authors should check whether they should be testing the attribute noZeroDivisors, the category EntireRing, which implies the presence of a 1, or the category IntegralDomain, which also implies commutativity. xi. Page 8. NaiveRingInternalUseOnly is a new name for what used to be called SimpleRing. \Simple ring" has a technical meaning in commutative algebra, which is not the sme as ours, so we have moved away from this name. Changing all occurrences of SimpleRing to NaiveRingInternalUseOnly should solve this problem. xii. Page 8. The area of modules and algebras has been extensively re-worked, as part of a better understanding of commutativity assumptions. Module is now a genuine two-sided module, de ned only over a CommutativeRing, and LeftModule is the equivalent of the original Module. Algebras are no longer assumed to be commutative, though they must be over a CommutativeRing. Types which used to be Ring with commutative "*" should probably now be declared as Join(CommutativeRing,Algebra($)). xiii. Page 10. Earlier versions of Scratchpad used the selector coef in the record structure returned by the unitNormal operation where we have used the selector canonical, which seems to be more meaningful. All occurrences of coef (within this record structure) should be changed to canonical. xiv. Page 11. The attribute canonicalsClosed is being installed, and Scratchpad authors should check their functors to see whether they should assert and/or propagate it. xv. Page 12. Scratchpad authors should check their functors to see whether they should assert and/or propagate the noetherian attribute. xvi. Page 22. There is a compatibility point with respect to the category DifferentialRing: the (oneargument) operator that used to be called deriv is now called differentiate. This should just be a simple name change. xvii. Page 22. There is a similar compatibility point with respect to the category PartialDifferentialRing: the (two-argument) operator that used to be called pderiv is now called differentiate. This also should just be a simple name change. xviii. Page 13. Some earlier versions of Fraction were assuming canonicality when this wasn't guaranteed. xix. Page 15. Factored used to be known as FactoredForm. There have been many new operators added to the old FactoredForm: in particular Factored is now an IntegralDomain in its own right. xx. Page 15. squareFree used to be known as SqFr, but the name was changed as part of the general move against abbreviations. xxi. Page 16. This is a change from previous versions. euclideanSize is new. The previous operator was sizelp, with the implicit de nition
x; y) euclideanSize(x) < euclideanSize(y);
sizelp(
26
with appropriate de nitions for x = 0 or y = 0. In fact, this operator (renamed sizeLess?) is still present as a compatibility aid and a programming convenience. xxii. Page 23. The ternary extendedEuclidean used to be called expressIdealElt, with a slightly di erent signature: "failed" used to be "notInIdeal"
27
