On Apr 30, 2008, at 6:38 PM, root wrote:
> > David, > >>> But we've already had this discussion and it is clear that I'm >>> completely out-in-the-weeds, talking-nonsense, and obviously have >>> no idea how REAL-open-source-projects are done. So lets just leave >>> it where it left off before, which is that I've simply dropped the >>> attempt to give the benefit of experience. >> >> Hi Tim, >> >> I've been vaguely following your posts to this list over the last few >> weeks. I don't think you're talking nonsense, but I don't completely >> understand what point you are trying to make. You seem to be making >> the following argument, correct me if I'm wrong. You claim that the >> documentation of the implementations of algorithms in Sage is not >> good enough, in the sense that someone looking at the Sage codebase >> in a few years won't be able to understand what is going on. You >> conclude that Sage will die. The implication is that the way to fix >> things is for us to improve the documentation of these >> implementations (perhaps via literate programming or whatever), so >> that Sage will be more likely to succeed. >> >> But isn't the core problem simply one of limited resources? We all >> have limited time (fields-medallists and non-fields-medallists >> alike), and so there is some tradeoff between getting something to >> work as quickly as possible (and hence is useful NOW) and making a >> beautiful product which meets higher standard of scholarship (and >> hence is more useful LATER). I can't see any way around this >> tradeoff. The only thing I can see that will stop a project like Sage >> from dying is to keep building a steady inflow of users and >> contributors, so that the knowledge you refer to remains as alive as >> possible. >> >> david > > I've been associated with some open source projects, and in > particular, > with Axiom, Magnus, and Doyen. And I've been programming for 35 years. In the interests of full disclosure, Sage is the first open source project I've been seriously involved with, and I haven't even been alive for 35 years :-) > Once a week I hear the "I don't have enough time" argument. > > This argument is fine for most of the things I do, e.g. the things > I get paid to do because, frankly, almost nothing I've ever done will > be worth anything 10 years from now. > > Computational Mathematics is different in this respect. The answer > to integrate(sin(x),x) will be the same 30 years from now. However, > the expert who wrote the code will not. (Manual Bronstein is dead). > Who will maintain this code if it requires a PhD in Infinite Group > Theory just to understand WHY it works and a computer science degree > to understand what the PROGRAM is doing? > > The real tradeoff question is "Are you doing science?" or just > "playing around with ideas". Because, if you're doing science then > you're doing it for the community. Which means that there is a > standard of scholarship that is expected. > > When I read a proof of a new theorem I expect to see references > to prior results, complete proofs of lemmas, complete documentation > of assumptions, and a full explanation of the whys-and-wherefores. > It takes about 5-10 pages to reach this standard of publication > for most mathematics. And THAT TAKES TIME. > > So ask yourself the following question: > What is the "standard of publication" for COMPUTATIONAL mathematics? > > What *I* expect to see is an explanation of the mathematics, possibly > with proofs (if new). I expect an explanation of how and why the CODE > implements the mathematics. I expect complexity bounds. I expect an > explanation of optimizations that are not obvious but are critical. > This may take 10-100 pages to reach this standard of publication for > computational mathematics. and THAT TAKES TIME. > > If you haven't given me that level of documentation then you haven't > given me anything but your lab notebook. You've published nothing but > your scribblings to yourself with no assurance that (a) it is > mathematically > sound, (b) it is correct, and (c) the who/what/where basis for your > work is anything but your own self-mutterings. > > Do we build a science on this? No, I agree we can't build a science on this. But you still haven't told me: where is all this time going to come from? I can't magically make more time appear. I have other things to do. It's a damn shame. (Oh this reminds me of a wonderful novel by Michael Ende called "Momo", about a town that gets invaded by strange evil men in grey suits who trick everyone into putting their time in a special "time bank", and of course they never get their time back. Momo is a little girl who saves the world. Highly recommended.) > A few centuries ago a mathematician could claim anything by > handwaving, and "prove it" by solving the questions posed to him. > > In the last century the standard of proof has risen in mathematics > from handwaving, thru simple explanations, and eventually onto more > rigourous proofs. > > Computational mathematics, the collision of math and computers, > is still at the handwaving stage. But for a computer program, the standard of proof needs to be so much higher to be meaningful. I mean, plenty of mathematics papers have mistakes in them. *Lots* of mistakes. Even the ones you refer to above when you say "complete proofs of lemmas, complete documentation of assumptions etc". But they are usually essentially correct, and that's good enough for scientific purposes. For a computer program, it's usually not enough to be essentially correct. Surely you don't believe that anyone can sit down and write a computer program, beautifully documented according to the standard you outline above, and expect it to actually work? i.e. "Beware of bugs in the above code; I have only proved it correct, not tried it." To achieve this you would really need something like a formal proof of correctness (i.e. a computer-checked proof). This is incredibly time-consuming. I've never done any formal correctness proofs, but I've heard from Paul Zimmermann, who performed a formal proof for the square root code in GMP. > Sage is dancing around like it has discovered something new and > wonderful. But I've been in this business now since the late 80s and > Sage has done absolutely NOTHING that has not already been done > before. Maple used a highly popular language (C) as its basis for a > user interface, MMA used Lisp-like notation initially. Magnus > collected experts and was funded by NSF. Axiom was funded by NSF and > IBM. Axiom used to be "free and open source" when I was at IBM. If you > asked I'd send you a tape of the source code. Magnus has always been > free as Gilbert thought it was important. William Stein is a new > incarnation of Gilbert Baumslag, 20 years later, thinking he's > discovered something that nobody ever noticed before. I might be wrong about this, but I think one of the things Sage is doing that is new is the development model. I don't mean just that it's "open source" and "free software" --- I mean that we are taking advantage of technology (mostly web stuff) to make the barrier of entry for new developers incredibly low. You said above "If you asked I'd send you a tape of the source code". Sage is the same, except that you don't have to ask, and there's no tape. It's nothing particularly clever, but we are leveraging it. This single thing might well be the key thing that makes Sage "different". As an aside, while you might argue that in big-picture terms Sage is not doing anything new, there are plenty of examples of specific things in Sage that have demonstrably not been done before. Here are two examples of things I've worked on, both of which are in my phd thesis, and have also been published in separate papers, and are not implemented anywhere else: (1) computing p-adic heights of points on elliptic curves (pure python, building on work of Mazur--Stein--Tate, written in collaboration with various other Sage developers), and (2) an algorithm for computing zeta functions of hyperelliptic curves with complexity sqrt(p) and polynomial in the genus of the curve (C++/ NTL). The former is something not many people care about, but there are lots of number theorists who would find (2) useful. > Sage has some deep problems which have yet to surface. > - It suffers from the namespace problem that Maple struggles with. I think Python does a pretty good job with namespaces. > - It suffers from the performance issues of multiple systems being > called by intermediate parsers from an interpreted core. Yeah this is unfortunate. Hopefully this will improve over time, as we get more native code, and better direct library interfaces (for example the excellent work Martin did with Singular). > - It suffers from the "I can do it better", do-it-yet-again-in-python > syndrome, where it will be discovered that python is too slow > so we need to rewrite it in Cython and do obscure, undocumented, > performance enhancing software hacks. Yeah it's a bummer. > - It suffers from the "OpenMath" communication issue (e.g. if you > take an Axiom expression, export it to maple, compute with it, > and re-import it to Axiom you have violated a lot of type > assumptions in Axiom, possibly violated branch cut assumptions > (e.g. acosh), done invalid simplifications, and any number of > violent mathematical mistakes) I agree that this is a serious problem. I haven't thought much about this since I work mostly on much simpler data types (e.g. polynomials over a fixed ring). > - It collects system that will eventually lose their maintainers > due to the many reasons that open source software stops being > maintained. Will Sage simply drop the software you depend upon? I think you're not appreciating the feedback going in the upstream direction. When something gets included in Sage, it gets more attention, and often ends up being better maintained as a result. For example, the discussion going on with Magnus on the other thread. You said Magnus was essentially dead. But while I wrote this email, two people on this list have tried compiling it and already a patch was posted fixing a compilation error. It might well be included in Sage within a week. People will start writing an interface, and before you know it Magnus will have an audience again. > - It drops "legacy" systems. But mathematicians rarely, if ever, > upgrade to the latest tools and opsys releases. It is fine to > say "update your compiler" (twice replied to my bugs) to a > hacker like me but most people won't do it. The only reason it > is working now is that all of the code is "new". Wait 5 years > and you'll find out that most people drop the system because > it requires them to upgrade their whole working environment. I think there's a confusion here between people who build from source and people who are happy with binaries. > - the list goes on.... Indeed it does. > What I'm suggesting is that if they want Sage to be different from > the many other systems lying dead on the road (e.g. Magnus) then they > need to capture the expertise needed to write, maintain, modify, and > extend the algorithms AS THEY ARE WRITTEN. > > But the argument is "that takes time". But it takes MUCH more time to > reverse engineer a mathematical algorithm (if it can be done at all). > Believe me, I dragged in the fields-medal experts to try to document > Magnus and failed. Why didn't they document it as they wrote it? Where does the time come from? > If Sage can contribute anything it can contribute new algorithms. > (Because python is going to be a "cobol" language eventually). > But if those algorithms are not properly documented they will die > when Sage dies (just like the group theory algorithms in Magnus > are dying as Magnus dies). > > It frustrates me to watch so many mathematicians fling their > notebooks into the public domain thinking they don't REALLY have > to TAKE THE TIME to do it right. Where does the time come from? david --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
