Modify testset "Generic.Ideal.addition"

[fingolfin]

Depending on the random seed, this test could take forever resp. run out of memory. Restrict it to fewer tests for now.

This may not be enough, though; we may need to set a fixed RNG seed in this testset, or just replace the "random" ideals by fixed ones which are known to not exhibit the bad performance.

Don't use random examples in the multivariate case, as some of these can
lead to really horribly bad runtimes. Instead use a fixed list of
examples.

For the univariate cases and the ideals in Z, I did not change anything
so far, as those should not suffer from the same problems (famous last
words...)

CC @benlorenz

[codecov]

Codecov Report

Merging #1458 (a1b4e6f) into master (e1c902f) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1458      +/-   ##
==========================================
+ Coverage   84.60%   84.61%   +0.01%     
==========================================
  Files         110      110              
  Lines       29379    29379              
==========================================
+ Hits        24857    24860       +3     
+ Misses       4522     4519       -3     

see 2 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[benlorenz]

Looking at the CI status it seems that Generic.Ideal.addition is not the only problem. Both nightly and 1.10 died before reaching the Generic.Ideal tests.

Also I don't think reducing the number of tests will fix this. I would guess there is probably a single example that triggers this. So depending of the index of the example we might just skip this now but it can eventually reappear for a different seed.
I will let the code run a bit more to check if that is really true and also to see if this happens with the reduced loops as well.

I would be in favor of fixed ideals.

[benlorenz]

With the reduced loops in this PR please try seed 16234.
That seed seems to be stuck here at

i = 3
I = AbstractAlgebra.Generic.Ideal{AbstractAlgebra.Generic.MPoly{BigInt}}(Multivariate polynomial ring in 2 variables over integers, AbstractAlgebra.Generic.MPoly{BigInt}[60*x^4 - 80*x^3*y + 48*x*y^3 - 64*y^4 - 70*y, 7*x^2*y^3 + 10*x^3 + 8*y^3, 6*x^3*y^2 + 6*x^2*y^3 + 20*x^3 + 16*y^3 + 10, 48*x*y^5 - 64*y^6 - 70*y^3 - 100*x, x^3*y^3 + x^2*y^4 + 10*x^4 - 10*x^3*y + 8*x*y^3 - 8*y^4 - 10*y, 1792*y^7 + 2*x^2*y^3 + 1152*y^5 + 1470*x*y^3 + 1960*y^4 - 2740*x^3 - 2192*y^3 + 2100*x^2 + 2800*x*y - 2400, 16*x*y^6 + 576*y^7 + 3*x^2*y^3 + 384*y^5 + 490*x*y^3 + 630*y^4 - 910*x^3 - 728*y^3 + 700*x^2 + 900*x*y - 800, x^2*y^5 + 1280*y^7 + 4*x^3*y^2 + 3*x^2*y^3 + 824*y^5 + 1050*x*y^3 + 1400*y^4 - 1950*x^3 - 1560*y^3 + 1500*x^2 + 2000*x*y - 1710])
J = AbstractAlgebra.Generic.Ideal{AbstractAlgebra.Generic.MPoly{BigInt}}(Multivariate polynomial ring in 2 variables over integers, AbstractAlgebra.Generic.MPoly{BigInt}[9*x^3*y^3 + 5*x^2*y^3 + 8*x^3*y])

in the first loop.

Edit: That seems to succeed after about 7 minutes and with 22GB of RAM.

[fingolfin]

OK, then I agree a fixed list of ideals would be preferable.

[fingolfin]

Modified to use a fixed list of polynomial ideals in the multivariate cases.

[fingolfin]

OK clearly this is not enough: I missed the function mix_ideal... sigh. I'll refine this.

[fingolfin]

I was easily able to reproduce this locally with a loop

for i in 1:100
  println(i)
  Random.seed!(i)
  @time include("test/generic/Ideal-test.jl")
end

where it took 50 minutes in some cases, e.g. seed 14.

With the latest tweak, each iteration of the above loops runs in about 15 seconds for me.

[thofma]

Are you happy with the current state @fingolfin?

[fingolfin]

So Generic.LaurentMPoly.conformance uses up a lot of memory, triggering multiple heap expansions, until:

...
GC: pause 903.67ms. collected 303.399345MB. incr 
Heap stats: bytes_mapped 3456.84 MB, bytes_resident 1847.31 MB,
heap_size 2884.55 MB, heap_target 5465.80 MB, Fragmentation 2.051

GC: pause 12610.96ms. collected 664.214760MB. incr 
Heap stats: bytes_mapped 3456.84 MB, bytes_resident 2724.72 MB,
heap_size 4992.27 MB, heap_target 10679.77 MB, Fragmentation 1.470
Test Summary:                    |  Pass  Total     Time
Generic.LaurentMPoly.conformance | 10911  10911  1m33.7s

and then it proceeds to run other test... until it eventually dies.

My guess: it never reduces the heap_target, which should never have grown that big in the first place, given that total: 6.760 GiB is reported at the start. And so it eventually tries to actually allocate this, and dies...

To test my theory I inserted a GC.gc() call after that test.... And that made it pass! At least in 1.10 (Julia nightly is completely broken for us for other reasons)

CC @gbaraldi

[fingolfin]

@thofma I am happy with the first commit. I am not sure we should keep the second "HACK" commit which inserts a GC.gc() call ... I mean, it does help right now (or at least it did in that one CI run...), which is useful.... Maybe it should be kept as a separate commit, though (i.e. no "squash") so that we can easily revert it later (as soon as they revert the GC changes from Julia's 1.10 branch, we'll want to test that.

But I am also fine if this gets squashed; or if we just merge the first commit... shrug

[thofma]

Let's keep it for now