William suggested I forward/post the stuff I wrote on fricas-devel over there, too. Since his wish is my command ;) here we go:
On Apr 21, 9:46 pm, Robert Dodier <[EMAIL PROTECTED]> wrote: > On Apr 20, 9:29 am, "William Stein" <[EMAIL PROTECTED]> wrote: Hello folks, > > c) ecls: the ray of hope? Bug Maxima can't be build on top of it due > > to same issues with save and load image. > Well, if there is any interest in resolving the problems, > let's join forces then. I got Maxima compiled by ECLS some > months ago; there were some problems but if there is enough > interest, I would be willing to try again. This is excellent news. As I wrote in this thread over on sage-devel I am willing to put some serious time into getting ecls to build on Sage's current and future supported platforms as well do serious testing that Maxima works on top of it. And it certainly sounds like FriCAS would not mind ecls being in Sage per default instead of clisp since the clisp we shop seems to be too broken to support FriCAS. > > The current plan is to rewrite symbolic manipulation in > > Cython using lots of tricks so it will be very > > fast, flexible, and not depend on Maxima at all. > I have an agenda to push here, so you can take this with a grain > of salt, but: Lisp was invented in part to do the kind of > expression mogrification which is needed for symbolic > algebra. A symbolic system written in some other language is > probably going to replicate a lot of Lisp functionality. > I am pretty sure that trying to get Maxima recompiled with > some/any Lisp implementation will be easier than reinventing > both Maxima and Lisp. Well, we are looking at several problems here: a) we use Maxima via pexpect, i.e. we dump some data into ASCII issue some commands and parse the results. While that is something that works well for say integrals or ODEs it is a huge performance drain on arithmetic. For example: Moving some operation on permutation groups form GAP+pexpect to Cython made the operation 4,000 times as fast. The implementation in Cython is roughly 3 times slower than the same operation in the GAP kernel, but since pexpect is out of the equation the somewhat slower Cython implementation is a huge win since we have not connected the GAP kernel to Sage as a library. Nobody has attempted to do that, but it will likely be quite a bit of work and a large effort. b) Using Maxima in itself is not bad and the thread that started this whole discussion was motivated by build issues with self hosted lisp. Since Maxima is written in lisp and the only reason we ship lisp currently with Sage my desire was to solve the lisp build problem and Maxima would have ended up as potential road kill in the process. c) Maxima has a lot of well debugged, well working code, but it seems for many things the 4 Ms are much faster. Factorization is one example, I am not quite clear how Integration compares, but my general impression from alt.sci.symbolic is that it is not on par with the commercial systems [feel free to correct me]. d) Sage itself wants to compete with the 4Ms, but it isn't the only Open Source CAS out there, in fact it is a quite young effort and William's method called for building on top of existing systems. But while he went through what I call the "rapid expansion phase" it was more important to get things working than to implement because doing things "right" as you point out would take many, many man years of effort. But now people are demanding more performance and due to (a) symbolic arithmetic is being rewritten. And according to Gary [the guy implementing it] it is much faster than Maxima [even accounting for clisp vs. sbcl and so on]. I cannot verify the number but since he is quite serious about the issue and he really, really *needs* fast symbolics I have little reason to doubt him. So, now the question is: "Why doesn't he work with the Maxima code then and improve it there. Everybody would benefit [Sage & Maxima] and all the higher level algorithms would likely get a boost by it." And the answer is: Because he prefers not to use lisp and that is something that is completely up to him. It is difficult to recruit developers and most people in Sage prefer C/C++/Python/Cython over list just like Maxima developers prefer lisp. Both camps are self selecting, so no surprises there. But to get back to the issue at hand: Once Maxima runs on ecls nearly all the issues I have with the build side of things will likely evaporate and I will put my energy toward other issues. It would likely also lessen the drive to "get rid of Maxima" considerably, but I am certain that over the next couple years more and more functionality that Maxima provides by Sage will be implemented on top of other systems unless Maxima gets faster. Systems inside Sage compete and it would be naive to believe that Sage does not compete will all its components for users as well as developers. But in the end Sage is supposed to be inclusive and should function as a unifying force of the Open Source CAS world that wants to join efforts with us. We should not be fighting among ourselves for the table scraps of the 4Ms, but go on and be able to compete with them on features *and* performance. I am actually convinced that the mathematical Open Source community can come up with something better than the 4Ms since an Open Source development model can and has created software superior to anything commercial out there. > All the best, > Robert Dodier > Maxima developer Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
