]> www.ginac.de Git - ginac.git/blobdiff - doc/tutorial/ginac.texi
some words about the new function registration macro
[ginac.git] / doc / tutorial / ginac.texi
index 04b8908ddf536511abf27102e3971fc302033441..1b81df503efe922ecfa3fcc7799890279ea3f60b 100644 (file)
@@ -215,11 +215,11 @@ generates Hermite polynomials in a specified free variable.
 #include <ginac/ginac.h>
 using namespace GiNaC;
 
-ex HermitePoly(symbol x, int deg)
+ex HermitePoly(const symbol & x, int n)
 @{
-    ex HKer=exp(-pow(x,2));
-    // uses the identity H_n(x) == (-1)^n exp(x^2) (d/dx)^n exp(-x^2) 
-    return normal(pow(-1,deg) * diff(HKer, x, deg) / HKer);
+    ex HKer=exp(-pow(x, 2));
+    // uses the identity H_n(x) == (-1)^n exp(x^2) (d/dx)^n exp(-x^2)
+    return normal(pow(-1, n) * diff(HKer, x, n) / HKer);
 @}
 
 int main()
@@ -422,19 +422,21 @@ installation.
 @c    node-name, next, previous, up
 @section Prerequisites
 
-In order to install GiNaC on your system, some prerequisites need
-to be met.  First of all, you need to have a C++-compiler adhering to
-the ANSI-standard @cite{ISO/IEC 14882:1998(E)}.  We used @acronym{GCC} for
+In order to install GiNaC on your system, some prerequisites need to be
+met.  First of all, you need to have a C++-compiler adhering to the
+ANSI-standard @cite{ISO/IEC 14882:1998(E)}.  We used @acronym{GCC} for
 development so if you have a different compiler you are on your own.
 For the configuration to succeed you need a Posix compliant shell
 installed in @file{/bin/sh}, GNU @command{bash} is fine.  Perl is needed
