On Apr 21, 12:32 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Apr 20, 2009, at 11:44 PM, Maurizio wrote:
>
> > Hi Michael,
>
> > Actually, I thought that this discussion (especially people much more
> > expert than me) has clarified the point that implementing integrals is
> > not really just matter of a couple of months... but I would be glad to
> > see this happen!
>
> Implementing something that can handle a huge number of integrals is
> a reasonable goal for a couple of months. Implementing something that
> can handle everything that we know how to handle in theory...well,
> that hasn't ever happened yet.
Yep, certainly implementation are certainly better than other
implementation here on average, but one could claim that neither Sympy
nor Maxima are at the head of the class. Maxima can do many things,
but often a little massaging is required by the user to get optimum
results comparable to MMA for example. And I believe plainly and
simply that this is not the role of the user of a CAS to be an expert
at term maniplulation. If I write intgerate($FOO) I expect to get a
correct answer without being required to transform the expression due
to knowledge one has about the underlying implementation.
> > I know there are some license issues with SymPy (not really issues,
> > just differences probably) but I think there's no problem in taking
> > inspiration and some pieces of code from it, right?
>
> There is a problem with just lifting code--but we can and do ship
> SymPy as part of Sage.
Yes. One could take code from Sympy (the BSD license allows this) and
make GPL ed changes on top of it. The main issue is just that our
pattern matching engine via pynac will be more powerful, our
arithmetic is faster and the other abstract math bits in Sage are way
more powerful than what is in Sympy. And the goal of Sympy is to be
self contained and depending on certain operations in Sage is not an
option and not wanted, so contributing such code back to Sympy is not
an option . There is the goal for Sympy to optionally depend on Pynac
and use it when available, but no one is working on this, so this is
not something we ought to be waiting for.
Plainly and simply: Waiting on someone else to fix the problem for us
has not worked, so we will do it ourselves.
> > I'm saying this, because I can see this new symbolic stuff exciting,
> > but without the right amount of interest on it, its development will
> > always be a little slow
>
> Given that we ship SymPy, so anything it can handle we should be able
> to handle. I imagine when you want to integrate something, it will
> try to do it natively first, and that failing ask SymPy and/or maxima
> before returning a failure. Over time we'll depend less and less on
> the other two.
Yep, that is the only way in my opinion. We control the Sage library
and can coordinate releases with improvements in the Sage library -
Sympy has not released as frequently as it used to be and unless
someone steps up and helps Ondrej out I doubt that is going to change
any time soon.
And by the way: the latest Symbolics code that is not yet available
for review can already user either Sympy and/or Maxima to do
integration. That code ought to be in Sage 4.0.
> - Robert
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
