Opened 3 years ago

Closed 3 years ago

is_morphism for maps of products of projective spaces

Reported by: Owned by: gjorgenson minor sage-6.10 algebraic geometry bhutz Grayson Jorgenson Ben Hutz N/A ee5676f (Commits) ee5676f3f02327ba15d9b9c13d337b4543b696a5

Description

Implement a function to determine whether a given map between products of projective spaces is a morphism.

comment:1 Changed 3 years ago by gjorgenson

• Branch set to u/gjorgenson/ticket/19512

comment:2 Changed 3 years ago by git

• Commit set to bca35ddbb8d6518535b43e32ec34514fcd0ab8c8

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

 ​bca35dd `19512: is_morphism implementation`

comment:3 Changed 3 years ago by gjorgenson

• Status changed from new to needs_review

comment:4 Changed 3 years ago by bhutz

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

Mapping down to each coordinate ring will only work when there is no mixing of coordinates in the map. So this approach will not work in general.

comment:5 Changed 3 years ago by bhutz

In thinking about this, I think it may be as simple as just checking the dimension of the ideal in the coordinate ring defined by the coordinates of the map. If this is 0, then a morphism and if it is >0, then it is not a morphism. i.e., you can basically duplicate the code from projective_morphism.py.

What do you think?

comment:6 Changed 3 years ago by gjorgenson

Oops! I guess my approach wasn't truly componentwise to begin with since I ignored the possibility of mixed coordinates.

Would checking the dimension of the ideal in the whole coordinate ring coincide with checking that the Segre embedding of the map is a projective morphism? It would be stricter than checking that the coordinates share no common zeros componentwise, right? Maps such as

```T.<x,y,z,w,u,v> = ProductProjectiveSpaces([2,2],QQ)
H = T.Hom(T)
F = H([x^2*u,y^2*w,z^2*v,w^2,u^2,v^2])
```

wouldn't be considered morphisms with this check.

comment:7 Changed 3 years ago by bhutz

another puzzling example:

```P.<x,y,z,w,u,v>=ProductProjectiveSpaces(QQ,[1,1,1])
H=End(P)
f=H([u,v,z^2,w^2,u^2,v^2])
```

Is this a morphism? It would fail the Segre embedding version (check if the Segre embedding was a morphism) and the dimension of the ideal is 2, but the indeterminacy locus is empty.

comment:8 Changed 3 years ago by bhutz

Actually, that example should be a morphism and does not fail the segre embedding check (it just isn't dominant). So the 0 dimensional check is (at least) not iff.

One solution that has come to mind is do something like define the subscheme of the productprojectivespaces for each set of coordinates of the map and check that there are no points on each such subscheme. Then we have a set of polynomials defined at every point in the product (the definition of a morphism)

For products of 2 projective spaces, the .dimension function works fine via segre embeddings, but calling dimension on the defining ideal for empty subschemes does not give the 'right' answer in products:

```P.<x,y,z,u,v,w>=ProductProjectiveSpaces(QQ,[2,2])
H=End(P)
f=H([u,v,w,u^2,v^2,w^2])
m=0
for i in range(P.num_components()):
t=P[i].dimension_relative()+1
X=P.subscheme(list(f)[m:m+t])
print X.defining_ideal().dimension(), X.defining_ideal().dimension() - P.num_components()
print "dim:",X.dimension()
m+=t
```

at the moment segre embedding (and hence dimension) is only implemented for products of 2 projective spaces. It would be nice to get that to work in general, but maybe the solution for this particular function is to be dependent on the dimension function for subschemes and then improve the dimension function as part of a separate ticket.

What do you think?

comment:9 Changed 3 years ago by gjorgenson

I think that sounds good. It will restrict any function that needs is_morphism to working only with spaces with two components, but that's probably not too much of a problem for right now and just makes it higher priority to implement Segre embedding for general products. I've implemented it locally, so I will push it up here.

comment:10 Changed 3 years ago by git

• Commit changed from bca35ddbb8d6518535b43e32ec34514fcd0ab8c8 to c65866abe29c01477544944371bac5fee6325aff

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

 ​c65866a `19512: Attempt at implementing new is_morphism check`

comment:11 Changed 3 years ago by gjorgenson

Does this seem to be okay? I assumed in this implementation that the check is iff; is that correct? That is, if for a map there is a point on one of the subschemes, then the map is not a morphism?

comment:12 Changed 3 years ago by bhutz

Just one issue here.

When you are creating the subschemes you need to be careful about the domain and codomain. They may not be the same. You are correctly creating subschemes of the domain, but the groups of coordinates needs to go by the component dimensions of the codomain.

comment:13 Changed 3 years ago by git

• Commit changed from c65866abe29c01477544944371bac5fee6325aff to f28a7df331d742ca60cee361cd245a1fe1a50832

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

 ​f28a7df `19512: adapted is_morphism to accomodate maps with different domains and codomains`

comment:14 Changed 3 years ago by gjorgenson

Alright, here is a revision. While testing I found that the dimension function doesn't seem to work unless the base rings of the product spaces are fields:

```P.<x,y,z,w,u> = ProductProjectiveSpaces([2,1],ZZ)
H = End(P)
f = H([x^2,y^2,z^2,w^2,u^2])
X = P.subscheme(list(f)[0 : 3])
X.dimension()
```

Is there any way around this?

comment:15 Changed 3 years ago by bhutz

Well, just like is_morphism for polynomials, if given a ring, you can change to the fraction field. The real question is should that be implemented here or in dimension. Since improving dimension is more than a trivial project, I'd say to do the same thing here and when dimension is improved it can be updated.

I don't think there are any adverse implications for changing to the fraction field (since dimension = dimension_relative), but I'll think some more about it when I review the updated version.

comment:16 Changed 3 years ago by git

• Commit changed from f28a7df331d742ca60cee361cd245a1fe1a50832 to ee5676f3f02327ba15d9b9c13d337b4543b696a5

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

 ​ee5676f `19512: base rings no longer required to be fields`

comment:17 Changed 3 years ago by gjorgenson

• Status changed from needs_work to needs_review

Okay, now if the base ring isn't a field, I change_ring both the ambient space of the domain and the coordinate polynomials before performing the dimension check.

comment:18 Changed 3 years ago by bhutz

• Status changed from needs_review to positive_review

This looks fine, but I've uncovered a few other simple errors in projective product morphisms that I've put in Trac #19551.

comment:19 Changed 3 years ago by vbraun

This ticket needs a milestone before it can be merged

comment:20 Changed 3 years ago by gjorgenson

• Milestone set to sage-6.10

comment:21 Changed 3 years ago by vbraun

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