On Dec 29, 2008, at 9:13 PM, root wrote: > >>> I think there might be a bit of overconfidence in assuming that any >>> one of the "top 10 Sage developers" is going to reproduce even a >>> fraction of that complexity in the near term. >> >> That's not what is being discussed. The question is about the >> technical feasibility of removing lisp/maxima from the core of Sage. > > ...[snip]... > >> The rest of your email is interesting but off topic, where I hope the >> topic of this thread will stay: "technical feasibility of removing >> lisp/maxima from the core of sage (they will instead be optional)". > > A strawman argument? Surely you can simply remove Maxima by .... > simply > removing it. If you don't wish to discuss the complexity of replacing > the removed functionality then I don't see that this thread has any > content at all. Simply remove Maxima and be done with it. > > I'd have thought that implicit in removing Maxima would be an effort > to replace the lost functionality. That implies an evaluation of the > complexity of the problem, which I was trying to give based on facts. > > I've clearly misunderstood. Sorry for the off topic post.
I didn't think your post was completely off topic--completely reproducing all the functionality of Maxima and/or Axiom/Fricas is clearly out of the question, at least for "a couple of weeks (or even a year) of hard work by any Sage developer." However, being able to perform symbolic integration and other related problems is a small part of what Sage does, and seems to be a more significant part of what Axiom and Maxima are about. On the other hand, despite it being a small part of what Sage does, calculus is certainly a hugely important feature for the majority of potential users (probably more so than anything else except numerical computation à la Matlab/SciPy) and is essential to have to even talk about competing with Maple/ Mathematica. I think the real questions that need to be answered are (1) how much of Sage (the non-calculus modules especially) would break if we didn't ship maxima, (2) how much of it could be easily fixed without needing aforementioned 300 "man-years" of sophisticated code, and (3) how much functionality would we be willing to lose in the Calculus modules (e.g. would it be acceptable to be able to do almost any integration problem out of a standard calculus text, but require an optional spkg to do something more sophisticated). It is important to note that moving something to an optional and rarely used spkg will probably have a negative impact the upkeep and reliability of the maxima interface, which I think would be an unfortunate step backwards unless we provide most of functionality elsewhere. > What puzzles me is the cognitive dissonance between the Sage goals > of "not re-inventing the wheel" and "working to connect existing > systems" and the apparent rejection of the largest bodies of CAS > work in systems like lisp/Maxima. The code needed to cleverly > connect Maxima to Sage is SO many orders-of-magnitude easier than > the code needed to reproduce Maxima functionality that I'm at a > complete loss to explain the rejection. > > So the question I have is: Why not devote some of the top 10 Sage > developers to figure out a clever, more generic, more well-designed > API between Sage and Maxima? Even better would be a way to inline > Lisp code in Python and then you can execute Maxima code directly. This is somewhat a technical question, and I think needs some answering. I agree there could be a lot of improvement in the sage- maxima interface, even without abandoning the pseudo-tty interface (e.g. being able to pass/manipulate parse trees directly and use it in more of a library mode, rather than the current interactive interface) and being able to access the lisp interpreter would be great. However, building a working lisp system, and a working maxima on top of that, which compiles and functions correctly out of the box on the wide variety of platforms we target, seems to be an large drain on resources and making a better interface doesn't solve this problem. Of course there are other issues as well, but now we are clearly straying from the original (and much less controversial) intent of this thread. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---