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

[Richard B. Kreckel]

Ondrej Certik wrote:

> I find the whole ginac unnecessary complex: for example declaring new
> symbolic functions requires using 2 macros, adding new classes is even
> more complicated. Then there are several types of functions "pow" (for
> example), one for ex, another for numeric and another for general
> typemaps T1 and T2.


The ones for ex are clear. The ones for numeric are for speed, not just 
for the call itself but also when it's put into another function where 
the numeric return type may yield another speedup. But that is not 
entirely undisputable and we've discussed this before, without clear 
outcome. The ones for general types T are for disambiguation purposes.

> There is the
> "ex" class - it seem to me it's not needed at all. In the source, it's
> written, its for counting references and acts like a proxy. But imho
> it's just making everything complicated.


Allocating all objects on the free store and having to delete them 
manually (and maybe even managing refcounts manually) wouldn't make 
everything simpler, I suppose. Class ex came into existence since there 
are so many operations where we know very little about the general 
result type. Consequently, we cannot juggle the objects themselves on 
the stack, but have to deal with basic pointers. A std::vector of 
objects of various types (as in a general, unexpanded polynomial) would 
really have to be a vector of such pointers, too. Such raw pointers are 
better wrapped. There is passing mention to this in the FAQ 
<http://www.ginac.de/FAQ.html#evaluation>.

Cheers
  -richy.

-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>