[GiNaC-list] Term ordering and compiling C++ code

[Richard B. Kreckel]

Hi!

jros wrote:
> Although I don't have a solution for your problem, as I'm myself
> addressing similar problems
> matching common subexpressions to variables, in down top manner, I think
> that such a functionality
> is implicitly implemented in GiNaC.
> 
> If I understand GiNaC internal structure correctly, subexpressions
> common to two expresions,
> are frequently  shared internally, to save memory.

This is entirely correct, but...

> So it must be possible to write a print algorithm that goes trough
> an/some expression/s tree, and that replaces
> every shared subexpression (let say sum product) with a variable, that
> again is assigned a expression that would be printed
> in the same way using recursion.  

...first, this sharing is entirely transparent for the user...

> Probably allowing/disallowing some kind automatic simplifications (so
> that subexpression sharing expected value increases) can probably help
> to obtain improved results.

...and second, sharing is currently not pursued aggressively! Rather, it 
is exploited whenever it is trivial to do so. (The product rule of 
differentiation is an example where exactly the same terms pop up again 
and again so exploiting sharing comes at no cost.)

> I wonder what do the developers think about this.

Well, I think that if the size of generated code is so prohibitively 
large and compiler CSE doesn't help you may be better off writing your 
own algorithm collecting similar terms in an associative array. You 
could then artificially introduce temporaries, in order to help the 
compiler. This would boil down to a more aggressive variant of GiNaC's 
subexpression sharing. What do you think?

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