New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Projective closure and affine patches for algebraic curves #20676
Comments
Branch: u/gjorgenson/ticket/20676 |
Commit: |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:3
I have two questions:
|
comment:4
Replying to @miguelmarco: Thanks for looking at this. I think it's not always the case that a given set of generators is sufficient for finding generators for the ideal of the projective closure. One example I have seen referenced in some texts is the twisted cubic in A3 defined by the ideal A proof is given in the book ideals, varieties, algorithms that if the generators of a groebner basis (with respect to a graded monomial ordering) for the defining ideal of an affine variety are homogenized, then the result is a set of generators for the ideal of the projective closure, so I tried to emulate that here. I'll work on getting some flexibility with the variable names. |
comment:5
As Grayson pointed out the twisted cubic is the typical example for needing the gb. For the variables. Actually it is not a good idea to name them the same as they really aren't the same variables. More importantly, you need to be careful to keep track of the embedding as well, since if you homogenize the affine patch, you would expect to get something back in the same projective space. Take a look at the functionality for projective space and projective subschemes (or in #16838) to see what I mean. |
comment:6
Thanks for the correction. I knew I was missing something. About the names of the variables... right now they might be named the same or not deppending on what were the original names. So I still think that there should be at least on option to let the user decide how are the new variables named: the same way as before, maybe adding a "bar" at the end, or completely new ones. And bhutz is totally right about the morphisms: that is the important thing to compute (either in this methods or in separated ones). |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:8
Okay, I actually just finished up an attempt to better manage the creation of ambient spaces in the projective closure/affine patches computation. I tried piggy-backing off of the existing projective_embedding and affine_patch functionality for projective/affine spaces, and it seems to be working so far. Things like:
and
should now return true. Is this the right way to keep track of everything? I also found something that seems strange:
returns false. As far as I can tell, this isn't an issue for projective space curves. Also, there seems to be an issue with the class structure of space curves vs plane curves. Right now there is a ProjectiveSpaceCurve_generic class, and a ProjectiveCurve_generic class, with the latter corresponding to plane curves, but the plane curve class does not inherit from the space curve class. Similarly for affine curves. Is there a reason why plane curves shouldn't inherit from the space curve class? |
comment:9
I would say it is a bug in Sage. Apparently, schemes don't have rich comparison implemented. |
comment:10
re: variable names. The way this is handled for general affine and projective subschemes is to allow the user to specify the space that it will be embedded into (or dehomogenized into). This is better functionality than just specifying the variable names, since you can then embedded different curves into the same space. re: ambient space
I haven't looked at the code, but it looks like Curve assumes you are passing in elements from a polynomial ring and doesn't see if they are actually from a particular affine space and hence creates a new affine space. This is a bug. If you pass in elements of the coordinate ring of an affine space, then the curve should be in that space. It may be that you need to include an optional parameter for the space and/or perhaps have an A.curve() function. one last thought: Should these curve classes inherit from affine and projective subscheme as well? This could save you a fair amount of code duplication (such as for affine_patch and projective_embedding. |
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Reviewer: Ben Hutz |
comment:15
|
comment:16
err...having a default for affine_patch() doesn't really make sense, so ignore that part. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Changed keywords from none to gsoc2016 |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:20
this looks good now |
Changed branch from u/gjorgenson/ticket/20676 to |
Given a curve in affine space, find its projective closure. Conversely, given a projective curve, find its affine patches with respect to the standard affine coordinate charts.
This could be done more efficiently by using the projective_embedding/affine patches functionality for affine/projective subschemes. Currently the projective_embedding function for affine subschemes doesn't always have the right codomain:
so this should be addressed here, along with creating a projective_closure function for affine subschemes.
Depends on #20697
Depends on #20698
CC: @bhutz @miguelmarco
Component: algebraic geometry
Keywords: gsoc2016
Author: Grayson Jorgenson
Branch/Commit:
91bc630
Reviewer: Ben Hutz
Issue created by migration from https://trac.sagemath.org/ticket/20676
The text was updated successfully, but these errors were encountered: