[GiNaC-list] Python wrapper for a GiNaC derived library

[Chris Dams]

Dear Ondrej and others,

On Mon, 31 Jul 2006, Ondrej Certik wrote:

> It seems to me that easiest way is to have one parent class ("basic")
> and derive everything from it (which ginac does in fact). And you
> return just a "basic". Wheter it is in fact "add", or "mul", or
> something else, will be determined at runtime. i.e.
> basic e=(a+b)^2

Yes, that would be easiest. However, I'm a bit afraid that it will not
really work in C++. A power is a thing that has a basis and and exponent.
So, I suppose these would need to be stored in basic. If power(a+b, 2)  
actually returns an object of type "power" it would get stripped of its
non-basic members by the construction that you give.

I sometimes wonder if it wouldn't be better if functions (not
constructors)  were used to construct our objects. Then there would be a
function ex power(basis, exponent) and a class that would have to be
called differently, say power_class. The function could dynamically
allocate the object of type power_class. With this idea it would no longer
be necessary to duplicate objects from stack to heap as is done now. This
is not simpler, but I suppose it is more efficient. Maybe some
cleverly-chosen macros could make it easier. Well, maybe it is simpler 
because the user will only see less objects derived from basic and only 
exes instead.
 
Best wishes,
Chris