I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? This is very much a design related question, and in the hurry to get GiNaC through review I feel that design issues and questions have been very much ignored. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term?
--Bill On Mon, Aug 25, 2008 at 8:24 AM, Burcin Erocal <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
