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.

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?



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. 




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.

Sage has some deep problems which have yet to surface. 
 - It suffers from the namespace problem that Maple struggles with. 
 - It suffers from the performance issues of multiple systems being 
   called by intermediate parsers from an interpreted core. 
 - 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.
 - 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)
 - 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?
 - 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.
 - the list goes on....


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.

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.

Tim


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to