Dear Alexei,
"SA" == Sheplyakov Alexei <varg@theor.jinr.ru> writes:
SA> GiNaC offers ex::map() method for implementation of such custom SA> evaluation rules. Unfortunately I cannot see how to use map() for simplification of automatic evaluations for derived classes, could you give me a hint? SA> Adding more methods to the `basic' class does not sound like SA> good idea to me. What if someone implements custom evaluation SA> rules, say, for the `mul' class? E.g. foosymbol times SA> barfunction is always zero. Add even more methods to basic? There is a limited number of evaluations (add(), mul(), ncmul()) so only three additional virtual methods will cover any desire in automatic evaluation. SA> Likewise, I think adding even more stuff to info_flags is bad SA> idea. However this makes a check for existence of an additional evaluation method much quicker. Are there a better way to check this? SA> Spamming to std{out,err} is a MORTAL SIN. NEVER, EVER do this. SA> Either return the expression unevaluated or throw an exception. Alright, I am not insisting on the warning message. Throwing an exception is not appropriate since nothing dangerous happens. SA> This slows down a bit evaluation of *every* power expression, SA> including those which do not provide such a method. GiNaC's SA> performance is not exactly brilliant, why reduce it even more? However it make much-much more faster evaluation of expressions which do contain such object. For example, calculations in two dimensions can be done now without usage Clifford algebras and *very* time-expensive non-commutativity. In my opinion it is a fair exchange for slowing down *a bit* for other calls. Everything in this world come at a price. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/