In this chapter we show you how to write functions and macros, and we explain how Axiom looks for and applies them. We show some simple one-line examples of functions, together with larger ones that are defined piece-by-piece or through the use of piles.
A function is a program to perform some function:vs. macro computation. macro:vs. function Most functions have names so that it is easy to refer to them. A simple example of a function is one named absabsInteger which computes the absolute value of an integer.
This is a use of the ``absolute value'' library function for integers.
This is an unnamed function that does the same thing, using the ``maps-to'' syntax +-> that we discuss in section ugUserAnon .
Functions can be used alone or serve as the building blocks for larger programs. Usually they return a value that you might want to use in the next stage of a computation, but not always (for example, see ExitXmpPage and VoidXmpPage ). They may also read data from your keyboard, move information from one place to another, or format and display results on your screen.
In Axiom, as in mathematics, functions function:parameters are usually parameterized. Each time you call (some people say apply or invoke) a function, you give parameters to a function values to the parameters (variables). Such a value is called an argument of function:arguments the function. Axiom uses the arguments for the computation. In this way you get different results depending on what you ``feed'' the function.
Functions can have local variables or refer to global variables in the workspace. Axiom can often compile functions so that they execute very efficiently. Functions can be passed as arguments to other functions.
Macros are textual substitutions. They are used to clarify the meaning of constants or expressions and to be templates for frequently used expressions. Macros can be parameterized but they are not objects that can be passed as arguments to functions. In effect, macros are extensions to the Axiom expression parser.
A macro provides general textual substitution of macro an Axiom expression for a name. You can think of a macro as being a generalized abbreviation. You can only have one macro in your workspace with a given name, no matter how many arguments it has.
The two general forms for macros are
macro name == body
macro name(arg1,...) == body
where the body of the macro can be any Axiom expression.
For example, suppose you decided that you like to use df for D. You define the macro df like this.
Whenever you type df, the system expands it to D.
Macros can be parameterized and so can be used for many different kinds of objects.
Apply it to a number, a symbol, or an expression.
Macros can also be nested, but you get an error message if you run out of space because of an infinite nesting loop.
This new macro is fine as it does not produce a loop.
This, however, loops since gg is defined in terms of ff.
The body of a macro can be a block.
Before entering next, we need values for present and future.
Repeatedly evaluating next produces the next Fibonacci number.
And the next one.
Here is the infinite stream of the rest of the Fibonacci numbers.
Bundle all the above lines into a single macro.
Use concatconcatStream to start with the first two Fibonacci numbers Fibonacci numbers.
The library operation fibonacci is an easier way to compute these numbers.
Each name in your workspace can refer to a single object. This may be any kind of object including a function. You can use interactively any function from the library or any that you define in the workspace. In the library the same name can have very many functions, but you can have only one function with a given name, although it can have any number of arguments that you choose.
If you define a function in the workspace that has the same name and number of arguments as one in the library, then your definition takes precedence. In fact, to get the library function you must package-call it (see section ugTypesPkgCall ).
To use a function in Axiom, you apply it to its arguments. Most functions are applied by entering the name of the function followed by its argument or arguments.
Some functions like ``+'' have infix operators as names.
The function ``+'' has two arguments. When you give it more than two arguments, Axiom groups the arguments to the left. This expression is equivalent to .
All operations, including infix operators, can be written in prefix form, that is, with the operation name followed by the arguments in parentheses. For example, can alternatively be written as . But is an error since + takes only two arguments.
Prefix operations are generally applied before the infix operation. Thus the form means producing , and means producing . An example of a prefix operator is prefix ``-''. For example, converts to producing the value . Any prefix function taking two arguments can be written in an infix manner by putting an ampersand ``&'' before the name. Thus can be written as returning .
Every function in Axiom is identified by a name and type. (An exception is an ``anonymous function'' discussed in ugUserAnon .) The type of a function is always a mapping of the form Source->Target where Source and Target are types. To enter a type from the keyboard, enter the arrow by using a hyphen ``-'' followed by a greater-than sign ``>'', e.g. Integer -> Integer.
Let's go back to ``+''. There are many ``+'' functions in the Axiom library: one for integers, one for floats, another for rational numbers, and so on. These ``+'' functions have different types and thus are different functions. You've seen examples of this overloading before---using the same name for different functions. Overloading is the rule rather than the exception. You can add two integers, two polynomials, two matrices or two power series. These are all done with the same function name but with different functions.
In ugTypesDeclare we discussed how to declare a variable to restrict the kind of values that can be assigned to it. In this section we show how to declare a variable that refers to function objects.
A function is an object of type
{\sf Source Type}
where Source and Target can be any type. A common type
for Source is Tuple(, ...,
), usually written (, ...,
), to indicate a function of arguments.
If takes an Integer, a Float and another Integer, and returns a String, the declaration is written:
The types need not be written fully; using abbreviations, the above declaration is:
It is possible for a function to take no arguments. If takes no arguments but returns a Polynomial Integer, any of the following declarations is acceptable.
Functions can also be declared when they are being defined. The syntax for combined declaration/definition is:
functionName(: , ..., : ): functionReturnType
The following definition fragments show how this can be done for the functions and above.
A current restriction on function declarations is that they must involve fully specified types (that is, cannot include modes involving explicit or implicit ``?''). For more information on declaring things in general, see ugTypesDeclare .
As you use Axiom, you will find that you will write many short functions function:one-line definition to codify sequences of operations that you often perform. In this section we write some simple one-line functions.
This is a simple recursive factorial function for positive integers.
This function computes .
This function computes a Mersenne number, several of which are prime. Mersenne number
If you type mersenne, Axiom shows you the function definition.
Generate a stream of Mersenne numbers.
Create a stream of those values of such that mersenne(i) is prime.
Finally, write a function that returns the -th Mersenne prime.
If you declare the type of a function, you can apply it to any data that can be converted to the source type of the function.
Define f with type {\sf Integer Integer}.
The function f can be applied to integers, ...
and to values that convert to integers, ...
but not to values that cannot be converted to integers.
To make the function over a wide range of types, do not declare its type. Give the same definition with no declaration.
If makes sense, you can apply g to .
A version of g with different argument types get compiled for each new kind of argument used.
Here for makes no sense.
As you will see in Chapter ugCategories Axiom has a formal idea of categories for what ``makes sense.''
A function is an object that you can create, manipulate, pass to, and return from functions (for some interesting examples of library functions that manipulate functions, see MappingPackage1XmpPage ). Yet, we often seem to use the term operation and function interchangeably in Axiom. What is the distinction?
First consider values and types associated with some variable in your workspace. You can make the declaration n : Integer, then assign an integer value. You then speak of the integer . However, note that the integer is not the name itself, but the value that you assign to .
Similarly, you can declare a variable in your workspace to have type Integer Integer, then assign , through a definition or an assignment of an anonymous function. You then speak of the function . However, the function is not , but the value that you assign to .
A function is a value, in fact, some machine code for doing something. Doing what? Well, performing some operation. Formally, an operation consists of the constituent parts of in your workspace, excluding the value; thus an operation has a name and a type. An operation is what domains and packages export. Thus Ring exports one operation ``+''. Every ring also exports this operation. Also, the author of every ring in the system is obliged under contract (see ugPackagesAbstract ) to provide an implementation for this operation.
This chapter is all about functions---how you create them interactively and how you apply them to meet your needs. In Chapter ugPackages you will learn how to create them for the Axiom library. Then in Chapter ugCategories , you will learn about categories and exported operations.
In ugLangAssign we discussed the difference between immediate and function:with no arguments delayed assignments. In this section we show the difference between delayed assignments and functions of no arguments.
A function of no arguments is sometimes called a nullary function.
You must use the parentheses ``()'' to evaluate it. Like a delayed assignment, the right-hand-side of a function evaluation is not evaluated until the left-hand-side is used.
If you omit the parentheses, you just get the function definition.
You do not use the parentheses ``()'' in a delayed assignment...
nor in the evaluation.
The only syntactic difference between delayed assignments and nullary functions is that you use ``()'' in the latter case.
What happens if you define a function that has the same name as a library function? Well, if your function has the same name and number of arguments (we sometimes say arity) as another function in the library, then your function covers up the library function. If you want then to call the library function, you will have to package-call it. Axiom can use both the functions you write and those that come from the library. Let's do a simple example to illustrate this.
Suppose you (wrongly!) define sin in this way.
The value is returned for any argument.
If you want the library operation, we have to package-call it (see ugTypesPkgCall for more information).
Even worse, say we accidentally used the same name as a library function in the function.
Then Axiom definitely does not understand us.
Again, we could package-call the inside function.
Of course, you are unlikely to make such obvious errors. It is more probable that you would write a function and in the body use a function that you think is a library function. If you had also written a function by that same name, the library function would be invisible.
How does Axiom determine what library function to call? It very much depends on the particular example, but the simple case of creating the polynomial will give you an idea.
When possible, Axiom completely determines the type of every object in a function, then translates the function definition to Common Lisp or to machine code (see the next section). This translation, function:compiler called compilation, happens the first time you call the function and results in a computational delay. Subsequent function calls with the same argument types use the compiled version of the code without delay.
If Axiom cannot determine the type of everything, the function may still be executed function:interpretation but interpret-code mode in interpret-code mode: each statement in the function is analyzed and executed as the control flow indicates. This process is slower than executing a compiled function, but it allows the execution of code that may involve objects whose types change.
If Axiom decides that it cannot compile the code, it issues a message stating the problem and then the following message:
We will attempt to step through and interpret the code.
This is not a time to panic. panic:avoiding Rather, it just
means that what you gave to Axiom is somehow ambiguous: either it is
not specific enough to be analyzed completely, or it is beyond Axiom's
present interactive compilation abilities.
This function runs in interpret-code mode, but it does not compile.
For equal to , this function displays three times.
The type of the argument to output changes in each iteration, so Axiom cannot compile the function. In this case, even the inner loop by itself would have a problem:
Sometimes you can help a function to compile by using an extra conversion or by using . pretend See ugTypesSubdomains for details.
When a function is compilable, you have the choice of whether it is compiled to Common Lisp and then interpreted by the Common Lisp interpreter or then further compiled from Common Lisp to machine code. machine code The option is controlled via )set functions compile. set function compile Issue )set functions compile on to compile all the way to machine code. With the default setting )set functions compile off, Axiom has its Common Lisp code interpreted because the overhead of further compilation is larger than the run-time of most of the functions our users have defined. You may find that selectively turning this option on and off will performance give you the best performance in your particular application. For example, if you are writing functions for graphics applications where hundreds of points are being computed, it is almost certainly true that you will get the best performance by issuing )set functions compile on.
To move beyond functions defined in one line, we introduce in this section functions that are defined piece-by-piece. That is, we say ``use this definition when the argument is such-and-such and use this other definition when the argument is that-and-that.''
There are many other ways to define a factorial function for nonnegative integers. You might function:piece-wise definition say piece-wise function definition factorial of is , otherwise factorial of is times factorial of . Here is one way to do this in Axiom.
Here is the value for .
Here is the value for . The vertical bar ``|'' means ``such that''. such that
What is the value for ?
What is the value for ?
Now for a second definition. Here is the value for .
Give an error message if .
Here is the value otherwise.
What is the value for ?
What is the value for ?
To see the current piece-wise definition of a function, use )display value.
In general a piece-wise definition of a function consists of two or more parts. Each part gives a ``piece'' of the entire definition. Axiom collects the pieces of a function as you enter them. When you ask for a value of the function, it then ``glues'' the pieces together to form a function.
The two piece-wise definitions for the factorial function are examples of recursive functions, that is, functions that are defined in terms of themselves. Here is an interesting doubly-recursive function. This function returns the value for all positive integer arguments.
Here is the first of two pieces.
And the general case.
Compute , the infinite stream of values of .
What is the value at ?
What is the Axiom's definition of ?
Here are the details about how Axiom creates a function from its pieces. Axiom converts the -th piece of a function definition into a conditional expression of the form: if then . If any new piece has a that is identical (after all variables are uniformly named) to an earlier , the earlier piece is removed. Otherwise, the new piece is always added at the end.
If there are pieces to a function definition for , the function
defined is:
if then else
. . .
if then else
error "You did not define f for argument <arg>."
You can give definitions of any number of mutually recursive function definitions, piece-wise or otherwise. No computation is done until you ask for a value. When you do ask for a value, all the relevant definitions are gathered, analyzed, and translated into separate functions and compiled.
Let's recall the definition of eleven from the previous section.
A similar doubly-recursive function below produces for all negative positive integers. If you haven't worked out why or how eleven works, the structure of this definition gives a clue.
This definition we write as a block.
Define to be the sum of plus and minus ``eleven'' functions divided by . Since , we define to be .
And the general term.
What are the first ten values of ?
Axiom can create infinite streams in the positive direction (for example, for index values ) or negative direction (for example, for ). Here we would like a stream of values of that is infinite in both directions. The function below returns the -th term of the infinite stream Its definition has three pieces.
Define the initial term.
The even numbered terms are the for positive . We use ``quo'' rather than ``/'' since we want the result to be an integer.
Finally, the odd numbered terms are the for negative . In piece-wise definitions, you can use different variables to define different pieces. Axiom will not get confused.
Look at the definition of . In the first piece, the variable was used; in the second piece, . Axiom always uses your last variable to display your definitions back to you.
Create a series of values of applied to alternating positive and negative arguments.
Evidently for all . Check it at .
We have already seen some examples of function:predicate predicates predicate:in function definition (ugUserPieceBasic ). Predicates are Boolean-valued expressions and Axiom uses them for filtering collections (see ugLangIts ) and for placing constraints on function arguments. In this section we discuss their latter usage.
The simplest use of a predicate is one you don't see at all.
Here is a longer way to give the ``opposite definition.''
Try it out.
Explicit predicates tell Axiom that the given function definition piece is to be applied if the predicate evaluates to true for the arguments to the function. You can use such ``constant'' arguments for integers, function:constant argument strings, and quoted symbols. constant function argument The Boolean values true and false can also be used if qualified with ``'' or ``'' and Boolean. The following are all valid function definition fragments using constant arguments.
If a function has more than one argument, each argument can have its own predicate. However, if a predicate involves two or more arguments, it must be given after all the arguments mentioned in the predicate have been given. You are always safe to give a single predicate at the end of the argument list.
A function involving predicates on two arguments.
This is incorrect as it gives a predicate on before the argument is given.
It is always correct to write the predicate at the end.
Here is the rest of the definition.
Try it out.
By default, Axiom does not save the values of any function. function:caching values You can cause it to save values and not to recompute unnecessarily remembering function values by using )set functions cache. set functions cache This should be used before the functions are defined or, at least, before they are executed. The word following ``cache'' should be to turn off caching, a positive integer to save the last computed values or ``all'' to save all computed values. If you then give a list of names of functions, the caching only affects those functions. Use no list of names or ``all'' when you want to define the default behavior for functions not specifically mentioned in other )set functions cache statements. If you give no list of names, all functions will have the caching behavior. If you explicitly turn on caching for one or more names, you must explicitly turn off caching for those names when you want to stop saving their values.
This causes the functions f and g to have the last three computed values saved.
This is a sample definition for f.
A message is displayed stating what f will cache.
This causes all other functions to have all computed values saved by default.
This causes all functions that have not been specifically cached in some way to have no computed values saved.
We also make f and g uncached.
Be careful about caching functions that have side effects. Such a
function might destructively modify the elements of an array or issue
a draw command, for example. A function that you expect to
execute every time it is called should not be cached. Also, it is
highly unlikely that a function with no arguments should be cached.
You should also be careful about caching functions that depend on free variables. See ugUserFreeLocal for an example.
One of the most useful classes of function are those defined via a ``recurrence relation.'' A recurrence relation makes each successive recurrence relation value depend on some or all of the previous values. A simple example is the ordinary ``factorial'' function:
The value of depends on the value of , on , and so on. Because it depends on only one previous value, it is usually called a first order recurrence relation. You can easily imagine a function based on two, three or more previous values. The Fibonacci numbers are probably the most famous function defined by a Fibonacci numbers second order recurrence relation.
The library function fibonacci computes Fibonacci numbers. It is obviously optimized for speed.
Define the Fibonacci numbers ourselves using a piece-wise definition.
As defined, this recurrence relation is obviously doubly-recursive. To compute , we need to compute and . And to , we need to compute and . And so on. It seems that to compute we need to compute once, twice, three times. Look familiar? The number of function calls needed to compute any second order recurrence relation in the obvious way is exactly . These numbers grow! For example, if Axiom actually did this, then requires more than function calls. And, given all this, our definition of fib obviously could not be used to calculate the five-hundredth Fibonacci number.
Let's try it anyway.
Since this takes a short time to compute, it obviously didn't do as many as operations! By default, Axiom transforms any recurrence relation it recognizes into an iteration. Iterations are efficient. To compute the value of the -th term of a recurrence relation using an iteration requires only function calls. Note that if you compare the speed of our fib function to the library function, our version is still slower. This is because the library fibonaccifibonacciIntegerNumberTheoryFunctions uses a ``powering algorithm'' with a computing time proportional to to compute fibonacci(n).
To turn off this special recurrence relation compilation, issue set function recurrence
To turn it back on, substitute ``on'' for ``off''.
The transformations that Axiom uses for fib caches the last two values. For a more general -th order recurrence relation, Axiom caches the last values. If, after computing a value for fib, you ask for some larger value, Axiom picks up the cached values and continues computing from there. See ugUserFreeLocal for an example of a function definition that has this same behavior. Also see ugUserCache for a more general discussion of how you can cache function values.
Recurrence relations can be used for defining recurrence relations involving polynomials, rational functions, or anything you like. Here we compute the infinite stream of Legendre polynomials.
The Legendre polynomial of degree
The Legendre polynomial of degree
The Legendre polynomial of degree .
Compute the Legendre polynomial of degree
There are many times when you compute a complicated expression and then wish to use that expression as the body of a function. Axiom provides an operation called function to do function:from an object this. function:made by function @{made by function} It creates a function object and places it into the workspace. There are several versions, depending on how many arguments the function has. The first argument to function is always the expression to be converted into the function body, and the second is always the name to be used for the function. For more information, see section MakeFunctionXmpPage .
Start with a simple example of a polynomial in three variables.
To make this into a function of no arguments that simply returns the polynomial, use the two argument form of function.
To avoid possible conflicts (see below), it is a good idea to quote always this second argument.
This is what you get when you evaluate the function.
To make a function in , use a version of function that takes three arguments. The last argument is the name of the variable to use as the parameter. Typically, this variable occurs in the expression and, like the function name, you should quote it to avoid possible confusion.
This is what the new function looks like.
This is the value of f1 at . Notice that the return type of the function is Polynomial (Integer), the same as .
To use and as parameters, use the four argument form of function.
Evaluate at and . The return type of f2 is still Polynomial(Integer) because the variable is still present and not one of the parameters.
Finally, use all three variables as parameters. There is no five argument form of function, so use the one with three arguments, the third argument being a list of the parameters.
Evaluate this using the same values for and as above, but let be . The result type of f3 is Integer.
The four functions we have defined via have been undeclared. To declare a function whose body is to be generated by function:declaring function, issue the declaration before the function is created.
It is an error to use without the quote in the penultimate expression since had been declared but did not have a value. Similarly, since it is common to overuse variable names like , , and so on, you avoid problems if you always quote the variable names for function. In general, if has a value and you use without a quote in a call to function, then Axiom does not know what you are trying to do.
What kind of object is allowable as the first argument to function? Let's use the Browse facility of HyperDoc to find out. Browse@Browse At the main Browse menu, enter the string function and then click on Operations. The exposed operations called function all take an object whose type belongs to category ConvertibleTo InputForm. What domains are those? Go back to the main Browse menu, erase function, enter ConvertibleTo in the input area, and click on categories on the Constructors line. At the bottom of the page, enter InputForm in the input area following S =. Click on Cross Reference and then on Domains. The list you see contains over forty domains that belong to the category ConvertibleTo InputForm. Thus you can use function for Integer, Float, String, Complex, Expression, and so on.
You need not restrict yourself to functions that only fit on one line or are written in a piece-wise manner. The body of the function can be a block, as discussed in ugLangBlocks .
Here is a short function that swaps two elements of a list, array or vector.
The significance of swap is that it has a destructive effect on its first argument.
You see that the second and fourth elements are interchanged.
Using this, we write a couple of different sort functions. First, a simple bubble sort. sort:bubble The operation # returns the number of elements in an aggregate.
Let this be the list we want to sort.
This is the result of sorting.
Moreover, is destructively changed to be the sorted version.
This function implements an insertion sort. sort:insertion The basic idea is to traverse the list and insert the -th element in its correct position among the previous elements. Since we start at the beginning of the list, the list elements before the -th element have already been placed in ascending order.
As with our bubble sort, this is a destructive function.
Neither of the above functions is efficient for sorting large lists since they reference elements by asking for the -th element of the structure .
Here is a more efficient bubble sort for lists.
Try it out.
This definition is both recursive and iterative, and is tricky! Unless you are really curious about this definition, we suggest you skip immediately to the next section.
Here are the key points in the definition. First notice that if you are sorting a list with less than two elements, there is nothing to do: just return the list. This definition returns immediately if there are zero elements, and skips the entire while loop if there is just one element.
The second point to realize is that on each outer iteration, the bubble sort ensures that the minimum element is propagated leftmost. Each iteration of the while loop calls bubbleSort2 recursively to sort all but the first element. When finished, the minimum element is either in the first or second position. The conditional expression ensures that it comes first. If it is in the second, then a swap occurs. In any case, the rest of the original list must be updated to hold the result of the recursive call.
When you want to refer to a variable that is not local to your function, use a ``free'' declaration. free Variables declared to be free free variable are assumed to be defined globally variable:free in the variable:global workspace. global variable
This is a global workspace variable.
This function refers to the global .
The global is incremented by .
Usually Axiom can tell that you mean to refer to a global variable and so free isn't always necessary. However, for clarity and the sake of self-documentation, we encourage you to use it.
Declare a variable to be ``local'' when you do not want to refer to variable:local a global variable by the same name. local variable
This function uses as a local variable.
Apply the function.
Check that the global value of is unchanged.
Parameters to a function are local variables in the function. Even if you issue a free declaration for a parameter, it is still local.
What happens if you do not declare that a variable in the body of your function is local or free? Well, Axiom decides on this basis:
Set two global variables to 1.
Refer to before it is assigned a value, but assign a value to before it is referenced.
Can you predict this result?
How about this one?
What happened? In the first line of the function body for , is referenced on the right-hand side of the assignment. Thus is a free variable. The variable is not referenced in that line, but it is assigned a value. Thus is a local variable and is given the value . In the second line, the free variable is assigned the value which equals This is the value returned by the function. Since was free in h, the global variable has value Since was local in h, the global variable is unchanged---it still has the value .
It is good programming practice always to declare global variables. However, by far the most common situation is to have local variables in your functions. No declaration is needed for this situation, but be sure to initialize their values.
Be careful if you use free variables and you cache the value of your function (see ugUserCache ). Caching only checks if the values of the function arguments are the same as in a function call previously seen. It does not check if any of the free variables on which the function depends have changed between function calls.
Turn on caching for p.
Define p to depend on the free variable .
Set the value of .
Evaluate p the first time.
Change the value of .
Evaluate p the second time.
If caching had been turned off, the second evaluation would have reflected the changed value of .
Turn off caching for p.
Axiom does not allow fluid variables, that is, variables variable:fluid bound by a function that can be referenced by functions called by . fluid variable
Values are passed to functions by reference: a pointer to the value is passed rather than a copy of the value or a pointer to a copy.
This is a global variable that is bound to a record object.
This function first modifies the one component of its record argument and then rebinds the parameter to another record.
Pass as an argument to resetRecord.
The value of was changed by the expression but not by .
To conclude this section, we give an iterative definition of Fibonacci numbers a function that computes Fibonacci numbers. This definition approximates the definition into which Axiom transforms the recurrence relation definition of fib in ugUserRecur .
Global variables past and present are used to hold the last computed Fibonacci numbers.
Global variable gives the current index of .
Here is a recurrence relation defined in terms of these three global variables.
Compute the infinite stream of Fibonacci numbers.
What is the 1000th Fibonacci number?
As an exercise, we suggest you write a function in an iterative style that computes the value of the recurrence relation having the initial values . How would you write the function using an element OneDimensionalArray or Vector to hold the previously computed values?
An anonymous function is a function that is function:anonymous defined anonymous function by giving a list of parameters, the ``maps-to'' compound +-> @+-> symbol ``+->'' (from the mathematical symbol ), and by an expression involving the parameters, the evaluation of which determines the return value of the function.
( , , ..., ) +-> expression
You can apply an anonymous function in several ways.
Anonymous functions are particularly useful for defining functions ``on the fly.'' That is, they are handy for simple functions that are used only in one place. In the following examples, we show how to write some simple anonymous functions.
This is a simple absolute value function.
This function returns true if the absolute value of the first argument is greater than the absolute value of the second, false otherwise.
We use the above function to ``sort'' a list of integers.
This function returns if is even, otherwise.
We create a four-by-four matrix containing or depending on whether the row plus the column index is even or not.
This function returns true if a polynomial in has multiple roots, false otherwise. It is defined and applied in the same expression.
This and the next expression are equivalent.
The one you use is a matter of taste.
If you declare any of the arguments you must declare all of them. Thus,
is not legal.
This is an example of a fully declared anonymous function. function:declaring function:anonymous:declaring The output shown just indicates that the object you created is a particular kind of map, that is, function.
Axiom allows you to declare the arguments and not declare the return type.
The return type is computed from the types of the arguments and the body of the function. You cannot declare the return type if you do not declare the arguments. Therefore,
is not legal. This and the next expression are equivalent.
The one you use is a matter of taste.
When should you declare an anonymous function?
This is an example of a named function for integers that returns a function.
We define g to be a function that adds to its argument.
Try it out.
function:anonymous:restrictions An anonymous function cannot be recursive: since it does not have a name, you cannot even call it within itself! If you place an anonymous function inside a named function, the anonymous function must be declared.
This example shows how you can use Axiom to organize a database of lineage data and then query the database for relationships.
The database is entered as ``assertions'' that are really pieces of a function definition.
Each piece means ``the children of are ''.
This family tree thus spans four generations.
Say ``no one else has children.''
We need some functions for computing lineage. Start with childOf.
To find the parentOf someone, you have to scan the database of people applying children.
And a grandparent of is just a parent of a parent of .
The grandchildren of are the people such that is a grandparent of .
Suppose you want to make a list of all great-grandparents. Well, a great-grandparent is a grandparent of a person who has children.
Define descendants to include the parent as well.
Finally, we need a list of people. Since all people are descendants of ``albert'', let's say so.
We have used ``=='' to define the database and some functions to query the database. But no computation is done until we ask for some information. Then, once and for all, the functions are analyzed and compiled to machine code for run-time efficiency. Notice that no types are given anywhere in this example. They are not needed.
Who are the grandchildren of ``richard''?
Who are the great-grandparents?
In this example we write some functions that display Pascal's triangle. Pascal's triangle It demonstrates the use of piece-wise definitions and some output operations you probably haven't seen before.
To make these output operations available, we have to expose the domain OutputForm. OutputForm See ugTypesExpose for more information about exposing domains and packages.
Define the values along the first row and any column .
Define the values for when the row and column index are equal. Repeating the argument name indicates that the two index values are equal.
Now that we have defined the coefficients in Pascal's triangle, let's write a couple of one-liners to display it.
First, define a function that gives the -th row.
Next, we write the function displayRow to display the row, separating entries by blanks and centering.
Here we have used three output operations. Operation outputoutputOutputForm displays the printable form of objects on the screen, centercenterOutputForm centers a printable form in the width of the screen, and blankSeparateblankSeparateOutputForm takes a list of nprintable forms and inserts a blank between successive elements.
Look at the result.
Being purists, we find this less than satisfactory. Traditionally, elements of Pascal's triangle are centered between the left and right elements on the line above.
To fix this misalignment, we go back and redefine pascalRow to right adjust the entries within the triangle within a width of four characters.
Finally let's look at our purely reformatted triangle.
Unexpose OutputForm so we don't get unexpected results later.
In this section we define a function pal? that tests whether its palindrome argument is a palindrome, that is, something that reads the same backwards and forwards. For example, the string ``Madam I'm Adam'' is a palindrome (excluding blanks and punctuation) and so is the number . The definition works for any datatype that has components that are accessed by the indices .
Here is the definition for pal?. It is simply a call to an auxiliary function called palAux?. We are following the convention of ending a function's name with ? if the function returns a Boolean value.
Here is palAux?. It works by comparing elements that are equidistant from the start and end of the object.
Try pal? on some examples. First, a string.
A list of polynomials.
A list of integers from the example in the last section.
To use pal? on an integer, first convert it to a string.
Compute an infinite stream of decimal numbers, each of which is an obvious palindrome.
How about their squares?
Well, let's test them all.
A common mathematical formula is The presence of ``'' indicates that and can stand for arbitrary mathematical expressions in the above formula. You can use such mathematical formulas in Axiom to specify ``rewrite rules''. Rewrite rules are objects in Axiom that can be assigned to variables for later use, often for the purpose of simplification. Rewrite rules look like ordinary function definitions except that they are preceded by the reserved word . rule For example, a rewrite rule for the above formula is:
Like function definitions, no action is taken when a rewrite rule is issued. Think of rewrite rules as functions that take one argument. When a rewrite rule is applied to an argument , its meaning is: ``rewrite every subexpression of that matches by '' The left-hand side of a rewrite rule is called a pattern; its right-side side is called its substitution.
Create a rewrite rule named logrule. The generated symbol beginning with a ``%'' is a place-holder for any other terms that might occur in the sum.
Create an expression with logarithms.
Apply logrule to .
The meaning of our example rewrite rule is: ``for all expressions and , rewrite by .'' Patterns generally have both operation names (here, log and ``+'') and variables (here, and ). By default, every operation name stands for itself. Thus log matches only ``'' and not any other operation such as sin. On the other hand, variables do not stand for themselves. Rather, a variable denotes a pattern variable that is free to match any expression whatsoever. pattern:variables
When a rewrite rule is applied, a process called pattern matching goes to work by systematically scanning pattern:matching the subexpressions of the argument. When a subexpression is found that ``matches'' the pattern, the subexpression is replaced by the right-hand side of the rule. The details of what happens will be covered later.
The customary Axiom notation for patterns is actually a shorthand for a longer, more general notation. Pattern variables can be made explicit by using a percent ``%'' as the first character of the variable name. To say that a name stands for itself, you can prefix that name with a quote operator ``'''. Although the current Axiom parser does not let you quote an operation name, this more general notation gives you an alternate way of giving the same rewrite rule:
This longer notation gives you patterns that the standard notation won't handle. For example, the rule
means ``for all and , replace by when is the product of and the explicit variable .''
Thus the pattern can have several adornments on the names that appear there. Normally, all these adornments are dropped in the substitution on the right-hand side.
To summarize:
To enter a single rule in Axiom, use the following syntax: rule
rule leftHandSide == rightHandSide
The leftHandSide is a pattern to be matched and the
rightHandSide is its substitution. The rule is an object of type
RewriteRule that can be assigned to a variable and applied to
expressions to transform them.
Rewrite rules can be collected into rulesets so that a set of rules can be applied at once. Here is another simplification rule for logarithms. If instead of giving a single rule following the reserved word you give a ``pile'' of rules, you create what is called a ruleset. ruleset Like rules, rulesets are objects in Axiom and can be assigned to variables. You will find it useful to group commonly used rules into input files, and read them in as needed.
Create a ruleset named .
Again, create an expression containing logarithms.
Apply the ruleset logrules to .
We have allowed pattern variables to match arbitrary expressions in the above examples. Often you want a variable only to match expressions satisfying some predicate. For example, we may want to apply the transformation only when is an integer.
The way to restrict a pattern variable by a predicate pattern:variable:predicate is by using a vertical bar ``|'', which means ``such that,'' in such that much the same way it is used in function definitions. predicate:on a pattern variable You do this only once, but at the earliest (meaning deepest and leftmost) part of the pattern.
This restricts the logarithmic rule to create integer exponents only.
Compare this with the result of applying the previous set of rules.
You should be aware that you might need to apply a function like integer within your predicate expression to actually apply the test function.
Here we use integer because has type Expression Integer but even? is an operation defined on integers.
Here is the application of the rule.
This is an example of some of the usual identities involving products of sines and cosines.
Another qualification you will often want to use is to allow a pattern to match an identity element. Using the pattern , for example, neither nor matches the expression . Similarly, if a pattern contains a product or an exponentiation , then neither or matches .
If identical elements were matched, pattern matching would generally loop. Here is an expansion rule for exponentials.
This rule would cause infinite rewriting on this if either or were allowed to match .
There are occasions when you do want a pattern variable in a sum or product to match or . If so, prefix its name with a ``?'' whenever it appears in a left-hand side of a rule. For example, consider the following rule for the exponential integral: This rule is valid for . One solution is to create a Ruleset with two rules, one with and one without . A better solution is to use an ``optional'' pattern variable.
Define rule eirule with a pattern variable to indicate that an expression may or may not occur.
Apply rule eirule to an integral without this term.
Apply rule eirule to an integral with this term.
Here is one final adornment you will find useful. When matching a pattern of the form to an expression containing a long sum of the form , there is no way to predict in advance which subset of the sum matches and which matches . Aside from efficiency, this is generally unimportant since the rule holds for any possible combination of matches for and . In some situations, however, you may want to say which pattern variable is a sum (or product) of several terms, and which should match only a single term. To do this, put a prefix colon ``:'' before the pattern variable that you want to match multiple terms. pattern:variable:matching several terms
The remaining rules involve operators and . operator
These definitions tell Axiom that and are formal operators to be used in expressions.
First define myRule with no restrictions on the pattern variables and .
Apply myRule to an expression.
Define myOtherRule to match several terms so that the rule gets applied recursively.
Apply myOtherRule to the same expression.
Summary of pattern variable adornments:
| (x | predicate?(x)) | means that the substutution for must satisfy predicate(s) = true. |
| ?x | means that can match an identity element (0 or 1). |
| :x | means that can match several terms in a sum. |
Here are some final remarks on pattern matching. Pattern matching provides a very useful paradigm for solving certain classes of problems, namely, those that involve transformations of one form to another and back. However, it is important to recognize its limitations. pattern:matching:caveats
First, pattern matching slows down as the number of rules you have to apply increases. Thus it is good practice to organize the sets of rules you use optimally so that irrelevant rules are never included.
Second, careless use of pattern matching can lead to wrong answers. You should avoid using pattern matching to handle hidden algebraic relationships that can go undetected by other programs. As a simple example, a symbol such as ``J'' can easily be used to represent the square root of or some other important algebraic quantity. Many algorithms branch on whether an expression is zero or not, then divide by that expression if it is not. If you fail to simplify an expression involving powers of to algorithms may incorrectly assume an expression is non-zero, take a wrong branch, and produce a meaningless result.
Pattern matching should also not be used as a substitute for a domain. In Axiom, objects of one domain are transformed to objects of other domains using well-defined coerce operations. Pattern matching should be used on objects that are all the same type. Thus if your application can be handled by type Expression in Axiom and you think you need pattern matching, consider this choice carefully. Expression You may well be better served by extending an existing domain or by building a new domain of objects for your application.