Forbid residue_ring for zero rings for technical reasons

[lgoettgens]

Resolves #1856.

List of split of changes:

• Require non-zero coefficient ring in universal polynomial ring #1858
• Require non-zero coefficient ring in free associative algebra #1859
• Require non-zero coefficient ring in power series ring #1860
• Require non-zero coefficient ring in laurent/puiseux constructions #1861
• Prevent creation of fields with one element #2233

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.33%. Comparing base (2627b5e) to head (cbcee23).
⚠️ Report is 30 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1857      +/-   ##
==========================================
+ Coverage   88.00%   88.33%   +0.33%     
==========================================
  Files         127      126       -1     
  Lines       31798    31765      -33     
==========================================
+ Hits        27983    28060      +77     
+ Misses       3815     3705     -110     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fingolfin]

Thank you!

This triggers a bunch of errors

1. In Oscar, it seems MPolyQuoRing (and maybe others) doesn't implement characteristic
2. Hecke has a bunch of failures, e.g. this one:

Error in testset LocalField/neq.jl:
Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/test/LocalField/neq.jl:33
  Got exception outside of a @test
  ArgumentError: The zero is currently not supported as a coefficient ring.
  Stacktrace:
    [1] macro expansion
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/Assertions.jl:599 [inlined]
    [2] #polynomial_ring_only#131
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/NCPoly.jl:768 [inlined]
    [3] #polynomial_ring#130
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/NCPoly.jl:757 [inlined]
    [4] _minmod_easy_pp(a::ZZRingElem, b::AbsSimpleNumFieldOrderElem)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Ideal.jl:1060
    [5] _minmod_comp_pp(a::ZZRingElem, b::AbsSimpleNumFieldOrderElem)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Ideal.jl:1106
    [6] _minmod(a::ZZRingElem, b::AbsSimpleNumFieldOrderElem)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Ideal.jl:1090
    [7] assure_has_minimum(A::AbsSimpleNumFieldOrderIdeal)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Ideal.jl:628
    [8] #minimum#2028
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Ideal.jl:587 [inlined]
    [9] +(x::AbsSimpleNumFieldOrderIdeal, y::AbsSimpleNumFieldOrderIdeal)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Arithmetic.jl:144
   [10] macro expansion
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/Assertions.jl:545 [inlined]
   [11] _decomposition(O::AbsSimpleNumFieldOrder, I::AbsSimpleNumFieldOrderIdeal, Ip::AbsSimpleNumFieldOrderIdeal, T::AbsSimpleNumFieldOrderIdeal, p::Int64)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/MaxOrd/Polygons.jl:796
   [12] macro expansion
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/Assertions.jl:267 [inlined]
   [13] prime_decomposition_polygons(O::AbsSimpleNumFieldOrder, p::Int64, degree_limit::Int64, lower_limit::Int64)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/MaxOrd/Polygons.jl:1039
   [14] prime_decomposition(O::AbsSimpleNumFieldOrder, p::Int64, degree_limit::Int64, lower_limit::Int64; cached::Bool)
      @ Hecke ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Prime.jl:263
   [15] prime_decomposition (repeats 2 times)
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/src/NumFieldOrd/NfOrd/Ideal/Prime.jl:241 [inlined]
   [16] macro expansion
      @ ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/test/LocalField/neq.jl:36 [inlined]

[fingolfin]

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)

[lgoettgens]

The problem with MPolyQuoRing is that it may indeed be trivial. But we need a groebner basis computation to decide that

[thofma]

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.

[lgoettgens]

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

[thofma]

It is correct for matrices. For fraction fields it gives errors in some situations, but no wrong results.

[lgoettgens]

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)

I'll split this PR up into multiple ones.

[lgoettgens]

Matrices are removed from this again.
I lost a bit tracked if something else (apart from Poly and MPoly) remains here once all of the split off things are merged. So let's just wait for a rebase.

[fingolfin]

I think here, too, we could remove the "currently", as any quotient of a zero ring can't be a field.

[fingolfin]

OscarCI and HeckeCI failures: for Oscar, see oscar-system/Oscar.jl#4239

For Hecke, getting several errors:

