On Jan 14, 2008 8:07 AM, William Stein <[EMAIL PROTECTED]> wrote: > > On 1/14/08, John Cremona <[EMAIL PROTECTED]> wrote: > > > > I think that as more people use Sage -- especially to do highly > > nontrivial computations like this, which are likely unavailable in > > other systems -- we will get more cases like this. >
> This isn't a highly nontrivial computation that couldn't be done in > other systems. It uses formulas that algebraic geometers came > up with that make it fairly explicit to compute certain invariants. > It is maybe a little like computing the "arithmetic genus of a degree > d plane curve", but of course it's much more complicated than that. > > I make no claim for this being difficult to code. I did it yesterday afternoon, after finally understanding the relevant passages in Hirzebruch's book. I want to make sure I understood. > > > So, to be > > realistic, there should perhaps be two stages to the "publication" of > > such things: > > > > (1) the .sage file (or files) are distributed by the author, ready to > > be attached by users; > > (2) a spkg is made for incorporation into Sage long-term. > > > > For (1) we have (as far as I know) no mechanism yet for maintaining > > any kind of repository of third party contributions. Should we have > > one? It would have to be the original contributor's responsibility to > > keep it updated for different Sage versions, otherwise we might as > > well go straight onto (2). A package in category (1) would come with > > no guarantees to work with later Sage versions, and no imprimatur > > (refereeing etc). > > > > For (2) we should have clearer instructions on what to do since it > > clearly isn't so obvious. > > > > As I was writing (1) above I could tell that others would probably not > > like it. In which case it is even more important that we make (2) > > easier. > > I think the best thing to do is to continue what we've been doing, > which is finding ways to make "third party" contributions part of the > core system, > and turn "third parties" into Sage developers as quickly as possible. > > Having only packages that are part of the main system is something > Magma has been doing for many years, and I think it is > one of their great strengths. It's completely different than what's done > in GAP, with their pages of third party packages, > and I think what Magma does in this regards > is much better, since it clearly addresses the fact > that end users want something that just works and just continues to work. > Code that gets put into the main Sage library, is refereed, and is heavily > doctested has the best chance of actually continue to just work as Sage > evolves (even this isn't perfect, but at least it's better). And I think > we've > finally just started to get our heads around how to make this process > work well. > > One thing we're missing is more in the way of narrative about new code. > E.g., > it might be very good if we required at minimum a good old-fashioned 2-3 > paragraphs at the top of new files explaining what they are about. Since > I > just made that up, it is probably not the right suggestion. But something > more of a narrative would be good. > > -- William > > > > --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
