<\body> <\enumerate> The symbolic types of should understood to be mainly syntactic. For instance, we systematically use the rules <\eqnarray*> >||*a>>|||>>>> which can be incorrect when , and are complex numbers, but which are correct in asuitable differential algebra. It should be noticed that equality testing is syntactic: we do not require that equality in all algebraic models can be detected syntactically (even though our normal forms should do as good as a job as possible). Some of the variants for symbolic expressions implement additional heuristic methods for zero-testing. This sometimes gives rise to massive simplifications, but may lead to incorrect results. More precisely, the following kinds of incorrectness can be encountered: <\enumerate> The semantics if coherent in itself but not compatible with the syntactic semantics described above. For instance, we may use evaluation at points for heuristic zero-tests, for which the rules() and() may be violated. When using a strict ball evaluation policy, we may safely detect inequalities (modulo the above remark). However, many expressions, such as >)>, typically evaluate to a ball containing the whole space, and will be assimilated to zero by a zero-test. When replacing subexpressions such as >)> by new variables, a positive answer to a zero-test usually means that the expression is really zero. However, it gets easier to miss certain identities, since only part of the algebraic/analytic structure is preserved. Even though the symbolic types do not rely on the evaluator, function application() is not acompletely trivial operation. First of all, we have implemented arithmetic on functions: <\eqnarray*> ||c>>|||>|||>>> The standard functions >, >, , etc. also receive special treatment. For instance, the expression evaluates to . The internal representation and the printed form do not need to coincide. For instance, sums can be kept in a rather expanded form; when printing them, some factoring may take place in order to enhance readability. Of course, such factoring would be to expensive during computations, but may be have a minor cost when printing. . If you don't have this file, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.>