Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix dim for affine schemes (#2369) #2766

Merged
merged 12 commits into from
Sep 5, 2023

Conversation

paemurru
Copy link
Contributor

@paemurru paemurru commented Sep 4, 2023

Implemented dimension for localizations along

  • MPolyPowersOfElement,
  • MPolyComplementOfPrimeIdeal, and
  • MPolyComplementOfKPointIdeal

Not implemented for other localizations.
Enabled check for primeness in creating localized rings.
@HechtiDerLachs

Implemented dimension for localizations along complements of prime
ideals and powers of an element. Not implemented for other
localizations.
Copy link
Collaborator

@HechtiDerLachs HechtiDerLachs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I fixed some minor things, but overall, I think, this is good.

Treating both, the case of prime ideals and ideals of rational points with one signature is good in terms of avoiding code duplication. But on the other hand deciding primeness and dimension, etc. is much easier for the latter ideals so that writing code of its own for that case also seems worthwhile. I chose the solution via setting the necessary attributes to avoid unnecessary computation for the moment.

@HechtiDerLachs
Copy link
Collaborator

I guess the tests for primeness had been disabled due to @wdecker ? In my opinion it's OK to switch them on. I mean: We already saw in the tests for the MPolyQuos where not testing this leads to (see the fix).

Copy link
Collaborator

@afkafkafk13 afkafkafk13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. But to avoid duplicate code, the case by case distinction should happen on the algebra side, not on the geometry side. (see comment in the code)

return dim(closure(X))
end

@attr function dim(X::AbsSpec{<:Ring, <:MPolyQuoLocRing{<:Any,<:Any,<:MPolyRing,<:MPolyRingElem, <:Union{MPolyComplementOfPrimeIdeal, MPolyComplementOfKPointIdeal}}})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not do the two cases together. They differ significantly, which is otherwise hidden in the calls to other functions.
For MPolyComplementOfPrimeIdeal this version is fine.
In the case of MPolyComplementOfKPointIdeal, you do not need to adjust at all as dim(P) is guaranteed to be zero; you can just use "return dim(saturated_ideal(modulus(OO(X))))", which is the line you (correctly) removed above.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Now that I try to fix the case of MPolyComplementOfKPointIdeal over the integers, I also start to have my doubts whether putting the cases together is a good idea.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You write that dim(P) is guaranteed to be zero. Is it also zero over the integers?

Comment on lines 389 to +391
@attr function dim(X::AbsSpec{<:Ring, <:MPolyQuoLocRing})
return dim(saturated_ideal(modulus(OO(X))))
error("Not implemented")
end
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment beforehand: Most of this should not happen on the geometric side, but on the algebra side. We need all these fixes on the algebra side as well and should only have them in one spot. The geometric side should directly refer dim (X) to dim(OO(X)) in the local and affine cases.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, agreed. It seems that a lot of this is still missing on the algebra side, so this might be a good occasion to add it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How serious are we about doing things on the algebra side?
If we are serious, then there would be only a single method:
dim(X::AbsSpec) = dim(OO(X))
and that is it. But yea, in the long run this is maybe the best way to go.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely the way to go. Otherwise there will be tons of duplicate code.

(My issue was meant as a marker not to forget this (large and necessary) cleanup. I wrote it on the geometric side because of my own lazyness, as I had stumbled into it on that side. But I always expected the solution to be implemented on the algebraic side and only a simple call on the geometric one.


Given a prime ideal ``P`` of a polynomial ring ``R``, say,
return the multiplicatively closed subset ``R\setminus P.``

!!! note
If `check` is set to `true`, the function checks whether ``P`` is indeed a prime ideal.
Since `check` is set to `true`, the function checks whether ``P`` is indeed a prime ideal.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should still be an "if", as it can be overruled by input.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default it is true, so I think that since fits.

# parallel, we introduce the analogous method here.
function prime_ideal(S::MPolyComplementOfKPointIdeal)
kk = coefficient_ring(ambient_ring(S))
# TODO: Test whether kk is an integral domain
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't find a way to test this. If anybody knows, let me know, too!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a primatlity test for the zero ideal of kk.

Copy link
Collaborator

@HechtiDerLachs HechtiDerLachs Sep 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sure. I tried it. It fails over ZZ: The required methods are not there and we do not have a coherent interface. We need one method like is_integral_domain which we expect to be implemented for the ring.

Copy link
Collaborator

@afkafkafk13 afkafkafk13 Sep 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree and I would explicitly test for the following cases:

  • field
  • integers
    and not set is_maximal for the other cases.

Edit: This is of course for the lowest level. As long as kk=R[x] for some R, we can still go one level further down and decide there.

if !isdefined(S, :m)
R = ambient_ring(S)
x = gens(R)
n = ngens(R)
m = ideal(R, [x[i]-a for (i, a) in enumerate(point_coordinates(S))])
set_attribute!(m, :is_prime=>true)
set_attribute!(m, :is_maximal=>true)
set_attribute!(m, :dim=>0)
set_attribute!(m, :is_maximal=>iszero(dim(kk)))
Copy link
Collaborator

@afkafkafk13 afkafkafk13 Sep 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt that this will work for kk = ZZ/<4>.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. But nothing really does, so I think, it cannot be a real issue here. It wouldn't be mathematically incorrect here, would it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This attribute is_maximal is mathematically incorrect here, as a maximal ideal in this example would be m+<2>, which strictly contains m.

@codecov
Copy link

codecov bot commented Sep 4, 2023

Codecov Report

Merging #2766 (4c94180) into master (bfd0792) will increase coverage by 0.05%.
Report is 3 commits behind head on master.
The diff coverage is 83.78%.

@@            Coverage Diff             @@
##           master    #2766      +/-   ##
==========================================
+ Coverage   73.02%   73.08%   +0.05%     
==========================================
  Files         450      450              
  Lines       64160    64191      +31     
==========================================
+ Hits        46853    46914      +61     
+ Misses      17307    17277      -30     
Files Changed Coverage
src/Rings/mpoly-localizations.jl 78.94%
...ometry/Schemes/AffineSchemes/Objects/Attributes.jl 85.71%
src/Rings/mpoly-ideals.jl 100.00%

@fingolfin
Copy link
Member

Hi @paemurru, thank you for your contribution. I assume the algebraic geometry people here know who you are, but right now your GitHub user profile is empty and so to an outsider you are a bit mysterious. In general we appreciate if we know for anyone who contributes at least the full name, ideally also affiliation. Perhaps you would be amenable to adding this to your GitHub user profile?

@fingolfin
Copy link
Member

(I guess technically this would also be nice for @simonbrandhorst but there the GitHub username at least is the full name, and we know him, so it's not really a double standard...)

@paemurru
Copy link
Contributor Author

paemurru commented Sep 5, 2023

your GitHub user profile is empty

Thanks, I added my full name and affiliation to my GitHub user profile.

Copy link
Collaborator

@simonbrandhorst simonbrandhorst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me for now.
Moving everything to the commutative algebra side could be done later?

@simonbrandhorst simonbrandhorst merged commit 37eec92 into oscar-system:master Sep 5, 2023
@lgoettgens
Copy link
Member

Looks good to me for now. Moving everything to the commutative algebra side could be done later?

I have added #2771 to keep that in mind.

@paemurru paemurru deleted the ep/dim_fix branch September 7, 2023 11:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

dim(X) gives wrong answer for X=Spec(A) and A localized at a prime ideal
6 participants