On Mon, Aug 25, 2008 at 12:34 PM, parisse <[EMAIL PROTECTED]> wrote: > >> 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.
Even at 10 minutes with no optimization that seriously tests my patience. And 72 minutes with optimization is real deal breaker. > (c) Did you first look at the giac.info page? I don't know what that is. However, I expect to be able to cd to the source directory, start looking around, and make progress. I was very pleasantly surprised by how well this worked with ginac, which certainly passes that test. > (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! True. I'm not saying giac is at all bad -- I just don't think it is the right tool for the problem that I need to solve. > (e) Perhaps. From my own experience, it is not easy to enter into a > large library (e.g. cocoa, pari, etc.). I don't know what you mean here. Pari is also a fairly unpleasant library to work with. Ginac is one of the better ones I've seen, similar maybe to NTL which is also quite good as far as usability goes. PARI is terrible to use as a library. > >>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. This nicely illustrates issues with using giac for sage. Again, it is not to say that giac is "bad"; just that it isn't suitable for my purposes. > 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). I am not at all trying to convince you to do anything differently. > 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. I'm not even trying to fight with closed source systems. I just want to get Sage's symbolic manipulation capabilities to be "up to snuff for research level work", which is something they are not right now, except for say calculus teaching. William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
