QuadFormWithIsom Patch 2: towards better time in CI

[StevellM]

We fix some type instability, remove unnecessary checks and improve some functions, with @lgoettgens

• Make orbit_representatives_and_stabilizers type stable
• Fix a function for the creation of subgroups of AutomorphismGroup{<:Union{TorQuadModule, GrpAbFinGen}}
• Make the finite field element conversion "GAP -> Oscar" types stable
• Make base_ring for matrix groups type stable
• Improvements of methods in QuadFormWithIsom
• Fix some type stability in QuadFormWithIsom

Related to #2599
@fingolfin could you check if the GAP-related changes are ok ?

[fingolfin]

Looks plausible to me, thanks!

[thofma]

Any noticeable improvements for compilation timings?

[lgoettgens]

Any noticeable improvements for compilation timings?

Still waiting for ci. We had to wait for #2826 to be merged

[codecov]

Codecov Report

Merging #2825 (9d8b249) into master (99f9cdb) will decrease coverage by 0.16%.
Report is 7 commits behind head on master.
The diff coverage is 93.36%.

@@            Coverage Diff             @@
##           master    #2825      +/-   ##
==========================================
- Coverage   80.63%   80.47%   -0.16%     
==========================================
  Files         456      456              
  Lines       64646    64945     +299     
==========================================
+ Hits        52127    52266     +139     
- Misses      12519    12679     +160     

Files Changed	Coverage
src/GAP/gap_to_oscar.jl	50.00%
.../QuadFormAndIsom/src/hermitian_miranda_morrison.jl	77.77%
...ntal/QuadFormAndIsom/src/lattices_with_isometry.jl	82.50%
experimental/QuadFormAndIsom/src/enumeration.jl	97.29%
experimental/QuadFormAndIsom/src/embeddings.jl	100.00%
src/Groups/abelian_aut.jl	100.00%
src/Groups/gsets.jl	100.00%
src/Groups/matrices/MatGrp.jl	100.00%

[lgoettgens]

CI doesn't seem to give reliable timings (aka there were differences in compilation time when no changes in this code were made, so I do not see a good baseline to compare against)

[StevellM]

@thofma we have at least better test timings once everything is compiled

[fingolfin]

You can't do timings using CI. First off, different machines run CI jobs, they can vary by their performance by a factor 2. Then on the same machine, timings can vary depending on how many VMs are active on that machine at a time, and how active each is. And then there is randomization, which should maybe not affect compilation time, but certainly can affect runtime greatly.

The only good way to compare timings before / after is to take an example input and compute it with the old and with the new code, on the same machine, which should not be busy (if it is a laptop, also plug it in, etc. -- but better test on a server, not a laptop or PC, they have far more flucation). Ideally also use @benchmark from the BenchmarkTools package which runs the test multiple times (so you can't use it to measure compile times, but that's OK, we are concerned with runtime here).

And to avoid random fluctuations, call Oscar.randseed!(1) or so at the start of your test. So

using BenchmarkTools
@benchmark  (Oscar.randseed!(1) ; run_real_test_case())