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
-~----------~----~----~----~------~----~------~--~---

Reply via email to