\documentclass{llncs}

\begin{document}

\title{YACAS: A Do-it-yourself Symbolic Algebra Environment}

\author{Ayal Zwi Pinkus\inst{1} \and Serge Winitzki\inst{2}}
\institute{3e Oosterparkstraat 109-III,
Amsterdam, The Netherlands
(\email{apinkus@xs4all.nl})
\and
Tufts Institute of Cosmology, Department of Physics and Astronomy, Tufts University, Medford, MA 02155, USA
(\email{serge@cosmos.phy.tufts.edu})
}

\maketitle

\begin{abstract}
We describe the design and implementation of \textsc{Yacas}, a free computer
algebra system currently under development.  The system consists of a core
interpreter and a library of scripts that implement symbolic algebra
functionality.  The interpreter provides a high-level weakly typed functional
language designed for quick prototyping of computer algebra algorithms, but the 
language is suitable for all kinds of symbolic manipulation. It supports
conditional term rewriting of symbolic expression trees, closures (pure
functions) and delayed evaluation, dynamic creation of transformation rules,
arbitrary-precision numerical calculations, and flexible user-defined syntax
using infix notation.  The library of scripts currently provides basic
numerical and symbolic algebra functionality, such as polynomials and
elementary functions, limits, derivatives and (limited) integration, solution
of (simple) equations. The main advantages of \textsc{Yacas} are: free (GPL)
software; a
flexible and easy-to-use programming language with a comfortable and adjustable
syntax; cross-platform portability and small resource requirements; and extensibility.
\end{abstract}

%%% Start of main text


\section{%
Introduction}
\textsc{Yacas} is a computer algebra system (CAS) which has been in development since the beginning of 1999.
The goal was to make a small system that allows to easily prototype and
research symbolic mathematics algorithms. A secondary future goal is to evolve
\textsc{Yacas} into a full-blown general purpose CAS.
%end of paragraph

\textsc{Yacas} is primarily intended to be a research tool for easy
exploration and prototyping of algorithms of symbolic
computation.  The main advantage of \textsc{Yacas} is its rich and flexible
scripting language. The language is closely related to LISP \small{\texttt{WH89}} but has
a recursive descent infix grammar parser \small{\texttt{ASU86}} which supports defining 
infix operators at run time similarly to Prolog \small{\texttt{B86}}, and includes 
expression transformation (term rewriting) as a basic feature of the
language.
%end of paragraph

The \textsc{Yacas} language interpreter comes with a library of scripts that implement a set of computer algebra features. The \textsc{Yacas} script library
is in active development and at the present stage does not offer the rich functionality of
industrial-strength systems such as \small{\texttt{Mathematica}} or \small{\texttt{Maple}}.
Extensive
implementation of algorithms of symbolic computation is one of the future
development goals.
%end of paragraph

\textsc{Yacas} handles input and output in plain ASCII,
either interactively or in batch mode. (A graphical interface is under development.) There is also an optional plugin mechanism
whereby external libraries can be linked into the system to provide extra
functionality. Basic facilities are in place to compile Yacas scripts
to C++ so they can be compiled into plugins.
%end of paragraph

\section{%
Basic design}
\textsc{Yacas} consists of a ``core engine" (kernel), which is an interpreter
for the \textsc{Yacas} scripting language, and a library of script code.
%end of paragraph

The
\textsc{Yacas} engine has been implemented in a subset of C++ which is
supported by almost all C++ compilers.
The design goals for \textsc{Yacas} core engine are: portability,
self-containment (no dependence on extra libraries or packages), ease of
implementing algorithms, code transparency, and flexibility. The \textsc{Yacas}
system as a whole falls into the ``prototype/hacker" rather than into the
``axiom/algebraic" category, according to the terminology of Fateman
\small{\texttt{F90}}. There are relatively few specific design decisions related to
mathematics, but instead the emphasis is made on extensibility.
%end of paragraph

The kernel offers sufficiently rich but basic functionality through a limited
number of core functions. This core functionality includes substitutions and
rewriting of symbolic expression trees, an infix syntax parser, and arbitrary
precision numerics. The kernel does not contain any definitions of symbolic
mathematical operations and tries to be as general and free as possible of
predefined notions or policies in the domain of symbolic computation.
%end of paragraph

