On Wed, Jul 1, 2009 at 1:43 PM, William Stein<wst...@gmail.com> wrote: > > On Wed, Jul 1, 2009 at 8:50 PM, Fernando Perez<fperez....@gmail.com> wrote: >> >> Howdy, >> >> On Wed, Jul 1, 2009 at 3:57 AM, William Stein<wst...@gmail.com> wrote: >>> I have to add that not only is Sage very low on the above list, Sage >>> got the *most* "no" votes from the 30 people who actually voted (tying >>> only with Networkx), according to the table here: >>> >>> >>> http://fdoperez.blogspot.com/2009/06/scipy-advanced-tutorials-results.html >>> >>> I don't know if I should interpret this as: >>> >>> (1) Sage doesn't at all provide what is needed by "the scipy community", >>> or >>> >>> (2) The scipy community has a strong opinion that in fact sage is >>> worse than useless. >> >> I have to say that *personally* I was both surprised and disappointed >> at the low ranking Sage got, since I was hoping to have a Sage >> tutorial again this year. On every talk I give on scientific >> computing with Python I always make a point of highlighting Sage, I >> use it myself and I think it's a key asset of a larger ecosystem of >> open source tools for scientific computing based on Python. But all >> I'm doing here is reporting the numbers as they came: the only change >> I made to the raw Doodle data was to remove the voters' names and >> transpose the table for readability (Doodle returns each topic as a >> column, which is annoying to read). >> >>> It might also be relevant that Sage, Hermes, and Networkx (in the >>> bottom 4) are all GPL'd, but the top 7 packages by interest in the >>> list above are all non-GPL (BSD or MIT licensed). It may just be >>> that whoever voted are mostly people who believe they can't use GPL'd >>> code. >>> >>> Anyway, I find Fernando's justification for the ranking "the ranking >>> roughly follows the generality of the tools" to be an unsatisfactory >>> explanation or summary of the data. Rather, perhaps the ranking >>> roughly follows the restrictiveness of the *license*. >> >> That was just a hand-wavy argument, since ultimately I can't know why >> people voted the way they did. I should note that Networkx is LGPL, >> not GPL; see >> https://networkx.lanl.gov/trac/browser/networkx/trunk/doc/GNU_LGPL.txt >> and >> https://networkx.lanl.gov/trac/browser/networkx/trunk/networkx/release.py, >> which specifically contains >> >> 1 """Release data for NetworkX.""" >> 2 >> 3 # Copyright (C) 2004-2008 by >> 4 # Aric Hagberg <hagb...@lanl.gov> >> 5 # Dan Schult <dsch...@colgate.edu> >> 6 # Pieter Swart <sw...@lanl.gov> >> 7 # Distributed under the terms of the GNU Lesser General Public >> License >> 8 # http://www.gnu.org/copyleft/lesser.html >> >> So the bottommost project (which as I mentioned, I also love and >> wanted to get a tutorial on) is not GPL. >> >> I should have definitely qualified my 'generality' comment by pointing >> that Sage was the outlier in this (weak) pattern: while finite >> elements, time series and graph theory are specialized topics, sage is >> a super-broad-spectrum tool, so it definitely doesn't fit that trend. >> That point was clear to me and did surprise me very much, I just >> failed to mention it last night (I wrote that blog post rather in a >> hurry, tired, and was mostly annoyed at blogspot's mangling of the >> table html). >> >> I sort of doubt that most people would make their decisions on what >> tools to learn based on licenses, or at least I hope that's the case. >> But perhaps I'm wrong on that and just naive... > > 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 you are all drawing too many conclusion from the poll -- it's just 30 people, so that's nothing and I definitely not think that this is the whole scipy community (if it was 200 people, then I would take it seriously). I can see that William is disappointed, and I am half --- sympy made it through, but finite elements (which is the project I am actually paid for) didn't and actually ended up just before NetworkX -- but I need to tease Aric here that even FEM ended above him. :) Besides I think the poll was for a tutorial for this particular conference --- I forgot how I vote for Sage, but I remember that I picked those tutorials, that I may actually learn something that I need for my work. E.g. like traits or cython. As to Sage + numerics --- I want that to work and I am actually trying to get something done in this area. For example last couple weeks I already spent *dozens* of hours (yes, it's a lot, but I think it's just that I am not particularly good at these things) gettting various packages to compile in SPD, and any Sage users can immediately benefit from that, since you just install that spkg inside Sage. Besides that, we want our finite element software to be working well with Sage too. Here is my latest progress: http://code.google.com/p/femhub/ I made 4 releases in 5 days. For Sage users, I suggest to just use Sage. SPD is a base for projects like femhub, where people need to create a Sage like project, but with our own packages. Sage itself compiles too long and as William pointed out, we don't need 95% of the packages there --- also I *need* the thing to build on our clusters --- and so far Sage can't do it, so I decided to concentrate on packages that I really need for my work and make sure at least those compile. Also, we want our own branding, e.g. call it femhub, so I will soon do some changes to the notebook spkg. In the long run, I expect that Sage will grow and it will include our improvements and packages and distribute everything at once (it will be couple hundreds MB bigger though). And it will contain both symbolic and algebraic/number theoretic stuff and numerics stuff like finite elements + related visualisation tools like mayavi... And I also expect that people will continue branding Sage for their needs, e.g. in our case we'll just call it femhub and that will be our own thing that we do. And that below the hood it's just sage and it's compatible with sage, then Sage users can just continue using Sage (+ our packages) and don't care. As to the license, that is not an obstacle for me (I am talking about the license for the whole thing), but it is for Enthought and I will definitely talk with them what can be done, so that they can use the same model as Sage. Honestly I think that if the Sage scripts can be made BSD, or rewritten from scratch to be BSD (and I have looked at that and I think it's definitely doable), but keeping it *compatible* with Sage (that's the crucial part), then Enthought and other people can just take BSD spkg packages and release what they want with it, or sell it or do whatever they want with it, and Sage itself (that contains lots of GPL packages and also lots of new code that is also GPL) will just continue being GPL. Honestly I think the build infrastructure should be BSD, but I know that some people are against it. Rewriting it from scratch is doable but very low on my priority list, because I also use GPL packages (and actually most of my colleagues in our group are against BSD too, ironically:)), so femhub has to be GPL anyway. But getting Enthought involved in this is imho a good thing, so I will definitely talk with them about it at scipy. Ondrej --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
