On Mon, 23 Jul 2001, Duraid Madina wrote:
Hi all,
Hi Duraid, nice meeting you again!
Please forgive my ignorance, but is there any chance GiNaC might move away from CLN and in its place use a "softer" library such as NTL? (http://www.shoup.net/ntl/) At least then we might have a chance of moving away from (or at least not kneeling before) Mark Mitchell and his GCC henchmen ;-)
What's so wrong about Mark and his henchmen? In my impression they are producing an excellent compiler. Both GiNaC and CLN should compile fine with GCC-3.0. (CLN-1.1.1 has compilation problems on non-x86 platforms with GCC-3.0, but I am working on these and plan to release 1.1.2 this week.) What is the exact problem? What alternative compiler are you having in mind? Note that CLN is ideally suited as a basis for computer algebra systems, mainly for three reasons: 1) Immediate types. An integer with absolute value smaller than 2^29 is immediate, not heap-allocated. Saves one indirection. 2) Honors the injection of integers into rationals automatically, many aspects are more algebraic than in any other comparable library. 3) Reference-counted memory management. This works seamlessly with GiNaC's memory management. Compare this with MuPAD, where the memory management occassionally clashes with that from the underlying PARI library or with Magma, which occassionaly blows up out of the blue sky because of interferences with some Kant remnants.
What sort of obstacles would such a 'port' face? Just how many innocent undergrad students would need to be tortured for such a feat to occur?
On the source-front only files numeric.h and numeric.cpp would have to be touched. But quite a number of functions would need to be implemented in GiNaC as opposed to delegating them to CLN. Hmm, I haven't gone through them and compared them with NTL's capabilities. Maybe one half or three undergrad students? Do you have some spare undergrads? ;-) There is of course also the packaging-front: NTL has no suitable packaging, in my opinion it badly needs to be libtoolized!
Disappointed with GCC, (albeit deleriously happy with GiNaC)
Oh, you shameless flatterer! Seriously, if making things work on another compiler is all you are concerned with, I can assure you that CLN is not so non-portable. Here is demo that it can be done with moderate effort: <http://www.ginac.de/lists/ginac-list/msg00028.html>. Be warned though: On non-GCC you must probably compile CLN with "-DNO_ASM -DNO_PROVIDE_REQUIRE", and build a static library only. By the way, all this nuisance is in order to prevent this: <http://www.awtechnologies.com/bytes/c++/faq-lite/ctors.html#[10.11]> from happening. Even then you can expect a fair number of compiler-sillinesses (no operator-> on iterators and bullshit of this sort) to happen. If you then still find CLN sillinesses I'ld definitely like to hear about them and see if they can be fixed. Cheers -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>