On Jul 26, 7:02 pm, daly <d...@axiom-developer.org> wrote: > On Tue, 2011-07-26 at 08:30 -0700, Bill Hart wrote:
<SNIP my long blurb> > To paraphrase your above comment, I believe that we need to raise the > standards of computational mathematics further toward being "a > respectable sport". > > Consider your observation: > "Of course properly citing Pari and the algorithm used and checking > under what conditions the result is meaningful, etc, assumes that > these things are well documented and accessible. So, a positive step > the Pari developers could take is to make it easy to read the source > code for a given function in Pari, much as Sage has done for Sage > library code, and to document the algorithms used and where they are > published and what their restrictions are." > > In regular mathematics it is standard practice to fully document, that > is, show the complete proof of your findings. In computational maths > we do not do this. There is no particular reason why we don't except > that it is not the expected behavior. Unfortunately this is rarely true these days. In regular mathematics it is now very common for there to be large leaps between steps. Usually the more advanced the mathematician the less detail that is expected. Graduate students spend a lot of time filling it in. But your point regarding computational mathematics is spot on. It is very common to find code completely undocumented in any way. There is a substantial disparity in attitudes here. When I began my massive rewrite of flint from scratch I decided that each function would have a complete description and justification of the algorithm (if not well-known) in an associated text file, with references and proofs if necessary. Sebastian Pancratz came along and saw these text files and decided to write a parser that automatically turned them into pdf documentation! > > We could raise the bar of expected behavior by having algorithms fully > explained in the source code along with citations of theory sources. We > could include a section on limitations, boundary conditions, examples, > assumptions, and test cases. This is not as challenging as it sounds > if it is done by the original author. It is extremely hard to recover > or discover this information after the fact. To a good extent this is done in most of the Sage library. I agree this should be the expected standard. Again I have to credit Sebastian Pancratz and Fredrik Johansson here for raising the standard in flint. I thought I had been producing beautiful code until Sebastian started rewriting some of it for me. :-) > > Knuth proposed the idea of "literate programs" which combine the > actual source code with the human language text as a single document. > The document re-arranges the source code for ease of explanation and > includes the usual paper sections on background, theory, along with > a bibliography citing prior (literate) work. (See Queinnec, Christian > ``Lisp in Small Pieces'' ISBN 0-521-56247-3 for a literate example) My favourite example of this is Jonesforth. I highly recommend anyone who has not read this program to do so immediately. It is one of the most beautiful documents you can obtain for free. And you get yourself a Forth implementation at no extra cost. I don't personally do literate programming in the sense you intend it, with rearranged code so that it reads more naturally. But for very complex and touchy pieces of critical code I sometimes add formal justifications for every line of code. A good example of this is the bitpacking code in flint. > > We could take small steps in this direction, possibly by hosting a > "literate program" track at conferences or workshops to encourage the > more literate among us to show examples and build up the technology. I could certainly imagine a talk being constructed around an actual program. I might try this one day and see how it goes. > > Raising the standards for published mathematical software will help > us all in the long run. We can look forward to a time when we can > read, understand, and cite particular Pari and Sage algorithms which > are their actual implementations in literate form. > It's not the only important step that needs to be taken though. My epiphany regarding automated program checking came when I serendipitously encountered a fantastic book on Prolog on the exact same day that I sat down to implement Damas-Hindley-Milner type inference for an interpreter I have been writing. I marvel that a 20 line implementation of the unification algorithm saves me so much hassle. After this little epiphany I have not had any problems seeing the future. Type inference and unification have been around for ages, but I feel like someone who has been in a time machine and returned and who has to sit around and watch the inevitable development of the compiler technology that I have already seen. Progress feels like a slow motion replay. Bill. -- 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
