On Jan 15, 2008, at 5:13 AM, David Harvey wrote:
>> 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.
Perhaps something like
P, Q = generic_points(2)
P+Q # this works (assuming we can do the fraction field arithmetic
efficiently enough)
where P and Q are defined over the same ring large enough to make
them independent. (I'm not returning the new curve here because with
a variable number of points I think this would be more cumbersome,
but one can always do E.parent()).
- Robert
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
