[ToricVarieties] Assert coordinate names from cox ring

[HereAround]

The serialization of toric varieties remembers the Cox ring, but not the coordinate names. This leads to unexpected/inconsistent behavior. Here is an example:

julia> p3 = projective_space(NormalToricVariety, 3);

julia> set_coordinate_names(p3, ["u1", "u2", "u3", "u4"]);

julia> cox_ring(p3)
Multivariate polynomial ring in 4 variables over QQ graded by
  u1 -> [1]
  u2 -> [1]
  u3 -> [1]
  u4 -> [1]

julia> ideal_of_linear_relations(p3)
Ideal generated by
  u1 - u4
  u2 - u4
  u3 - u4

julia> save("/tmp/test.mrdi", p3)

CRUCIAL: Close your julia session and then proceed as follows:

julia> p3_2 = load("/tmp/test.mrdi")

julia> cox_ring(p3_2)
Multivariate polynomial ring in 4 variables over QQ graded by
  u1 -> [1]
  u2 -> [1]
  u3 -> [1]
  u4 -> [1]

julia> ideal_of_linear_relations(p3_2)
Ideal generated by
  x1 - x4
  x2 - x4
  x3 - x4

The ideal of linear relations is not homogeneous w.r.t. the grading of the Cox ring and so does not "live" in the Cox ring. Yet, the geometric meaning of the ideal of linear relations makes it beneficial to employ the same variables names as used in the Cox ring.

You can see that the root cause for this behavior is the call to coordinate_names in the implementation of ideal_of_linear_relations:

@attr MPolyIdeal function ideal_of_linear_relations(v::NormalToricVarietyType)
    R, _ = graded_polynomial_ring(coefficient_ring(v), coordinate_names(v); cached=false)
    return ideal_of_linear_relations(R, v)
end

function ideal_of_linear_relations(R::MPolyRing, v::NormalToricVarietyType)
    @req is_simplicial(v) "The ideal of linear relations is only supported for simplicial toric varieties"
    @req ngens(R) == n_rays(v) "The given polynomial ring must have exactly as many indeterminates as rays for the toric variety"
    return ideal(transpose(matrix(ZZ, rays(v))) * gens(R))
end

I propose to fix this by checking in the coordinate_names function if the attribute cox_ring is known for the toric variety, and if so to use the names of the indeterminates of cox_ring as return value for coordinate_names.

Certainly, we could also serialize the coordinate_names for any toric variety. This have its benefits, but there are has at least two draw-backs:

1. Larger file sizes (although this is likely super minor).
2. I would have to overhaul the QSM database again (which I would really like to avoid).

What are your thoughts @lkastner @antonydellavecchia?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.59%. Comparing base (5c30f3a) to head (9cd126e).
Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4240   +/-   ##
=======================================
  Coverage   84.59%   84.59%           
=======================================
  Files         631      631           
  Lines       85060    85062    +2     
=======================================
+ Hits        71954    71956    +2     
  Misses      13106    13106           

Files with missing lines	Coverage Δ
...heoryTools/src/AbstractFTheoryModels/attributes.jl	99.59% <ø> (ø)
.../ToricVarieties/NormalToricVarieties/attributes.jl	98.67% <100.00%> (+0.01%)	⬆️