[GiNaC-list] GiNaC as the symbolic manipulation engine in Sage
jensv at nikhef.nl
Mon Aug 11 11:39:42 CEST 2008
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).
> - cln seems to support on only gcc, which might be a problem for the
> windows port (which will be using ms compilers)
That is a real problem, but it can only be solved by the cln people.
> - 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.
> - 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? :-)
More information about the GiNaC-list