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

Stefan Weinzierl stefanw at thep.physik.uni-mainz.de
Fri Apr 6 15:35:18 CEST 2007


Dear Alexei,

On Wed, 4 Apr 2007, Sheplyakov Alexei wrote:

> First of all, I'd prefer this to do the following:
>
> ex e = log(sin(y+x))+sin(y+x)+pow(sin(y+x),2)+log(y+x);
> exmap repls;
> e = find_common_subex(e, repls);
> // e:
> // log(symbol0) + pow(symbol0, 2) + log(symbol1) + symbol0
> // repls: symbol1 => y+x
> //        symbol0 => sin(symbol1)
>
> Such transformation is useful even if user is not going  to generate
> any code at all.

In case that I repeat myself: I don't think that an exmap is appropriate
here, as it looses the information in which order the substitutions should
occur. This information is available when parsing the expression tree, it
gets lost when you squeeze it into an exmap and has to be recovered with
an overhead of computational cost when ones wants to print out the
assignments in the right order.

Secondly, there is a more subtle issue: The content of exmap will depend
on implementation details of subs(). In the example above, should repls
contain
 symbol1 => y+x
 symbol0 => sin(symbol1)
or
 symbol1 => y+x
 symbol0 => sin(y+x)
The answer depends on whether subs() visits the children of each node in
post- or preorder. (It visits the children first.)
If for some reason this is changed in the future, it will break the code
for find_common_subex().
I don't want to introduce such subtle dependencies.

 Best regards,

   Stefan





More information about the GiNaC-devel mailing list