On Monday 25 August 2008, parisse wrote: > I still do not understand why giac is not even mentionned in the > symbolic discussion considering the fact that like ginac, it is a C++ > library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) > has much more advanced calculus functions (either functionnalities > like limits, integration) and good benchmarks. I thought sage was an > effort to build a free alternative to maple or mathematica and that > collaboration between projects having this goal would prevail, not > competition (how much time lost duplicating the functionnalities > already available in giac for pynac?). > By the way, I installed in ~parisse on sage the 64 bits binaries > version of giac (icas) and xcas so that everybody can test benchmarks. > Unfortunately a few system libraries on sage have bad rights, e.g. > libstdc++.so.6 is rw instead of rwx, hence one must run > export LD_LIBRARY_PATH=~parisse > before running > ~parisse/icas > For example > g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); > time(factor(r));
Hi there, I totally agree with you that it is annoying that your e-mails don't get addressed properly. Thus, I'm answering however I don't really use symbolics, so my expertice is very limited in that area. The official guidelines for inclusion of new packages are: > = License = > GPL version 2+ compatible license. (This will be publicly revisited around > Jan 15, 2009.) GIAC seems to be GPL v3+ according to Michael Abshoff? > = Build Support = > "The package must build on our supported architectures and compilers [and > intended port targets]: * Linux: x86, x86_64, Itanium, ppc, ppc64, Sparc > (gcc 3.4-4.3) > * Apple Mac OS X: ppc, ppc64, x86, x86-64 (Xcode 2.5+) > * Microsoft Windows: x86, x86_64 MSVC 2005/Intel Fortran [MinGW or Cygwin > * support is insufficient!] * Solaris 10: Sparc, x86, x86_64 (Sun Forte 12) > Remarks: > Some Sage developers are willing to help you port to OSX, Solaris and > Windows. But this is no guarantee and you or your project are expected to > do the heavy lifting and also support those ports upstream if there is no > Sage developer who is willing to share the burden. Potential future ports: > FreeBSD: x86, x86-64 > OpenBSD: x86, x86-64 > HPUX: Itanium > AIX: PPC64 > ARM: OSX As far as I know there were a couple of build issues with GIAC in the past. But you replied fast to any issue brought up on this list. Michael Abshoff wrote about this on [sage-devel]: 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 am not aware of any build issue with GINAC because I never tried. However, it seems that this issue was not addressed in William's proposal. William, can you clarify where you tried to build GINAC and how it worked? Also, since MSVC support is now a *requirement*, does Pynac compile with MSVC? > Quality > The package should be "better" than anything else (that passes the two > above criteria) and an argument should be made for this. The comparison > should be made to both Python and other software. Criteria in passing the > quality test include: > Speed As far as I understand it there is an issue defining what "Speed" is in that context. But both Ginac and Giac seem to do well overall. Someone else needs to address this in more detail > Documentation Ginac seems to be fairly well documented from what I gather: Tutorial, reference manual. Same goes for Giac which also seems to have a tutorial and a reference manual. This seems to be focused on Xcas though, which is not what Sage could use. Is there any C++ level reference manual? Michael Abshoff wrote about this: 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 > Usability I have no clue. However, Ginac seems to be extendible since it is designed as a C++ library rather than a full system. Libraries are obviously better for Sage since they are easier to integrate. > Memory leaks No clue. > Maintainable That seems to be an issue, since people complaint about the lack of code documentation, module separation and so on for Giac. I'm just repeating what others said already on this list, I personally never tried. Also Giac comes with a lot of stuff that is already in Sage, while Ginac only does stuff that is not there yet (fast symbolic arithmetic) > Reasonable build time, size, dependencies Ondrej reported that building Giac required 72 minutes on sage.math which is way too long. Ginac builds in up to 6 minutes. Also Giac seems much larger than Ginac. > Voting > JSAGE vote (majority) > A certain number of sage-devel +1 votes (and sage-support votes) > Every spkg *must* be available as an optional spkg until at least 5 people > download it. The vote for Ginac is ongoing. One is of course free to open a vote on Giac too. However, I do appreciate that William Stein calling a vote would outweight competing attempts. Still, no harm in trying. I hope this addresses some of your questions, Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
