Implement equality for toric varieties

[paemurru]

The only computationally expensive part is computing the rays of the toric varieties, which are usually already computed anyway.

[joschmitt]

I vaguely remember that there was a longer discussion about this (parts of it are in #3934, #3946) and eventually it was decided to do things like they are (with the information about slow_equal in the docstring). Did something change?

@HereAround @lkastner

[HereAround]

I vaguely remember that there was a longer discussion about this (parts of it are in #3934, #3946) and eventually it was decided to do things like they are (with the information about slow_equal in the docstring). Did something change?

@HereAround @lkastner

@paemurru seems to have an increased interest in this feature/functionality. After several discussions more (the last of which I recall did take place before Christmas among @lkastner @paemurru and myself), it was agreed that one could implement such a method - provided interest and time. It seems that @paemurru found both! (Thank you!)

[HereAround]

@paemurru given the failed required test, I assume this is WIP. Please ping me once ready for review.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.40%. Comparing base (0d59f06) to head (5113dab).
Report is 15 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4509      +/-   ##
==========================================
- Coverage   84.55%   84.40%   -0.15%     
==========================================
  Files         672      672              
  Lines       88833    89139     +306     
==========================================
+ Hits        75109    75236     +127     
- Misses      13724    13903     +179     

Files with missing lines	Coverage Δ
...oricVarieties/NormalToricVarieties/constructors.jl	100.00% <100.00%> (+3.63%)	⬆️

... and 25 files with indirect coverage changes

[lkastner]

What is this needed for?

[paemurru]

@HereAround Those three test failures are from nightly, those are not required or relevant here! This is not a WIP, that tag can be removed

[paemurru]

@joschmitt One thing that changed is that I wrote a fast equality check

[lkastner]

@joschmitt One thing that changed is that I wrote a fast equality check

It is not fast, since it still potentially involves double description computation. This is why I am asking for a use case. Because in the long run we will have users using this check and then complain about Oscar being slow. Most of the time this equality check can be avoided by studying the underlying mathematics. For example we were able to avoid a lot of equality checks of polyhedra in the git fans that way. Often one is in the situation where one fan is already refining the other fan, e.g. for blow ups. Adding this operator makes this check convenient and seemingly cheap. It is not.

[paemurru]

@lkastner

It is not fast, since it still potentially involves double description computation.

All the "famous toric varieties" in the documentation already have rays computed, so this does not involve double description computation for them. For any kind of blowups or refining of fans by adding a ray, again the rays are already computed. Often one works with the Cox ring, so the rays need to be computed. I cannot think of a use case where the rays are not already computed.

Would you prefer it if it first checked whether the rays are already computed and if not, it would return an error?

[paemurru]

Should be ready to merge now

[lgoettgens]

I cannot say anything about the concrete implementations. But two comments regarding the docstrings below

resolved

[benlorenz]

Is it clear (and maybe checked?) that the polyhedral fans for these varieties are pointed (lineality_dim == 0)? I could not find anything regarding this in the docs, and otherwise all this breaks down since the rays are not unique.

[paemurru]

@benlorenz According to the book of Cox–Little–Schenck, polyhedral fans are pointed. At least according to the documentation, toric geometry in OSCAR follows the book of Cox. I am not sure if this is actually checked in the constructor (it should be!)

[benlorenz]

I still don't see why exactly this is necessary but the code seems reasonable now. Probably similar to computing Groebner bases when comparing ideals. So I think we can keep it like this.

But it would still be good to add input checks for toric varieties to make sure the fans are pointed, probably in a separate PR. This is not required for general polyhedral fans in Oscar.

[HereAround]

General comment (along our dicussions on slack):

The expectation is that the new equality check could be potentially slow in case polymake has not computed the rays of the toric variety. Let us be careful and reflect this in your changes. I see two ways:

Option 1:
When you describe the equality of toric varieties, please add a warning that informs the users, that this may be potentially slow in the above scenario.

Option 2:
You check in the equality function if the rays are known to polymake. For a given toric variety v, this should work something like the following:

"RAYS" in Polymake.list_properties(Oscar.pm_object(polyhedral_fan(v))

In case this returns false, we default back to the currently existing functionality. (This should also be spelled out in the documentation.)

Note that option 2 requires that you align the hash-function accordingly. In this regard, option 1 is likely easier. So I am leaning towards option 1. But if you prefer option 2, that is also fine with me.

Another useful thing - since we are concerned about the performance of the equality (and hash) operation - could be to subject one CI-test to a time requirement. Here is an in-use example testset:

  @testset "Speed test for Stanley-Reisner ideal (at most a few seconds)" begin
    success = false
    for i in 1:5
      ntv5 = normal_toric_variety(polarize(polyhedron(Polymake.polytope.rand_sphere(5, 60; seed=42))))
      stats = @timed stanley_reisner_ideal(ntv5)
      duration = stats.time - stats.gctime
      if duration < 10
        success = true
        break
      else
        @warn "Stanley-Reisner ideal took $duration > 10 seconds (i=$i)"
      end
    end
    @test success == true
    ntv5 = normal_toric_variety(polarize(polyhedron(Polymake.polytope.rand_sphere(5, 60; seed=42))))
    @test ngens(stanley_reisner_ideal(ntv5)) == 1648
  end

Presumably, any of the tests for == that you wrote should complete in less than 2 (?) seconds?

[HereAround]

I left a few comments above @paemurru . Please address those, and then this PR should be good to be merged. Thank you!

[paemurru]

I chose Option 1. The slowness in the case the rays have not been computed is already documented and appears in the documentation. Just in case, also mentioned the polymake code to check for this.

About the CI test with a time requirement: this seems a bit overkill to me. It could happen that it spends a lot of time garbage collecting some previous tests or compiling some functions not before used. And besides, this function here is not that important for time-considerations. There are far more important functions in OSCAR in terms of speed-criticality that have no timed tests whatsoever (saturation, smoothness tests, your own FTheoryTools methods). So I am hesitant to add these here.

[paemurru]

Added speed test as @HereAround suggested

[HereAround]

Thank you @paemurru . Looks good to me!