Hi! You probably won't see it on national TV but it's new, improved, and finger-licking good. :-) GiNaC 1.0.5 is binary compatible to 1.0.x and has - a slightly more versatile degree()/coeff()/collect() facility - a bugfix for the output of imaginary numbers As usual, you can get it from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/
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.
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/>
On Tue, 29 Jan 2002 12:45:57 +0100 (CET) "Richard B. Kreckel" <kreckel@thep.physik.uni-mainz.de> wrote:
Now the question: why did choose expression ex to be unspecified?
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>.
Thanks for the reference. It was interesting reading, but I was not totally sure whether Richard Fateman also expects too much, e.g. when he writes "... Could we anticipate new results such as the invention of the Risch integration algorithm ..." (With a diagonal argument you could probably disprove such a conjecture, if it were mad.) But also on the practical side, he does not seem to realise that many "facts" of mathematics cannot be constructed, either because no algorithm has been found or because no algorithm can be found. Even the simple test whether something is zero can only be answered in special situations. (You have to give an algorithm that finishes, not to speak of the complexity it might have.) So far I have found for most of my little problems a solution, maybe not an elegant one, but one that seems to work. Maybe one pattern matching situation could find a different implementation in a future release (I am aware of your statement that pattern matching is purely syntactic): find(x^2, pow(x,wild())) will return {x^2} find(x, pow(x,wild())) will return {} whereas find(x, pow(x,1)) will return {x} I would prefer if the latter two were equal and == {x} Cheers, H.P.
participants (3)
-
Christian Bauer
-
Hans Peter W�rmli
-
Richard B. Kreckel