X-Git-Url: https://www.ginac.de/ginac.git//ginac.git?p=ginac.git;a=blobdiff_plain;f=doc%2Ftutorial%2Fginac.texi;h=73e1547bc975980a33bb7692cc647826f1fe86c6;hp=96ecfc11b1bbc7a7e75d4152453062230bb2a146;hb=9d22692238af9dd0875b5ed849e6ce3a3d503a87;hpb=fb38db2d3476bf411940606824ef976187bf58f2

diff --git a/doc/tutorial/ginac.texi b/doc/tutorial/ginac.texi
index 96ecfc11..73e1547b 100644
--- a/doc/tutorial/ginac.texi
+++ b/doc/tutorial/ginac.texi
@@ -1171,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
@@ -1302,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
@@ -1864,6 +1866,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
@@ -1892,16 +1906,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}
@@ -2264,7 +2268,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