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/>