Error in testset AlgAssAbsOrd/Conjugacy/Husert.jl:
Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/test/AlgAssAbsOrd/Conjugacy/Husert.jl:1
  Got exception outside of a @test
  ArgumentError: Zero rings are currently not supported as coefficient ring.

and

Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/oscar-dev/Hecke/test/QuadForm/Herm/Spaces.jl:130
  Test threw exception
  Expression: is_isometric(V1, V2)
  ArgumentError: Zero rings are currently not supported as coefficient ring.

[lgoettgens]

Even in the case that we fix all of the downstream issues, this needs to get released in a breaking release, to not accidentally breaking Oscar 1.2

[thofma]

More Oscar woes:

  Characteristic not known
  Stacktrace:
    [1] error(s::String)
      @ Base ./error.jl:35
    [2] characteristic(R::AffineSchemeOpenSubschemeRing{AffineScheme{QQField, MPolyQuoRing{QQMPolyRingElem}}, AffineSchemeOpenSubscheme{AffineScheme{QQField, MPolyQuoRing{QQMPolyRingElem}}, QQField}})
      @ AbstractAlgebra ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/NCRings.jl:165
    [3] is_trivial(F::AffineSchemeOpenSubschemeRing{AffineScheme{QQField, MPolyQuoRing{QQMPolyRingElem}}, AffineSchemeOpenSubscheme{AffineScheme{QQField, MPolyQuoRing{QQMPolyRingElem}}, QQField}})
      @ AbstractAlgebra ~/work/AbstractAlgebra.jl/AbstractAlgebra.jl/src/Rings.jl:197

[lgoettgens]

Since we don't let Nemo overload polynomial_ring_only anymore, adding the is_trivial check here inside zpolynomial_ring_only` makes this check too coarse. Each polynomial ring type needs to implement this on their own.

But which of the Nemo coeff types even allows zero rings?

[thofma]

None at the moment, but with this approach here I cannot fix the generic ones without fixing the Nemo ones.

[fingolfin]

So how do we proceed here?

It seems there is some overlap resp. "tension" with PR #1910. Also a bunch of tweaks to this PR here have been suggested but not yet applied.

Would it make sense to split off yet another PR from this with the changes which do not clash with #1910, e.g. for fraction_field ?

[lgoettgens]

@thofma can the univariate and multivariate poly ring stuff from this PR dropped since this is fixed by #1911 and #1910?

[thofma]

Yes for generic polynomials from AA but no for polynomials coming from flint:

julia> R, = residue_ring(ZZ, 1); # zzModPolyRingElem

julia> Rx, x = polynomial_ring(R, "x");

julia> divexact(x, x);
ERROR: DivideError: integer division error
Stacktrace:
 [1] divexact(x::zzModPolyRingElem, y::zzModPolyRingElem; check::Bool)
   @ Nemo ~/.julia/packages/Nemo/i8LKC/src/flint/nmod_poly.jl:373
 [2] divexact(x::zzModPolyRingElem, y::zzModPolyRingElem)
   @ Nemo ~/.julia/packages/Nemo/i8LKC/src/flint/nmod_poly.jl:371
 [3] top-level scope
   @ REPL[45]:1

julia> R, = residue_ring(AbstractAlgebra.ZZ, 1);

julia> Rx, x = polynomial_ring(R, "x");

julia> divexact(x, x);

[thofma]

Wait, I think I might have fixed the things for flint: https://github.com/flintlib/flint/pulls?q=is%3Apr+author%3Athofma

Let me try to open a PR in Nemo with some tests.

[thofma]

After Nemocas/Nemo.jl#2195 we should be able to remove it.

[fingolfin]

I've removed the (m)poly changes (as discussed: they were no long needed). All that is left are changes to two residue_ring methods. Therefore I've also changed the title of this PR.

@lgoettgens hope you don't mind I've messed with this, please holler if I messed stuff up.

[lgoettgens]

I've removed the (m)poly changes (as discussed: they were no long needed). All that is left are changes to two residue_ring methods. Therefore I've also changed the title of this PR.

@lgoettgens hope you don't mind I've messed with this, please holler if I messed stuff up.

Thanks for taking over!