Sheaf cohomology tables and potential rework of Betti tables

[RafaelDavidMohr]

This PR will implement the Oscar interface to the Singular function sheafCohBGG:

https://www.singular.uni-kl.de/Manual/4-3-1/sing_1827.htm#SEC1908

Me and @ederc found that the easiest way to get the printing of the sheaf cohomology tables done as in Singular would be to use PrettyTables.jl. This package is already present as a test dependency for Oscar. If we print these tables using this package then it would have to be added as a "proper" dependency.

If we decide to do use PrettyTables.jl then we could also use it to print Betti tables which would simplify the Base.show implementation for Betti Tables (see the Base.show implementation on this branch for a "preview" of what this could look like). Without pulling in extra dependencies, PrettyTables.jl requires the data to be present in a matrix format in order to print it. As a consequence, if @jankoboehm agrees to using PrettyTables.jl for Betti tables, then I would also propose reworking the Betti table data structure to store it directly as a matrix and to also potentially implement a Base.getindex method for Betti tables so that the user may easily query the tables.

[fieker]

is_z_graded

[thofma]

I would suggest that we do not add a dependency on PrettyTables.jl.

[ederc]

I would suggest that we do not add a dependency on PrettyTables.jl.

Why exactly? Doing all these tables by hand, as it is implemented right now, is not a good way to do. What would be your suggestion?

[thofma]

External dependencies which we do not control are bad. There was recently another fiasco, where a maintainer of heavily used packages went missing (https://github.com/JuliaFolds).

[jankoboehm]

The data structure of the Betti table as a Dict has an important mathematical meaning in the form it is, so it should please not be changed.

I do not mind a different show function, as long as it prints as currently, which is exactly what we want.

That show function would first have to generate internally a matrix and then print it. I would however also suggest that we are very cautious to add a dependency, since we can pretty easily produce our own generic code to handle the pretty printing.

In case we would want to go into this deeper, there is the very nice conpept of a Net (which is modular and can be used for any sort of printing for tables, matrices, polynomials, maps, rings ...) in M2 and Singular.

[RafaelDavidMohr]

The data structure of the Betti table as a Dict has an important mathematical meaning in the form it is, so it should please not be changed.

I do not mind a different show function, as long as it prints as currently, which is exactly what we want.

That show function would first have to generate internally a matrix and then print it. I would however also suggest that we are very cautious to add a dependency, since we can pretty easily produce our own generic code to handle the pretty printing.

In case we would want to go into this deeper, there is the very nice conpept of a Net (which is modular and can be used for any sort of printing for tables, matrices, polynomials, maps, rings ...) in M2 and Singular.

Ok, thanks for weighing in. In light of this and the above discussion I will leave the Betti table completely as is and simply also use its Base.show implementation for the sheaf cohomology tables so as to not add the PrettyTables dependency.

Just FYI, they are currently on hold due to an issue on the Singular side.

[codecov]

Codecov Report

Merging #2392 (ea6dce8) into master (79874fd) will decrease coverage by 0.06%.
Report is 9 commits behind head on master.
The diff coverage is 64.28%.

@@            Coverage Diff             @@
##           master    #2392      +/-   ##
==========================================
- Coverage   73.63%   73.57%   -0.06%     
==========================================
  Files         455      455              
  Lines       64411    64517     +106     
==========================================
+ Hits        47427    47467      +40     
- Misses      16984    17050      +66     

Files Changed	Coverage
experimental/JuLie/src/schur_polynomials.jl	ø
...ntal/QuadFormAndIsom/src/lattices_with_isometry.jl	ø
experimental/Schemes/CoveredProjectiveSchemes.jl	ø
src/AlgebraicGeometry/Schemes/Glueing/Methods.jl	ø
...eometry/Schemes/ProjectiveSchemes/Objects/Types.jl	ø
src/Modules/FreeModules-graded.jl	0.00%
src/Rings/mpoly-affine-algebras.jl	0.00%
src/Rings/mpoly-graded.jl	0.00%
src/Rings/mpolyquo-localizations.jl	ø
src/TropicalGeometry/curve.jl	0.00%
... and 12 more

[fingolfin]

What's the status of this? Is the Singular issue resolved? If not, please add a link to the relevant issue at the Singular.jl and or Singular repository, so we can track its status

[wdecker]

The Singular part is settled, the cm-regularity is now in OSCAR, the rest will be finished as sooon as time permits.

…

Am 22.08.2023 um 09:22 schrieb Max Horn ***@***.***>: What's the status of this? Is the Singular issue resolved? If not, please add a link to the relevant issue at the Singular.jl and or Singular repository, so we can track its status — Reply to this email directly, view it on GitHub <#2392 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXESPBY6GO6YPIH7LYODXWRM5FANCNFSM6AAAAAAYDIQ3NA>. You are receiving this because you are subscribed to this thread.

[RafaelDavidMohr]

I added a first Wrapper for the sheafCohBGGregul_w function. Let me know if this is going in the right direction. Also, there still seem to be some issues on the Singular side, see Singular/Singular#1184

[wdecker]

I have several problems here. In particular, the results seem to be incorrect.

@RafaelDavidMohr, @ederc: Can we discuss this in gathertown some time soon?

For example, Tomorrow, 14.10., 11:00?