Open lgoettgens opened 10 hours ago
Do the tests here or the functions they test employ any kind of randomness?
To my knowledge, there should not be any randomness involved.
I hope to investigate more shortly (a.k.a. in the next couple of days - latest by beginning of the coming week). If you feel this is more urgent, please let me know and I will prioritize this.
It does not seem to be randomness but due to some side-effects from Polymake.prefer
blocks. This should not really happen but they should also not be necessary. I created #4351 to remove those blocks, merge target is the branch for the weight lattice.
(For this problem to appear the linear_program.jl
test file must be executed as one of the first tests.)
But it would also be better if the blow-up testcase would not rely on a specific order of the rays of some normal fan: In a session where this toric blowup test fails I get:
julia> rays(normal_fan(Oscar.simplex(2)))
3-element SubObjectIterator{RayVector{QQFieldElem}}:
[1, 0]
[-1, -1]
[0, 1]
Without the side-effect from the prefer
block I get
julia> rays(normal_fan(simplex(2)))
3-element SubObjectIterator{RayVector{QQFieldElem}}:
[1, 0]
[0, 1]
[-1, -1]
and then the testcase succeeds.
@benlorenz I will be happy to update the blowup tests so that they do not rely on the order of the rays used.
For now #4351 seems to fix the errors, and I will rebase it to master to get it merged. But adjusting the test would still be good.
To reproduce the changed order you can do the following:
In a fresh julia session directly after loading Oscar run
julia> pt = convex_hull([0 1 0]);
julia> Polymake.prefer("beneath_beyond") do
affine_hull(pt)
end;
then the rays should print like this
julia> rays(normal_fan(simplex(2)))
3-element SubObjectIterator{RayVector{QQFieldElem}}:
[1, 0]
[-1, -1]
[0, 1]
and then
julia> Oscar.test_module("test/AlgebraicGeometry/ToricVarieties/toric_blowups.jl"; new=false,tempproject=false)
should fail.
If you run the rays(...)
statement once before running the prefer block everything works fine, even after the prefer block.
(It should only change the preferred convex hull code inside the block but if it runs very early in the session it somehow seems to persist longer than intended.)
Thanks for looking into this @benlorenz!
I have seen some test failures there today on CI, but only some of the jobs failed there, e.g. see
Do the tests here or the functions they test employ any kind of randomness? If yes, maybe the tests need to be adapted a bit like e.g. in https://github.com/oscar-system/Oscar.jl/pull/4153 by @benlorenz .
failure log:
pinging @HereAround since this is about toric varieties