Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse <[EMAIL PROTECTED]> 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 think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. There is also the question why use GiNaC and not giac as the symbolic arithmetic engine in Sage. The answer lies in the formulation of the question, and the word "arithmetic." We already have a pretty good "symbolic engine" in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. The situation would be the same if we adopted yet another system, such as giac. The point of the pynac effort (at least from my pov), is to acquire a fast and capable arithmetic and manipulation engine and write the higher level algorithms on top of that. This way Sage can advance from being a user interface to become a research environment. > 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?). <snip> Pynac is a modification of GiNaC to use python objects as coefficients in its data types. This was a rather tricky, but well isolated change, since GiNaC already abstracts this functionality into a single class. I don't think this is duplicating any functionality already in giac. Cheers, Burcin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---