On Sun, Jan 30, 2011 at 5:20 PM, daly <d...@axiom-developer.org> wrote: > On Sun, 2011-01-30 at 13:52 -0800, William Stein wrote: >> On Sun, Jan 30, 2011 at 9:23 AM, daly <d...@axiom-developer.org> wrote: >> > >> >> >> >> 3) I think the issue of crackpots and bad code dragging things down is >> >> not much of a problem. The reason is that it takes quite a bit of >> >> perseverance to get code into Sage. My experience with my Jmol >> >> contributions is an example. I would not claim to be the best coder, >> >> but think my Jmol contributions addressed some issues people had. >> >> And certainly the code is not yet ideal, but it does do most of what I >> >> understood people to want. Because of the load on people doing >> >> testing, it has taken months to get much feedback on it. This means >> >> anybody submitting code has to be willing to stick with it and prod it >> >> along over the long term. People who are not serious won't do this. >> >> My example may be a little slower than many people's because I also >> >> have very little time to contribute to this, but I still think you are >> >> unlikely to get really bad code included using the present model. >> > >> > To quote the above "This means anybody submitting code has to be >> > willing to stick with it and prod it over the long term". >> > >> > The real problem with Sage's development model will not show up >> > for a few years. >> >> How long do you mean by "a few years"? > The major packages, Maxima, Reduce, Axiom, Mathematica, Maple, > and others of that ilk are 30+ years old. So I would define > "a few years" as the time it took the project to move from > the primary authors to a "second generation" support role. > > How long will this take for Sage? Well, as I recall you have > said that you plan to move on to doing number theory work > rather than system development. Indeed, I suspect that the > pSage effort is a first move in that direction.
I've written thousands of lines of code in the last few months. And I'm currently organizing (and actively participating in) numerous Sage development workshops this year. >> > At the moment most of the code being contributed >> > is supported by the original authors. >> >> I don't know what you're basing this vague claim on... >> >> > The algorithms are complex >> > and some implementations are only competitive when optimized into >> > Cython, despite the "Sage is Python" mantra. >> >> There is no "Sage is Python" mantra. Sage is a mathematical >> software system, some parts of which are written using Python, and the >> interpreted user language of Sage is indeed Python. > Umm...ok. It has been my impression that "Sage is Python" has been > one of the major bullet points of the project. I remember a discussion > about rewriting things like integration into python. But my memory is > not what it used to be so perhaps I'm mistaken. You're right, there are many, many discussion about implementing algorithms in Python. I think that's different than "Sage is Python", whatever that means. >> > The real problem will arise when these authors leave the project. >> > Code rots. People make simple changes. Linux changes libraries. >> > Who will be able to debug research-level elliptic curve code >> > when some minor, unrelated change breaks it? >> >> I can easily think of at least a dozen people immediately. But given >> that you're worried about "a few years", and you didn't define what >> this phrase means, it's perhaps not possible to answer your question. > > There is a distinction between "those who can" (e.g. Victor Miller) > and "those who will", especially if the bug is upstream. Tracing a > bug through the inheritance hierarchy, into Cython, and then into > an upstream linked library is not a trivial exercise. New people pop up regularly who can do that. If anything, youth, a fresh perspective, and the desire to fix the bug "no matter what" is vastly more valuable than being the original author. At the last Sage "Bug Days" (http://wiki.sagemath.org/days27) there were at least 10 people who I had never met before there, and some of them did "trace a bug through the inheritance hierarchy, into Cython, and then into an upstream linked library"... The best thing to do for Sage is to make it more and more developer friendly, open, and encourage more people to get involved. The typical talented and highly motivated people (especially the grad students and young postdocs) that come to Sage Days are often better at fixing difficult bugs in Sage than I am, because they are so motivated, they know enough math and programming background, and they can *think* clearly and logically. That's all it takes. > Pick a python-implemented algorithm of high complexity and we can > reconsider the point, possibly algorithms with subfield structures > and uniqueness of finite fields? Surely there must be some high > complexity algorithm in python that depends on upstream libraries. > Choose one. I can't think of any, except _maybe_ in graph theory, maybe (see networkx). I think this is because Sage is the nearly the only project that implements sophisticated non-numerical mathematics algorithms directly in Python. There's tons of numerical code in Python (e.g., scipy, numpy, cvxopt, etc.), but that's certainly not the foundation for anything like "subfield structures and uniqueness of finite fields". > In both cases the forks conflicted with published project goals. > If I started rewriting Sage into Lisp, for instance, we would > eventually have a parting of the ways and my only alternative > would be to fork Sage, as that would conflict with project goals. It depends on what you implemented in Lisp and if was useful. If you sat down and implemented some algorithm in Lisp to compute some interesting function f(N) say (e.g., say f(N) = number of partitions of N), and it was better than the code in Sage already, we would be happy to include it in Sage. We do ship ecl (=embedded common lisp) as a standard component of Sage, and there are no plans to ever change this. We also ship a working Cython library interface to ecl, which is supposed to be fairly powerful, and would make it possible to call your f(N) very efficiently from the Sage prompt, with no fragile or stupid overhead. So far as I know, the only lisp code in Sage, is code that is in Maxima. However, I don't see at all why it isn't conceivable that there could be a lot of new interesting Lisp code in Sage, were people able to actually find any good ways to make use of Lisp. Recently, Bill Hart has been experimenting with using Lisp to implement highly optimized mini-languages. Supposing he has some breakthrough, I could certainly imagine one of these languages actually getting included in Sage, and being used by people. If it is genuinely useful... > So that's the report you asked for. I don't know if creating > a divergence from the stated project goals would be correctly > characterized as "scaring off most of the contributors" but you're > welcome to your own description of the process. > > Now that we've gotten past the axiom-directed non-issue I again ask: > How do we architect systems to survive the loss of the authors? I think a better question is: "How do we architect systems to encourage new people to join the project?" Instead of worrying about a negative, we instead focus on a positive, which more than cancels out a negative. Your question is like "How do we architect a company to survive the loss of the customers?" when instead one should ask "How do we architect a company to encourage new customers to buy our products?" >> > How do we architect systems to survive the changing platforms? >> > Will Sage live? >> >> It will have at least a 6-year lifespan. :-) > > Well I believe that you have the basis for an existence proof > of your statement. :-) > > I believe there is an emerging discipline of computational > mathematics which requires both a deep mathematical background > and a deep programming background. Sage could make the claim > that it is a good basis for an interdisciplinary degree or > even a separate department that provides an equal focus on > both subjects. If Sage, with both its mathematical and > algorithmic focus, was brought forward to the NSF as a > broad-curriculum basis I believe it could be funded as such. I think you are right. Here's a "little lemma" that points in that direction: http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=1020687&WT.z_pims_id=5741 and http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBMQFjAA&url=http%3A%2F%2Fbuzzard.ups.edu%2Fprivate%2Fnsf-ccli-proposal.pdf&ei=Yh1GTfiTN4n0tgP5pfWOCg&usg=AFQjCNFXFihZ_7BhSIDN2-yH9iUFbm3HDA > In fact, as an open source effort, Sage offers what Mathematica > and Maple cannot, namely the ability to see and modify the > algorithms. From that we can train "computational mathematicians". > Eventually we might not have to ask "I'm a programmer..." style > questions. We need only look for a Bachelors of Computational > Mathematics degree. This might require a proposal involving > several universities and, unfortunately, I am not in a position > to write proposals for NSF grants (I've asked several times). > > So I'm suggesting that there is an opportunity to think big > (whole degree programs), long term (30+ years), and fundamental > (how to architect for survival). There is a degree program at University of Washington called "Applied and Computational Mathematics" -- http://www.math.washington.edu/acms/ It's pretty popular. I gave an ACMS seminar talk on Sage a few weeks ago, which was very well received. Perhaps someday Sage will infiltrate the ACMS program further, when Sage curriculum materials exist that make it more friendly for applied math... (MATLAB is clearly still more user friendly and more curriculum materials exist, than with Numpy/Scipy/Sage, and MATLAB exists on Windows.) > Axiom, by the way, has exactly these goals. But I welcome and > encourage the competition as I think it will help us all. Me too. I encourage you. :-) -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
