Classes for points on generic curves

[sagetrac-gjorgenson]

Implement classes for points on generic algebraic curves. Then implement singularity analysis functionality at the point level, such as Q.is_singular() and Q.multiplicity() for a point Q on a curve.

The implementations of the basic singularity analysis functionality at the curve level can be found in #20774.

CC: @bhutz @miguelmarco

Component: algebraic geometry

Keywords: gsoc2016

Author: Grayson Jorgenson

Branch/Commit: 314d511

Reviewer: Ben Hutz

Issue created by migration from https://trac.sagemath.org/ticket/20811

[sagetrac-gjorgenson]

Branch: u/gjorgenson/ticket/20811

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

e26403b	20811: added curve point classes
f775a0f	20839: first implementation attempt.
e0188ce	20839: some changes from review
6564724	20839: merge with ticket 20774
09eea02	20839: some remaining changes from review
4b9ab0a	20839: implemented Serre intersection multiplicity for affine/projective subschemes
cae16fe	20839: improved is_transverse
1c90458	20811: merge with ticket 20839 for access to is_transverse
f3a68c3	20811: added is_transverse for points

[sagetrac-git]

Commit: f3a68c3

[sagetrac-git]

Changed commit from f3a68c3 to bb7aa7c

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

bb7aa7c

20811: intersection_multiplicity for affine/projective scheme morphism point classes

[sagetrac-gjorgenson]

comment:5

Alright I added intersection_multiplicity functions to the affine/projective point classes and think this should be ready for a first review. I haven't changed the usage of _point in the curve classes since point creation seems to be working properly, and I think it works the same as adding actual _point function implementations (that just call the corresponding point class constructors).

[bhutz]

Reviewer: Ben Hutz

[bhutz]

comment:6

These classes seem fine in how they are structured. Also, since the functionality is calling the curve functionality, that all should be ok. However, I did come across of few things I would like some clarification on. First some minor issues.

• no '.' for file title (first line)

• curve() function - I don't see the point for creating this function. That is what codomain() does.

• Return whether this point is or is not a singular point of the projective curve it is on.

Remove the 'or is not' since the boolean it returns is in relation to 'is'

---

Now for the more interesting questions:

• Does multiplicity() work for higher dimensional varieties? Or perhaps 'should' multiplicity work for higher dimensional varieties (just for points? or also higher dim subvarieties?) Maybe this is a candidate for a separate ticket.

• I was trying to test this with a less standard example, the multiplicities of periodic points: graph intersect diagonal in the product space.

PP.<x,y,u,v>=ProductProjectiveSpaces(QQ,[1,1])
G = PP.subscheme([(x^2-2*y^2)*u - y^2*v])
D = PP.subscheme([x*v-y*u])
Z=G.intersection(D)
Z.dimension()

What do you think, should intersection_multiplicity() work here? Since we're working locally in an affine patch, this should be reasonably doable. This may be a candidate for a separate ticket since it is also unrelated to the class structure.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

f2ae6ea

20811: minor changes from review

[sagetrac-git]

Changed commit from bb7aa7c to f2ae6ea

[sagetrac-gjorgenson]

comment:8

Thanks, made the minor changes.

I think multiplicity() can be made to work for arbitrary varieties without much modification. It didn't occur to me before, but I don't think there's anything curve-specific about the definition of multiplicity that's currently used. Should I make a ticket to implement multiplicity() for higher dimensional varieties and points?

For intersection_multiplicity(), I was wondering if we might be able to make the current implementations a bit more general as well. Right now, we consider the varieties to intersect as subvarieties of their ambient space, but if I understand correctly, computing intersection multiplicity can also work if we replace the ambient space by a large variety that contains the two given subvarieties (though besides having the right dimension, I'm not sure what other conditions this variety would need to satisfy).

To implement this, maybe we could have an optional parameter to pass in a large variety, and then adapt the Tor formula computation by creating the needed ideals in the coordinate ring of the large variety (which could be an actual quotient ring) instead of in that of the ambient space. I tried implementing some of these modifications and so far they appear to be working.

I think if this generalization makes sense it could give another way to define intersection multiplicity for products. In the example you gave, PP embeds into projective space of dimension 3 via the Segre embedding, but the space is too big to apply the current projective intersection multiplicity implementation to the images of G and D since they each have dimension 1. I think we could instead treat them as subvarieties of the image of PP when computing their intersection multiplicity at a point. So far doing this seems to agree with applying the current affine intersection_multiplicity() function to affine patches of the product space.

Do you think it makes sense to try generalizing intersection_multiplicity() this way?

[bhutz]

comment:9

Yes, I think the new multiplicity functionality should have a new ticket, but both the multiplicity for subschemes and the intersection muliplicty can probably be the same ticket.

To answer your questions: No, I don't think Sage can deal with subschemes of subschemes. In fact, I don't think you can even define something like that. The ambient space can only be affine or projective space. I see your comment about making a parameter for the ambient space to get around that, but I don't think it is a good idea, it would be better to create the functionality for subschemes of subschemes, if that is even reasonable to do.

I don't think the products one is as complicated as you are making it. Don't you just take an affine patch and work there for intersection multplicity. For a product of projective spaces, the affine patches are products of affine spaces, which is just an affine space (eg, A2 x A2 = A4). Yes, you could probably pass to the Segre embedding, but that is rather slow and complicated.

[sagetrac-git]

Changed commit from f2ae6ea to 314d511

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

314d511

20811: moved multiplicity functions to plane curve point classes

[sagetrac-gjorgenson]

comment:11

Okay thanks, I agree with that. I was mainly wondering about the generalization as a way to convince myself that the affine patch approach for products gives the right intersection multiplicity, but I think I understand better now. I opened ticket #20930 to generalize multiplicity() and implement intersection_multiplicity() for subschemes of products using affine patches.

For this ticket, I moved the point class multiplicity functions to just the plane curve point classes since the plane curve implementation of multiplicity does not need Singular. In #20930 I'll give points of projective/affine subschemes access to the generalized multiplicity functionality.

[vbraun]

Changed branch from u/gjorgenson/ticket/20811 to 314d511