On Thu, Jul 2, 2009 at 12:15 AM, Dag Sverre Seljebotn<da...@student.matnat.uio.no> wrote: > > William Stein wrote: >> Perhaps I'm missing the point, but I'm taking this as a message to >> focus in Sage more on the algebraic/symbolic side of mathematics >> (e.g., Magma, Maple, Mathematica) rather than the numerical side, at >> least for the time being. I don't have a problem with that >> personally, since that is what I do best, and where most of my >> personal interests are. >> >> My impression is that Enthought is the overall the leader in the >> effort to create and distribute scientific computing tools using >> Python. The founders of the company have a clear passion and love >> for this, and seem from the outside at least to have simultaneously >> done well for their clients and developer and user base, while walking >> the tightrope of commercial versus open source. Part of that >> balance has been for the most part drawing a line and *not* having GPL >> or LGPL code in the core of their codebase. I do not in any think >> that is "morally wrong" (I obviously prefer it to the situation with >> my Microsoft neighbors). However, since Sage is a GPL'd project, this >> has the natural corollary that almost no two-way technical interaction >> is possible between the two projects. As result, the Sage project and >> the Enthought/Python stack tend to compete for users rather than share >> them, since they really are two different platforms (at least at some >> layers, especially the GUI/graphics layers and distribution system). >> >> I think it's roughly reasonable to call the top 7 most popular topics >> in your tutorial list basically "the Enthought scientific computing >> stack". The bottom four are (L)GPL'd, one is Sage and another in >> Sage. >> >> The best conclusion I can draw from all this is that for now at least >> I'm going to focus on symbolic/algebraic computation, and let >> Enthought continue to do a great job building the Python numerical >> stack. If at some point users in the numerical Python community >> really want what Sage has to offer, maybe they will do the extra work >> to make Sage work for them. If not, they still have a great >> Sage-compatible platform on which to build their work. No matter >> what happens users win. >> >> Perhaps "numerical Python people" are the right people to make Sage >> very numericaly Python friendly. The vast majority of Sage developers >> are not "numerical Python people", and so maybe we have no clue what >> should be done or how to make Sage what you guys want. I know very >> well what number theory researcher mathematicians need out of Sage, >> and I can't imagine that say Dag knows what number theory research >> mathematicians need, nor should he, and even if I explained it in >> detail, I wouldn't expect him to do the work of implementing it. >> >> The remaining people -- like Brian Granger, Ondrej Certik, etc., -- >> are clearly already doing what numerical folks want wrt Sage, which is >> to remove almost everything in Sage that is of interest to 95% of Sage >> users/developers (groups, rings, fields, matrices, 2d and 3d plotting, >> etc.)., and making a distribution (SPD) that satisfies precisely their >> needs. >> >> I think I'm not uncomfortable with any of the above, unless of course >> I'm totally wrong, in which case I would like to know why. > > I think something important is missing from the picture: > > NumPy/SciPy isn't exactly a majority player either! In large parts of > science and engineering the big M's (mostly MATLAB), Fortran and to some > extent C++ are the only tools people have even heard of. (In my department > few have even heard about Python.) > > Looking ahead, it might be that Mathematica is what is likely to supersede > MATLAB, not any form of Python (according to one source of opinion -- I > don't know much about this myself). > > Now SciPy, EPD, SPD etc. is great for people who know programming, and who > want a better mix of software engineering and numerics/science packages. > But, I don't see them ever becoming the simple, unified mathematical > package which engineers could learn as their first tool in college. (And > where 1/10 is by default something decent, yet numerics easily > available...) > > I see in Sage (proper, not SPD!) the hope of something I really, really > want, and which I think SciPy/Enthought/SPD isn't even trying to do. > Obviously, the SciPy conference people are the selection of people who > wants what the SciPy stack does though. > > The prime audience of a hypothetical numerics-boosted Sage are all of > those who are likely unaware of the existance of Python in the first > place, and those obviously haven't voted here (many of them don't even > have the software skills to attend SciPy 09). > > All I can do though is ask you not to close the door for numerics if and > when somebody steps up to lead the charge. > > Dag Sverre >
I think you're absolutely 100% right. I received other email offlist from people pointing out exactly the same point. Many thanks for the above clarification. I indeed did completely miss the point. OK, any volunteers to lead the charge? :-) -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---