-
Notifications
You must be signed in to change notification settings - Fork 63
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
Add many @req !is_trivial
checks
#1857
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1857 +/- ##
=======================================
Coverage 88.16% 88.17%
=======================================
Files 120 120
Lines 30219 30227 +8
=======================================
+ Hits 26643 26652 +9
+ Misses 3576 3575 -1 ☔ View full report in Codecov by Sentry. |
Thank you! This triggers a bunch of errors
|
Since this causes failures, perhaps we can introduce this incrementally: separate PRs for the series rings (which are not much used so hopefully won't break any upstream tests), matrix rings (heavily used but perhaps still will go through), universal polynomial rings (should go through) and finally polynomial rings (causing problems) |
The problem with MPolyQuoRing is that it may indeed be trivial. But we need a groebner basis computation to decide that |
Is there a reason that residue rings, matrices and fraction fields are also restricted? I was mainly thinking about polynomials and series, because the code there is wrong. |
I put one in all constructions that take a ring. If you verified that the code for these other types isn't wrong, I am happy to take it out again |
It is correct for matrices. For fraction fields it gives errors in some situations, but no wrong results. |
I'll split this PR up into multiple ones. |
254eb62
to
e26b4c9
Compare
Matrices are removed from this again. |
ef779e1
to
2b22d78
Compare
@@ -823,6 +823,7 @@ that it will always be returned by a call to the constructor when the same | |||
base ring $R$ is supplied. | |||
""" | |||
function fraction_field(R::Ring; cached::Bool=true) | |||
@req !is_trivial(R) "Zero rings are currently not supported as coefficient ring." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can a zero ring have a fraction field at all? What would that be?
So maybe the "currently" can be removed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the zero ring satisfies the universal property of being a fraction field of the zero ring.
Edit: What I wrote is only correct if you don't insist on the fraction field being a field.
Edit edit: I guess the answer is no. What I wrote makes sense for the "total field of fractions", but not for fraction fields.
@@ -490,6 +490,7 @@ residue ring parent object is cached and returned for any subsequent calls | |||
to the constructor with the same base ring $R$ and element $a$. | |||
""" | |||
function residue_field(R::Ring, a::RingElement; cached::Bool = true) | |||
@req !is_trivial(R) "Zero rings are currently not supported as base ring." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here, too, we could remove the "currently", as any quotient of a zero ring can't be a field.
@@ -450,6 +450,7 @@ to the constructor with the same base ring $R$ and element $a$. A modulus | |||
of zero is not supported and throws an exception. | |||
""" | |||
function residue_ring(R::Ring, a::RingElement; cached::Bool = true) | |||
@req !is_trivial(R) "Zero rings are currently not supported as base ring." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since residue_ring
can already be a zero ring, I think it is kinda OK to allow a zero ring as base ring? OTOH I also see no strong need to support a zero ring as base ring. But perhaps it allows to make some code more uniform... In any case, we could probably handle it with some code like this:
@req !is_trivial(R) "Zero rings are currently not supported as base ring." | |
if is_trivial(R) | |
a = one(R) # base ring is trivial, so we might as well factor out 1 | |
end |
Then again: if R
is a zero ring, won't the next code line trigger anyway, which throws an error if iszero(A)
is true? If that's a case, we may as well keep this line and strengthen it by removing currently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep the error as provided by the PR for now (with the "currently").
I think the line below with the reference to the C library is a bit misleading, as it is not relevant.
@@ -823,6 +823,7 @@ that it will always be returned by a call to the constructor when the same | |||
base ring $R$ is supplied. | |||
""" | |||
function fraction_field(R::Ring; cached::Bool=true) | |||
@req !is_trivial(R) "Zero rings are currently not supported as coefficient ring." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@req !is_trivial(R) "Zero rings are currently not supported as coefficient ring." | |
@req !is_trivial(R) "Base ring must not be the zero ring." |
OscarCI and HeckeCI failures: for Oscar, see oscar-system/Oscar.jl#4239 For Hecke, getting several errors:
and
|
Resolves #1856.
List of split of changes: