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. > 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 [email protected] 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/ -~----------~----~----~----~------~----~------~--~---
