Hi,
On Apr 12, 4:23 am, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote: > On Friday 11 April 2008 05:39:03 pm Martin Albrecht wrote: > > > PS: In any case, If anyone wants to work on an optional GIAC spkg, please > > speak up! > > I tried to build GIAC and it didn't go so well. The seemingly obvious way to > have it pick up sage pre-installed components (--prefix=...) allowed > configure to go through fine, but the compile did not. I manually fixed this > in one directory, but another failed then. I know that this is way to vague > to be a real bug report. > > Another thing is that I think giac should be separated out from xcas so as to > not introduce an X dependency. This too, I'm not sure that I did my own > research adequately. You can disable the X component of GIAC, so that isn't too much of a problem. But the fact that it isn't cleanly separate is something I would consider non-optimal. > Nevertheless, I say all that to say that I did (quickly) attempt to try out > giac and when I get another bit of time to return to these pursuits that is > near the top of the list of things to try. > > But, I'm also interested in making the sage sparse multivariate a very fast > alternative for simple arithmetic since we can offer a breadth of choices for > base rings that appears unparalleled. But, indeed, I'm simply enjoying > learning about mpoly factorization myself ... and one way (the best way?) to > learn it is to try and *do* it for oneself. Aside from that we did discuss GIAC again in IRC a couple days ago [some people did look at it in the past and it has come up in the past] and there were a couple comments [my recollection, not some official statement]: * Any standard component of Sage for now has to be GPL V2+ compatible. GIAC seems to be GPL V3[+] now * The code is sparingly commented and seems to conform to its own coding style. We specifically looked at the Risch code and also infrastructure like vecteur - this is really a big issue since dealing with sparingly documented code in the past had proven to be a huge pain in case we had to fix bugs * It is unclear that a ten time speedup over the current code is worth dealing with 150k lines of code. It is another polynomial class to deal with in coercion, build issues and so on. If it were "Magma" speed that probably would be something we would be willing to live with ;) * The code doesn't seem to have MSVC support and due to its size the size/benefit ratio doesn't look good. Since I will likely end up porting the code I am not too excited to have to deal with another 150k lines of code. * there are CoCoALib leftover files in the src directory, namely Tmp* - I am sure this is an oversight. * It is likely that improved algorithms will need fast linear algebra or some other goodies and writing interfaces to GIAC if we already have them in Sage seems of little benefit to us. All of the above can be overcame and somebody else should take a look and check if my impression is correct and you should correct me if I am wrong. > -- > Joel Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
