some words about the new function registration macro

[ginac.git] / doc / tutorial / ginac.texi

diff --git a/doc/tutorial/ginac.texi b/doc/tutorial/ginac.texi
index 7e3b98a35f6eb67ce6064e23acd8e6a0461dc68c..1b81df503efe922ecfa3fcc7799890279ea3f60b 100644 (file)
--- a/doc/tutorial/ginac.texi
+++ b/doc/tutorial/ginac.texi
@@ -1752,7 +1752,7 @@ instance are then handled automatically by @code{basic::diff} and
 @code{ex::diff}):
 
 @example
-static ex cos_derive(const ex & x, unsigned diff_param)
+static ex cos_deriv(const ex & x, unsigned diff_param)
 @{
     return -sin(x);
 @}
@@ -1773,14 +1773,20 @@ going to descibe how it expands, please consult your preprocessor if you
 are curious:
 
 @example
-REGISTER_FUNCTION(cos, cos_eval, cos_evalf, cos_derive, 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 used for calling it and for
-output.  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
+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
@@ -1866,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
@@ -1894,18 +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).
-Second, as a more consistent approach, an interactive interface to the
-@acronym{CINT} C++ interpreter is under development (called
-@acronym{GiNaC-cint}) that will allow an interactive interface
-consistent with the C++ language.
-
 @item
 advanced features: GiNaC cannot compete with a program like
 @emph{Reduce} which exists for more than 30 years now or @emph{Maple}