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

[Burcin Erocal]

Hi,

sorry for coming into the discussion so late. I haven't been checking
the ginac lists lately.

On Wed, 22 Aug 2012 00:51:39 +0200
"Richard B. Kreckel" <kreckel at ginac.de> wrote:

> Hi!
> 
> On 08/14/2012 11:00 AM, Timo Kluck wrote:
> > 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).
> 
> 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.

As Richard said, since libraries like MPIR, MPFR, which are already in
Sage provide arbitrary precision numbers, we didn't want to introduce
a new library for this purpose. Pynac can wrap an arbitrary Python
object in the numeric class. This flexibility is not exploited/exposed
fully in Sage actually.

We are interested in the "high energy physics" stuff. There is just
not enough time to write interfaces to GiNaC functionality from Sage.
There were a few questions about accessing the Clifford algebra stuff
from Sage.

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

Timo, if you want to provide a patch to pynac for this purpose, I'd be
happy to merge it. I am assuming that if caching is done properly,
there won't be any performance regressions. Now we have the tools to
test for those, though the test suite needs some love:

http://titusnicolae.blogspot.de/2012/06/benchmarking.html


Then we can try to push your patch upstream to GiNaC.


Cheers,
Burcin