WIP: Resolution structure

[afkafkafk13]

Only for collaboration on this task!

[HechtiDerLachs]

Some tests still need to be adjusted. But other than that, I think this is rather fine as a working base. The adjustments can be made in the end, or at any time where we would like to have a good picture of the test suite.

[afkafkafk13]

Thank you for the help and the preparation for monday.

[afkafkafk13]

Currently untested: Framework for handling embedded setting.

[HechtiDerLachs]

Today I contributed:

• the method find_refinement_with_local_system_of_params which, given an affine scheme W returns a pair U, d where U is a Covering of W and d a dictionary with d[U_i] a tuple (I, J, f) with I a subset of the rows and J a subset of the columns of the jacobian matrix A for W such that the (I, J)-th minor of A is a unit d on U_i.
• the very similar method find_refinement_with_local_system_of_params_rec which does almost the same thing, but recursively and with a different output at the moment.
• non_snc_locus(list) which digests a list of EffectiveCartierDivisors on a smooth scheme and returns an IdealSheaf indicating where these divisors are not snc.

In particular, this required the construction of common refinements of coverings. These are not yet fully optimized, but at least functional.

What did the others do? Let's wrap it up here a bit so that next week we know where to take it from. (@afkafkafk13, @jankoboehm, @simonbrandhorst, @wdecker)

[simonbrandhorst]

@paemurru worked on implementing normalizations of affine schemes. We started to work on lifting normalizations to gluings then hit a missing corner case for normalizations.

[afkafkafk13]

I finished yesterdays work and implemented _delta_list and the locus of order at least b, based on yesterday's work of @HechtiDerLachs.

[afkafkafk13]

@paemurru worked on implementing localizations of affine schemes. We started to work on lifting normalizations to gluings then hit a missing corner case for normalizations.

@simonbrandhorst Did you want to say 'normalization of affine schemes'? What is the missing corner case?

I looked up, how to specify the testideal in Singular: It is done by setting InputJ. This needs to be made accessible through Singular.jl.
@wdecker : The warning message about this option is precisely, what is to be expected: If one ignores components of the singular locus by setting the testideal manually, the result will not be a normalization (because of the ignored points). This is precisely, what is needed in the setting we discussed yesterday.

[wdecker]

To make the option accessible just check the normalization function in mpoly-affine-algebras.jl and add this possibility. Here is a code sample from @fieker:

julia> function bla(a::Int; one::Symbol = :f, kw...) @show a, one @show kw, typeof(kw) end bla (generic function with 1 method)

julia> bla(1, one=:b, two = 4) (a, one) = (1, :b) (kw, typeof(kw)) = (Base.Pairs(:two => 4), Base.Pairs{Symbol, Int64, Tuple{Symbol}, @NamedTuple{two::Int64}}) (Base.Pairs(:two => 4), Base.Pairs{Symbol, Int64, Tuple{Symbol}, @NamedTuple{two::Int64}})

julia> bla(1, one=:b, two = 4, go=5.5) (a, one) = (1, :b) (kw, typeof(kw)) = (Base.Pairs{Symbol, Real, Tuple{Symbol, Symbol}, @NamedTuple{two::Int64, go::Float64}}(:two => 4, :go => 5.5), Base.Pairs{Symbol, Real, Tuple{Symbol, Symbol}, @NamedTuple{two::Int64, go::Float64}}) (Base.Pairs{Symbol, Real, Tuple{Symbol, Symbol}, @NamedTuple{two::Int64, go::Float64}}(:two => 4, :go => 5.5), Base.Pairs{Symbol, Real, Tuple{Symbol, Symbol}, @NamedTuple{two::Int64, go::Float64}})

[HechtiDerLachs]

This PR has already become quite big. So I suggest we bring this to a mergable state and then continue in a next step?

@afkafkafk13 : Could you add some tests from the code snippets you're currently working with?

[afkafkafk13]

Now everything that needed to be in here is in and I will not add any more features in this PR.

As @HechtiDerLachs suggested, the remaining goal is mergable state from here on.

[HechtiDerLachs]

@afkafkafk13 : It looks like the tests are failing now because of some anticipated error messages. Could you have a look?

[HechtiDerLachs]

@afkafkafk13 : I squashed all changes for the rebase. Be careful when you pull this now! Better do a backup of your local branch before that.

[codecov[bot]]

Codecov Report

Merging #3480 (4b2c800) into master (39a24f2) will decrease coverage by 0.01%. Report is 1 commits behind head on master. The diff coverage is 69.60%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3480      +/-   ##
==========================================
- Coverage   82.10%   82.10%   -0.01%     
==========================================
  Files         566      567       +1     
  Lines       76123    76615     +492     
==========================================
+ Hits        62504    62901     +397     
- Misses      13619    13714      +95     

Files	Coverage Δ
experimental/Schemes/CoveredProjectiveSchemes.jl	88.40% <100.00%> (+7.04%)	:arrow_up:
experimental/Schemes/ToricBlowups/types.jl	65.21% <ø> (ø)
...raicGeometry/Schemes/Covering/Morphisms/Methods.jl	97.74% <100.00%> (ø)
...metry/Schemes/PrincipalOpenInclusion/Attributes.jl	100.00% <100.00%> (ø)
src/Modules/ExteriorPowers/Generic.jl	91.05% <100.00%> (+0.07%)	:arrow_up:
experimental/Schemes/IdealSheaves.jl	81.88% <88.88%> (+2.78%)	:arrow_up:
experimental/Schemes/BlowupMorphism.jl	90.09% <71.42%> (-0.46%)	:arrow_down:
experimental/Schemes/SimplifiedAffineScheme.jl	82.03% <56.25%> (-1.65%)	:arrow_down:
experimental/Schemes/Resolution_structure.jl	68.54% <68.54%> (ø)

... and 4 files with indirect coverage changes

[HechtiDerLachs]

@fingolfin : Thanks for having a look. I agree with your suggestions.

Concerning the maps: I propose to introduce a method map(f, i) here as a direct getter in accordance with what we already have for ComplexOfMorphisms. I know that this is debated as map also stands for something more general. But it is what we have in Oscar in many other cases at the time and it would only be coherent if we introduced it also here. If at some later point we decide to clean this up, then its usage will also be cleaned up here.

[fingolfin]

If Oscar.map is a distinct (and then necessarily non-exported) function from Base.map, I guess we could live with it... But overall this I find this very problematic, and it runs completely counter to the definition of Base.map, and even has the same arity as it has.

IMHO at the very least this needs to be run by @fieker and @thofma.

[simonbrandhorst]

How about replacing maps by morphisms? Then there is no clash.

[HechtiDerLachs]

@afkafkafk13 : I took the liberty to implement the AbsBlowdownMorphism interface we once worked out. Simply because I was curious whether this was doable and we were recently working on this topic with @HereAround for the toric blowups.

In particular, I resolved the suggestion about the underlying morphism which I pointed out above.