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

[Ondrej Certik]

> Yes, doing garbage collection is a reason to have a type ex. It is indeed
> possible to use another garbage collector. I'm not sure what it would do
> to performance. This might even depend on the particular computer algebra
> problem under considerating. Reference counting certainly is more
> predictable. Algorithms that would seem to be, say, O(N^6), will perform
> precisely like that in GiNaC.
>
> Another reason to have the type ex is automatic evaluation. If objects are
> to be made by constructors and after that we are going to pass around
> pointers to them, I'm not sure who is going to take care of automatic
> evaluation. You can get around this by declaring for every class a
> function that returns a basic* (as the "pow"  function that you showed).
> However, that defeats the purpose of making the library simpler.
>
> Another nice thing about exes is that you can compare them by using the
> operator ==. That cannot be done with pointers, because it already means
> something else.

This answers my question. Thanks.

I am not sure about the performance either, it would have to be tried
to see, but I it seems that ex  -way is going to be faster. As to the
eval(), you are completely right, I am addressing the same issue in my
library. Either I can evaluate everything automatically right when I
construct the expression, or I need to call eval() manually later. As
to the "==", you would have to use either of those 2 ways:

basic *p=pow(e1,e2), *q=pow(e1,e2);
*p==*q

or

basic &p=*pow(e1,e2), &q=*pow(e1,e2);
p==q


Thanks for enlightening me the issue, I can see the reasons behind ex now.

So what about changing this in ex.h:

/** Lightweight wrapper for GiNaC's symbolic objects.  Basically all it does is
 *  to hold a pointer to the other objects, manage the reference counting and
 *  provide methods for manipulation of these objects.  (Some people call such
 *  a thing a proxy class.) */

to something like:

Lightweight wrapper for GiNaC's symbolic objects. Basically all it
does is the garbage collection. It would be possible to use another
garbage collector, but we are not sure about the speed and reference
counting certainly is more predictable. Another reason for ex is the
automatic evaluation, which is triggered, whenever an ex is
constructed from a basic-derived object. It also provides methods for
manipulation of these objects.

Ondrej