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

[Jens Vollinga]

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)

<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