On Tue, Apr 21, 2009 at 12:44 AM, mabshoff <mabsh...@googlemail.com> wrote: > > > > 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 exper > 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 believe that too. > >> > 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 Could you give some specific examples where the pynac pattern engine is more powerful? > 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 We want sympy to run without Sage. But I have absolutely no problems calling Sage for certain things if it's available. In fact, I do want to call Sage if it's available. > 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. For the record, I offered William and you that I will work on this, if we manage to find funding for it over the summer. So just to be clear that I am very interested in this, and not just talking. But unfortunately I myself didn't find funding for it (and I haven't heard from you either that you found some possibility), so I had to find an internship somewhere else related more to my research (finite elements). We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. >> > 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. We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) Besides, it will take almost a year to Sage too to release the new symbolics (started August 2008), so I don't think we are doing that bad. Also in terms of developers working just on symbolics, I think sympy has much more developers. I don't know if it's easy to extract just patches to Sage symbolics, to compare speeds of developments, but I would not be surprised if it turns out it's actually very comparable, or even less people are working on Sage symbolics than on sympy. That being said, I like that you pursue the pynac way, because first I also wanted to use ginac but using swig was just not the way, so William showed me with cython how to actually do it. And second, I welcome competition, because that's the only way to actually move forward, but for Sage and sympy. For example thanks to sympy, you completely abandoned your previous approach for symbolics, because after many months of development, it was still slower than pure python sympy and less tested and robust. So now it's our turn to speed up sympy. :) Ondrej --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