-by the built process as well, since some of the source files are automatically
-generated by Perl scripts.  Last but not least, Bruno Haible's library
-@acronym{CLN} is extensively used and needs to be installed on your system.
-Please get it from @uref{ftp://ftp.santafe.edu/pub/gnu/} or from
-@uref{ftp://ftp.ilog.fr/pub/Users/haible/gnu/, Bruno Haible's FTP site}
-(it is covered by GPL) and install it prior to trying to install GiNaC.
-The configure script checks if it can find it and if it cannot
+by the built process as well, since some of the source files are
+automatically generated by Perl scripts.  Last but not least, Bruno
+Haible's library @acronym{CLN} is extensively used and needs to be
+installed on your system.  Please get it either from
+@uref{ftp://ftp.santafe.edu/pub/gnu/}, from
+@uref{ftp://ftpthep.physik.uni-mainz.de/pub/gnu/, GiNaC's FTP site} or
+from @uref{ftp://ftp.ilog.fr/pub/Users/haible/gnu/, Bruno Haible's FTP
+site} (it is covered by GPL) and install it prior to trying to install
+GiNaC.  The configure script checks if it can find it and if it cannot
 it will refuse to continue.
 
 
@@ -1169,6 +1171,8 @@ They are created by simply using the C++ operators @code{==}, @code{!=},
 @xref{Built-in functions}, for examples where various applications of
 the @code{.subs()} method show how objects of class relational are used
 as arguments.  There they provide an intuitive syntax for substitutions.
+They can also used for creating systems of equations that are to be
+solved for unknown variables.
 
 
 @node Archiving, Important Algorithms, Relations, Basic Concepts
@@ -1300,7 +1304,7 @@ would require @code{A=x+1; subs(A,x==2);} (after proper declaration of
 @code{A:=x^2+3; coeff(A,x,0);} (GiNaC: @code{A=pow(x,2)+3;
 coeff(A,x,0);}) it is clear that MapleV is not trying to be consistent
 here.  Also, users of MuPAD will in most cases feel more comfortable
-with GiNaC's convention.  All function wrappers are always implemented
+with GiNaC's convention.  All function wrappers are implemented
 as simple inline functions which just call the corresponding method and
 are only provided for users uncomfortable with OO who are dead set to
 avoid method invocations.  Generally, nested function wrappers are much
@@ -1536,7 +1540,7 @@ using namespace GiNaC;
 ex EulerNumber(unsigned n)
 @{
     symbol x;
-    ex generator = pow(cosh(x),-1);
+    const ex generator = pow(cosh(x),-1);
     return generator.diff(x,n).subs(x==0);
 @}
 
@@ -1729,25 +1733,28 @@ static ex cos_eval_method(const ex & x)
 @cindex @code{hold()}
 @cindex evaluation
 The last line returns @code{cos(x)} if we don't know what else to do and
-stops a potential recursive evaluation by saying @code{.hold()}.  We
+stops a potential recursive evaluation by saying @code{.hold()}, which
+sets a flag to the expression signalint that it has been evaluated.  We
 should also implement a method for numerical evaluation and since we are
 lazy we sweep the problem under the rug by calling someone else's
 function that does so, in this case the one in class @code{numeric}:
 
 @example
-static ex cos_evalf_method(const ex & x)
+static ex cos_evalf(const ex & x)
 @{
-    return sin(ex_to_numeric(x));
+    return cos(ex_to_numeric(x));
 @}
 @end example
 
-Differentiation will surely turn up and so we need to tell
-@code{sin} how to differentiate itself:
+Differentiation will surely turn up and so we need to tell @code{cos}
+what the first derivative is (higher derivatives (@code{.diff(x,3)} for
+instance are then handled automatically by @code{basic::diff} and
+@code{ex::diff}):
 
 @example
-static ex cos_diff_method(const ex & x, unsigned diff_param)
+static ex cos_deriv(const ex & x, unsigned diff_param)
 @{
-    return cos(x);
+    return -sin(x);
 @}
 @end example
 
@@ -1766,20 +1773,27 @@ going to descibe how it expands, please consult your preprocessor if you
 are curious:
 
 @example
-REGISTER_FUNCTION(cos, cos_eval_method, cos_evalf_method, cos_diff, NULL);
+REGISTER_FUNCTION(cos, eval_func(cos_eval).
+                       evalf_func(cos_evalf).
+                       derivative_func(cos_deriv));
 @end example
 
-The first argument is the function's name, the second, third and fourth
-bind the corresponding methods to this objects and the fifth is a slot
-for inserting a method for series expansion.  (If set to @code{NULL} it
-defaults to simple Taylor expansion, which is correct if there are no
-poles involved.  The way GiNaC handles poles in case there are any is
-best understood by studying one of the examples, like the Gamma function
-for instance.  In essence the function first checks if there is a pole
-at the evaluation point and falls back to Taylor expansion if there
-isn't.  Then, the pole is regularized by some suitable transformation.)
-Also, the new function needs to be declared somewhere.  This may also be
-done by a convenient preprocessor macro:
+The first argument is the function's name used for calling it and for
+output. The second binds the corresponding methods as options to this
+object. Options are separated by a dot and can be given in an arbitrary
+order. GiNaC functions understand several more options which
+are always specified as @code{.option(params)}, for example a method
+for series expansion @code{.series_func(cos_series)}. If no series
+expansion method is given, GiNaC defaults to simple Taylor
+expansion, which is correct if there are no poles involved (as is
+the case for the @code{cos} function).  The way
+GiNaC handles poles in case there are any is best understood by studying
+one of the examples, like the Gamma function for instance.  In essence
+the function first checks if there is a pole at the evaluation point and
+falls back to Taylor expansion if there isn't.  Then, the pole is
+regularized by some suitable transformation.)  Also, the new function
+needs to be declared somewhere.  This may also be done by a convenient
+preprocessor macro:
 
 @example
 DECLARE_FUNCTION_1P(cos)
@@ -1858,6 +1872,18 @@ usually only extend on a high level by writing in the language defined
 by the parser.  In particular, it turns out to be almost impossible to
 fix bugs in a traditional system.
 
+@item
+multiple interfaces: Though real GiNaC programs have to be written in
+some editor, then be compiled, linked and executed, there are more ways
+to work with the GiNaC engine.  Many people want to play with
+expressions interactively, as in traditional CASs.  Currently, two such
+windows into GiNaC have been implemented and many more are possible: the
+tiny @command{ginsh} that is part of the distribution exposes GiNaC's
+types to a command line and second, as a more consistent approach, an
+interactive interface to the @acronym{Cint} C++ interpreter has been put
+together (called @acronym{GiNaC-cint}) that allows an interactive
+scripting interface consistent with the C++ language.
+
 @item
 seemless integration: it is somewhere between difficult and impossible
 to call CAS functions from within a program written in C++ or any other
@@ -1886,16 +1912,6 @@ Of course it also has some disadvantages:
 
 @itemize @bullet
 
-@item
-not interactive: GiNaC programs have to be written in an editor,
-compiled and executed.  You cannot play with expressions interactively.
-However, such an extension is not inherently forbidden by design.  In
-fact, two interactive interfaces are possible: First, a shell that
-exposes GiNaC's types to a command line can readily be written (the tiny
-@command{ginsh} that is part of the distribution being an example) and
-second, as a more consistent approach we are working on an integration
-with the @acronym{CINT} C++ interpreter.
-
 @item
 advanced features: GiNaC cannot compete with a program like
 @emph{Reduce} which exists for more than 30 years now or @emph{Maple}
@@ -2258,7 +2274,7 @@ name of the executable
 
 @item
 If you move the GiNaC package from its installed location,
-you will need either need to modify @command{ginac-config} script
+you will either need to modify @command{ginac-config} script
 manually to point to the new location or rebuild GiNaC.
 
 @end itemize