On Dec 20, 2007 9:55 AM, John Cremona <[EMAIL PROTECTED]> wrote: > > eclib is ok (though I was tempted to make if jeclib ;))
If you make it eclib you increase the chances of getting outside contributions a little maybe. Also, I personally hope that your code gets picked up and improved a lot by other people in addition to you. Imagine if instead of starting from scratch the Magma or PARI developers had spent all their effort improving your C++ libraries, and making the results freely available and usable from their systems? Then eclib would now have 3-descent, 4-descent, S-integral points, etc. Just packaging your code in a way that encourages contributions could lead to just that sort of thing happening in the years to come. Also, packaging it with Sage means that basically anybody can trivially build all your code from source, and hence start working on it (without having to worry about build issues). > though it does > not capture the new modular symbol functionality, it is snappier than > (say) meclib. Of course we should have started to think about this > back at SD6. Your modular symbols functionality is all geared toward and motivated by elliptic curves, so I think it's an OK name. William > > > On 20/12/2007, William Stein <[EMAIL PROTECTED]> wrote: > > > > On Dec 20, 2007 4:21 AM, John Cremona <[EMAIL PROTECTED]> wrote: > > > Topic 2: package names. > > > > > > I am a little embarrassed that there is precisely one package (spkg) > > > whose name is a person's name (especially when it apparently results > > > in bug reports of the form "cremona causes fatal crash"). It has > > > never occurred to me to invent a name for my programs collectively > > > though. > > > > * How about "eclib", for "elliptic curve library"? > > Googling for that suggests it would be a good choice of name. > > > > * "ecl" is not a good choice, since it is already taken by a programming > > language and a lisp implementation > > > > > > > > > > Topic 3: trac #1058: the mwrank interface barfs on bad input > > > > > > The issue here is whether to extend mwrank_EllipticCurve to allow > > > curves with rational (as opposed to integral) coefficients. I have > > > been thinking about this. I do not want to rewrite my elliptic curve > > > code from scratch, but some things would be relatively easy: > > > * allowing the mwrank binary to accept 5-tuples of rationals to define a > > > curve > > > * allowing the two_descent class (which computes rank and the MW > > > group) to accept rationals > > > -- in each case, the generating points returned would be correctly > > > mapped back to the input not-necessarily-integral model. > > > > > > But it would be a lot harder to extend this to all the other > > > functionality, to the extent that a Sage user could construct an > > > mwrank_EllipticCurve which was not integral. Since I guess hardly any > > > Sage users actually construct mwrank_EllipticCurves anyway, would that > > > be a problem? > > > > I think making mwrank_EllipticCurve give an error on non-integral > > input is fine, since nobody should use mwrank . Transforming a > > curve to integral form first should be done in Sage. > > > > OK, so I will add the functionality to allow rational input both for > command-line mwrank and for the two_descent class which Sage's rank > function calls. Watch this space. > > John > > > William > > > > > > > > > > > -- > John Cremona > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
