[GiNaC-list] GiNaC as the symbolic manipulation engine in Sage

[Burcin Erocal]

On Mon, 11 Aug 2008 11:39:42 +0200
Jens Vollinga <jensv at nikhef.nl> wrote:

> Hi from GiNaC side,
> 
> just some short comments:
> 
> Burcin Erocal schrieb:
> > - It takes ages to build
> > 	The packages above took ~25 minutes to build on my desktop
> > machine (15 for cln, 9 for ginac)
> 
> Did you configure with the --disable-static option? Otherwise your build 
> time is just twice the usual time (looks like it).

I didn't do anything to try to make these times better. I was more
concerned with benchmarking speed of basic manipulations, and thought
that these problems can be solved easily later.

Your suggestion reduces the compilation time of ginac to 5 minutes.
Looks like we're already below William's 8 minute limit. Now can we fix
the cln problem? :)


Thanks.

Burcin


> > - cln seems to support on only gcc, which might be a problem for the
> > windows port (which will be using ms compilers)
> 
> <blame others>
> That is a real problem, but it can only be solved by the cln people.
> </blame others>
> 
> > - cln duplicates functionality which is provided by different libraries
> > already distributed with Sage (mpfr, mpir, flint) at a considerable
> > speed penalty.
> 
> It would be quite useful for ginac if the numeric class that wraps the 
> cln library would allow for other libraries as well, even pure C double 
> precision ones. The problem in realizing this idea was always that other 
> libraries were missing certain features (some functions, modular 
> arithmetic,...) and to make up for these would incur a lot of extra 
> work. It didn't seem like it was worth the hassle (yet).
> 
> > - IIRC, GiNaC documentation suggests the printing order for the
> > variables is stable between different sessions, regardless of creation
> > order. However, running the doctests in the experimental wrapper
> > reveals different results. We may need to write a custom pretty printer.
> 
> True.
> 
> > - The gethash() function of GiNaC objects doesn't return stable
> > results, which is probably the cause of the problem above. We need a
> > stablehash() function.
> 
> Yes, the two points above are related and I am to a certain point 
> responsible for that mess. To explain: The original tinfo system in 
> ginac was changed a few years ago to avoid fixed magic numbers which are 
> a problem if you have a lot of user supplied ginac classes (made more 
> urgent by the plan to make functions into full ginac classes). The 
> current system assigns these dynamically during compilation. But it is 
> not done in a smart way, so the tinfo numbers usually differ between 
> different compilations. Now, these tinfo numbers also go into the hash 
> calculation and the term ordering ...
> 
> Personally, I would like to have this issue solved and have ginac to 
> produce a fixed term ordering (as long as the declaration order of the 
> symbols done by the user is the same). But at the moment I don't have 
> the time to do this. Any volunteers? :-)
> 
> Regards,
> Jens
> _______________________________________________
> GiNaC-list mailing list
> GiNaC-list at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-list
>