Topic 1: isomorphisms between Weierstrass models For Robert B as author of weierstrass_morphism.py: It's not a bug but I would recommend that you test for equality of j-invariants before doing the harder work (which you do by extracting 12th roots of the ratio of the discriminants). Similarly in
elliptic_curves/ell_generic.py in the function is_isomorphic(). Also, I am yet to be convinced that the code in weierstrass_morphism.py is correct, but I will reserve judgement until I have a counterexample. It certainly is *not* correct in char. 2 & 3 since you divide by 2 and 3! I have always done this using the ratio of c4 and/or c6 invariants, which is fine except in characteristics 2 and 3 anyway, and also simpler (since unless j=0 or j=1728 you only need to test for something being a square, not need for 12'th roots). That code can already be found in simon's ellQ.gp (the new version incorporating some improvements I suggested to him). But it does not deal with char 2 & 3, which I'll sit down and work through one day, and then submit an improved version of weierstrass_morphism.py. 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. Anyway, given this, having types in Sage such as mwrank_EllipticCurve seems odd now that the mwrank package has been superceded, and logically they should probably be called cremona_EllipticCurve -- at least until I decide that may package should be renamed foobar at which point they'll have to be foobar_EllipticCurve. 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? John -- 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/ -~----------~----~----~----~------~----~------~--~---
