ToricVarieties_project 2.0

[HereAround]

👋 First steps & summary of discussion on Monday, February 22 (2021):

First of all, here are the first minimal steps, that we agreed to perform:

1. The functionality of the package ToricVarieties should become accessible from Oscar/Julia. The dependencies include NConvex (>= 2017.01.01), which in turn depends on CddInterface (https://github.com/homalg-project/CddInterface). I briefly discussed this with @kamalsaleh , but could not (yet) get CddInterface to work in Julia. @fingolfin: Suggestions/ideas/help on this is very much appreciated.
2. Once the ToricVarieties package is accessible from Julia, we agreed that it is desirable to offer Polymake as alternative oracle to Cdd. @lkastner: To anticipate this step, you may want to have a look at the functionality of NConvex (https://github.com/homalg-project/NConvex). Most likely, all of this functionality is available in Polymake? From our discussion, I also do understand that some functionality for ToricVarieties (e.g. for smoothness) is supported directly in Polymake. For optimization/speedup, we may want to consider direct calls to Polymake.

Beyond that, we of course have various applications in mind. Inspired by my interest, the current form of the ToricVarieties_project focuses on coherent sheaves and their cohomologies. Computations of the latter rely among others on NormalizInterface. @fingolfin: I have not tried if this is available in Julia. Maybe you could briefly report the status? Thank you!

Similarly, it can be checked if an f.p. graded S-module (S the Cox/coordinate ring) sheafifies to zero. For the latter, I provide an alternative to https://github.com/homalg-project/CAP_project/tree/master/ToricSheaves, which I believe is at least better documented: https://github.com/homalg-project/ToricVarieties_project/tree/master/CoherentSheavesOnToricVarieties.

@mohamed-barakat , here is an example of how this test works:

LoadPackage( "SheafC" );
LoadPackage( "Coherent" );
F := Fan( [ [ 0, 1 ], [ 1, 0 ], [ -1, -2 ] ], [ [ 1, 2 ], [ 2, 3 ], [ 1, 3 ] ] );;
P112 := ToricVariety( F );;
CohP112 := CategoryOfCoherentSheaves( P112 );;
S := CoxRing( P112 );;
#! Now we test if the irrelevant ideal sheafifes to zero (which it should not, but rather give the structure sheaf):
k := IrrelevantLeftIdealForCAP( P112 );;
IsWellDefined( k );
#! true
Sh_K := CoherentSheafOnToricVariety( P112, k );;
ob := DefiningSerreQuotientObject( Sh_K );;
IsZero( ob );
#! false
#! Likewise, we can test if the factor object sheafifes to zero. This is expect to give true:
vars := IndeterminatesOfPolynomialRing( CoxRing( P112 ) );
matrix := HomalgMatrix( [ [ vars[ 1 ] ], [ vars[ 2 ] ], [ vars[ 3 ] ] ], S );
range := GradedRow( [[[0],1]], CoxRing( P112 ) );
factor := FreydCategoryObject( DeduceSomeMapFromMatrixAndRangeForGradedRows( matrix, range ) );
IsWellDefined( factor );
#! true
Sh_factor := CoherentSheafOnToricVariety( P112, factor );;
ob_factor := DefiningSerreQuotientObject( Sh_factor );;
IsZero( ob_factor );
#! true

Based on our discussion, other future extension include (but are not limited to):

• Logic affine to abstract variety. (E.g. to check smoothness via https://www.mathematik.uni-kl.de/~boehm/singulargpispace/).
• Resolution of singularities (basic blow-up example below).

@ Anne Frühbis-Krüger (sorry - I could not find your github account): Here is an example of the current down-to-earth blow-up resolution routine. It computes the blow-up of C^3 at the origin. This is facilitated by a star subdivision of the fan of C^3. This star subdivision is implemented in NConvex. A more extensive example is outlined in section 3.1.5 of the manual of the ToricVarieties package:

gap> rays := [ [1,0,0], [0,1,0], [0,0,1] ];
[ [1,0,0], [0,1,0], [0,0,1] ]
gap> max_cones := [ [1,2,3] ];
[ [1,2,3] ]
gap> fan := Fan( rays, max_cones );
<A fan in |R^3>
gap> C3 := ToricVariety( rays, max_cones, [[0],[0],[0]], "x1,x2,x3" );
<A toric variety of dimension 3>
gap> B1C3 := BlowupOfToricVariety( C3, "x1,x2,x3", "u0" );
<A toric variety of dimension 3>
gap> [ IsComplete( B1C3 ), IsOrbifold( B1C3 ), IsSmooth( B1C3 ) ];
[ false, true, true ]

Please feel free to elaborate on what functionality for ToricVarieties you would like to see realized in the future. A minimal pseudo-code is very much appreciated. For example:

Cohomology( ToricSpace, Module, Index )
-> Extremely clever and quick algorithm...
Output: Integer n s.t. n = h^index( ToricSpace, Module ).

[lkastner]

I started a jupyter notebook at https://github.com/lkastner/polymakejl4tv . Optionally we could also go via OscarPolytope.jl, but this might be more of a moving target at this point and it uses the same backend, so I think this is entirely up to you.

[fingolfin]

There is no OscarPolytope.jl anymore, it was merged into Oscar.jl, and so
i think it could and should be used?

[lkastner]

You are right. I will adapt my examples. Nevertheless there aren't fans and toric varieties, so at least for the latter we will probably want to access polymake.jl directly, right?

[HereAround]

Thank you @lkastner.

[kamalsaleh]

I have already tried the standard procedure for installing the packages

using GAP
GAP.Packages.install( "CddInterface" )
GAP.Packages.install( "NormalizInterface" )

on Julia Version 1.5.2 (2020-09-23), Ubuntu 18.04 and both succeeded. We can meet this week to figure out what is happening, if it is a serious issue, then an issue in Gap.jl should be opened.

With regard to offering Polymake as an alternative to Cdd & Normaliz, it depends on how you want to proceed. Do you want to still use NConvex as a data structure for ToricVarieties and extend NConvex to use Polymake.jl when the session runs in Julia? or to directly use objects of Polymake.jl as a data structure for ToricVarieties? or maybe communicate with Polymake.jl via a new gap package? If you have the first option in mind, then, I believe, NConvex can be extended by some functions that checks whether the current session is running in Julia, and if yes, to use the Polymake.jl as an alternative to Cdd & Normaliz, e.g., for

• for checking properties of cones: smooth, normal, complete, etc
• for translating between h-rep and v-rep
• computing the generators of a polyhedron
• and a lot more ..

[HereAround]

The installation of NormalizInterface does not succeed for me. I opened an issue here gap-packages/NormalizInterface#96.

[mohamed-barakat]

I would suggest leaving NConvex as it is. The N stands for Normaliz. Instead, one should either try to resurrect Convex (which called the by now deprecated PolymakeInterface) or write a fresh Convex guided by the code in NConvex, as Martin has suggested during the meeting. It should be decided on a higher level which package to use. ToricVarieties could check if a variable (e.g., USE_POLYMAKE_FOR_TORIC_VARIETIES) is bound and set to true. In the latter case, it should use polymake.jl through Convex instead of NormalizInterface and CddInterface through NConvex.

[HereAround]

Ok. A new Convex it is.

@mohamed-barakat does it make sense to refresh the old Convex, i.e. update this step by step along the example of @lkastner. In this case, maybe we should even integrate this package (including its history) into the ToricVarieties_project?

In any case - I cannot seem to find that old repository any more. Where is it?

[mohamed-barakat]

Here you can find the last commit in which both Convex and PolymakeInterace were part of the homalg_project repository. At that point, they were not properly functional. I assume that writing such an interface with polymake.jl in place should be much easier and more stable, but I cannot estimate how reasonable it is to revive Convex.

[HereAround]

Thank you @mohamed-barakat. I will look into this shortly.

[HereAround]

@lkastner @fingolfin @kamalsaleh @mohamed-barakat:

I have just added the first version of the new (gap4) package Convex, which mediates between Polymake, the ToricVarieties-package and the NConvex (https://github.com/homalg-project/NConvex). I do not claim that this first version is perfect or free of bugs, but it should get things started.

ToricVarieties_project is available as part of CapAndHomalg.jl (https://github.com/homalg-project/CapAndHomalg.jl). Eventually, one should simply have to use this Julia package for toric geometry. Currently, one additional step is necessary.

Convex relies on the definitions in NConvex, which I did not repeat for reasons of efficiency and good coding style (code duplication). NConvex cannot (yet) be loaded in Julia because it relies on CddInterface and Normalizinterface, which are in turn not yet available in Julia (see homalg-project/CddInterface#23 and gap-packages/NormalizInterface#96 - also, @fingolfin, please correct me if this is no longer correct).

To circumvent this, I have made a few minor modifications to NConvex (a few packages are suggested rather than necessary and I have out-commented a few definitions). Thereby, my version of NConvex (see https://github.com/HereAround/NConvex/tree/martindevel) can be loaded in Julia and is sufficient to get (part of) the ToricVarieties_project running in Julia.

Long story short, here is what you currently want to do to use the ToricVarieties_project in Julia:

1. Clone https://github.com/homalg-project/CapAndHomalg.jl
2. In Julia, add this package as development version, so that you can easily change the version of NConvex. (Maybe this works also if you use the distributed version in Julia, but I have not tested this): Pkg.develop( path = "path/to/local/version/of/Cap/And/Homalg" ) and Pkg.build( "CapAndHomalg" )
3. In the pkg/NConvex subfolder of CapAndHomalg.jl switch NConvex to my branch: https://github.com/HereAround/NConvex/tree/martindevel.
4. Now, you should be able to execute the following in Julia:

using Polymake
using CapAndHomalg
LoadPackage( "ToricV" )

P2 = ProjectiveSpace( 2 )
IsSmooth( P2 )

Rays = ConvertJuliaToGAP( [[-1,5],[0,1],[1,0],[0,-1]] )
Cones = ConvertJuliaToGAP( [[1,2],[2,3],[3,4],[4,1]] )
H5 = Fan( Rays, Cones )
H5 = ToricVariety( H5 )
IsComplete( H5 )
IsAffine( H5 )
IsOrbifold( H5 )
IsProjective( H5 )
P = TorusInvariantPrimeDivisors( H5 )
A = P[ 1 ] - P[ 2 ] + 4*P[ 3 ]
IsAmple( A )
CoordinateRingOfTorus( H5, ConvertJuliaToGAP( "x" ) )
D=CreateDivisor( ConvertJuliaToGAP( [ 0,0,0,0 ] ),H5 )
BasisOfGlobalSections( D )
divi = DivisorOfCharacter( ConvertJuliaToGAP([ 1,2 ]),H5 )
BasisOfGlobalSections( divi )

rays = ConvertJuliaToGAP( [ [1,0,0], [-1,0,0], [0,1,0], [0,-1,0], [0,0,1], [0,0,-1], [2,1,1], [1,2,1], [1,1,2], [1,1,1] ] )
cones = ConvertJuliaToGAP( [ [1,3,6], [1,4,6], [1,4,5], [2,3,6], [2,4,6], [2,3,5], [2,4,5], [1,5,9], [3,5,8], [1,3,7], [1,7,9], [5,8,9], [3,7,8], [7,9,10], [8,9,10], [7,8,10] ] )
F = Fan( rays, cones )
T = ToricVariety( F )
[ IsSmooth( T ), IsComplete( T ), IsProjective( T ) ]
SRIdeal( T )

The test suite of ToricVarieties_project does currently not perform tests in Julia. In particular, the tests in Convex for Cones and Polytopes were only tested locally. Suggestions/hints on how to extend the current test-suite to also execute the gap-tests in Julia are appreciated.

[fingolfin]

A minor technical note: there already is a GAP package Convex, which used to be distributed with GAP, but was withdrawn in favor of NConvex. I am not actually sure what will happen with the GAP infrastructure code if we try to again ship a package with the same name but different content... Also, there may be confusion if any papers or other package cited the old GAP package.

As to CddInterface and NormalizInterface being available in Julia via GAP: they could be made available, it's "just" a matter of invoking their build systems in the right way. Of course in terms of Oscar, I'd be more interested in accessing this functionality directly from Julia, not via GAP; or possible access it via Polymake.jl (which also has such functions available, I believe?). But it seems you are writing the bulk of your code in GAP, so perhaps that's not convenient... Or perhaps it could be handled by having a GAP package JConvex which performs the computations via calls into Julia... In general, perhaps instead of having multiple FooConex packages which implement the same interface, one could instead follow the model of the float package, which contains multiple backends (that can be disabled/enabled at build time), and code using it can choose to either select a specific one, or else allow using a "default" backend, whatever that is (so e.g. NormalizInterface/CddInterface when available, else JuliaInterface if available, else ...)

The Julia code example you post do seems reasonable, but is at the same time very obviously thinly veiled GAP code which would stick out severely to a "regular" Julia programmer; not just the use of ConvertJuliaToGAP but also the naming conventions (CamelCase vs. snake_case) and that fact that rays is an untyped list of lists of integers... Note that there is an ongoing effort by @lkastner to add proper types for these things in Oscar (in GAP doing that is annoying and possible would cause speed and memory overhead; in Julia all these drawbacks don't apply).