Hi, On Mon, 28 Jan 2002, Hans Peter Würmli wrote:
Sorry, should I ask questions that are answered somewhere. I browsed through most of the tutorial, the "Introduction to the GiNaC Framework ..." and GiNaC's wishlist. My own motivation is rather doing algorithmic algebra than physics and being able to make use of your choice of C++.
The situation I stumble again and again in GiNaC is that "ex" expressions seem to make implicit assumption about the algebraic structure I am in. It is comparable to the implicit type conversions of C (that C++ unfortunately inherited). For example, if the coefficients of a polynomial are seen as integers, it is assumed that the splitting field is contained in C. But it could also be a polynomial over a finite field, or one might be interested in p-adic extensions. I checked, how GAP handles it. There you would have to declare an indeterminate x as indeterminate over some specific ring.
Now the question: why did choose expression ex to be unspecified? Specified expressions would probably have a definition like
template <class T> class ex { ... }
with a constructor
ex(const lst & s, ...)
that would require a list of symbols, being the indeterminates. ex<T> would then be implemented for abstract structures T like groups, rings, fields, algebras and specialisations like integers, rationals, finite fields etc. The syntax and substitution rules of the expressions could then differ according to what is allowed and possible in T. The semantics of such expressions would also always be clear and would allow for specialised algorithms.
I ask this question because I am interested to know how you vision the future evolution of GiNaC. I cannot commit myself, but will be happy to contribute as much (or little) as I can.
Good question. Such a hierarchic algebraic approach would make some things clearer. Mathematicians frequently seem to favor it but they tend to seep the implementation problems under the rug. Why didn't we do it? Because designing and implementing such a thing would have been much more work and we needed to use the library and have it run fast and we simply had not enough spare man-years lying around. Richard Fateman once wrote an interesting comparison betweeen the two approaches: <http://http.cs.berkeley.edu/~fateman/papers/asmerev94.ps>. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>