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
-~----------~----~----~----~------~----~------~--~---

Reply via email to