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