Thank you very much for agreeing to work on this Michael. Way down the road, thin will be a big deal i think.
On Mon, Apr 21, 2008 at 8:45 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---