OK, so I was perhaps over-enthusiastic in my praise! But it is still useful to have done this, so thanks.
John On 14/01/2008, D. Benjamin Antieau <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > > > > -- John Cremona --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
