Recommendations for Improvement

Even if Maple is a good package there are several reasons for concern (see also Maple's Users Group on the Internet):

• Bugs were found in Maple's routines for defining new operators and for making assumptions about them.
• Support from the Maple developers is very poor and leaves a lot to be desired. This impression is shared by many users and can be verified by taking a look at the Maple Users Group.
• Maple bugs are poorly documented, and developers seem not to have any systematic approach to fixing them.
• Bugs seem to be history-dependent and what works on one release, might not on the next.

New implementations of LTP could rely on GiNaC [53], which is an open framework for symbolic computations recently developed in the C++ programming language. GiNaC extends the well established and standardized C++ language by some fundamental symbolic capabilities, and thus constitutes a convenient alternative for large-scale projects in which both numerical and symbolic calculations are required. Another option would be to employ Reduce [54], which is a CAS with more than 30 years of development. Reduce also has a basic function called operator function that allows the declaration of new user-defined operators (this function is equivalent to define in Maple). Parts in an expression can be accessed in Reduce by means of the parts function (op function in Maple). This features would allow to easily implement LTP using Reduce. Like GiNaC, Reduce is open source, however it is based on Lisp, which might not be so appealing as C++. There are other CAS, however they do not provide adequate facilities to declare new operators, which is a key element in the creation of a software package like this. For this and other reasons that would be too extense to discuss here, other CAS are not advisable alternatives. The reader is referred to [55] and [56] for further information about CAS and related information.