7. A Comparison With Other CAS

This chapter will give you some information on how GiNaC compares to other, traditional Computer Algebra Systems, like Maple, Mathematica or Reduce, where it has advantages and disadvantages over these systems.

7.1 Advantages

GiNaC has several advantages over traditional Computer Algebra Systems, like

• familiar language: all common CAS implement their own proprietary grammar which you have to learn first (and maybe learn again when your vendor decides to `enhance' it). With GiNaC you can write your program in common C++, which is standardized.

• structured data types: you can build up structured data types using structs or classes together with STL features instead of using unnamed lists of lists of lists.

• strongly typed: in CAS, you usually have only one kind of variables which can hold contents of an arbitrary type. This 4GL like feature is nice for novice programmers, but dangerous.
• development tools: powerful development tools exist for C++, like fancy editors (e.g. with automatic indentation and syntax highlighting), debuggers, visualization tools, documentation generators...

• modularization: C++ programs can easily be split into modules by separating interface and implementation.

• price: GiNaC is distributed under the GNU Public License which means that it is free and available with source code. And there are excellent C++-compilers for free, too.
• extendable: you can add your own classes to GiNaC, thus extending it on a very low level. Compare this to a traditional CAS that you can 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.

• 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 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 Cint C++ interpreter has been put together (called GiNaC-cint) that allows an interactive scripting interface consistent with the C++ language. It is available from the usual GiNaC FTP-site.

• seamless integration: it is somewhere between difficult and impossible to call CAS functions from within a program written in C++ or any other programming language and vice versa. With GiNaC, your symbolic routines are part of your program. You can easily call third party libraries, e.g. for numerical evaluation or graphical interaction. All other approaches are much more cumbersome: they range from simply ignoring the problem (i.e. Maple) to providing a method for `embedding' the system (i.e. Yacas).

• efficiency: often large parts of a program do not need symbolic calculations at all. Why use large integers for loop variables or arbitrary precision arithmetics where int and double are sufficient? For pure symbolic applications, GiNaC is comparable in speed with other CAS.

7.2 Disadvantages

Of course it also has some disadvantages:

• advanced features: GiNaC cannot compete with a program like Reduce which exists for more than 30 years now or Maple which grows since 1981 by the work of dozens of programmers, with respect to mathematical features. Integration, factorization, non-trivial simplifications, limits etc. are missing in GiNaC (and are not planned for the near future).

• portability: While the GiNaC library itself is designed to avoid any platform dependent features (it should compile on any ANSI compliant C++ compiler), the currently used version of the CLN library (fast large integer and arbitrary precision arithmetics) can only by compiled without hassle on systems with the C++ compiler from the GNU Compiler Collection (GCC).(3) GiNaC uses recent language features like explicit constructors, mutable members, RTTI, dynamic_casts and STL, so ANSI compliance is meant literally. Recent GCC versions starting at 2.95.3, although itself not yet ANSI compliant, support all needed features.

7.3 Why C++?

Why did we choose to implement GiNaC in C++ instead of Java or any other language? C++ is not perfect: type checking is not strict (casting is possible), separation between interface and implementation is not complete, object oriented design is not enforced. The main reason is the often scolded feature of operator overloading in C++. While it may be true that operating on classes with a + operator is rarely meaningful, it is perfectly suited for algebraic expressions. Writing as 3*x+5*y instead of x.times(3).plus(y.times(5)) looks much more natural. Furthermore, the main developers are more familiar with C++ than with any other programming language.