> 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.
Yep. > 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. Yep. > 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? Because you want to use it using the tools which Sage have chosen, i.e. Python, C, Cython and you want it to be maintainable. Also the one who wrote the code usually chooses the technology, so you should ask those Sage devs who wrote it, why they didn't chose giac instead. > >> 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. Other people will join in too. Patches need to be reviewed and I believe anyone can do solid work. There were high school students who contributed a very nontrivial fixes to SymPy through google GHOP, so given that Gary is already undergraduate I don't see who better should do it. You don't need to understand quantum field theory to write symbolic manipulation software. :) > >> 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? Yes, I tried just now at PMAA08 conference, where they block all traffic besides port 80 and I was unable to download the code from the web, because it is over ftp only (ftp://ftp-fourier.ujf-grenoble.fr/xcas/giac_unstable.tgz). Well, that's a show stopper for me. You may criticize me, that I am strict, but I think I am not. I wanted to use (try) your software right now and I cannot. So any user who encounters that will immediatelly turn away. So I may write you an email to send me the sources in an email, or to put it somewhere on the web, but that's exactly what I am talking about -- people should be able to download it without writing an email to the author. :) >> > 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). Why do you want me to make sympy interoperable with giac if you are not willing to make giac interoperable with sympy? :) Just a joke. Well, my experience with Sage developers is that they are extremely helpful with helping these efforts and answer all questions I might have. Did you try to send or do some patch? I am sure Sage devels will help. On Fri, Jun 20, 2008 at 6:18 PM, root <[EMAIL PROTECTED]> wrote: > >>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. > > I have to second Bernard's comment here. The integration code in Axiom > was written by Davenport, Trager, and Bronstein, all of whom invented > the code as their PhD thesis work. I worked with all three people on > the Axiom project. Axiom represents an estimated 300 man-years of work > over a 23 year period, with funding at an estimated total of $42 million > (back when the dollar was worth something). All three people spent years > working on the project. > > The belief that it might be "better" to rewrite this code from scratch > seriously underestimates the time, knowledge, and effort required to > achieve high quality, well tested, trustworthy code. > > The code size, time requirements, porting effort and complexity of > making a working interface to systems like Giac, Maxima, or Axiom > is MUCH less than rewriting algebra code from scratch. > > I do admit that interfaces lacks the same "street cred" as new algebra > code but Sage would end up with a much higher quality final product. Well, you know what Linus says[1], right. :) If it was that easy as you say, someone would already did it. Ondrej [1] http://lkml.org/lkml/2000/8/25/132 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
