Add method ex::symbols for obtaining all symbols appearing in an expression
Hi, You may know the CAS Sage [1] which uses GiNaC. It wraps ginac expressions in Python, and it adds some extra methods of its own. One of those methods is variables(), which returns a list of symbols appearing in the expression. It does so by recursively walking down the expression tree. At one point, that was a bottle neck in my algorithm, and I realized that it would be very easy to cache those variables at construction time from the subexpressions. I think the natural place to implement such a thing would be in GiNaC itself, so that everyone (not only sage users) may benefit. Is this planned and/or would you accept such a patch? Best regards, Timo Kluck [1] www.sagemath.org
Hello, On Mon, Aug 13, 2012 at 01:19:22AM +0200, Timo Kluck wrote:
One of those methods is variables(), which returns a list of symbols appearing in the expression. It does so by recursively walking down the expression tree. At one point, that was a bottle neck in my algorithm, and I realized that it would be very easy to cache those variables at construction time from the subexpressions.
I think the natural place to implement such a thing would be in GiNaC itself, so that everyone (not only sage users) may benefit.
I don't think it's a good idea. This adds quite a non-negligible overhead to every eval() and expression construction, even if the actual calculation does not need the variables() (symbols(), or whatever it is). Besides I don't think caching really helps. Consider the following code: symbol x, y; ex e = x + y; ex g = x - y; ex e_plus_g = e + g; One would expect e_plus_g.symbols() to return just x, that means symbols() needs to scan the whole e_plus_g expression (to find out that it doesn't contain y), which makes the cache kind of useless. Best regards, Alexei
Hi, On 08/13/2012 01:19 AM, Timo Kluck wrote:
You may know the CAS Sage [1] which uses GiNaC. It wraps ginac expressions in Python, and it adds some extra methods of its own.
One of those methods is variables(), which returns a list of symbols appearing in the expression. It does so by recursively walking down the expression tree. At one point, that was a bottle neck in my algorithm, and I realized that it would be very easy to cache those variables at construction time from the subexpressions.
I think the natural place to implement such a thing would be in GiNaC itself, so that everyone (not only sage users) may benefit. Is this planned and/or would you accept such a patch?
Wouldn't it be better to go one step further and cache those variables when the variables() function is first used? This avoids quite a lot of overhead in space and time! And then, variables() wouldn't have to be a member function, right? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (3)
-
Alexei Sheplyakov
-
Richard B. Kreckel
-
Timo Kluck