> 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. >
And after that, you will have to add support for e.g. sin(x)/x as x- >inf, or x^n/n! as n->inf, etc. After it's done, you'll have to debug it, and probably speed it up. Maybe another 2 or 3 months of work. Same for integration. I didn't look at your arithmetic code (gcd), but it is most probably very slow compared to maxima or even more to giac. What about linear algebra, etc. You say you have to write it from scratch, and people at sage have also to do it. I do of course not have experience in writing C++/Python interfaces, but how can it be that it's better to restart from scratch? > 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. > Actually I would really like to know why Sage developers prefer to restart from scratch. I do really believe that they are underestimating the required work. I have read somewhere that Gary is an undergraduate. I have nothing against undergraduates, we were all undegraduates at one time, but assigning this kind of task to *one* undergraduate is in my opinion a clear sign of an underestimation of the work/knowledge required to build serious calculus capabilites. > 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. Why? As soon as after I made the required modifications, it builds from the source tarball. Building giac with all the optimizations and libraries is not easy because you must build all the libraries before. But building giac just with GMP support should not be hard. Did you try recently? > > 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 do not consider it to be my job to make giac interoperable with Sage, it should be a common job that someone in Sage should do together with me. But it requires first someone within Sage that is interested to do that work, and it does not seem to be the case right now. Maybe later, if some of the Sage developers decide that it might be easier to interface with giac than restart symbolic from scratch (and even do not want to start with your python project). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
