On Tue, 2011-07-26 at 08:30 -0700, Bill Hart wrote:
> Hi Simon,
>
...[snip]...
>
> 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.
>
> A lot of Pari code is especially difficult because it uses messy stack
> allocation all over the place. This is not thread safe and it is
> difficult to read and contribute to. If I wanted to make Pari really
> easy to contribute to and understand, I'd probably use garbage
> collection for all but the core arithmetic routines. I'd still make
> the core threadsafe though. I believe flint2 proves that this is
> possible in an efficient manner without messy stack allocation
> routines.
>
> The Pari developers might also like to consider people who wrote the
> Sage wrapper for Pari as contributing to Pari and credit them as
> such.
>
> It is in matters like these that Sage has taken a massive first step
> towards making Computational Number Theory a respectable sport. Whilst
> it doesn't address all the issues I raised in my earlier post, it has
> taken the field from being a mass of poorly documented, broken, non-
> portable, incompatible code lying around on people's hard drives or
> locked up in inscrutable closed implementations to being a unified
> distribution which meets some minimum standards. The code in the Sage
> library is open and easily accessible. Every function has a docstring
> and doctests (alright, that's a lie, but it's almost true). Library
> code is subjected to some kind of peer review. References to papers
> are provided. And moreover, Sage builds on multiple platforms and is
> tested regularly so it is more useful for some people. These are all
> very important first steps in bringing the field into good repute.
> None of these things seems to have hurt the popularity of Sage.
>
> Having said that, I personally find it very difficult to trace through
> which algorithm is used in what regime in Sage. I once made some
> comments about which algorithms were used in Sage in a certain regime
> and someone lambasted me for getting it wrong. I subsequently
> carefully checked it through, following the rabbit warren of function
> calls across multiple interface boundaries through many files
> separated across vast reaches of the Sage directory tree and I am
> convinced I had the details substantially right. Of course if we just
> relied on Sage documentation to tell us what algorithm is being used
> in which package, we'd get it wrong much of the time, because that
> relies on the documentation having been maintained correctly. But at
> least Sage makes a step in the right direction. I've had similar
> issues trying to trace through the linbox package to figure out which
> algorithm is used.
...[snip]...
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.
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.
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)
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.
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.
Tim Daly
d...@literatesoftware.com
d...@axiom-developer.org
--
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
