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

[Timo Kluck]

2012/8/14 Richard B. Kreckel <kreckel at ginac.de>:
> There remains Alexei's worry that this is likely to substantially slow down
> all applications.
I think his worry related to my initial suggestion for doing this at
construction time. I think that just adding a member function
implementing its own cache shouldn't add overhead to applications not
using it. (The only difference would be the constructor having to
initialize the cache to NULL).
>
> Well, any patch would have to go into Pynac, in order to be of advantage in
> Sage. Pynac is a fork of GiNaC. (In the past, we've repeatedly fixed Sage
> bugs in GiNaC and suggested patches for Pynac and vice-versa, but that
> doesn't mean that changes in GiNaC propagate automatically into Sage. At
> least I'm not aware of that.)
Thanks for pointing that out; I was under the impression that Pynac
was a Python wrapper for Ginac. I might just have to look at Pynac
then. Do you happen to know what the reason was for forking?

>> 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?
> It should be possible to equip that global function with a static hashmap ex
> -> symbols. Of course, that opens a memory leak because the map is never
> cleaned up. So, as an alternative, one could maintain that map only while it
> can really speed up things: store it in an object and delete it when that
> object is destructed.
There would be no memory leak if the cache were to live in the object.