The plugin inter-operability mechanism allows extension of the \textsc{Yacas} kernel and the use of external libraries, e.g. GUI toolkits or implementations of special-purpose algorithms. A simple C++ API is provided for writing ``stubs'' that make external functions appear in \textsc{Yacas} as new core functions. Plugins are on the same footing as the \textsc{Yacas} kernel and can in principle manipulate all \textsc{Yacas} internal structures. Plugins can be compiled either statically or dynamically as shared libraries to be loaded at runtime from \textsc{Yacas} scripts. 
In addition, \textsc{Yacas} scripts can be compiled to C++ code for further
compilation into a plugin. Systems that don't support plugins can then
link these modules in statically. The system can also be run without
the plugins, for debugging and development purposes. The scripts
will be interpreted in that case.
%end of paragraph

The script library contains declarations of transformation rules and of function
syntax (prefix, infix etc.). The intention is that all symbolic manipulation algorithms, definitions
of mathematical functions etc. should be held in the script library and not in the kernel. The
only exception so far is for a very small number of mathematical or utility
functions that are frequently used; they are compiled into the core for speed.
%end of paragraph

\subsection*{%
Portability}
\textsc{Yacas} is designed to be as platform-independent as possible.
All platform-specific parts have been clearly separated to facilitate porting.
Even the standard C++ library is considered to be platform-specific, as there
exist  platforms without support for the standard C++ library (e.g. the
EPOC32 platform).
%end of paragraph

The primary development platform is GNU/Linux. Currently \textsc{Yacas} runs under
various Unix variants, Windows environments, Psion organizers (EPOC32),
Ipaq PDAs,
BeOS, and Apple iMacs. Creating an executable for another platform (including embedded platforms)
should not be difficult.
%end of paragraph

\subsection*{%
A self-contained system}
\textsc{Yacas} should work as a standalone package, requiring minimum support from other
operating system components. \textsc{Yacas} takes input and output in plain ASCII,
either interactively or in batch mode. (An optional graphical interface is under development.) The system comes with its own
(unoptimized) arbitrary precision arithmetic module but could be compiled to
use another arbitrary precision arithmetic library; currently linking to \small{\texttt{gmp}}
is experimentally supported. There is also an optional plugin mechanism
whereby external libraries can be linked into the system to provide extra
functionality.
%end of paragraph

Self-containment is a requirement if the program is to be easy to port. A
dependency on libraries that might not be available on other platforms would
reduce portability. On the other hand, \textsc{Yacas} can be compiled with a complement
of external libraries on ``production" platforms.
%end of paragraph

\subsection*{%
Ease of use}
\textsc{Yacas} is used mainly by executing programs written in the \textsc{Yacas} script
language. A design goal is to create a high-level language that allows the user
to conveniently express symbolic algorithms. A few lines of user code should go
a long way.
%end of paragraph

