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

Chris Dams Chris.Dams at mi.infn.it
Thu Aug 3 16:22:07 CEST 2006

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,

More information about the GiNaC-list mailing list