The Axiom world deals with many kinds of objects. There are mathematical objects such as numbers and polynomials, data structure objects such as lists and arrays, and graphics objects such as points and graphic images. Functions are objects too.
Axiom organizes objects using the notion of domain of computation, or simply domain. Each domain denotes a class of objects. The class of objects it denotes is usually given by the name of the domain: Integer for the integers, Float for floating-point numbers, and so on. The convention is that the first letter of a domain name is capitalized. Similarly, the domain Polynomial(Integer) denotes ``polynomials with integer coefficients.'' Also, Matrix(Float) denotes ``matrices with floating-point entries.''
Every basic Axiom object belongs to a unique domain. The integer belongs to the domain Integer and the polynomial belongs to the domain Polynomial(Integer). The domain of an object is also called its type. Thus we speak of ``the type Integer'' and ``the type Polynomial(Integer).''
After an Axiom computation, the type is displayed toward the right-hand side of the page (or screen).
Here we create a rational number but it looks like the last result. The type however tells you it is different. You cannot identify the type of an object by how Axiom displays the object.
When a computation produces a result of a simpler type, Axiom leaves the type unsimplified. Thus no information is lost.
This seldom matters since Axiom retracts the answer to the simpler type if it is necessary.
When you issue a positive number, the type PositiveInteger is printed. Surely, also has type Integer! The curious reader may now have two questions. First, is the type of an object not unique? Second, how is PositiveInteger related to Integer?
Any domain can be refined to a subdomain by a membership predicate. A predicate is a function that, when applied to an object of the domain, returns either true or false. For example, the domain Integer can be refined to the subdomain PositiveInteger, the set of integers such that , by giving the Axiom predicate . Similarly, Axiom can define subdomains such as ``the subdomain of diagonal matrices,'' ``the subdomain of lists of length two,'' ``the subdomain of monic irreducible polynomials in ,'' and so on. Trivially, any domain is a subdomain of itself.
While an object belongs to a unique domain, it can belong to any number of subdomains. Any subdomain of the domain of an object can be used as the type of that object. The type of is indeed both Integer and PositiveInteger as well as any other subdomain of integer whose predicate is satisfied, such as ``the prime integers,'' ``the odd positive integers between 3 and 17,'' and so on.
In Axiom, domains are objects. You can create them, pass them to functions, and, as we'll see later, test them for certain properties.
In Axiom, you ask for a value of a function by applying its name to a set of arguments.
To ask for ``the factorial of '' you enter this expression to Axiom. This applies the function factorial to the value to compute the result.
Enter the type Polynomial (Integer) as an expression to Axiom. This looks much like a function call as well. It is! The result is appropriately stated to be of type Domain, which according to our usual convention, denotes the class of all domains.
The most basic operation involving domains is that of building a new domain from a given one. To create the domain of ``polynomials over the integers,'' Axiom applies the function Polynomial to the domain Integer. A function like Polynomial is called a domain constructor or, constructor:domain more simply, a constructor. A domain constructor is a function that creates a domain. An argument to a domain constructor can be another domain or, in general, an arbitrary kind of object. Polynomial takes a single domain argument while SquareMatrix takes a positive integer as an argument to give its dimension and a domain argument to give the type of its components.
What kinds of domains can you use as the argument to Polynomial or SquareMatrix or List? Well, the first two are mathematical in nature. You want to be able to perform algebraic operations like ``+'' and ``*'' on polynomials and square matrices, and operations such as determinant on square matrices. So you want to allow polynomials of integers and polynomials of square matrices with complex number coefficients and, in general, anything that ``makes sense.'' At the same time, you don't want Axiom to be able to build nonsense domains such as ``polynomials of strings!''
In contrast to algebraic structures, data structures can hold any kind of object. Operations on lists such as insertinsertList, deletedeleteList, and concatconcatList just manipulate the list itself without changing or operating on its elements. Thus you can build List over almost any datatype, including itself.
Create a complicated algebraic domain.
Try to create a meaningless domain.
Evidently from our last example, Axiom has some mechanism that tells what a constructor can use as an argument. This brings us to the notion of category. As domains are objects, they too have a domain. The domain of a domain is a category. A category is simply a type whose members are domains.
A common algebraic category is Ring, the class of all domains that are ``rings.'' A ring is an algebraic structure with constants and and operations +, -, and *. These operations are assumed ``closed'' with respect to the domain, meaning that they take two objects of the domain and produce a result object also in the domain. The operations are understood to satisfy certain ``axioms,'' certain mathematical principles providing the algebraic foundation for rings. For example, the additive inverse axiom for rings states:
Every element has an additive inverse such that .
The prototypical example of a domain that is a ring is the integers. Keep them in mind whenever we mention Ring.
Many algebraic domain constructors such as Complex, Polynomial, Fraction, take rings as arguments and return rings as values. You can use the infix operator ``'' to ask a domain if it belongs to a particular category.
All numerical types are rings. Domain constructor Polynomial builds ``the ring of polynomials over any other ring.''
Constructor List never produces a ring.
The constructor Matrix(R) builds ``the domain of all matrices over the ring .'' This domain is never a ring since the operations ``+'', ``-'', and ``*'' on matrices of arbitrary shapes are undefined.
Thus you can never build polynomials over matrices.
Use SquareMatrix(n,R) instead. For any positive integer , it builds ``the ring of by matrices over .''
Another common category is Field, the class of all fields. field A field is a ring with additional operations. For example, a field has commutative multiplication and a closed operation / for the division of two elements. Integer is not a field since, for example, does not have an integer result. The prototypical example of a field is the rational numbers, that is, the domain Fraction(Integer). In general, the constructor Fraction takes an IntegralDomain, which is a ring with additional properties, as an argument and returns a field. Actually, the argument domain must have some additional so as to belong to the category IntegralDomain Other domain constructors, such as Complex, build fields only if their argument domain is a field.
The complex integers (often called the ``Gaussian integers'') do not form a field.
But fractions of complex integers do.
The algebraically equivalent domain of complex rational numbers is a field since domain constructor Complex produces a field whenever its argument is a field.
The most basic category is Type. Type It denotes the class of all domains and subdomains. Note carefully that Type does not denote the class of all types. The type of all categories is Category. The type of Type itself is undefined. Domain constructor List is able to build ``lists of elements from domain '' for arbitrary simply by requiring that belong to category Type.
Now, you may ask, what exactly is a category? category Like domains, categories can be defined in the Axiom language. A category is defined by three components:
This last component is a new idea. And it is key to the design of Axiom! Because categories can extend one another, they form hierarchies. Detailed charts showing the category hierarchies in Axiom are displayed in Appendix (TPDHERE). There you see that all categories are extensions of Type and that Field is an extension of Ring.
The operations supported by the domains of a category are called the exports of that category because these are the operations made available for system-wide use. The exports of a domain of a given category are not only the ones explicitly mentioned by the category. Since a category extends other categories, the operations of these other categories---and all categories these other categories extend---are also exported by the domains.
For example, polynomial domains belong to PolynomialCategory. This category explicitly mentions some twenty-nine operations on polynomials, but it extends eleven other categories (including Ring). As a result, the current system has over one hundred operations on polynomials.
If a domain belongs to a category that extends, say, Ring, it is convenient to say that the domain exports Ring. The name of the category thus provides a convenient shorthand for the list of operations exported by the category. Rather than listing operations such as + and * of Ring each time they are needed, the definition of a type simply asserts that it exports category Ring.
The category name, however, is more than a shorthand. The name Ring, in fact, implies that the operations exported by rings are required to satisfy a set of ``axioms'' associated with the name Ring. This subtle but important feature distinguishes Axiom from other abstract datatype designs.
Why is it not correct to assume that some type is a ring if it exports all of the operations of Ring? Here is why. Some languages such as APL APL denote the Boolean constants true and false by the integers and respectively, then use ``+'' and ``*'' to denote the logical operators or and and. But with these definitions Boolean is not a ring since the additive inverse axiom is violated. That is, there is no inverse element such that , or, in the usual terms: true or a = false. This alternative definition of Boolean can be easily and correctly implemented in Axiom, since Boolean simply does not assert that it is of category Ring. This prevents the system from building meaningless domains such as Polynomial(Boolean) and then wrongfully applying algorithms that presume that the ring axioms hold.
Enough on categories. To learn more about them, see Chapter ugCategories . We now return to our discussion of domains.
Domains export a set of operations to make them available for system-wide use. Integer, for example, exports the operations + and = given by the signatures +: (Integer,Integer)->Integer and =: (Integer,Integer)->Boolean, respectively. Each of these operations takes two Integer arguments. The + operation also returns an Integer but = returns a Boolean: true or false. The operations exported by a domain usually manipulate objects of the domain---but not always.
The operations of a domain may actually take as arguments, and return as values, objects from any domain. For example, Fraction (Integer) exports the operations /: (Integer,Integer)->Fraction(Integer) and characteristiccharacteristicFraction: ->NonNegativeInteger.
Suppose all operations of a domain take as arguments and return as values, only objects from other domains. package This kind of domain constructor:package is what Axiom calls a package.
A package does not designate a class of objects at all. Rather, a package is just a collection of operations. Actually the bulk of the Axiom library of algorithms consists of packages. The facilities for factorization; integration; solution of linear, polynomial, and differential equations; computation of limits; and so on, are all defined in packages. Domains needed by algorithms can be passed to a package as arguments or used by name if they are not ``variable.'' Packages are useful for defining operations that convert objects of one type to another, particularly when these types have different parameterizations. As an example, the package PolynomialFunction2(R,S) defines operations that convert polynomials over a domain to polynomials over . To convert an object from Polynomial(Integer) to Polynomial(Float), Axiom builds the package PolynomialFunctions2(Integer,Float) in order to create the required conversion function. (This happens ``behind the scenes'' for you: see ugTypesConvert for details on how to convert objects.)
Axiom categories, domains and packages and all their contained functions are written in the Axiom programming language and have been compiled into machine code. This is what comprises the Axiom library. We will show you how to use these domains and their functions and how to write your own functions.