#20811 closed enhancement (fixed)

Classes for points on generic curves

Reported by: gjorgenson Owned by:
Priority: minor Milestone: sage-7.3
Component: algebraic geometry Keywords: gsoc2016
Cc: bhutz, mmarco Merged in:
Authors: Grayson Jorgenson Reviewers: Ben Hutz
Report Upstream: N/A Work issues:
Branch: 314d511 (Commits) Commit: 314d511ad851f6f025cbc2a8e5b0c6c93a005de4
Dependencies: Stopgaps:


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.

Change History (13)

comment:1 Changed 11 months ago by gjorgenson

  • Branch set to u/gjorgenson/ticket/20811

comment:2 Changed 11 months ago by git

  • Commit set to f3a68c3789fdd99dc13d69ee9e82938076aadb30

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

e26403b20811: added curve point classes
f775a0f20839: first implementation attempt.
e0188ce20839: some changes from review
656472420839: merge with ticket 20774
09eea0220839: some remaining changes from review
4b9ab0a20839: implemented Serre intersection multiplicity for affine/projective subschemes
cae16fe20839: improved is_transverse
1c9045820811: merge with ticket 20839 for access to is_transverse
f3a68c320811: added is_transverse for points

comment:3 Changed 11 months ago by gjorgenson

  • Status changed from new to needs_review

comment:4 Changed 11 months ago by git

  • Commit changed from f3a68c3789fdd99dc13d69ee9e82938076aadb30 to bb7aa7c2f7cf6ef8a92cbcd5e5de8e106d1766c5

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

bb7aa7c20811: intersection_multiplicity for affine/projective scheme morphism point classes

comment:5 Changed 11 months ago by gjorgenson

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).

comment:6 Changed 11 months ago by bhutz

  • Reviewers set to Ben Hutz
  • Status changed from needs_review to needs_work

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.
G = PP.subscheme([(x^2-2*y^2)*u - y^2*v])
D = PP.subscheme([x*v-y*u])

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.

comment:7 Changed 11 months ago by git

  • Commit changed from bb7aa7c2f7cf6ef8a92cbcd5e5de8e106d1766c5 to f2ae6ea307d641e83bdc209271ebe79baac26c48

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

f2ae6ea20811: minor changes from review

comment:8 Changed 11 months ago by gjorgenson

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?

comment:9 Changed 11 months ago by bhutz

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.

comment:10 Changed 11 months ago by git

  • Commit changed from f2ae6ea307d641e83bdc209271ebe79baac26c48 to 314d511ad851f6f025cbc2a8e5b0c6c93a005de4

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

314d51120811: moved multiplicity functions to plane curve point classes

comment:11 Changed 11 months ago by gjorgenson

  • Status changed from needs_work to needs_review

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.

comment:12 Changed 11 months ago by bhutz

  • Status changed from needs_review to positive_review

comment:13 Changed 11 months ago by vbraun

  • Branch changed from u/gjorgenson/ticket/20811 to 314d511ad851f6f025cbc2a8e5b0c6c93a005de4
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.