One major advantage of \textsc{Yacas} is the flexibility of its syntax. Although \textsc{Yacas}
works internally as a LISP-style interpreter, all user interaction is through
the \textsc{Yacas} script language which has a flexible infix grammar. Infix operators
are defined by the user and may contain non-alphabetic characters such as ``\small{\texttt{=}}"
or ``\small{\texttt{\#}}". This means that the user interacts with \textsc{Yacas} using a comfortable and adjustable infix syntax,
rather than a LISP-style syntax. The user can introduce such syntactic
conventions as are most convenient for a given problem.
%end of paragraph

For example, the \textsc{Yacas} script library defines infix operators ``\small{\texttt{+}}", "\small{\texttt{*}}" and so
on with conventional precedence, so that an algebraic expression can be entered
in the familiar infix form such as
%end of paragraph

\begin{quote}\small\begin{verbatim}
(x+1)^2 - (y-2*z)/(y+3) + Sin(x*Pi/2)
\end{verbatim}\end{quote}
%end of paragraph

Once such infix operators are defined, it is possible to describe new
transformation rules directly using the new syntax. This makes it easy to
develop simplification or evaluation procedures adapted to a particular
problem.
%end of paragraph

Suppose the user needs to reorder expressions containing non-commutative creation and
annihilation operators of quantum field theory. It takes about 20 lines of
\textsc{Yacas} script code to define an infix operation ``\small{\texttt{**}}" to express non-commutative
multiplication with the appropriate commutation relations and to automatically
normal-order all expressions involving these symbols and other (commutative)
factors. Once the operator \small{\texttt{**}} is defined (with precedence 40),
\begin{quote}\small\begin{verbatim}
Infix("**", 40);
\end{verbatim}\end{quote}
the rules that express distributivity of the operation \small{\texttt{**}} with
respect to addition may look like this:
\begin{quote}\small\begin{verbatim}
15 # (_x + _y) ** _z <-- x ** z + y ** z;
15 # _z ** (_x + _y) <-- z ** x + z ** y;
\end{verbatim}\end{quote}
Here, \small{\texttt{15 \#}} is a specification of the rule precedence, \small{\texttt{\_x}} denotes a
pattern-matching variable \small{\texttt{x}} and the expression to the right of \small{\texttt{<--}} is to be
substituted instead of a matched expression on the left hand side. Since all
transformation rules are applied recursively, these two lines of code are enough for the \textsc{Yacas}
engine to expand all brackets in any expression containing the infix operators
\small{\texttt{**}} and \small{\texttt{+}}.
%end of paragraph

Rule-based programming is not the only method that can be used in \textsc{Yacas} scripts;
there are alternatives that may be more useful in some situations. For example,
the familiar \small{\texttt{if}} / \small{\texttt{else}} constructs, \small{\texttt{For}}, \small{\texttt{ForEach}} loops are
defined in the script library for the convenience of users.
%end of paragraph

Standard patterns of procedural programming, such as subroutines that
return values, with code blocks and temporary local variables, are also
available. (A ``subroutine" is implemented as a new ``ground term" with a single
rule defined for it.) Users may freely combine rules with C-like
procedures or LISP-like list processing primitives such as \small{\texttt{Head()}},
\small{\texttt{Tail()}}.
%end of paragraph

\subsection*{%
Code clarity vs. speed}
Speed is obviously an important factor. For \textsc{Yacas}, where a choice had to be
made between speed and clarity of code, clarity was chosen. \textsc{Yacas} is mainly a
prototyping system and its future maintainability is more important.
%end of paragraph

This means that special-purpose systems designed for specific types of
calculations, as well as heavily optimized industrial-strength computer algebra
systems, will outperform \textsc{Yacas}. However, special-purpose or optimized external
libraries can be dynamically linked into \textsc{Yacas} using the plugin mechanism.
%end of paragraph

\subsection*{%
Flexible, ``policy-free" engine}
The core engine of the \textsc{Yacas} system interprets the Yacas script language.
The reason to implement yet another LISP-based custom language interpreter
instead of taking an already existing one was to have full control over the
design of the system and to make it self-contained.
While most of the features of the \textsc{Yacas} script language are ``syntactic sugar" on top of a LISP 
interpreter, some features not commonly found in LISP systems were added.
%end of paragraph

The script library contains declarations of transformation rules and of function
syntax (prefix, infix etc.). The intention is that all symbolic manipulation algorithms, definitions
of mathematical functions and so on should be held in the script library and not in the kernel. The
only exception so far is for a very small number of mathematical or utility
functions that are frequently used; they are compiled into the core for speed.
%end of paragraph

For example, the mathematical operator ``\small{\texttt{+}}" is an infix operator defined in the
library scripts. To the kernel, this operator is on the same footing as any
other function defined by the user and can be redefined. The \textsc{Yacas} kernel
itself does not store any properties for this operator. Instead it relies
entirely on the script library to provide transformation rules for manipulating
expressions involving the operator ``\small{\texttt{+}}". In this way, the kernel does not need
to anticipate all possible meanings of the operator ``\small{\texttt{+}}" that users might need
in their calculations.
%end of paragraph

This policy-free scheme means that \textsc{Yacas} is highly configurable through its
scripting language. It is possible to create an entirely different symbolic
manipulation engine based on the same C++ kernel, with different syntax and
different naming  conventions, by simply using another script library instead
of the current library scripts. An example of the flexibility of the \textsc{Yacas}
system is a sample script \small{\texttt{wordproblems.ys}} that comes with the distribution. It contains a set of rule
definitions that make \textsc{Yacas} recognize simple English sentences, such as ``Tom
has 3 apples" or ``Jane gave an apple to Tom", as valid \textsc{Yacas} expressions. \textsc{Yacas}
can then ``evaluate" these sentences to \small{\texttt{True}} or \small{\texttt{False}} according to
the semantics of the current situation described in them.
%end of paragraph

The ``policy-free" concept extends to typing: strong typing is not required by
the kernel, but can be easily enforced by the  scripts if needed for a
particular problem. The language offers features, but does not enforce their
use.
Here is an example of a policy implemented in the script library:
%end of paragraph

\begin{quote}\small\begin{verbatim}
61 # x_IsPositiveNumber ^ y_IsPositiveNumber 
      <-- MathPower(x,y);
\end{verbatim}\end{quote}
By this rule, expressions of the form $x^y$ (representing powers $x ^{y}$) are
evaluated and replaced by a number if and only if \small{\texttt{x}} and \small{\texttt{y}} are positive
numerical constants. (The function \small{\texttt{MathPower}} is  defined in the kernel.) If
this simplification by default is not desirable, the user could erase this rule
from the library
and have a CAS without this feature.
%end of paragraph

\section{%
The \textsc{Yacas} kernel functionality}
\textsc{Yacas} script is a functional language based on various ideas that seemed useful
for an implementation of CAS: list-based data structures, object properties,
and functional programming (a la LISP); term rewriting [BN98] with
pattern matching somewhat along the lines of Mathematica; user-defined infix
operators a la PROLOG; delayed evaluation of expressions; and
arbitrary-precision arithmetic.
Garbage collection is implemented through reference counting.
%end of paragraph

The kernel provides three basic data types: numbers,
strings, and atoms, and two container types: list and static array (for speed).
Atoms are implemented as strings that can be assigned values and evaluated.
Boolean values are simply atoms \small{\texttt{True}} and \small{\texttt{False}}. Numbers are 
represented by objects on which arithmetic can be performed
immediately. Expression trees, association (hash) tables,
stacks, and closures (pure functions) are all implemented using nested lists. In
addition, more data types can be provided by plugins. Kernel primitives are
available for arbitrary-precision arithmetic, string manipulation, array and
list access and manipulation, for basic control flow, for assigning variables (atoms) and for defining rules for functions (atoms with a function syntax).
%end of paragraph

The interpreter engine recursively evaluates expression trees according to
user-defined transformation rules from the script library.
Evaluation proceeds bottom-up, that is, for each function term, the arguments are evaluated first and then the function is applied to these values.
%end of paragraph

A \small{\texttt{HoldArg()}} primitive is provided to not evaluate certain arguments of
certain functions before passing them on as parameters to these functions. The
\small{\texttt{Hold()}} and \small{\texttt{Eval()}} primitives, similarly to LISP's \small{\texttt{QUOTE}} and \small{\texttt{EVAL}}, can
be used to stop the recursive application of rules at a certain point and
obtain an unevaluated expression, or to initiate evaluation of an expression
which was previously held unevaluated.
%end of paragraph

When an expression can not be transformed any further, that is, when no more rules apply to it, the expression is returned
unevaluated. For instance, a variable that is not assigned a value will
return unevaluated. This is a desired behavior in a symbolic manipulation
system. Evaluation is treated as a form of ``simplification", in
that evaluating an expression returns a simplified form of the
input expression.
%end of paragraph

Rules are matched by a pattern expression which can contain \emph{pattern variables}, i.e. atoms marked by the ``\small{\texttt{\_}}" operator. During matching, each pattern variable atom becomes a local variable and is tentatively assigned the subexpression being matched. For example, the pattern \small{\texttt{\_x + \_y}} can match an expression \small{\texttt{a*x+b}} and then the pattern variable \small{\texttt{x}} will be assigned the value \small{\texttt{a*x}} (unevaluated) and the variable \small{\texttt{y}} will have the value \small{\texttt{b}}.
%end of paragraph

This type of semantic matching has been frequently implemented before in
various term rewriting systems (see, e.g., [C86]). However, the \textsc{Yacas} language
offers its users an ability to create a much more flexible and powerful term
rewriting system than one based on a fixed set of rules. Here are some of the features:
%end of paragraph

First, transformation rules in \textsc{Yacas} have predicates that control whether a
rule should be applied to an expression. Predicates can be any \textsc{Yacas}
expressions that evaluate to the atoms \small{\texttt{True}} or \small{\texttt{False}} and are typically
functions of pattern variables. A predicate could check the types or
values of certain subexpressions of the matching context (see the \small{\texttt{\_x \^ \_y}}
example in the previous subsection).
%end of paragraph

Second, rules are assigned a precedence value (a positive integer) that
controls the order of rules to be attempted. Thus \textsc{Yacas} provides somewhat better control
over the automatic recursion than the pattern-matching system of \small{\texttt{Mathematica}}
which does not allow for rule precedence.
The interpreter will first apply the rule that matches the argument pattern,
for which the predicate returns \small{\texttt{True}}, and which has the least precedence.
%end of paragraph

Third, new rules can be defined dynamically as a side-effect of evaluation.
This means that there is no predefined ``ranking alphabet" of ``ground terms" (in
the terminology of [TATA99]), in other words, no fixed set of functions with
predefined arities. It is also possible to define a ``rule closure" that defines
rules depending on its arguments, or to erase rules. Thus, a \textsc{Yacas} script
library (although it is read-only) does not represent a fixed tree rewriting
automaton. An implementation of machine learning is possible in \textsc{Yacas} (among
other things). For example, when the module \small{\texttt{wordproblems.ys}} (mentioned in the previous subsection) "learns" from the
user input that \small{\texttt{apple}} is a countable object, it defines a new postfix
operator \small{\texttt{apples}} and a rule for its evaluation, so the expression \small{\texttt{3 apples}} is later parsed as a
function \small{\texttt{apples(3)}} and evaluated according to the rule.
%end of paragraph

Fourth, \textsc{Yacas} expressions can be ``tagged" (assigned a ``property object" a la
LISP) and tags can be checked by predicates in rules or used in the evaluation.
%end of paragraph

Fifth, the scope of variables can be controlled. In addition to having its own
local variables, a function can be allowed to access local variables of its
calling environment (the \small{\texttt{UnFence()}} primitive).
It is also possible to encapsulate a group of variables and functions into a
``module", making some of them inaccessible from the outside (the \small{\texttt{LocalSymbols()}} primitive).
The scoping of variables is a ``policy decision", to be enforced by the script
which  defines the function. This flexibility is by design and allows to easily
modify the behavior of the interpreter, effectively changing the language
as needed.
%end of paragraph

\section{%
The \textsc{Yacas} scripting language}
The \textsc{Yacas} interpreter is sufficiently powerful so that the functions 
\small{\texttt{For}}, \small{\texttt{ForEach}}, \small{\texttt{if}}, \small{\texttt{else}} etc., as well as the convenient shorthand
``...\small{\texttt{<--}}..." for defining new rules, can be defined in the script library
itself rather than in the kernel. This power is fully given to the user, since
the library scripts are on the same footing as any user-defined code. Some
library functions are intended mainly as tools available to a \textsc{Yacas} user to
make algorithm implementation more comfortable. Below are some examples of the features provided by the \textsc{Yacas} script language.
%end of paragraph

\textsc{Yacas} supports ``function overloading": it allows a user to declare functions
\small{\texttt{f(x)}} and \small{\texttt{f(x,y)}}, each having their own set of transformation rules. Of
course, different rules can be defined for the same function name with the same
number of arguments (arity) but with different argument patterns or different
predicates.
%end of paragraph

Simple transformations on expressions can be performed using rules. For
instance, if we need to expand the natural logarithm in an expression, we could
use the following rules:
%end of paragraph

\begin{quote}\small\begin{verbatim}
log(_x * _y) <-- log(x) + log(y);
log(_x ^ _n) <-- n * log(x);
\end{verbatim}\end{quote}
These two rules define a new symbolic function \small{\texttt{log}} which will not be evaluated
but only transformed if one of these two rules are applicable. The symbol \small{\texttt{\_}}, as before, indicates that the following atom is a pattern variable that matches subexpressions.
%end of paragraph

After entering these two rules, the following interactive session is possible:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> log(a*x^2)

log( a ) + 2 * log( x )
\end{verbatim}\end{quote}
%end of paragraph

Integration of the new function \small{\texttt{log}} can be defined by adding a rule for the
\small{\texttt{AntiDeriv}} function atom,
%end of paragraph

\begin{quote}\small\begin{verbatim}
AntiDeriv(_x,log(_x)) <-- x*log(x)-x;
\end{verbatim}\end{quote}
Now \textsc{Yacas} can do integrations involving the newly defined \small{\texttt{log}} function, for example:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Integrate(x)log(a*x^n)

log( a ) * x + n * ( x * log( x ) - x ) + C18

In> Integrate(x,B,C)log(a*x^n)

log( a ) * C + n * ( C * log( C ) - C ) -

( log( a ) * B + n * ( B * log( B ) - B ) )
\end{verbatim}\end{quote}
%end of paragraph

Rules are applied when their associated patterns match and when their
predicates return \small{\texttt{True}}. Rules also have precedence, an integer value
to indicate which rules need to be applied first. Using these features, a
recursive implementation of the integer factorial function may look like this
in \textsc{Yacas} script,
%end of paragraph

\begin{quote}\small\begin{verbatim}
10 # Factorial(_n) _ (n=0) <-- 1;
20 # Factorial(n_IsInteger) _ (n>0) <--
  n*Factorial(n-1);
\end{verbatim}\end{quote}
Here the rules have precedence 10 and 20, so that the first rule will be tried first and the recursion will stop when $n = 0$ is reached.
%end of paragraph

Rule-based programming can be freely combined with procedural programming when
the latter is a more appropriate method. For example, here is a function that
computes ($x ^{n}\bmod m$) efficiently:
%end of paragraph

\begin{quote}\small\begin{verbatim}
powermod(x_IsPositiveInteger, 
   n_IsPositiveInteger,
   m_IsPositiveInteger) <--
[
  Local(result);
  result:=1;
  x:=Mod(x,m);
  While(n != 0)
  [
    if ((n&1) = 1)
	[
      result := Mod(result*x,m);
    ];
    x := Mod(x*x,m);
    n := n>>1;
  ];
  result;
];
\end{verbatim}\end{quote}
%end of paragraph

Interaction with the function \small{\texttt{powermod(x,n,m)}} would then look like this:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> powermod(2,10,100)
Out> 24;
In> Mod(2^10,100)
Out> 24;
In> powermod(23234234,2342424234,232423424)
Out> 210599936;
\end{verbatim}\end{quote}
%end of paragraph

\section{%
Currently supported CAS features}
\textsc{Yacas} consists of approximately 22000 lines of C++ code and  13000 lines of 
scripting code, with 170 functions defined in the C++ kernel and 600 functions
defined  in the scripting language. These numbers are deceptively small. The
program is written in clean and simple style to keep it maintainable. Excessive
optimization tends to bloat software and make it less readable.
%end of paragraph

A base of mathematical capabilities has already been implemented in the script
library (the primary sources of inspiration were the books [K98], [GG99] and
[B86]). The script library is currently under active development.  The
following section demonstrates a few facilities already offered in the  current
system.
%end of paragraph

Basic operations of elementary calculus have been implemented:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Limit(n,Infinity)(1+(1/n))^n

Exp( 1 )

In> Limit(h,0) (Sin(x+h)-Sin(x))/h

Cos( x )

In> Taylor(x,0,5)ArcSin(x)

     3        5
    x    3 * x 
x + -- + ------
    6      40  

In> InverseTaylor(x,0,5)Sin(x)

     5    3    
3 * x    x     
------ + -- + x
  40     6     

In> Integrate(x,a,b)Ln(x)+x

                   2   /                    2 \
                  b    |                   a  |
b * Ln( b ) - b + -- - | a * Ln( a ) - a + -- |
                  2    \                   2  /

In> Integrate(x)1/(x^2-1)

Ln( 2 * ( x - 1 ) )   Ln( 2 * ( x + 1 ) )      
------------------- - ------------------- + C38
         2                     2               

In> Integrate(x)Sin(a*x)^2*Cos(b*x)

Sin( b * x )   Sin( -2 * x * a + b * x )   
------------ - ------------------------- - 
   2 * b          4 * ( -2 * a + b )       

Sin( -2 * x * a - b * x )      
------------------------- + C39
   4 * ( -2 * a - b )          

In> OdeSolve(y''==4*y)

C193 * Exp( -2 * x ) + C195 * Exp( 2 * x )
\end{verbatim}\end{quote}
%end of paragraph

Solving systems of equations has been implemented using a generalized Gaussian
elimination scheme:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Solve( {x+y+z==6, 2*x+y+2*z==10, \ 
In> x+3*y+z==10}, \ 
In>      {x,y,z} ) [1]
Out> {4-z,2,z};
\end{verbatim}\end{quote}
(The solution of this underdetermined system is returned as a vector, so $x = 4 - z$, $y = 2$, and $z$ remains arbitrary.)
%end of paragraph

A small theorem prover [B86] using a resolution principle is offered:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> CanProve(P Or (Not P And Not Q))

Not( Q ) Or P
\end{verbatim}\end{quote}
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> CanProve(a > 3 And a < 2)

False
\end{verbatim}\end{quote}
%end of paragraph

Various exact and arbitrary-precision numerical algorithms have been
implemented:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> N(1/7,40);    // evaluate to 40 digits
Out> 0.1428571428571428571428571428571428571428;
In> Decimal(1/7);    // obtain decimal period
Out> {0,{1,4,2,8,5,7}};
In> N(LnGamma(1.234+2.345*I)); // gamma-function
Out> Complex(-2.13255691127918,0.70978922847121);
\end{verbatim}\end{quote}
%end of paragraph

Various domain-specific expression simplifiers are available:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> RadSimp(Sqrt(9+4*Sqrt(2)))

Sqrt( 8 ) + 1

In> TrigSimpCombine(Sin(x)^2+Cos(x)^2)

1

In> TrigSimpCombine(Cos(x/2)^2-Sin(x/2)^2)

Cos( x )

In> GcdReduce((x^2+2*x+1)/(x^2-1),x)

x + 1
-----
x - 1
\end{verbatim}\end{quote}
%end of paragraph

Univariate polynomials are supported in a dense representation, 
and multivariate polynomials in a sparse representation:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Factor(x^6+9*x^5+21*x^4-5*x^3-54*x^2-12*x+40)

         3            2            
( x + 2 )  * ( x - 1 )  * ( x + 5 )

In> Apart(1/(x^2-x-2))

      1               1      
------------- - -------------
3 * ( x - 2 )   3 * ( x + 1 )

In> Together(%)

         9         
-------------------
     2             
9 * x  - 9 * x - 18

In> Simplify(%)

     1     
----------
 2        
x  - x - 2

\end{verbatim}\end{quote}
%end of paragraph

Various ``syntactic sugar" functions are defined to more easily enter
expressions:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Ln(x*y) /: { Ln(_a*_b) <- Ln(a) + Ln(b) }

Ln( x ) + Ln( y )

In> Add(x^(1 .. 5))

     2    3    4    5
x + x  + x  + x  + x 

In> Select("IsPrime", 1 .. 15)
Out> {2,3,5,7,11,13};

\end{verbatim}\end{quote}
Groebner bases [GG99] have been implemented:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Groebner({x*(y-1),y*(x-1)})

/           \
| x * y - x |
|           |
| x * y - y |
|           |
| y - x     |
|           |
|  2        |
| y  - y    |
\           /
\end{verbatim}\end{quote}
(From this it  follows that $x = y$, and $x ^{2} = x$ so $x$ is $0$ or $1$.)
%end of paragraph

Symbolic inverses of matrices:
%end of paragraph

\begin{quote}\small\begin{verbatim}
In> Inverse({{a,b},{c,d}})

/                                      \
| /       d       \ /    -( b )     \  |
| | ------------- | | ------------- |  |
| \ a * d - b * c / \ a * d - b * c /  |
|                                      |
| /    -( c )     \ /       a       \  |
| | ------------- | | ------------- |  |
| \ a * d - b * c / \ a * d - b * c /  |
\                                      /
\end{verbatim}\end{quote}
%end of paragraph

This list of features is not exhaustive. 
%end of paragraph

\section{%
Interface}
Currently, \textsc{Yacas} is primarily a text-oriented application with interactive
interface through the text console. Commands are entered and evaluated line by
line; files containing longer code may be loaded and evaluated. A ``notebook"
interface under the GNU Emacs editor is available. There is also an experimental
graphical interface (\small{\texttt{proteus}}) for Unix and Windows environments.
%end of paragraph

Debugging facilities are implemented, allowing to trace execution of a
function, trace application of a given rule pattern, examine the stack when
recursion did not terminate, or an online debugger from the
command line. An experimental debug version of the \textsc{Yacas}
executable that provides more detailed information can be compiled.
%end of paragraph

\section{%
Documentation}
The documentation for the \textsc{Yacas} is extensive and is actively updated, following
the development of the system. Documentation currently consists of two tutorial
guides (user's introduction and programmer's introduction), a collection of
essays that describe some advanced features in more detail, and a full
reference manual.
%end of paragraph

\textsc{Yacas} currently comes with its own document formatting module that allows 
maintenance of documentation in a special plain text format with a minimal 
markup.
This text format is automatically converted to HTML, $\textrm{\LaTeX\/}$, PostScript and
PDF formats. The HTML version of the documentation is hyperlinked and is used
as online help available from the \textsc{Yacas} prompt.
%end of paragraph

\section{%
Future plans}
The long-term goal for \textsc{Yacas} is to become an industrial-strength CAS and to
remain a flexible research tool for easy prototyping of various methods of
symbolic calculations. \textsc{Yacas} is meant to be a repository and a
testbed for such algorithm prototypes.
%end of paragraph

The plugin facility will be extended in the future, so that a rich set of extra
additional libraries (especially free software libraries), system-specific as
well as mathematics-oriented, should be loadable from the \textsc{Yacas} system. The
issue of speed is also continuously being addressed. 
%end of paragraph

%%% End of main text

\begin{thebibliography}{TATW99}

\bibitem[ASU86]{ASU86} A. Aho, R. Sethi and J. Ullman, \emph{Compilers (Principles, Techniques and Tools)}, Addison-Wesley, 1986.


\bibitem[B86]{B86} I. Bratko, \emph{Prolog (Programming for Artificial Intelligence)}, Addison-Wesley, 1986.


\bibitem[BN98]{BN98} F. Baader and T. Nipkow, \emph{Term rewriting and all that}, Cambridge University Press, 1998.


\bibitem[C86]{C86} G. Cooperman, \emph{A semantic matcher for computer algebra}, in Proceedings of the symposium on symbolic and algebraic computation (1986), Waterloo, Ontario, Canada (ACM Press, NY).


\bibitem[F90]{F90} R. Fateman, \emph{On the design and construction of algebraic manipulation systems}, also published as: ACM Proceedings of the ISSAC-90, Tokyo, Japan.


\bibitem[GG99]{GG99} J. von zur Gathen and J. Gerhard, \emph{Modern Computer Algebra}, Cambridge University Press, 1999.


\bibitem[K98]{K98} D. E. Knuth, \emph{The Art of Computer Programming (Volume 2, Seminumerical Algorithms)}, Addison-Wesley, 1998.

\bibitem[TATA99]{TATA99} H. Comon, M. Dauchet, R. Gilleron, F. Jacquemard, D. Lugiez, S. Tison, and M. Tommasi, \emph{Tree Automata Techniques and Applications}, 1999, online book: {\small \verb|http://www.grappa.univ-lille3.fr/tata|}


\bibitem[W96]{W96} S. Wolfram, \emph{The Mathematica book}, Wolfram Media, Champain, 1996.


\bibitem[WH89]{WH89} P. Winston and B. Horn, \emph{LISP}, Addison-Wesley, 1989.


\end{thebibliography}

\end{document}
