;; This buffer is for notes you don't want to save, and for Lisp evaluation. ;; If you want to create a file, visit that file with C-x C-f, ;; then enter the text in that file's own buffer.
> 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. > The main reason is that it is not a top level priority to do a proper splitting. And for example readrgb is using the FLTK images library. But as you say, it can be compiled without X. > > 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 This should not be a problem. I can switch back to v2. But the normal way should be that v2 softwares go to v3. > * 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 I believe that someone looking at someone else code will always find it difficult (unless they worked together), I find it hard myself to read other people code. I certainly do not pretend to comment it perfectly (and I don't plan to make a detailled description of the math behind), I do so that I can fix bug myself using gdb. Sometimes in the future, I'll certainly have to make some documentation for programmers, but I'll move it as a priority only if I'm sure active developers are using giac. > * 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 current bottleneck which explains at least a part of the speed difference with magma is sparse multivariate division, I'm going to improve it and I'll update my benchmarks. Now, I want to emphasize that giac is not just another polynomial library. It is a full- featured CAS that sage could call as a library (unlike other CAS where most probably communication is handled by text streams). > * 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. I don't see any interest to have MSVC support myself, giac/xcas is ported on windows with cygwin. I bet however that it is easier to port code to another compiler than to implement, test and fix again the algorithms :-) > * there are CoCoALib leftover files in the src directory, namely Tmp* > - I am sure this is an oversight. These files are not part of libcocoa.a (I did not recheck since the last time I downloaded cocoa), but they are required for the F5 implementation in cocoa. This F5 is not used by default inside giac, it seems slower than cocoa standard reduction algorithm which is used (if CoCoA is detected), so that giac has a correct Groebner basis implementation. I'll certainly try to build a link to singular when I'll have some time (I didn't try before since it was not linkable as a library). > * 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. > I believe that the main advantage for sage would be to use giac as an alternative for maxima for calculus, and that would be useful for giac since the number of users would grow. I'm working on the efficiency of the basic algorithm of giac (like polynomial arithmetic but also linear algebra, like determinant over the integers) mainly because they are required for that. They could be used inside sage until a better alternative is ready (and people could choose to implement new functions first instead). I'm also interested to use sage components to improve giac if possible, like I did with pari, ntl, cocoa (would you for example implement polynomial arithmetic so that it could be used from C++?). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
