Make tests pass with GAP 4.15

[antonio-rojas]

GAP 4.15 causes a few test failures caused mostly by different ordering of group characters and different elements returned for an_element in group algebras, make test pass with both old and new versions.

[github-actions]

Documentation preview for this PR (built with commit 733c477; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[collares]

Not sure if you addressed this already, but it seems that some tests are now really slow:

sage -t --long --warn-long 30.0 --random-seed=48470199707196632862320241923438074047 /nix/store/lcqvpnmfb5p7j07wzxialg4315qv2k1p-sage-src-10.6/src/sage/groups/libgap_morphism.py
**********************************************************************
File "/nix/store/lcqvpnmfb5p7j07wzxialg4315qv2k1p-sage-src-10.6/src/sage/groups/libgap_morphism.py", line 452, in sage.groups.libgap_morphism.GroupMorphism_libgap._call_
Warning: slow doctest:
    f = O.hom([r*x*r_ for x in O.gens()])  # long time (19s on sage.math, 2011)
Test ran for 521.46s cpu, 524.36s wall
Check ran for 0.00s cpu, 0.00s wall
    [209 tests, 524.92s wall]

[antonio-rojas]

Not sure if you addressed this already, but it seems that some tests are now really slow:

sage -t --long --warn-long 30.0 --random-seed=48470199707196632862320241923438074047 /nix/store/lcqvpnmfb5p7j07wzxialg4315qv2k1p-sage-src-10.6/src/sage/groups/libgap_morphism.py
**********************************************************************
File "/nix/store/lcqvpnmfb5p7j07wzxialg4315qv2k1p-sage-src-10.6/src/sage/groups/libgap_morphism.py", line 452, in sage.groups.libgap_morphism.GroupMorphism_libgap._call_
Warning: slow doctest:
    f = O.hom([r*x*r_ for x in O.gens()])  # long time (19s on sage.math, 2011)
Test ran for 521.46s cpu, 524.36s wall
Check ran for 0.00s cpu, 0.00s wall
    [209 tests, 524.92s wall]

By "now" do you mean with GAP 4.15? This PR only changes the expected output of some tests

[collares]

Yes, sorry, I should have been more clear. The test I mentioned seems to be a lot slower on GAP 4.15 than it was on GAP 4.14. More specifically, testing src/sage/groups/libgap_morphism.py goes from 3 seconds on GAP 4.14 to at least 460 seconds (minimum of three runs) on GAP 4.15, and it doesn't seem to be seed-specific.

[antonio-rojas]

Yes, sorry, I should have been more clear. The test I mentioned seems to be a lot slower on GAP 4.15 than it was on GAP 4.14. More specifically, testing src/sage/groups/libgap_morphism.py goes from 3 seconds on GAP 4.14 to at least 460 seconds (minimum of three runs) on GAP 4.15, and it doesn't seem to be seed-specific.

Indeed. I have reported it upstream at gap-system/gap#6135

[antonio-rojas]

Tests are passing now with GAP 4.14 and 4.15 modulo the upstream bugs gap-system/gap#6133 and gap-system/gap#6135, ready for review

[cxzhong]

the GAP4.15.1 is out.

[antonio-rojas]

All tests pass now with unpatched 4.15.1

[cxzhong]

All tests pass now with unpatched 4.15.1

Thank you. I want to know just using random is ok?

[antonio-rojas]

All tests pass now with unpatched 4.15.1

Thank you. I want to know just using random is ok?

For the examples in the doc source files it should be, those are already widely tested in the code itself.

[cxzhong]

All tests pass now with unpatched 4.15.1

Thank you. I want to know just using random is ok?

For the examples in the doc source files it should be, those are already widely tested in the code itself.

Thank you. I will set positive review.

[orlitzky]

Adding # random doesn't really make the tests pass with both versions, it just ignores any failures short of a segfault/timeout.

We can check the GAP version with libgap.GAPInfo["Version"] at runtime. Adding # needs gap414 and # needs gap415 would take only a few lines, and would leave behind useful examples that are actually tested. I've done this with # needs mpmath13 in #41014 for example and it was painless.

[antonio-rojas]

Adding # random doesn't really make the tests pass with both versions, it just ignores any failures short of a segfault/timeout.

We can check the GAP version with libgap.GAPInfo["Version"] at runtime. Adding # needs gap414 and # needs gap415 would take only a few lines, and would leave behind useful examples that are actually tested. I've done this with # needs mpmath13 in #41014 for example and it was painless.

I'm aware of that, but that is not something that would look good in an examples block in the middle of an html documentation page whose main purpose is to teach users how sage works. I actually question the need to test documentation source files at all, which just repreat the tests that have already been run in the main code up to 10 times (once per language).

[orlitzky]

I'm aware of that, but that is not something that would look good in an examples block in the middle of an html documentation page whose main purpose is to teach users how sage works. I actually question the need to test documentation source files at all, which just repreat the tests that have already been run in the main code up to 10 times (once per language).

I don't think re-testing the code was ever the intention. It helps keep the documentation from falling out of date. Right now,

sage: G.character_table() # random
[ 1  1  1  1  1]
[ 1 -1 -1  1  1]
[ 1 -1  1 -1  1]
[ 1  1 -1 -1  1]
[ 2  0  0  0 -2]

looks reasonable because we know what it does in both recent versions of GAP, and "random" means "ignore minor (mathematically unimportant) differences." But this test will continue to pass if someone deletes the character_table() method two years from now. In situations like those it's nice to get a heads up.

[antonio-rojas]

looks reasonable because we know what it does in both recent versions of GAP, and "random" means "ignore minor (mathematically unimportant) differences." But this test will continue to pass if someone deletes the character_table() method two years from now. In situations like those it's nice to get a heads up.

Well, if someone deletes the method this test would throw an error. The worst that could happen is that some output format changes are not reflected in the documentation. I see this as any other instance of manually maintained docs getting out of date. Ideally there would be a way to "link" an examples block from a py file in the rst file so the changes would automatically be picked up.