> I meant stuff like this: > > """ > Installing the required libraries from source (recommended) > .... > * CoCoA 0.99 (for faster Groebner basis). > """ > > Sage already has "faster Groebner bases" since it included Singular. There is > > a lot of stuff like that in Xcas/Giac like that Sage already has. This makes > sense since Giac/Xcas is a stand-alone system just like Sage. >
This is not a part of giac, it is an optional external library that is linked in giac. There are other parts of giac that might be interesting for sage or are fast inside giac. Like gcd, limit, integration, contexts... > Sage is built from source by many people. One of the design goals was to > enable each end user easily to contribute and thus there is no such stark > distinction between "development" and "final binaries". This might change > eventually, but a build time of 72 minutes seems way too long. > I don't see why it's a problem if the spkg_install script specifies CXXFLAGS=-g so that it compiles without optimization in less than 10 minutes by default. If you develop around giac, you will most likely want to use gdb, hence -O2 is bad even with -g. Optimization is only required from time to time when one needs to make benchmarks. Re: William >My experience with Giac is that: >(a) I can't build it, (b) even on systems where I could, I'm not >patient enough, and (c) looking at the source code from the point >of view of doing what I want makes me dizzy and I get nowhere, >(d) and Giac is HUGE -- about five times the size of Ginac, and >much of that code in Giac overlaps with what Sage already does, >and (e) my technical build guy tells me that Giac isn't a model >of super high quality code. (a) and (b) are bad excuses, since there is a spkg. (c) Did you first look at the giac.info page? (d) Yes, giac/xcas is large (maybe 100K lines for giac, you don't have to look at the interface code), but that's the price to have a CAS! (e) Perhaps. From my own experience, it is not easy to enter into a large library (e.g. cocoa, pari, etc.). >So to me Giac cannot solve any of our problems today, >unless we want Sage to be bloated, and we want to take months >or years rather than a few days to get this stuff done. I can't believe it would take years to make sage and giac interoperate. Even if it take months, that should be compared to the time required to get the same level of functionnalities at a comparable speed over ginac. >Perhaps I could take code from Giac, e.g., for limits or >symbolic integration, but (a) you're using GPLv3, so I can't, >and (b) probably that would make you unhappy anyways, >and (c) I would rather such functionality comes from the sympy >project, since that is in Python. (a) is not recevable since I could relicense it to GPL v2. Anyway, it is highly improbable that you could take code slices without taking almost all of the library. Higher level code depends on the low level routines and data structures (e.g. rational fraction integration from multivariate polynoms) + many parts are interconnected (e.g. integration requires linear algebra) which BTW makes modularization difficult. Ok, it's probably time lost for both parts, I'm afraid I won't convince you to use giac and you will certainly not convince me to abandon giac in favor of re-developing over ginac or inside sympy (which I find interesting, I wonder how the speed problem will be fixed). The real fight should be with closed-source systems. I will keep looking at symbolic threads, it's always interesting to test examples and benchmarks. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
