[GiNaC-devel] GiNaC is not a C compiler [Was: Optimized C-style output]

Stefan Weinzierl stefanw at thep.physik.uni-mainz.de
Tue Mar 27 18:30:11 CEST 2007

Dear Alexei,

On Mon, 26 Mar 2007, Sheplyakov Alexei wrote:

> There is a type which represents such objects, it is called exmap
> (std::map<ex, ex_is_less>). Is new type really necessary?

exmap is hard-wired to ex_is_less and uses the internal order of GiNaC.
For substitutions which are supposed to be printed out in the end, one has
to ensure that they occur in the right order, e.g. no symbol is used on
the right-hand-side before it has been defined on a left-hand-side.

> > Examples of such methods could be:
> >  - replace common subexpressions of type T1, T2, ...  in the rhs.
> >  - split containers with more than n_max arguments
> >  - (eliminate redundant variables)
> >
> > This structure has then a print method, which simply prints
> >  ...
> >  double t1 = expr1;
> >  double t0 = expr0;
> >
> > Everybody happy with this concept ?
> No. There are 3 different _independent_ transformations: 1) finding
> commong subexpressions, 2) splitting an expression into a smaller parts,
> 3) generating code. Each of them is useful on its own, so it would be nice
> to keep them separate.

That's what I wrote above: One has three different methods.


More information about the GiNaC-devel mailing list