Questions re GiNaC design

[Richard B. Kreckel]

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 at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>