Hello, On Sat, Oct 28, 2006 at 08:57:27PM +0100, kisilv@maths.leeds.ac.uk wrote:
My concerns are rather that rooting something as specialized inside the class hierarchy will not be useful enough but open the floodgates for much more specialized ideas and make the code even harder to understand for novices.
Once more: nothing specialised is intended for the GiNaC core classes. This is only a pair of wires leading outside of the kernel where an end user can connect his own devices to.
What if someone else wants to insert another "pair of wires" to implement another weird feature? And than one more... making the whole thing more cumbersome and slow (yes, two extra useless method calls do not really improve the performance). Please stop adding more methods to core classes (unless there is a _really_ good reason for this), there are already much of them (evalm, evalf, eval_integ, eval_indexed, eval_ncmul). Pretty please.
Have you tried using subs or custom tree traversers for your purpose? (Along the ideas sketched in the FAQ, I mean.)
Imagine that any calculation with complex numbers will require manual substitution of I^2=-1, will it be convenient?
It depends. E.g., for someone who hardly ever uses complex numbers this is not a big deal. On the other hand,
+It is not unusual to use some objects which have special properties with +respect to exponentiation. For example, if a symbol @code{s} may take +only values @math{-1} or @math{1} then @math{s^2=1}.
This sounds like modular arithmetics (in Z_3, to be more specific). It would be nice if GiNaC had support of such a thing. CLN has modular integers, so _probably_ it is possible to do such calculations in more natural way (so that simplification of this kind are handled by CLN, just as I^2 -> -1).
The purpose of the extension is just to let a user a freedom to make some such simple rules work automatically.
IMHO, GiNaC's purpose is somewhat inverse: not to give as much freedom as possible, but to restrict the freedom to do some specific things effectively. BTW, other tools used by [particle] physicists (e.g. FORM) are even more restrictive, and there are very few complaints (if any) about that.
It is the responsibility of the end user to decide himself what kind of rules are suitable for his task.
The main point is not validity of those rules. Your implementation complicates things even for those who are not going to use any of such rules.
I think that this is a nice way to keep GiNaC kernel small and tidy and yet suitable for very wide set of questions.
IMHO, this is exaclty the way to make it more cumbersome without any positive side effects. Best regards, Alexei -- All science is either physics or stamp collecting.