On Fri, Jun 20, 2008 at 12:45 PM, parisse <[EMAIL PROTECTED]> wrote: > >> I know you once written to the SymPy mailinglist asking us to rather >> join (or use) Maxima [1], instead of reinventing the wheel. Well, Sage >> does exactly what you wanted, i.e. using maxima from Python, instead >> of reinventing the wheel. But lisp is just too difficult for me (and >> all other people I personally know) to fix. The other reason is that I >> think lisp is dead. >> >> Compare this: >> >> http://maxima.cvs.sourceforge.net/maxima/maxima/src/limit.lisp?revisi... >> >> to this: >> >> http://hg.sympy.org/sympy/file/ccebd03423df/sympy/series/gruntz.py >> >> it has more or less the same functionality now. Which is more >> readable? I guess there are people who will find the lisp version more >> readable, but I and most people I know find the python version more >> readable/maintainable. >> > > But you should not forget that the question of the class of problemes > solved is what is relevant to the users. Looking for example at the > sympy implementation of the mrv algorithm, it is far from being able > to solve even simple limits, like > limit((3**x+5**x)**(1/x),x,oo) > and many limits that are solved by the mrv algorithm fail: > limit(x*ln(x)*ln(x*exp(x)-x**2)**2/ > ln(ln(x**2+2*exp(exp(3*x**3*ln(x))))),x,oo) > limit(exp(exp(exp(x)))/exp(exp(exp(x-exp(-exp(exp(x)))))),x,oo) > ... > or return wrong answer > limit(exp(exp(exp(x)))/exp(exp(exp(x-exp(-x)))),x,oo)
Yes, I am well aware of that. The problem is not in the mrv algorithm itself, but in series expansion, which needs to support very general series. My original code from a year ago was able to handle all the cases you wrote above and it took me about 3 weeks to write and debug. However, it was built on a little fragile series expansion code. In SymPy, we were fixing bugs that people discover and need fixed urgently, and people don't need these limits often, so that's why we were fixing other issues first. But it's definitely on my TODO list. > With sufficient hard work, there is no reason for sympy not being able > to solve these problems, but it will be interesting to compare the > complexity to maintain/extend the limit algorithm of sympy with maxima > or giac *when* sympy will be able to do it and do it not too slowly > (as well as other calculus tasks like e.g. integration) Yep. > And then I ask the question : is it really worth the effort to > duplicate the work done in maxima or giac? How hard is it compared to > making sympy interoperable with maxima or giac? Actually, I think it is easier to write it from scratch than to maintain wrappers to maxima/giac/ginac. Remember that I wrote swiginac with Ola Skavhaug, so I know what I am talking about. And you can ask Sage developers about their opinion on maxima wrappers and why Gary is writing symbolics from scratch. I thought that if I try to integrate sympy in Sage, the Sage develpers will not have to write the symbolics from scratch. But I was wrong, because I don't have enough time to do it myself and noone else have step up to help with this. And the reason is not that other people don't "see the light". The reason is that it is simply easier to do it from scratch and do it right within the constrains that you have and the tools you have. I.e. in the case of Sage -- cython+other Sage parts, in the case of sympy -- pure Python + maybe cython, but without other sage parts. Then you might think -- ok, so pure Python, maybe Cython, so why have Pearu started sympycore as another project? Well, again, it is easier to start from scratch. On the other hand, I find this scatter of resources also bad. So I try as much as I can to talk to people and to try common grounds and try to make things in a way, so that people feel motivated by themselves (without me forcing them) to cooperate on one thing, instead of each of us doing things on our own. > I believe that many people are underestimating the work required to > have common calculus tasks properly done and that might explain the > current roadmap of sympy. Well, since I started sympy and I am still active in its development I know first hand, that it's very hard to be robust and get all the corner cases right. But the last time I tried giac it didn't built and it required several emails between you and me to get things fixed. That's a show stopper. With sympy, it's maybe slower, but at least it works. Also having it in pure Python it has many other advantages, like running on the google app engine, being native on windows, and similar. But of course, there are many other use cases, where Giac or Sage are better. > >> However, on a positive note, I think this game is not a game with a >> sum of 1, but rather it seems to me that all Sage, Maxima, SymPy and >> other packages are getting new users and developers. In the end, all I >> want is to get the job done and I think it's important to make sure >> all the packages talk to each other well, and also to try to find >> common grounds of cooperation, if possible. >> > > Then I hope you will reconsider making sympy interoperable either with > maxima or giac or both. Yep. In fact, we always wanted sympy to by interoperable, that's why I wrote Sage interface code and why we have a simple maxima parser. But I think the best way is to be interoperable is to work well in Sage and for maxima and giac to work well in Sage as well. So, I think I did my part, i.e. integrating sympy in sage (it could greatly be improved though, but the usual time constrains apply with me:), and now it's your job (imho) to make giac operable in Sage as well. Then we can use both packages together. I am interested in your (or anyone elses) thoughts on this. I would like to spent my time as efficiently as I could. :) Ondrej --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
