On Jul 1, 2009, at 3:15 PM, Dag Sverre Seljebotn 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).
I think you've hit the nail on the head here. These were my first thoughts (other than disappointment) when I saw how low Sage got ranked in the list. I think Sage has a huge amount to offer by bringing the power of the SciPy stack together with the ease of use of the notebook (interact, visualization, etc.). Of course there's still a lot of work to do here... Currently the way to do numerics in Sage is to import scipy and numpy (because they really have created a good stack), and turn off preparsing (because those type issues get really annoying). At this point, it may become unclear why one is using Sage instead of the SciPy stack itself. The fact that most Sage examples and discussion revolves around "esoteric" things like Rings and Categories and Modular Forms just promotes this view. Dag, if you put together a list of why Sage isn't good enough for you, that would be very interesting. I wonder if many things on that list would be desirable for non-numerical use as well. - 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 -~----------~----~----~----~------~----~------~--~---
