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.55%. Comparing base (0d59f06) to head (985293e).
Report is 8 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4509   +/-   ##
=======================================
  Coverage   84.55%   84.55%           
=======================================
  Files         672      672           
  Lines       88833    88860   +27     
=======================================
+ Hits        75109    75136   +27     
  Misses      13724    13724           

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

... and 5 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!)