[GiNaC-devel] Fwd: Add method ex::symbols for obtaining all symbols appearing in an expression

[Timo Kluck]

On ma, aug 13, 2012 at 9:02 , Richard B. Kreckel <kreckel at ginac.de> wrote:
>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?

That is probably best, especially in the light of the (x+y) - y
example that Alexei mentioned.

I could easily do that in Sage, but I think it wouldn't help in my
case because I'm constructing so many expressions.

However, I'm thinking it may make sense to do that in GiNaC, because
from what I've seen it has some sort of a copy-on-right mechanism for
subexpressions? As in:

f = sin(x+y)
g = f * cos(x-y)
h = f * tan(z)

will make g and h share the instance (and therefore the cache!) for f?
Please correct me if I've misunderstood that. But if it has, this is
abstracted away in Sage, so caching the variables() function in Sage
would have much less benefit than caching it in GiNaC.

I'm not sure whether this will actually give me any speed benefit in
practice, because even though I'm using very similar subexpressions
over and over again, I'm not sure if I could construct them as the
same object without writing really awkward code. I'm interested in
your opinions, though.

So my next question is: would you accept a patch implementing a
recursive, cached version of symbols(), for Sage to call directly, and
then have responsibility for optimizing / caching that going to the
level of GiNaC?

I would normally think that it would be a method of ex (and basic).
Where would you say the cache lives if it where a global function?

Timo