On Jan 15, 2008, at 4:08 AM, John Cremona wrote:
> I think this computation (in the quotient ring) makes sense even if
> the ideal is not prime. I had already tried to do it that way, but
> failed.
>
> However I am not quite convinced that verifying P1+(P1+P3)==(P1+P2)+P3
> is genuinely proving anything! Since in the implementation of
> elliptic curve addition, it may well be that commutativity and/or
> associativity are implicitly assumed.
Ah yes. I agree this is a problem for verifying commutativity. For
associativity, what if you did the following. First compute P1 + P2
in generic coordinates using the EllipticCurve class, i.e. you get
the coordinates of P1 + P2 as a function of x1, y1, x2, y2 in the
appropriate quotient ring. Then introduce x3, y3, relabel variables,
and make the appropriate substitutions to verify that the "formula"
for the coordinates of (P1 + P2) + P3 is the same as the formula for
P1 + (P2 + P3). Would this constitute a correct verification of
associativity (perhaps modulo problems caused by the point at infinity)?
> I tried doing this in Magma some time ago, using something like David
> Harvey's code. I longed for a function GenericPoint() for a curve, so
> that for example
> (x1,y1)=E.GenericPoint()
> would return a point where x1,y1 live in the function field k(x1,y1)
> of the curve. In fact I did manage to do that in Magma, but had
> problems then trying to define a second *independednt* generic point,
> since in Magma there is only ever *one* univariate polynomial ring
> over any given field. To get a second generic point I had to make a
> base change of the curve from k (the proginal ground field) to the
> function field k(x1,y1), and then define a second point (x2,y2) such
> that k(x1,y1){x2,y2) is the function field of the curve over k(x1,y1).
> I think I was then able to verify commutativity....but chickened out
> before going up another level to get a third point.
>
> There may be a better way of doing all that in Magma than I was doing,
> and I'm not sure that I care now. But I think it would be really
> useful if in Sage we could define a GenericPoint for a curve, in such
> a way that subsequent calls to it returned independent generic points.
> Does anyone think that might be possible?
That would be very nice.
The problem is.... once you've called (x1, y1) = E.generic_point()
and (x2, y2) = E.generic_point(), suppose Sage was able to construct
two different function fields (which I think it can). When you try to
add the points, at some stage it has to decide what field (or ring)
the sum is defined over, since it has to be a point on *some*
elliptic curve. But that should never work, for the same reason that
this can't work:
sage: R.<x> = ZZ[]
sage: S.<y> = ZZ[]
sage: x + y
[boom]
I can't remember exactly all the things that are supposed to be wrong
with the above example, but I remember discussing this ad nauseum
with a few people at various Sage Days (what's the plural of Sage
Days?), and we definitely agreed it would be bad for this to work. I
think perhaps the problem is that perhaps there are relations between
x and y, and Sage has no way of knowing that without you explicitly
telling it. I don't think this was the whole story though. Perhaps
someone else remembers.
BUT I think it would be totally reasonable to support a syntax more like
E2, P = E.generic_point()
which returns a new elliptic curve over the function field (as you
suggested), and a point P = (x, y) on that curve, and then you could
subsequently do
E3, Q = E2.generic_point()
to get another point. But then you have the problem that adding
points in different orders give you fields that Sage would almost
certainly not recognise as being the same field. In fact it
*shouldn't*, for exactly the same reason that x + y doesn't work in
the above example, so I don't think this solves anything.
Hmmm...... the more I think about it, the more this is exactly like
the example I suggested above. Perhaps the analogy is clearer if I
write:
sage: E1.<P> = E[]
sage: E2.<Q> = E[]
sage: P + Q
!!!!!!!!!!!!!!!!
david
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
