present day computer algebra systems (CAS) are linguistically and
semantically impoverished. Although they are quite powerful tools for
learning math and solving particular problems they lack modern
-linguistical structures that allow for the creation of large-scale
+linguistic structures that allow for the creation of large-scale
projects. GiNaC is an attempt to overcome this situation by extending a
well established and standardized computer language (C++) by some
fundamental symbolic capabilities, thus allowing for integrated systems
And here is a configuration for a private static GiNaC library with
several components sitting in custom places (site-wide @acronym{GCC} and
-private @acronym{CLN}). The compiler is pursuaded to be picky and full
+private @acronym{CLN}). The compiler is persuaded to be picky and full
assertions and debugging information are switched on:
@example
to fiddle around with optimization.
Generally, the top-level Makefile runs recursively to the
-subdirectories. It is therfore safe to go into any subdirectory
+subdirectories. It is therefore safe to go into any subdirectory
(@code{doc/}, @code{ginsh/}, @dots{}) and simply type @code{make}
@var{target} there in case something went wrong.
the main program even if you don't want to do any special error handling.
Otherwise whenever an error occurs in GiNaC, it will be delegated to the
default exception handler of your C++ compiler's run-time system which
-ususally only aborts the program without giving any information what went
+usually only aborts the program without giving any information what went
wrong.
Here is an example for a @code{main()} function that catches and prints
denominator. When multiplied by 10, the denominator becomes unity and
the result is automatically converted to a pure integer again.
Internally, the underlying @acronym{CLN} is responsible for this
-behaviour and we refer the reader to @acronym{CLN}'s documentation.
-Suffice to say that the same behaviour applies to complex numbers as
+behavior and we refer the reader to @acronym{CLN}'s documentation.
+Suffice to say that the same behavior applies to complex numbers as
well as return values of certain functions. Complex numbers are
automatically converted to real numbers if the imaginary part becomes
zero. The full set of tests that can be applied is listed in the
Also, expressions involving integer exponents are very frequently used,
which makes it even more dangerous to overload @code{^} since it is then
hard to distinguish between the semantics as exponentiation and the one
-for exclusive or. (It would be embarassing to return @code{1} where one
+for exclusive or. (It would be embarrassing to return @code{1} where one
has requested @code{2^3}.)
@end itemize
functions, where the argument list is templated. This means that
whenever you call @code{GiNaC::sin(1)} it is equivalent to
@code{sin(ex(1))} and will therefore not result in a floating point
-numeber. Unless of course the function prototype is explicitly
+number. Unless of course the function prototype is explicitly
overridden -- which is the case for arguments of type @code{numeric}
(not wrapped inside an @code{ex}). Hence, in order to obtain a floating
point number of class @code{numeric} you should call
@code{j}.
Note the difference between the indices @code{i} and @code{j} which are of
-class @code{idx}, and the index values which are the sybols @code{i_sym}
+class @code{idx}, and the index values which are the symbols @code{i_sym}
and @code{j_sym}. The indices of indexed objects cannot directly be symbols
or numbers but must be index objects. For example, the following is not
correct and will raise an exception:
@itemize
@item it checks the consistency of free indices in sums in the same way
@code{get_free_indices()} does
-@item it tries to give dumy indices that appear in different terms of a sum
+@item it tries to give dummy indices that appear in different terms of a sum
the same name to allow simplifications like @math{a_i*b_i-a_j*b_j=0}
@item it (symbolically) calculates all possible dummy index summations/contractions
with the predefined tensors (this will be explained in more detail in the
The epsilon tensor is totally antisymmetric, its number of indices is equal
to the dimension of the index space (the indices must all be of the same
numeric dimension), and @samp{eps.1.2.3...} (resp. @samp{eps~0~1~2...}) is
-defined to be 1. Its behaviour with indices that have a variance also
+defined to be 1. Its behavior with indices that have a variance also
depends on the signature of the metric. Epsilon tensors are output as
@samp{eps}.
@end itemize
The @code{clifford} and @code{color} classes are subclasses of
-@code{indexed} because the elements of these algebras ususally carry
+@code{indexed} because the elements of these algebras usually carry
indices. The @code{matrix} class is described in more detail in
@ref{Matrices}.
Actually, if you construct an expression like @code{a == b}, this will be
represented by an object of the @code{relational} class (@pxref{Relations})
-which is not evaluated until (explicitly or implicitely) cast to a @code{bool}.
+which is not evaluated until (explicitly or implicitly) cast to a @code{bool}.
There are also two methods
In general, having more than one single wildcard as a term of a sum or a
factor of a product (such as @samp{a+$0+$1}) will lead to unpredictable or
-amgiguous results.
+ambiguous results.
Here are some examples in @command{ginsh} to demonstrate how it works (the
@code{match()} function in @command{ginsh} returns @samp{FAIL} if the
representations are the recursive ones where one collects for exponents
in one of the three variable. Since the factors are themselves
polynomials in the remaining two variables the procedure can be
-repeated. In our expample, two possibilities would be @math{(4*y + z)*x
+repeated. In our example, two possibilities would be @math{(4*y + z)*x
+ 20*y^2 + 21*y*z + 4*z^2} and @math{20*y^2 + (21*z + 4*x)*y + 4*z^2 +
x*z}.
@cindex Taylor expansion
@cindex Laurent expansion
@cindex @code{pseries} (class)
+@cindex @code{Order()}
Expressions know how to expand themselves as a Taylor series or (more
generally) a Laurent series. As in most conventional Computer Algebra
@item @strong{Name} @tab @strong{Function}
@item @code{abs(x)}
@tab absolute value
+@cindex @code{abs()}
@item @code{csgn(x)}
@tab complex sign
+@cindex @code{csgn()}
@item @code{sqrt(x)}
@tab square root (not a GiNaC function, rather an alias for @code{pow(x, numeric(1, 2))})
+@cindex @code{sqrt()}
@item @code{sin(x)}
@tab sine
+@cindex @code{sin()}
@item @code{cos(x)}
@tab cosine
+@cindex @code{cos()}
@item @code{tan(x)}
@tab tangent
+@cindex @code{tan()}
@item @code{asin(x)}
@tab inverse sine
+@cindex @code{asin()}
@item @code{acos(x)}
@tab inverse cosine
+@cindex @code{acos()}
@item @code{atan(x)}
@tab inverse tangent
+@cindex @code{atan()}
@item @code{atan2(y, x)}
@tab inverse tangent with two arguments
@item @code{sinh(x)}
@tab hyperbolic sine
+@cindex @code{sinh()}
@item @code{cosh(x)}
@tab hyperbolic cosine
+@cindex @code{cosh()}
@item @code{tanh(x)}
@tab hyperbolic tangent
+@cindex @code{tanh()}
@item @code{asinh(x)}
@tab inverse hyperbolic sine
+@cindex @code{asinh()}
@item @code{acosh(x)}
@tab inverse hyperbolic cosine
+@cindex @code{acosh()}
@item @code{atanh(x)}
@tab inverse hyperbolic tangent
+@cindex @code{atanh()}
@item @code{exp(x)}
@tab exponential function
+@cindex @code{exp()}
@item @code{log(x)}
@tab natural logarithm
+@cindex @code{log()}
@item @code{Li2(x)}
@tab Dilogarithm
+@cindex @code{Li2()}
@item @code{zeta(x)}
@tab Riemann's zeta function
+@cindex @code{zeta()}
@item @code{zeta(n, x)}
@tab derivatives of Riemann's zeta function
@item @code{tgamma(x)}
@tab Gamma function
+@cindex @code{tgamma()}
+@cindex Gamma function
@item @code{lgamma(x)}
@tab logarithm of Gamma function
+@cindex @code{lgamma()}
@item @code{beta(x, y)}
@tab Beta function (@code{tgamma(x)*tgamma(y)/tgamma(x+y)})
+@cindex @code{beta()}
@item @code{psi(x)}
@tab psi (digamma) function
+@cindex @code{psi()}
@item @code{psi(n, x)}
@tab derivatives of psi function (polygamma functions)
@item @code{factorial(n)}
@tab factorial function
+@cindex @code{factorial()}
@item @code{binomial(n, m)}
@tab binomial coefficients
+@cindex @code{binomial()}
@item @code{Order(x)}
@tab order term function in truncated power series
+@cindex @code{Order()}
@end multitable
@end cartouche
the @code{syms} list above, the @code{ex1.subs(x == 2)} statement would
have had no effect because the @code{x} in @code{ex1} would have been a
different symbol than the @code{x} which was defined at the beginning of
-the program, altough both would appear as @samp{x} when printed.
+the program, although both would appear as @samp{x} when printed.
You can also use the information stored in an @code{archive} object to
output expressions in a format suitable for exact reconstruction. The
language. There are no loops or conditional expressions in
@command{ginsh}, it is merely a window into the library for the
programmer to test stuff (or to show off). Still, the design of a
-complete CAS with a language of its own, graphical capabilites and all
+complete CAS with a language of its own, graphical capabilities and all
this on top of GiNaC is possible and is without doubt a nice project for
the future.
Now that all the ingredients for @code{cos} have been set up, we need
to tell the system about it. This is done by a macro and we are not
-going to descibe how it expands, please consult your preprocessor if you
+going to describe how it expands, please consult your preprocessor if you
are curious:
@example
@end example
The @code{GINAC_DECLARE_REGISTERED_CLASS} and @code{GINAC_IMPLEMENT_REGISTERED_CLASS}
-macros are defined in @file{registrar.h}. They take the name of the class
+macros are defined in @file{registrar.h}. They take the name of the class
and its direct superclass as arguments and insert all required declarations
for the RTTI system. The @code{GINAC_DECLARE_REGISTERED_CLASS} should be
the first line after the opening brace of the class definition. The
@code{GINAC_DECLARE_REGISTERED_CLASS} contains, among other things the
declarations of the default and copy constructor, the destructor, the
-assignment operator and a couple of other functions that are required. It
+assignment operator and a couple of other functions that are required. It
also defines a type @code{inherited} which refers to the superclass so you
don't have to modify your code every time you shuffle around the class
-hierarchy. @code{GINAC_IMPLEMENT_REGISTERED_CLASS} implements the copy
+hierarchy. @code{GINAC_IMPLEMENT_REGISTERED_CLASS} implements the copy
constructor, the destructor and the assignment operator.
Now there are nine member functions we have to implement to get a working
it will be set by the constructor of the superclass and all hell will break
loose in the RTTI. For your convenience, the @code{basic} class provides
a constructor that takes a @code{tinfo_key} value, which we are using here
-(remember that in our case @code{inherited = basic}). If the superclass
+(remember that in our case @code{inherited = basic}). If the superclass
didn't have such a constructor, we would have to set the @code{tinfo_key}
to the right value manually.
@}
@end example
-This function is where we free all dynamically allocated resources. We don't
-have any so we're not doing anything here, but if we had, for example, used
-a C-style @code{char *} to store our string, this would be the place to
-@code{delete[]} the string storage. If @code{call_parent} is true, we have
-to call the @code{destroy()} function of the superclass after we're done
-(to mimic C++'s automatic invocation of superclass destructors where
-@code{destroy()} is called from outside a destructor).
+This function is where we free all dynamically allocated resources. We
+don't have any so we're not doing anything here, but if we had, for
+example, used a C-style @code{char *} to store our string, this would be
+the place to @code{delete[]} the string storage. If @code{call_parent}
+is true, we have to call the @code{destroy()} function of the superclass
+after we're done (to mimic C++'s automatic invocation of superclass
+destructors where @code{destroy()} is called from outside a destructor).
The @code{copy()} function just copies over the member variables from
another object:
@end example
We can simply overwrite the member variables here. There's no need to worry
-about dynamically allocated storage. The assignment operator (which is
+about dynamically allocated storage. The assignment operator (which is
automatically defined by @code{GINAC_IMPLEMENT_REGISTERED_CLASS}, as you
recall) calls @code{destroy()} before it calls @code{copy()}. You have to
explicitly call the @code{copy()} function of the superclass here so
Next are the three functions for archiving. You have to implement them even
if you don't plan to use archives, but the minimum required implementation
-is really simple. First, the archiving function:
+is really simple. First, the archiving function:
@example
void mystring::archive(archive_node &n) const
The only thing that is really required is calling the @code{archive()}
function of the superclass. Optionally, you can store all information you
deem necessary for representing the object into the passed
-@code{archive_node}. We are just storing our string here. For more
+@code{archive_node}. We are just storing our string here. For more
information on how the archiving works, consult the @file{archive.h} header
file.
@}
@end example
-You don't have to understand how exactly this works. Just copy these four
-lines into your code literally (replacing the class name, of course). It
-calls the unarchiving constructor of the class and unless you are doing
-something very special (like matching @code{archive_node}s to global
-objects) you don't need a different implementation. For those who are
-interested: setting the @code{dynallocated} flag puts the object under
-the control of GiNaC's garbage collection. It will get deleted automatically
-once it is no longer referenced.
+You don't have to understand how exactly this works. Just copy these
+four lines into your code literally (replacing the class name, of
+course). It calls the unarchiving constructor of the class and unless
+you are doing something very special (like matching @code{archive_node}s
+to global objects) you don't need a different implementation. For those
+who are interested: setting the @code{dynallocated} flag puts the object
+under the control of GiNaC's garbage collection. It will get deleted
+automatically once it is no longer referenced.
Our @code{compare_same_type()} function uses a provided function to compare
the string members:
@subsection Automatic evaluation
@cindex @code{hold()}
+@cindex @code{eval()}
@cindex evaluation
When dealing with objects that are just a little more complicated than the
simple string objects we have implemented, chances are that you will want to
@end example
The @code{level} argument is used to limit the recursion depth of the
-evaluation. We don't have any subexpressions in the @code{mystring} class
-so we are not concerned with this. If we had, we would call the @code{eval()}
-functions of the subexpressions with @code{level - 1} as the argument if
-@code{level != 1}. The @code{hold()} member function sets a flag in the
-object that prevents further evaluation. Otherwise we might end up in an
-endless loop. When you want to return the object unmodified, use
-@code{return this->hold();}.
+evaluation. We don't have any subexpressions in the @code{mystring}
+class so we are not concerned with this. If we had, we would call the
+@code{eval()} functions of the subexpressions with @code{level - 1} as
+the argument if @code{level != 1}. The @code{hold()} member function
+sets a flag in the object that prevents further evaluation. Otherwise
+we might end up in an endless loop. When you want to return the object
+unmodified, use @code{return this->hold();}.
Let's confirm that it works:
disadvantages over these systems.
@menu
-* Advantages:: Stengths of the GiNaC approach.
+* Advantages:: Strengths of the GiNaC approach.
* Disadvantages:: Weaknesses of the GiNaC approach.
* Why C++?:: Attractiveness of C++.
@end menu
scripting interface consistent with the C++ language.
@item
-seemless integration: it is somewhere between difficult and impossible
+seamless integration: it is somewhere between difficult and impossible
to call CAS functions from within a program written in C++ or any other
programming language and vice versa. With GiNaC, your symbolic routines
are part of your program. You can easily call third party libraries,
@cindex garbage collection
An expression is extremely light-weight since internally it works like a
handle to the actual representation and really holds nothing more than a
-pointer to some other object. What this means in practice is that
+pointer to some other object. What this means in practice is that
whenever you create two @code{ex} and set the second equal to the first
no copying process is involved. Instead, the copying takes place as soon
as you try to change the second. Consider the simple sequence of code:
@item
@cite{Computer Algebra: Systems and Algorithms for Algebraic Computation},
-J.H. Davenport, Y. Siret, and E. Tournier, ISBN 0-12-204230-1, 1988,
+James H. Davenport, Yvon Siret, and Evelyne Tournier, ISBN 0-12-204230-1, 1988,
Academic Press, London
+@item
+@cite{Computer Algebra Systems - A Practical Guide},
+Michael J. Wester (editor), ISBN 0-471-98353-5, 1999, Wiley, Chichester
+
@item
@cite{The Art of Computer Programming, Vol 2: Seminumerical Algorithms},
-D.E. Knuth, ISBN 0-201-89684-2, 1998, Addison Wesley
+Donald E. Knuth, ISBN 0-201-89684-2, 1998, Addison Wesley
@item
-@cite{The Role of gamma5 in Dimensional Regularization}, D. Kreimer, hep-ph/9401354
+@cite{The Role of gamma5 in Dimensional Regularization}, Dirk Kreimer, hep-ph/9401354
@end itemize