Opened 5 years ago
Closed 5 years ago
#20811 closed enhancement (fixed)
Classes for points on generic curves
Reported by:  gjorgenson  Owned by:  

Priority:  minor  Milestone:  sage7.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, GitHub, GitLab)  Commit:  314d511ad851f6f025cbc2a8e5b0c6c93a005de4 
Dependencies:  Stopgaps: 
Description
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 5 years ago by
 Branch set to u/gjorgenson/ticket/20811
comment:2 Changed 5 years ago by
 Commit set to f3a68c3789fdd99dc13d69ee9e82938076aadb30
comment:3 Changed 5 years ago by
 Status changed from new to needs_review
comment:4 Changed 5 years ago by
 Commit changed from f3a68c3789fdd99dc13d69ee9e82938076aadb30 to bb7aa7c2f7cf6ef8a92cbcd5e5de8e106d1766c5
Branch pushed to git repo; I updated commit sha1. New commits:
bb7aa7c  20811: intersection_multiplicity for affine/projective scheme morphism point classes

comment:5 Changed 5 years ago by
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 5 years ago by
 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.
PP.<x,y,u,v>=ProductProjectiveSpaces(QQ,[1,1]) G = PP.subscheme([(x^22*y^2)*u  y^2*v]) D = PP.subscheme([x*vy*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.
comment:7 Changed 5 years ago by
 Commit changed from bb7aa7c2f7cf6ef8a92cbcd5e5de8e106d1766c5 to f2ae6ea307d641e83bdc209271ebe79baac26c48
Branch pushed to git repo; I updated commit sha1. New commits:
f2ae6ea  20811: minor changes from review

comment:8 Changed 5 years ago by
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 curvespecific 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 5 years ago by
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 5 years ago by
 Commit changed from f2ae6ea307d641e83bdc209271ebe79baac26c48 to 314d511ad851f6f025cbc2a8e5b0c6c93a005de4
Branch pushed to git repo; I updated commit sha1. New commits:
314d511  20811: moved multiplicity functions to plane curve point classes

comment:11 Changed 5 years ago by
 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 5 years ago by
 Status changed from needs_review to positive_review
comment:13 Changed 5 years ago by
 Branch changed from u/gjorgenson/ticket/20811 to 314d511ad851f6f025cbc2a8e5b0c6c93a005de4
 Resolution set to fixed
 Status changed from positive_review to closed
Branch pushed to git repo; I updated commit sha1. New commits:
20811: added curve point classes
20839: first implementation attempt.
20839: some changes from review
20839: merge with ticket 20774
20839: some remaining changes from review
20839: implemented Serre intersection multiplicity for affine/projective subschemes
20839: improved is_transverse
20811: merge with ticket 20839 for access to is_transverse
20811: added is_transverse for points