yacas-1.3.6/ 0002755 0001750 0001750 00000000000 12435165641 012512 5 ustar muammar muammar yacas-1.3.6/docs/ 0002755 0001750 0001750 00000000000 12435165640 013441 5 ustar muammar muammar yacas-1.3.6/docs/examples-static.txt 0000644 0001750 0001750 00000022520 12261607322 017277 0 ustar muammar muammar Abs:Abs(-1/2) "+
"If this page includes a Yacas calculation center, and you are visiting this page for the first time, "+
"it could take a minute to download the program."+
"
Complete source code for
the current yacas version can be downloaded
from Sourceforge files section, where you can
also find binary packages for selected architectures and the
source code for older versions.
The online documentation in HTML format can be downloaded as one
tar.gz file.
Documentation in PDF format is
also available.
Some of you may have noticed changes that have been made to the Yacas project recently. The structure and look of the web site has changed a lot, as have the contents of the downloadable version of Yacas. The sharp observer might even have noticed that the release discipline has changed too. Yacas had collected a lot of unnecessary weight over the years, and there was room for improvements to the ease of use of Yacas.
The original idea behind open-sourcing Yacas was always to get people to help extend it. My reasoning was that if I wanted such a system, other people were bound to also want it. Wouldn't it be great if all those people helped me extend Yacas, instead of them starting their own system? All I had to do is stop them from starting their own project and work on mine instead. They would thus extend Yacas, improve on it, making the system more valuable as a whole to every one else including me. So Yacas started life as an open-source project, and people did come to help.
In retrospect it is a wonder that people came to help at all! Consider the effort one has to take in order to be able to contribute to Yacas. First, one has to be able to use it, which means:
Articles
Loading page, one moment please.
"+
"
yacas-1.3.6/docs/range_control.css 0000755 0001750 0001750 00000001220 12261607322 016776 0 ustar muammar muammar
.sliderContainer
{
width: 320px;
height: 12px;
background-color: #FFFFFF;
border: 1px solid #000000;
}
.sliderWidgetLeft
{
position: absolute;
width: 4px;
height: 12px;
background-color: #555599;
border: 1px solid #000000;
}
.sliderWidgetLeft:hover
{
background-color: #AAAAEE;
}
.sliderWidgetRight
{
position: absolute;
width: 4px;
height: 12px;
background-color: #555599;
border: 1px solid #000000;
}
.sliderWidgetRight:hover
{
background-color: #AAAAEE;
}
.sliderInbetween
{
position: absolute;
width: 4px;
height: 12px;
background-color: #FF0000;
border: 1px solid #000000;
}
yacas-1.3.6/docs/plain.html 0000644 0001750 0001750 00000002761 12261607322 015431 0 ustar muammar muammar
About
Read the manual
License (GPL)
Download
F.A.Q.
Credits
Related links
Email us
yacas-1.3.6/docs/back.texhtml 0000644 0001750 0001750 00000004117 12261607322 015744 0 ustar muammar muammar
Downloading Yacas
Range sliders
histo!
yacas-1.3.6/docs/paper2.tex 0000644 0001750 0001750 00000104714 12261607322 015354 0 ustar muammar muammar \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}
yacas-1.3.6/docs/recent.html 0000644 0001750 0001750 00000003546 12300203211 015567 0 ustar muammar muammar
yacas-1.3.6/docs/credits.html 0000644 0001750 0001750 00000017117 12261607322 015764 0 ustar muammar muammar
yacas-1.3.6/docs/Makefile.am 0000644 0001750 0001750 00000003023 12434151461 015464 0 ustar muammar muammar ## Makefile.am -- Process this file with automake to produce Makefile.in
## EXTRA_DIST contains the files automake does not know about,
## that need to go in the distribution.
noinst_PROGRAMS = riptestfromyart autocompleter
riptestfromyart_SOURCES = riptestfromyart.cpp
autocompleter_SOURCES = autocompleter.cpp
# These files make up the home page.
EXTRA_DIST = \
about.html basicindex.html \
consoleedit.html consoleview.html consoledescr.html credits.html faq.html \
gpl.html homepage.html links.html \
placeholder.html plain.html recent.html recentindex.html articles.html \
tabber.css tabber.js tutorials.html yacas.css yacas.html \
yacas.js datahub.js yacaslogo.png stop.gif journal.js \
cookie.js autocompleter.css \
tutorialtext1.html back-dark.gif back.gif back.texhtml \
$(YART_FILES) newtonconvergence.html newdesign.html \
range_control.html range_control.css range_control.js \
journaldescr.html \
downloads.html \
README autocompleteraccess.js examples-static.txt \
paper1.tex paper2.tex
YART_FILES = newtonconvergence.yart
## The file "yacaslogo.png" is used in the HTML documentation
html_DATA = yacaslogo.png
autocompleterarray.js: autocompleter examples-static.txt ../JavaYacas/hints.txt
cd ../JavaYacas ; make hints.txt ; cd ../docs/
./autocompleter ../JavaYacas/hints.txt autocompleterarray.js
#check: riptestfromyart $(YART_FILES)
# for file in $(YART_FILES) ; do echo "Running test code from $$file..." ; ./riptestfromyart $$file temp.yts ; ../src/yacas -pc --rootdir ../scripts temp.yts ; done
yacas-1.3.6/docs/paper1.tex 0000644 0001750 0001750 00000040366 12261607322 015355 0 ustar muammar muammar \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 functionality. 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.
\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}, besides being free software, is its rich and flexible
scripting language. The language is closely related to LISP \cite{WH89} but has
a recursive descent infix grammar parser \cite{ASU86}, includes expression
transformation (term rewriting), and supports defining infix operators at run time
similarly to Prolog \cite{B86}.
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 \textsc{Mathematica} or \textsc{Maple}.
Extensive
implementation of algorithms of symbolic computation is one of the future
development goals.
\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.
\textsc{Yacas} currently (at version 1.0.49) consists of approximately 22000 lines of C++ code and 13000 lines of
script code, with 170 functions defined in the C++ kernel and 600 functions
defined in the script library.
\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.
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
\cite{F90}. There are relatively few specific design decisions related to
mathematics, but instead the emphasis is made on extensibility.
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.
The plugin inter-operability mechanism allows to extend the \textsc{Yacas} kernel or to use 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.
%
The script library contains declarations of transformation rules and of function
syntax (prefix, infix etc.). The intention is that almost all symbolic manipulation algorithms and definitions
of mathematical functions 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.
For example, the mathematical operator ``\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 ``\texttt{+}". In this way, the kernel does not need
to anticipate all possible meanings of the operator ``\texttt{+}" that users might need
in their calculations.
\section{Advantages of \textsc{Yacas}}
The ``policy-free" kernel design 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 kernel, with different syntax
and different naming conventions, by loading another script library. An example of the flexibility of the
\textsc{Yacas} system is a sample script \texttt{wordproblems.ys}. It contains
a set of rule definitions that make \textsc{Yacas} recognize simple English
sentences, e.g.~``Tom has 3 chairs" or ``Jane gave an apple to Jill", as
valid \textsc{Yacas} expressions. \textsc{Yacas} can then ``evaluate" these
sentences to \texttt{True} or \texttt{False} according to the semantics of the
described situation.
This example illustrates a major advantage of \textsc{Yacas}---the flexibility of its syntax. Although \textsc{Yacas}
works internally as a LISP-style interpreter,
the script language has a C-like grammar. Infix operators
defined in the script library or by the user may contain non-alphabetic characters such as ``\texttt{=}"
or ``\verb|#|". This means that the user works with 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.
For example, algebraic expressions can be entered
in the familiar infix form such as
%
\begin{quote}\small\begin{verbatim}
(x+1)^2 - (y-2*z)/(y+3) + Sin(x*Pi/2)
\end{verbatim}\end{quote}
%
The same syntactic flexibility is available for defining transformation rules.
Suppose the user needs to reorder expressions containing non-commutative
operators of quantum theory. It takes about 20
rules to define an infix operation ``\texttt{**}"
to express non-commutative multiplication with the appropriate commutation
relations and to automatically reorder all expressions involving both non-commutative and commutative factors. Thanks to the \textsc{Yacas} parser,
the rules for the new operator can be written in a simple and readable form. Once the operator
``\texttt{**}" is defined, the rules that express distributivity of this operation
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, ``\verb|15 #|" is a specification of the rule precedence, ``\verb|_x|" denotes a
pattern-matching variable \texttt{x} and the expression to the right of ``\texttt{<--}" is to be
substituted instead of a matched expression on the left hand side.
Rule-based and functional programming can be freely combined with procedural
programming style when the latter is more appropriate for reasons of efficiency or simplicity. Standard
patterns of procedural programming, such as subroutines that return values,
with code blocks and temporary local variables, the familiar \texttt{if} /
\texttt{else} construct and \texttt{For()},
\texttt{ForEach()} loop functions are defined in the script library for the
convenience of users. The \textsc{Yacas} interpreter is sufficiently powerful
to define these functions in the script library itself rather than in the
kernel. This power is fully given to the user, since the library scrips are on
the same footing as any user-defined code. Many library functions are intended
mainly as tools available to a \textsc{Yacas} user to make algorithm
implementation more comfortable.
% more advantages?
%
\section{The \textsc{Yacas} kernel functionality}
\textsc{Yacas} script is a functional language based on various ideas that
seemed useful for an implementation of a CAS: list-based data structures,
object properties, functional programming (\`{a} la LISP); term rewriting
\cite{BN98} with pattern matching somewhat along the lines of
\textsc{Mathematica}; user-defined infix operators \'{a} la PROLOG; delayed
evaluation of expressions; and arbitrary precision arithmetic. Garbage
collection is implemented through reference counting.
The kernel provides three basic data types: numbers, strings, and atoms and
two container types: list and static array (for speed). Additional container or data types (``generic objects'') can be made available through C++ plugins. Atoms are implemented
as strings that can be assigned values and evaluated. Boolean values are simply
atoms \texttt{True} and \texttt{False}. Hash tables, stacks, and
closures (pure functions) are implemented using nested lists. Kernel primitives are available for arbitrary
precision arithmetic, string and list manipulation, control flow, defining
transformation rules, and declaring function syntax. Expression trees are
internally represented by nested lists. Expressions can be ``tagged" (assigned a
``property object" \`{a} la LISP).
The interpreter engine recursively evaluates expression trees according to
the transformation rules from the script library.
Evaluation proceeds from the leaves of the tree upwards. The engine tries to apply all existing rules to each subexpression, rewriting leaves or branches of the expression tree, until no more rules apply.
%
This type of semantic matching has been implemented in the past
(see, e.g., \cite{C86}). However, the \textsc{Yacas} language
includes some advanced features to create a more flexible and powerful term
rewriting system.
Rules have predicates that determine whether a
rule should be applied to an expression. Predicates can be any \textsc{Yacas}
expressions that evaluate to the atoms \texttt{True} or \texttt{False} and are typically
functions of pattern variables.
All rules are assigned a precedence value (a positive integer) and
rule matching is attempted in the order of precedence. (Thus \textsc{Yacas} provides somewhat better control
over the automatic recursion than e.g.~the pattern-matching system of \textsc{Mathematica}
which does not allow for rule precedence.)
% example
Using rule precedence and predicates, a
recursive implementation of the integer factorial function may look like this:
%
\begin{quote}\small\begin{verbatim}
10 # Factorial(0) <-- 1;
20 # Factorial(n_IsInteger) _ (n>0) <-- n*Factorial(n-1);
\end{verbatim}\end{quote}
%
The rules have precedence $10$ and $20$, therefore the first rule will be tried first and the recursion will stop when $n = 0$ is reached.
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 \cite{TATA99}). It is possible to define a ``rule closure"
that defines rules depending on its arguments, or to erase rules. Thus, a
(read-only) \textsc{Yacas} script library does not actually represent a
fixed tree rewriting automaton; an implementation of machine learning is
possible.
%A \texttt{HoldArg()} primitive is provided to not evaluate certain arguments of certain functions before passing them on as parameters to these functions. The \texttt{Hold()} and \texttt{Eval()} primitives, similarly to LISP's \texttt{QUOTE} and \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.
The Knuth-Bendix termination algorithm \cite{KB70} is not used because rules in \textsc{Yacas} are not an expression of mathematical equivalence but a programming technique. Termination is the responsibility of the user who has complete control over the order of rule application.
\section{Current status}
Currently, the script library implements basic algorithms of computer algebra:
manipulation of polynomials and elementary functions, limits, derivatives and
(basic) symbolic integration, solution of (simple) equations, and some special-purpose
functions. (The primary sources of inspiration were the books \cite{K98}, \cite{GG99} and
\cite{B86}.) The system is free (GNU GPL) software and comes with ample documentation to facilitate cooperative development. The main Internet site for \textsc{Yacas} is \texttt{http://www.xs4all.nl/\homedir apinkus/}.
The main development platform is GNU/Linux, but \textsc{Yacas} runs also
under various Unix flavors, Windows environments, Psion organizers (EPOC32),
Ipaq PDAs running the Linux kernel, BeOS, and Mac OS X. Creating an
executable for another platform (including embedded platforms) should not be
difficult.
In the future, \textsc{Yacas} is intended to grow into a general-purpose CAS as well as a repository and a testbed of algorithms.
In our opinion, \textsc{Yacas} is a promising research tool for exploring symbolic computation.
%%% 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[KB70]{KB70} D. E. Knuth and P. B. Bendix, \emph{Simple word problems in universal algebras}, in \emph{Computational problems in abstract algebra}, ed.~J. Leech, p.~263, Pergamon Press, 1970.
%\bibitem[M98]{M98} See, for example, M. B. Monagan \emph{et al.}: \emph{Maple V programming guide,} Springer-Verlag, Berlin, 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}
yacas-1.3.6/docs/stop.gif 0000644 0001750 0001750 00000001616 12261607322 015112 0 ustar muammar muammar GIF89a ÷ ÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ, s Á‚& ¡Ã† .|H1@D‰+R¼H°¡ >ZìR`ÅdôhÒ!J‡)¾| s¥K…cž¤ùP§Lž5w&Ìi³¤H >>ä1#P¥#:)’£T=%ªÄUkQ˜Z4(1 ; yacas-1.3.6/docs/autocompleteraccess.js 0000644 0001750 0001750 00000012432 12261607322 020037 0 ustar muammar muammar var prevOnLoadAutocompl = window.onload;
window.onload = initPage;
function initPage()
{
if (prevOnLoadAutocompl) prevOnLoadAutocompl();
if (document.getElementById("funcLookup"))
{
document.getElementById("funcLookup").onkeyup = searchSuggest;
setTimeout('updateHints("")',100);
}
}
var highlighted = null;
var tip = null;
function enterItem(id)
{
id = parseInt(id);
var elem = document.getElementById(id);
if (elem == highlighted)
return;
if (highlighted)
{
highlighted.style.backgroundColor = "#FFFFFF";
}
highlighted = elem;
if (tip)
{
document.getElementsByTagName("body")[0].removeChild(tip);
}
var exString = "";
if (hints[id+3] != "")
{
if (allowDemos)
{
exString = 'Credits
Ayal Pinkus
John Lapeyre
Juan Pablo
Doreen Pinkus
Igor Khavkine
James Gilbertson
Daniel Richard G.
Ladislav Zejda
Fred Bacon
Schneelocke
Serge Winitzki
Jay Belanger
Gopal Narayanan
Vladimir Livshits
Eugenia Loli
Saverio Prinz
John Fremlin
Mark Arrasmith
Robert V Schipper
Gopal Narayanan
Christian Obrecht
Jitse Niesen
Pablo Di Napoli
Joris van der Hoeven
Alberto González Palomo
Jonathan Leto
Andrei Zorine
Daniel Rigby
Dirk Reusch
Mark Hatsell
Yannick Versley
Franz Hack
Mike Pinna
Sebastian Ferraro
Roberto Colistete Junior
Jim Apple
Wolfgang Hšnig
Rene Grothmann
Peter Gilbert
Ingrid Halters
Gabor Grothendieck
Examples
(clicking on one of the items below sends them to the Yacas calculation center on the left)';
var examples = hints[id+3].split("
";
}
}
tip = document.createElement("div");
tip.className = "autocompletertooltip";
tip.innerHTML =
'Function '+hints[id]+' — '+hints[id+2]+' more...' +
'
' +
'Prototypes
'+hints[id+1] +
exString;
tip.style.position = "absolute";
var cursorPosition = [0, 0];
if (elem != null)
{
elem.style.backgroundColor = "#AAAAEE";
cursorPosition[0] += elem.offsetWidth + 16;
}
elem = document.getElementById("popups");
while (elem != null)
{
cursorPosition[0] += elem.offsetLeft;
cursorPosition[1] += elem.offsetTop;
elem = elem.offsetParent;
}
var left = cursorPosition[0];
var top = cursorPosition[1];
tip.style.left = left + "px";
tip.style.top = top + "px";
tip.style.visibility = "hidden";
tip.style.overflow = "hidden";
document.getElementsByTagName("body")[0].appendChild(tip);
var viewportSize = getViewportSize();
if (left > viewportSize[0]-tip.offsetWidth)
{
left = viewportSize[0]-tip.offsetWidth;
if (left < cursorPosition[0]+10-48)
left = cursorPosition[0]+10-48;
tip.style.left = left;
}
if (top > viewportSize[1]-tip.offsetHeight)
{
top = viewportSize[1]-tip.offsetHeight;
tip.style.top = top;
}
tip.style.visibility = "visible";
}
function searchSuggest()
{
var searchString = this.value;
updateHints(searchString);
}
var allowDemos = true;
function setAllowDemos(allow)
{
allowDemos = allow;
}
function updateHints(searchString)
{
var firstId = "";
var firstIdIndex = 100;
if (tip)
{
document.getElementsByTagName("body")[0].removeChild(tip);
}
highlighted = null;
tip = null;
var popups = document.getElementById("popups");
popups.style.visibility = "hidden";
popups.innerHTML = "";
{
var matches = new Array("","","","","","","","");
var lengths = new Array(0,0,0,0,0,0,0,0);
var moreAvailable = 0;
var maxMatches=1000;//15;
// Most interesting functions, make sure people see these first so they have something interesting to click on
var fronts = ":Div:N:Select:Factor:Taylor:D:Integrate:Simplify:Solve:Sum:Limit:DiagonalMatrix:ForEach:Pi:Plot2D:";
var lwr = searchString.toLowerCase();
for (var i=0;i
yacas-1.3.6/docs/newdesign.html 0000644 0001750 0001750 00000036464 12261607322 016320 0 ustar muammar muammar
Find function:
Big changes ahead for Yacas
Now, that was just to use Yacas. Now, if you want to actually contribute, you have to:
People had to be really persistent, they had to really really want to help extend Yacas. It is a miracle people came to help at all.
User interface design to the rescue
User interface design is generally frowned upon in academia. It is not 'smart', does not require 'brains'. If you look at what equivalent projects work on they very rarely spend much time considering the interface to the user, the way the end user is going to communicate with the system. There is a command line, and you type in commands there. If you don't know a command, you look it up in a manual, or worse, the source code because the manual is non-existent or incomplete or not kept up to date. I have seen Google summer of code projects for competing software programs where they sollicited help from computer science students to design a user interface for them. This is akin to, say, asking a student of mathematics to become a cook in a one-star restaurant, tonight, or a photographer, or an artist painter, etcetera. No amount of smarts will allow you to do work instantly that requires skill and years of training. And user interface design is an art, a skill, and it requires knowledge and experience. You can not substitute smartness for that.
There are two big competing computer algebra systems that Yacas competes with, Axiom and Maxima. Axiom and Maxima have their roots in the seventies, in an era where artificial intelligence was the next big thing. Computers had to second-guess you. You typed in a problem, and the system presented you with the solution. People have come to think of computer algebra systems in that way, as huge databases of mathematical knowledge to query, a search engine of mathematics. That is what they mean when they say Yacas is less powerful than the other systems. People type in some calculation that Axiom and Maxima had entries for in their databases, and Yacas doesn't. These two systems have math knowledge databases that are more extensive than the database of knowledge in Yacas.
When I started Yacas back in 1998, there were no big open-source computer algebra systems. People tend to forget that now with Maxima and Axiom available in open-source form. But we used to be alone. We were this little rowing boat on a big ocean. Suddenly two huge titanic-sized ships named Axiom and Maxima came and floated next to us. Two huge ships faring next to us, and we are in the middle with our tiny little rowing boat named Yacas. These big ships suddenly showed up out of the blue!
The event of the arrival of two big competitors forced me to consider how to compete with them. Do we compete on their turf, or do we do something else? The two classic ways to compete are to compete on features (who has more features?), or to compete by providing something different. Maxima and Axiom have approximately 30 years under their belts. Hundreds of researchers have worked on it. They have both been commercial. Hundreds of man-years of work went in to them. Competing with them on their own turf might be a bad idea. Maxima is understood to be the most powerful system, but Axiom has another dream. Axioms dream is based on strong typing, and the promise of mathematically provable correct code as a consequence. Equally, Yacas will also have to find its niche, its area where it outshines the other systems, if it is to have a reason to exist.
Some other systems are focused on mathematical calculations of the brute-force kind. You have some simple boring repetitive task, and write a computer program specifically optimized for that calculation, and let the computer do the dull grunt work, because that is what computers are good at. This is not something Yacas will typically shine at, since clean code and maintainability are considered more important than raw performance in the Yacas project.
The thing Yacas development will focus on is ease of use. Ease of use is not something you can casually fake. If this is done right other systems can not easily copy it, because making a software program easy to use is hard work. You have to think about the computers people use, the software they have running on it, the operating system they run it on, the tasks they would typically want to perform, their level of knowledge of math and computer-related subjects, even the fonts they have installed. You want to make it as easy as possible for them to start using the system, preferably without having to install software. The web site and application have to be responsive. When they have the system running they should be able to do what they want to do without having to learn too much about the system. People will generally want to do a calculation, or learn some new mathematics. They don't want to learn Yacas-specific details per se. Using Yacas should be effortless in that they have to invest very little in order to start using it.
In a sense, ease of use has always been a focus for Yacas. I always wanted the system to be self-contained, easy to download, easy to install without external dependencies. Yacas was as self-contained as possible. It used its own numerics library, its own array and linked list classes, all so it would not have to depend on external libraries. After installation, the ideal was to only have to write a few lines of code to do complex calculations, in an easy to read programming language. Those are ease-of-use issues, and I have cared for them from the very inception of Yacas.
For the recent update of the web site I decided that we should use Javascript to make Yacas easier to use. Javascript is now supported by most browsers, it has been around for a long while, so almost every one has access to a computer with a browser with Javascript support. Javascript allows you to make dynamic web pages, where an application runs inside a web browser without needing a constant link to a web server to serve it pages. This causes the web page to feel much more responsive than if it had to get every page through a request to a server. The "on-line application" can be used immediately, without having to download or install anything, thereby removing one hurdle for people to start using the it. They can just run Yacas on-line, from any OS that has a Java and Javascript-capable browser. When entering the Yacas site, one is now one click away from actually using Yacas.
Javascript is used in combination with the Yacas Java applet to bring the on-line version of Yacas to life. One can now program on-line and run your program directly in the Java applet inside your browser, emulating the work-flow of an experienced user of Yacas. In addition, the Yacas web site now also offers an interactive tutorial using Javascript and Java to bring the examples to life. Also, there is a find utility written in Javascript which allows the user to find functions with accompanying descriptions and examples. The find utility allows the user to use the system without having to remember too much. Functions and their calling sequences can be looked up very quickly.
For the long term one has to worry about the maintainability of a system, if the system is to survive over the long haul. Will it still be useful in a few years time? Will it still run on future systems? Will it be easy to maintain by future generations?
The development mailing lists of the two systems Maxima and Axiom are interesting reads. Essentially, you have the next generation of maintainers of these systems communicating with each other there. The original authors have generally moved to greener pastures (or retired?). You have to understand that these systems are huge, and mathematical algorithms are (or can be) highly non-trivial. Taking over maintenance of such a system is not trivial! These more mature systems now seem to have run in to the problem of succession, where the next generation has to take over and maintain the code that was sometimes developed three decades ago, when memory was at a premium and every byte counted and you would rather use a variable name with one letter, and rather not have comments in the code. Looking at these systems gives us a glance at what lies ahead in the future of Yacas (if it survives the next 30 years like these systems have, impressively).
I had the problem of maintainability and succession in small with the Yacas project. I was always willing to give cvs write access to Yacas, to people whose coding expertise I had not checked yet. This resulted in people adding non-trivial parts to Yacas, which was really great because it made the system do more. However, there were now parts of the code I didn't know intimately. Sometimes I didn't agree with the way it was implemented either. But now it was in the system. Leaving it in was easier than removing it. This reduced maintainability from my standpoint. It is easier to maintain code you wrote yourself than it is to write code written by some one else, in another programming language, in another coding style. Most of the people making contributions have now left, leaving me with the task of maintaining what they contributed. Maintenance of parts that I don't understand will cause me to slow down as I have to delve in to understanding that part.
Because the code became harder for me to maintain, I have decided to do a big cleanup. If I am going to commit to maintaining this system for the next 50 or so years, I should be allowed to decide on what I will be maintaining. I need to be quick, flexible, efficient. Yacas needs to grow, become more useful. That is not going to happen if I get slowed down in to trying to understand obscure code. I am in the process of removing things that we don't need. It is funny to see that I can remove enormous amounts of files and Yacas still does what it used to do! It still passes all the tests! Apparently we didn't need plugins. Apparently we didn't need an fltk-based user interface. The list goes on. Removing big parts will also make it easier for others to understand the system, and will hopefully make the succession problem less severe for Yacas in 50 years.
The policy for accepting contributions has changed also. I have become more strict. I now reserve the right to referree, review and edit everything that goes in to the Yacas branch that I maintain. Every one is free to maintain a different branch, or an addition to Yacas, but control over the branch that I maintain is going to rest with me.
Contributions are very welcome. If you have any suggestions for improvements, please don't hesitate to send an email! This is about making it easier for you (yes, you) after all. I can not promise that I can accommodate every wish, but feedback on how the system can be improved is much appreciated. Feedback is a contribution too. I am interested in the types of calculations you want to do, problems you experience while using Yacas either on-line or off-line, or even plain simple bugs or typos in the manual. Yacas will change some more in the near future, and it can improve a lot with your help. If you are a good writer or expert on a specific topic in mathematics, contributed articles are also very welcome.
Releases are now very frequent, with a new release being made a couple of times each week. The idea behind this is that since there are a lot of improvements in the system, user interface, web log, and documentation and such, it would be a pity if others would have to wait in order to be able to use the new and improved version. People don't have to download and install anything any more in order to be able to use Yacas on-line. People who visit the web site use the version that is on the web site at that moment. Updating that version frequently means that people other than me have instant access to the latest version also.
Big changes have been made recently to Yacas to improve its ease of use and maintainability. I hope you enjoy the changes I made. The plan is to step up the effort and make more improvements in the near future. So watch this space!
Ayal
yacas-1.3.6/docs/yacaslogo.png 0000644 0001750 0001750 00000341557 12262355100 016133 0 ustar muammar muammar ‰PNG IHDR € [î¢ bKGD ÿ ÿ ÿ ½§“ pHYs šœ tIMEÞ(»´ – IDATxÚìÝk°lgyøç]ݽ÷9ºœs$ÎÑ’ÀQpDì )®LQEœ¨ Lœ¢R)¾Ä.‡2;b*O2N\qü!©JÕ!‰q*l&ÆæÊ*Lf"€ˆd#táb.çì^ë½V÷».Ý{!0Ñþý¨¦»W_öåì~õáý¯ÿ ß;’_Á÷–÷½=žúð£ñܧ]Ϭ›¸9E<-¥8›R\Q×qcDTuMޏ»®#–uÜ¿\ƃË:þ çøÂ~%>¿·ˆÏüõŸ{ýFvûÿ꺧^|4?÷ÌSçÏlê¸9¥xZ¤8›bµî6MÜ9ª¦ÉMDÜÝÔÍ2ß_×ùÁf_øÆ½ËÏÏé3ïø™û¬» ÀÿP„þ}â7bÖ4ñ¼Û?¯ø“ÏŽ¾2nÛ[Ä U©ªÚœö_(çˆÈM^ÝnšÍ¥n"Úð@,—ˈƒƒÈ^ˆ{¾ñP|âÎ/ÆÇŸýŒø`ÎqÇ_û[QûÍÇÕßzï ³\ÇóîþÔ…W\÷ý{/:qEuÛ|/ݪH)¥Hƒÿ*æ‘sŽÈ¹]ss“Wëo£ D}Q/s>x¬¹çчšOÜ÷Ń_óŒÅsÄ¿òæû¬» À÷,¡ï²ÿú›±¸çÞxÙU§ãÕO9?ºXÄùÅ