Twists of sheaves with higher Picard rank and arithmetic operations for sequences

[mahrud]

Here's an annoying bug:

i1 : X = Proj(QQ[x,y,z,w,Degrees => {2:{1,0}, 2:{0,1}}]);

i2 : F = OO_X^1;

i3 : F(1,2)
stdio:3:1:(3): error: no method for adjacent objects:
--               1
--            OO   (of class CoherentSheaf)
--              X
--    SPACE   (1, 2) (of class Sequence)

i4 : F{1,2}
stdio:4:1:(3): error: no method for adjacent objects:
--               1
--            OO   (of class CoherentSheaf)
--              X
--    SPACE   {1, 2} (of class List)

i5 : F(1)
stdio:5:1:(3): error: expected each multidegree to be of length 2

This is currently fixed by the NormalToricVarieties package, but probably should happen in Core (either that, or Proj should be absorbed there), but along with that we should probably also allow arithmetic operations on sequences, similar to the way they are for lists:

i3 : {1,2,3} - 2 * {4,5,6}

o3 = {-7, -8, -9}

o3 : List

So that this can work:

i1 : needsPackage "NormalToricVarieties";

i2 : X = toricProjectiveSpace 1 ** toricProjectiveSpace 1;

i3 : F = OO_X^1;

i4 : a = (1,2); b = (2,3);

i6 : F a ** F b

        1
o6 = OO   (3, 5)
       X

o6 : coherent sheaf on X

i7 : F(a + b)
stdio:6:5:(3): error: no method for binary operator + applied to objects:
--            (1, 2) (of class Sequence)
--      +     (2, 3) (of class Sequence)

[mahrud]

Related to this, cohomology of sheaves over a bigraded ring doesn't work because of this: https://github.com/Macaulay2/M2/blob/d1ca9321d4d3dfacda90d3174ceba32ea6f3f1b1/M2/Macaulay2/m2/varieties.m2#L179-L202 Would be great to fix this.

[pzinn]

reminds me of an old discussion in the mailing list:

On Thursday, November 10, 2016 at 5:11:25 AM UTC-6, Paul Zinn-Justin wrote: I have some very naive questions about projective varieties / Proj in M2, since the documentation is a bit sparse.

• why is it that in the definition of Proj, one only tests if "isHomogeneous R"? for example, a polynomial ring with no grading at all is homogeneous, and we shouldn't be able to take the Proj of it...

good point

• is it expected that the ring is singly graded? I'd be more happy to let the ring be multi-graded, the first degree being the projective degree and the others being spectators (allowing to define say equivariant coherent sheaves), but as far as I can tell lots of functions assume singly graded. if so, shouldn't it be tested in the definition of Proj? and if not, should we try to fix the functions to allow multi-grading? (it shouldn't be too hard, considering basis(n,x) automatically assumes we mean degree n in the first degree)

It's expected to be singly graded, but I'd be happier if the general case was handled with multi-Proj. I see no reason to single out the first degree.

• and finally, is it expected that all variables have degree 1? again, not tested anywhere, but since the result is supposed to be a "projective variety", I'm assuming the answer should be yes...

Some algorithms won't work right if some variables have degree not 1, but no, I think it's not expected.

[mahrud]

Thanks, that's useful!

I'm also confused about the code over affine varieties. For instance, what does this mean?!

i1 : R = kk[x];

i2 : OO_(Spec R) (1)

             1
o2 = OO       (1)
       Spec R

o2 : coherent sheaf on Spec R, free

I can't figure out what's the correct way to remove the grading from a homogeneous module before sheafifying it.

[DanGrayson]

• why is it that in the definition of Proj, one only tests if "isHomogeneous R"? for example, a polynomial ring with no grading at all is homogeneous, and we shouldn't be able to take the Proj of it...

Aren't all polynomials rings in Macaulay2 graded?

[mahrud]

Aren't all polynomials rings in Macaulay2 graded?

I think the issue is that if a variable has degree 0 then the Proj isn't of finite type over the field. I agree that this should probably be an error unless we're clear on what is the correct behavior.

[DanGrayson]

Probably the correct behavior is to make a projective scheme of Spec of the degree 0 part.

[mahrud]

I'm not sure if I understand your suggestion, but if you mean for instance take Proj kk[x,y, Degrees => {0,1}] to be interpreted as:

Proj R[y] --> Spec(R = kk[x, Degrees => {0}]

then I don't think that would suffice. In particular, most sheaf algorithms depend on being finite type over a field, which I thought is checked using isAffineRing, but that doesn't quite check finite type:

i1 : isAffineRing(kk[x,y,Degrees => {0,1}])

o1 = true

The documentation of isAffineRing says:

For our purposes, an affine ring is a quotient of a (not necessarily commutative) polynomial ring over a field.

So if the general philosophy is to take the base to be the degree 0 part of the ring (for instance as discussed for basis in #909 and #2056), then perhaps isAffineRing should be adjusted to give false in this case, since the base is not a field.

cc: @jkyang92 and @mikestillman in case you have thoughts about this.