Hi! On 08/14/2012 11:00 AM, Timo Kluck wrote:
2012/8/14 Richard B. Kreckel<kreckel@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).
That is correct. How would you manage that list of symbols? One may have to take care about when to destroy it, in order not to break refcounting and create a memory leak, I suppose.
Do you happen to know what the reason was for forking?
Sage already had its own number system and didn't want to bring another one (CLN). Also, there wasn't much interest in some of the special algebra for high energy physics. No worries.
There would be no memory leak if the cache were to live in the object.
That's correct, too. Still, you should carefully benchmark your proposal to see if it really helps. If it does, and if a .symbols() MF is really a bottleneck in some applications, then, well, why not add it to GiNaC? And, please, discuss this with the Pynac developers, too, for the obvious reasons. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>