This is a tutorial that documents GiNaC @value{VERSION}, an open
framework for symbolic computation within the C++ programming language.
-Copyright (C) 1999-2000 Johannes Gutenberg University Mainz, Germany
+Copyright (C) 1999-2001 Johannes Gutenberg University Mainz, Germany
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1999-2000 Johannes Gutenberg University Mainz, Germany
+Copyright @copyright{} 1999-2001 Johannes Gutenberg University Mainz, Germany
@sp 2
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
@section License
The GiNaC framework for symbolic computation within the C++ programming
-language is Copyright @copyright{} 1999-2000 Johannes Gutenberg
+language is Copyright @copyright{} 1999-2001 Johannes Gutenberg
University Mainz, Germany.
This program is free software; you can redistribute it and/or
@subsection Checking expression types
@cindex @code{is_ex_of_type()}
+@cindex @code{ex_to_numeric()}
+@cindex @code{ex_to_@dots{}}
+@cindex @code{Converting ex to other classes}
@cindex @code{info()}
Sometimes it's useful to check whether a given expression is a plain number,
bool ex::info(unsigned flag);
@end example
+When the test made by @code{is_ex_of_type()} returns true, it is safe to
+call one of the functions @code{ex_to_@dots{}}, where @code{@dots{}} is
+one of the class names (@xref{The Class Hierarchy}, for a list of all
+classes). For example, assuming @code{e} is an @code{ex}:
+
+@example
+@{
+ @dots{}
+ if (is_ex_of_type(e, numeric))
+ numeric n = ex_to_numeric(e);
+ @dots{}
+@}
+@end example
+
@code{is_ex_of_type()} allows you to check whether the top-level object of
an expression @samp{e} is an instance of the GiNaC class @samp{t}
(@xref{The Class Hierarchy}, for a list of all classes). This is most useful,
@item @code{crational_polynomial}
@tab @dots{}a polynomial with (possibly complex) rational coefficients (such as @math{2/3+7/2*I})
@item @code{rational_function}
-@tab @dots{}a rational function
+@tab @dots{}a rational function (@math{x+y}, @math{z/(x+y)})
+@item @code{algebraic}
+@tab @dots{}an algebraic object (@math{sqrt(2)}, @math{sqrt(x)-1})
@end multitable
@end cartouche
@cindex simplification
@cindex temporary replacement
-Some basic from of simplification of expressions is called for frequently.
+Some basic form of simplification of expressions is called for frequently.
GiNaC provides the method @code{.normal()}, which converts a rational function
into an equivalent rational function of the form @samp{numerator/denominator}
where numerator and denominator are coprime. If the input expression is already
@tab exponential function
@item @code{log(x)}
@tab natural logarithm
+@item @code{Li2(x)}
+@tab Dilogarithm
@item @code{zeta(x)}
@tab Riemann's zeta function
@item @code{zeta(n, x)}
@cindex branch cut
For functions that have a branch cut in the complex plane GiNaC follows
-the conventions for C++ as defined in the ANSI standard. In particular:
-the natural logarithm (@code{log}) and the square root (@code{sqrt})
-both have their branch cuts running along the negative real axis where
-the points on the axis itself belong to the upper part.
+the conventions for C++ as defined in the ANSI standard as far as
+possible. In particular: the natural logarithm (@code{log}) and the
+square root (@code{sqrt}) both have their branch cuts running along the
+negative real axis where the points on the axis itself belong to the
+upper part (i.e. continuous with quadrant II). The inverse
+trigonometric and hyperbolic functions are not defined for complex
+arguments by the C++ standard, however. In GiNaC we follow the
+conventions used by CLN, which in turn follow the carefully designed
+definitions in the Common Lisp standard. It should be noted that this
+convention is identical to the one used by the C99 standard and by most
+serious CAS. It is to be expected that future revisions of the C++
+standard incorporate these functions in the complex domain in a manner
+compatible with C99.
@node Input/Output, Extending GiNaC, Built-in Functions, Methods and Functions
implement does have a pole somewhere in the complex plane, you need to
write another method for Laurent expansion around that point.
-Now that all the ingrediences for @code{cos} have been set up, we need
+Now that all the ingredients for @code{cos} have been set up, we need
to tell the system about it. This is done by a macro and we are not
going to descibe how it expands, please consult your preprocessor if you
are curious:
AC_PROG_INSTALL
AC_LANG_CPLUSPLUS
-AM_PATH_GINAC(0.4.0, [
+AM_PATH_GINAC(0.7.0, [
LIBS="$LIBS $GINACLIB_LIBS"
- CPPFLAGS="$CFLAGS $GINACLIB_CPPFLAGS"
+ CPPFLAGS="$CPPFLAGS $GINACLIB_CPPFLAGS"
], AC_MSG_ERROR([need to have GiNaC installed]))
AC_OUTPUT(Makefile)
The only command in this which is not standard for automake
is the @samp{AM_PATH_GINAC} macro.
-That command does the following:
-
-@display
-If a GiNaC version greater than 0.4.0 is found, adds @env{$GINACLIB_LIBS} to
-@env{$LIBS} and @env{$GINACLIB_CPPFLAGS} to @env{$CPPFLAGS}. Otherwise, dies
-with the error message `need to have GiNaC installed'
-@end display
+That command does the following: If a GiNaC version greater or equal
+than 0.7.0 is found, then it adds @env{$GINACLIB_LIBS} to @env{$LIBS}
+and @env{$GINACLIB_CPPFLAGS} to @env{$CPPFLAGS}. Otherwise, it dies with
+the error message `need to have GiNaC installed'
And the @file{Makefile.am}, which will be used to build the Makefile.
git://www.ginac.de / ginac.git / blobdiff