- New example in Tour of GiNaC about exact radicals.

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

diff --git a/doc/tutorial/ginac.texi b/doc/tutorial/ginac.texi
index 20d7c5440cc0c884197e8abf4c7f053efeb86ba0..a47e7cadaf39c0e813708a316500cd43d5e9ce30 100644 (file)
--- a/doc/tutorial/ginac.texi
+++ b/doc/tutorial/ginac.texi
@@ -280,8 +280,23 @@ integers:
 1/3
 @end example
 
-All numbers occuring in GiNaC's expressions can be converted into floating
-point numbers with the @code{evalf} method, to arbitrary accuracy:
+Exact numbers are always retained as exact numbers and only evaluated as
+floating point numbers if requested.  For instance, with numeric
+radicals is dealt pretty much as with symbols.  Products of sums of them
+can be expanded:
+
+@example
+> expand((1+a^(1/5)-a^(2/5))^3);
+1+3*a+3*a^(1/5)-5*a^(3/5)-a^(6/5)
+> expand((1+3^(1/5)-3^(2/5))^3);
+10-5*3^(3/5)
+> evalf((1+3^(1/5)-3^(2/5))^3);
+0.33408977534118624238
+@end example
+
+The function @code{evalf} that was used above converts any number in
+GiNaC's expressions into floating point numbers.  This can be done to
+arbitrary predefined accuracy:
 
 @example
 > evalf(1/7);
@@ -545,21 +560,24 @@ takes to compile GiNaC depends not only on the speed of your machines
 but also on other parameters, for instance what value for @env{CXXFLAGS}
 you entered.  Optimization may be very time-consuming.
 
-Just to make sure GiNaC works properly you may run a simple test
-suite by typing
+Just to make sure GiNaC works properly you may run a collection of
+regression tests by typing
 
 @example
 $ make check
 @end example
 
-This will compile some sample programs, run them and compare the output
-to reference output. Each of the checks should return a message @samp{passed}
-together with the CPU time used for that particular test.  If it does
-not, something went wrong.  This is mostly intended to be a QA-check
-if something was broken during the development, not a sanity check
-of your system.  Another intent is to allow people to fiddle around
-with optimization.  If @acronym{CLN} was installed all right
-this step is unlikely to return any errors.
+This will compile some sample programs, run them and check the output
+for correctness.  The regression tests fall in three categories.  First,
+the so called @emph{exams} are performed, simple tests where some
+predefined input is evaluated (like a pupils' exam).  Second, the
+@emph{checks} test the coherence of results among each other with
+possible random input.  Third, some @emph{timings} are performed, which
+benchmark some predefined problems with different sizes and display the
+CPU time used in seconds.  Each individual test should return a message
+@samp{passed}.  This is mostly intended to be a QA-check if something
+was broken during development, not a sanity check of your system.
+Another intent is to allow people to fiddle around with optimization.
 
 Generally, the top-level Makefile runs recursively to the
 subdirectories.  It is therfore safe to go into any subdirectory