Bug in isVeryAmple for simplicial normal toric varieties

[mahrud]

Here is an example, related to CLS Example 6.1.11:

needsPackage "NormalToricVarieties"
N = ZZ^3;
P = convexHull matrix {0_N, N_0, N_1, N_0 + N_1 + 2*N_2};
X = normalToricVariety P
D = 2*X_0-2*X_1+2*X_2;
isVeryAmple D -- throws error!

This divisor is not very ample, but 2*D should be.

@ggsmith do you have a preferred fix, or should I make a pull request with my local fix?

[ggsmith]

In my attempt to reproduce this error, it seems that the isVeryAmple method in Polyhedra allows for option arguments whereas the current version in NormalToricVarieties doesn't. Is that the same issue you see?

@mahrud: What is your local fix?

[mahrud]

In my attempt to reproduce this error, it seems that the isVeryAmple method in Polyhedra allows for option arguments whereas the current version in NormalToricVarieties doesn't.

I think you might be using an old version of M2 or your repository is outdated. isVeryAmple is now exported from Core only and accepts options.

To be precise, this is the error I get:

i8 : isVeryAmple D -- throws error!
NormalToricVarieties/Divisors.m2:495:19:(2):[4]: error: no method found for applying numColumns to:
     argument   :  null (of class Nothing)
NormalToricVarieties/Divisors.m2:495:19:(2):[4]: --entering debugger (type help to see debugger commands)
NormalToricVarieties/Divisors.m2:495:9-
495:21: --source code:
    n := numColumns V;

Which is because V here is null.

What is your local fix?

First I thought I should add a check to return false if V is null, but that's not correct because very ampleness is about the line bundle, not the divisor, and O(D) here is very ample (unless there's a different meaning for toric divisors?).

I can think of several options, for instance:

1. Translate D linearly into the positive quadrant and take the vertices of polytope D instead
2. Take the monomials in basis(degree D, S^1) use that in the algorithm instead (this is what I did locally).

I'm not sure if either of these are particularly efficient in higher dimensions. Is there an easy way to find an effective divisor that is linearly equivalent to D?

[ggsmith]

Indeed, I forgot to uninstall packages when I updated my version of Macaulay2. I now get the same error as you.

'V' should not be equal to null. In particular, I believe that the error is in isEffective.

[mahrud]

This always confuses me: is effective a property of the toric divisor or the corresponding line bundle? I thought the package intentionally says this divisor is not effective because $2D_0-2D_1+2D_2$ has negative coefficients:

i11 : code methods isEffective

o11 = -- code for method: isEffective(ToricDivisor)
      /home/mahrud/Projects/M2/research/M2/Macaulay2/packages/NormalToricVarieties/Divisors.m2:405:39-405:72: --source code:
      isEffective ToricDivisor := Boolean => D -> all (entries D, i -> i >= 0)

[ggsmith]

Testing whether the coefficients of a divisor are nonnegative isn't particularly useful. The more interesting feature is to determine whether a toric divisor is linearly equivalent to a divisor with nonnegative coefficients. The isVeryAmple code is implicitly (and currently incorrectly) assuming the second.

[mahrud]

To be specific, should isEffective return true for this example (in which case the documentation would also need to change), or is that correct and we should check something else here?

Depending on your answer, I can try to work on a solution and show you later.

[ggsmith]

I think that we should change isEffective and update the documentation to reflect this change. In particular, this particular toric divisor should be effective (meaning it is linearly equivalent to an effective divisor).

[mahrud]

I looked into CLS and a few other references again, and I think changing isEffective ToricDivisor would confuse people.

Maybe different references treat the definitions differently, but I think effective is used as a property of a divisor (hence not preserved under linear equivalence) but nef is a property of the line bundle (hence preserved under linear equivalence). Am I missing something?

Maybe we should add a different function for this. how about isEffective CoherentSheaf so we can call isEffective OO(D)?