Bug:ToricVarieties: DegreeGroup of the Cox ring of a product of varieties is not identical to the SuperObject of degrees of its indeterminates.

[kamalsaleh]

Hallo Sebastian,
In ToricVarieties package one would expect that the ClassGroup( variety ) is identical as object to the range of the map MapFromWeilDivisorsToClassGroup( variety ). Actaully they are by implementation always identical unless the variety is product of two varieties.

Try this example:

LoadPackage( "ToricVarieties" );
variety := ProjectiveSpace(1)*ProjectiveSpace(2);
# <A projective toric variety of dimension 3 which is a product of 2 toric varieties>
S := CoxRing( variety );
# Q[x_1,x_2,x_3,x_4,x_5]
# (weights: [ ( 0, 1 ), ( 1, 0 ), ( 1, 0 ), ( 1, 0 ), ( 0, 1 ) ])
A := DegreeGroup( S );
# <A free left module of rank 2 on free generators>
B := SuperObject( Degree( "x_1"/S ) );
# <A free left module of rank 2 on free generators>
IsIdenticalObj( A, B );
# true
C := SuperObject( Degree( Indeterminates( S )[ 1 ] ) );
# <A free left module of rank 2 on free generators>
IsIdenticalObj( A, C );
# false
Degree("x_1"/S) + Degree( Indeterminates( S )[ 1 ] );
Error, the two maps are not comparable at ....

I would suggest removing the block

    if Length( IsProductOf( variety ) ) > 1 then

        return Sum( List( IsProductOf( variety ), ClassGroup ) );

    fi;

from the global function

InstallGlobalFunction( _Functor_ClassGroup_OnToricVarieties,
                       
  function( variety )
    
    if Length( IsProductOf( variety ) ) > 1 then
        
        return Sum( List( IsProductOf( variety ), ClassGroup ) );
        
    fi;
    
    return Range( MapFromWeilDivisorsToClassGroup( variety ) );
    
end );

If this is how you would fix the issue, I can create a PR to do that.

[sebasguts]

I think the fix you propose is fine.

Although, we do not have the class group generated as a sum then, which is a problem in the homalg context, as I think the object knows what it is the sum of. So this is a trade-off, I think.

But I think it is more important to be able to map the Weil divisors into the class group. Is there a way to actually create the MapFromWeilDivisorsToClassGroup as a sum? That would probably solve the problem in the most general way.

[kamalsaleh]

It is possible to precompose the current output of MapFromWeilDivisorsToClassGroup(U_1 x ... x U_n) with an isomorphism whose range is the direct sum of the calss groups of U_1,...,U_n. So the resulting morphism will still be another cokernel epimorphism of the MapFromCharacterToPrincipalDivisor(U_1 x ... x U_n). This isomorphism can be computed in a categorical way by making use of the SmithNormalForm command. SmithNormalForm is needed to correct the possible change in the order of the ray generators of the fan of the product variety.

Take a look at this temporarily commit in devel3 branch
kamalsaleh@7db7fb4

Side effect of using another cokernel epimorphism will be a change in the weights of cox ring of product varieties. Trying the above example will give this cox ring:

Q[x_1,x_2,x_3,x_4,x_5]
(weights: [ ( 0, 1 ), ( -1, 1 ), ( -1, 1 ), ( -1, 1 ), ( 0, 1 ) ])

[sebasguts]

@kamalsaleh Are the weights really changed, or are they just displayed differently?

[kamalsaleh]

The weights are the rows of the matrix of MapFromWeilDivisorsToClassGroup(U_1 x ... x U_n), which could be any cokernel epimorphism of MapFromCharacterToPrincipalDivisor(U_1 x ... x U_n).
In other words, the new weights which live in the direct sum class group are images of the old weights under an isomorphism computed by the use of smith normal form. So mathematically they are different but still true.
In the implementation, the weights are the classes of torus-invariant prime divisors and such a class is computed using the MapFromWeilDivisorsToClassGroup(U_1 x ... x U_n).

[sebasguts]

I see. So because of applying the iso they are different now. That is fine I guess, since the weights are proper group elements anyway.

Do the tests still work?

[kamalsaleh]

One output must be changed in Morphism.g.

# Input is:
Display(ClassGroup(M));
# Expected output:
[ [  0,  1 ],
  [  1,  0 ] ]

the map is currently represented by the above 2 x 2 matrix
# But found:
[ [   1,  -1 ],
  [   1,   0 ] ]

the map is currently represented by the above 2 x 2 matrix
########