Two neighbor step in char 0 #4183
Conversation
| if !is_zero(P) | ||
| WC = weierstrass_chart_on_minimal_model(X) | ||
| U = original_chart(PX) | ||
| @assert OO(U) === ambient_coordinate_ring(WC) | ||
| PY = PrimeIdealSheafFromChart(X, WC, ideal(OO(WC), PX(U))) | ||
| set_attribute!(PY, :name, string("section: (",P[1]," : ",P[2]," : ",P[3],")")) | ||
| set_attribute!(PY, :_self_intersection, -euler_characteristic(X)) | ||
| return WeilDivisor(PY, check=false) | ||
| end |
There was a problem hiding this comment.
I switched to the creation of sections from points to come from the weierstrass chart directly. This has the advantage that the strict transforms do not have to be computed to realize this divisor on that chart. This computation was killing us in char. 0, so I hope this is ok.
There was a problem hiding this comment.
Previously, it was a PrimeIdealSheafFromChart. But I deliberately changed that to StrictTransformIdealSheaf because it was more performant (and in principle it allows the algorithms to take advantage of the blowup structure).
Unless you can provide evidence that your change improves performance in a wide range of examples please leave it as is. Optionally you could include another dispatch with a type as first argument.
There was a problem hiding this comment.
One case where a PrimeIdealSheafFromChart will be faster is when we do only computations in the weierstrass chart e.g. for computing a linear system.
There was a problem hiding this comment.
Exactly. The computations just didn't go through with the strict transform. Having a second argument as the return type should be OK, but we would still have to decide for a default.
| mat2 = [constant_coefficient(numerator(x)) for x in mat] | ||
| M = matrix(B, length(eqns), length(ab), mat2) |
There was a problem hiding this comment.
This was making trouble over number fields:
ERROR: MethodError: no method matching (::AbsSimpleNumField)(::AbstractAlgebra.Generic.FracFieldElem{AbstractAlgebra.Generic.Poly{AbsSimpleNumFieldElem}})
Closest candidates are:
(::AbsSimpleNumField)(::Singular.n_FieldElem{AbsSimpleNumFieldElem})
@ Singular ~/.julia/packages/Singular/lsYSW/src/MessyHacks.jl:119
(::AbsSimpleNumField)(::Vector{QQFieldElem})
@ Hecke ~/.julia/packages/Hecke/7wI0D/src/NumField/Elem.jl:284
(::AbsSimpleNumField)(::ZZRingElem)
@ Nemo ~/.julia/packages/Nemo/tzyHK/src/antic/nf_elem.jl:1095
...
I guess the implicit conversion via B was not very clean, anyway, so I tried to clear this up. @simonbrandhorst : Could you have a look whether this is now reasonable?
There was a problem hiding this comment.
Your change looks like it should work.
Alternatively in line 1302 it could be
R,ab = polynomial_ring(Bt,vcat([Symbol(:a,i) for i in 0:dega],[Symbol(:b,i) for i in 0:degb]),cached=false)
instead (base was replaced by Bt)
because we don't get any denominators anyway.
| function reduction_to_pos_char(X::EllipticSurface, red_map::Map) | ||
| return get_attribute!(X, :reduction_to_pos_char) do | ||
| kk0 = base_ring(X) | ||
| @assert domain(red_map) === kk0 | ||
| kkp = codomain(red_map) | ||
| @assert characteristic(kkp) > 0 | ||
| _, result = base_change(red_map, X) | ||
| return red_map, result | ||
| end::Tuple{<:Map, <:Map} | ||
| end |
There was a problem hiding this comment.
This is what we need to discuss. For elliptic surfaces it is sometimes reasonable to do computations of intersection numbers in a reduction modulo primes (as I hear). We probably do not want to allow this in general but have to hide it a bit from the user so that they use it at their own risk when they know what they're doing.
Instead of giving it as a second argument, I propose to have a field/attribute good_reduction which holds the reduction of the base_rings to positive characteristic, if it is set. Then the rationale is that a model of X in positive characteristic is held in the background, together with a list of counterparts for the generators of the algebraic_lattice. The methods to do intersection theory have to be customized in order to allow for several assumptions which can not be made unless we deal with elliptic surfaces. This is carried out in the code below. Someone with more background knowledge in elliptic surfaces (@simonbrandhorst ?) should check whether the code is safe to use, decide which precautions we require the user to take and how we want to communicate them.
| function _reduce_as_prime_divisor(bc::AbsCoveredSchemeMorphism, I::PrimeIdealSheafFromChart) | ||
| U = original_chart(I) | ||
| bc_cov = covering_morphism(bc) | ||
| V = __find_chart(U, codomain(bc_cov)) | ||
| IV = I(V) | ||
| bc_loc = first(maps_with_given_codomain(bc_cov, V)) | ||
| J = pullback(bc_loc)(IV) | ||
| set_attribute!(J, :is_prime=>true) | ||
| return PrimeIdealSheafFromChart(domain(bc), domain(bc_loc), J) | ||
| end |
There was a problem hiding this comment.
This method assumes that the prime ideal sheaf I stays prime when reduced via bc. This is not automatically the case, so we should probably warn the user to only use "sufficiently good reduction" here.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4183 +/- ##
==========================================
- Coverage 84.59% 84.55% -0.04%
==========================================
Files 631 631
Lines 84829 84866 +37
==========================================
+ Hits 71758 71761 +3
- Misses 13071 13105 +34
|
HechtiDerLachs
force-pushed
the
two_neighbor_step_in_char_0
branch
from
35374f6
to
a1c1f28
Compare
HechtiDerLachs
force-pushed
the
two_neighbor_step_in_char_0
branch
from
b4aa995
to
1e85bd3
Compare
Building on #4177.
@simonbrandhorst : I managed to perform our two neighbor step in characteristic zero with this (modulo mistakes).
It would therefore be great if we could decide on how to integrate this code properly. I will leave some comments below.