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

Reply via email to