[GiNaC-list] Bug with evalm()?

[Ondrej Certik]

> I agree with you completely: it's much better to not provide evalm() for
> anything but matrix (frankly, I think all those eval* things are plain
> evil).  But with current [sloppy] type system such kind of interface
> is hardly ever possible. :(

Hi, this is the reason why GiNaC is using ex - so that it
automatically calls eval(). We had this discussion already - it's
because of C++, memory handling, speed and automatic evaluation.

But in Python I recently found a very elegant solution to this (in SymPy):
I also have eval() but it's called automatically right after the
construtor and if it returns a different instance, then that instance
is returned.
Example:

e = Add(x,x)

however "e" contains Mul(2,x), because in python you can make the
Add.eval() get called right after the Add constructor. Thus Add.eval()
evaluates x+x to 2*x and returns Mul(2,x). So in the end Add(x,x) is
in fact the same as Mul(2,x).

And in the end, you don't have to think about eval() at all. And you
don't need ex (python is handling the garbage collection
automatically).

But soon I would like to implement the core of SymPy in C++ for speed
and I am curious, if my system is going to be faster or slower than
GiNaC.

my question is this: do you know, if it is possible to implement the
above procedure in C++? and how? maybe using some macros? Because it
is certainly non standard, that you construct an instance of some
class Add(x,x) and it returns an instance of a completely different
class Mul(2,x).

Thanks,
Ondrej