On Jan 14, 3:07 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 1/14/08, John Cremona <[EMAIL PROTECTED]> wrote:
Hi,
sorry for being late to the party, but I had to catch up on sleep
first ;)
> > 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.
Yep, and it think it is a good sign that people want to contribute
their own code.
> 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.
Yes, the documentation on doing this needs to be written [improved?].
As David Roe pointed out that was a project at Sage Days 6. David, did
anything come of it? Does any text exist that could be merged?
> > 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.
Yes, that makes us different from the other commercial systems. There
are probably thousands of Maple/Matlab code snippets out there that
Maple/Matlab cannot or won't include because it is too specialized/not
where they see their market or not licensed properly for the,. We
should solicit those 3rd party authors to contribute their code to
Sage since
a) will bring in more Sage users [user to author: I want to use your
code. How do I best ...? author: install Sage 2.13.5 or later]
b) we will gain more developers
c) we will get design input from people who might come to a given
area with a different perspective, so that in the end we should end up
with a better design.
Obviously there needs to be code review and doctests, but we should be
working with authors to get their code in shape [if there is even the
need to do that - from William's email it seems that the code is well
written and well documented]. People who contribute should obviously
be added to ack.html :)
> 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.
Yep, +1 - pretty close to my point of view above.
> 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.
+1
> 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.
That would be nice and auditing our existing code to comply with such
higher standards is certainly needed. I.e. compare the goal for 50%
doctests for the Sage 3.0 release.
> -- William
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
