Add some ring / field conformance tests

[fingolfin]

... and fix some issues this revealed. In particular "missing" base_ring methods
which the conformance tests kind of assume, but here in some cases "only" base_field methods were available.

Contains #1706 because of overlap.

[thofma]

I probably misunderstood something, but base_ring is not part of the ring interface. How can a missing base_ring method make the conformance tests fail?

[fieker]

why? From the docs:

Approximation (floating point and ball arithmetic only)

isapprox(f::MyElem, g::MyElem; atol::Real=sqrt(eps()))

so it is not part of the normal ring/field interface I'd say

[fingolfin]

I never really questioned the use of isapprox in the conformance tests, I assumed that Dan had checked this was the right thing to use when he added them.

I'd be happy to use something else then, but what? We currently have this helper in the conformance tests:

# helper
function equality(a, b)
   if is_exact_type(typeof(a)) && is_exact_type(typeof(b))
      return a == b
   else
      return isapprox(a, b)
   end

We use it to implement tests like these:

            @test equality(a^4, a*a*a*a)
            @test equality((a + b) + c, a + (b + c))
            @test equality(a + b, b + a)
            @test equality(a - c, a + (-c))

What would be a way to compare two QAdicFieldElem in a way that would satisfy such tests that deals with the problem that e.g. a^4 and a*a*a*a may produce slightly different results (e.g. perhaps a^4 is "more" accurate)

[thofma]

==

[fingolfin]

No I don't think you missed anything -- the general conformance tests should not require base_ring. So this is a bug in them. It may still makes sense to test it if available (specifically: if base_ring is there, then so should base_ring_type, and they should agree).

We'll fix the conformance test suite, and once that's there, I can adjust this PR (there are still a few valid changes in here, like a missing hash function; and there are also some more rings defined in Hecke for which it would be IMHO useful to run conformance tests)

[fieker]

@thofma I thought we'd rather get rid of the RelFinField?

[thofma]

I only replaced the ones in the prime decomposition of relative number fields. They might be used somewhere else still.

[thofma]

Thanks for the clarification. I am also happy to help with missing methods.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 6.46%. Comparing base (c907cf9) to head (364fe92).
Report is 127 commits behind head on master.

Files with missing lines	Patch %	Lines
src/LocalField/LocalField.jl	0.00%	2 Missing ⚠️
src/Misc/RelFiniteField.jl	0.00%	2 Missing ⚠️
src/NumField/Embedded.jl	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1707      +/-   ##
==========================================
+ Coverage    6.39%    6.46%   +0.06%     
==========================================
  Files         361      361              
  Lines      114249   114640     +391     
==========================================
+ Hits         7310     7414     +104     
- Misses     106939   107226     +287     

Files with missing lines	Coverage Δ
src/NumField/Embedded.jl	0.00% <0.00%> (ø)
src/LocalField/LocalField.jl	0.00% <0.00%> (ø)
src/Misc/RelFiniteField.jl	0.00% <0.00%> (ø)

... and 16 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[fingolfin]

I forgot about this PR :-( But now it is updated.