-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression in ConstructAllGroups(2916) between stable-4.8
and master
#798
Comments
I observe the same problem with |
No, I think the homomorphisms seem to be harmless here. I suspect it has something to do with recent changes to lists, though I cannot point my finger on the place. The calculation hangs in a normalizer calculation for a subgroup of order 2 whjich is specially treated by using an element centralizer. A binary search through the master branch (it would be helpful if someone could check this in case I misused git) finds that commit 633aa9a [633aa9a] Merge branch 'stable-4.8' is still OK, but the subsequent commit 6c9b41d [6c9b41d] Merge pull request #781 from frankluebeck/fl_fix_random_list Several fixes for Random on long lists in 64-bit GAP triggers the problem. To observe, apply the following patch to stbcbckt.gi:
If a line |
Thanks for the assessment, I will have a closer look at what's happening
there.
Cheers,
|
Some further analysis of the change. If I revert the changes in random.gi in chunks |
For some reason the first method selection in the following takes a really long time:
Trying to compute the type of the list by any chance? Digging further... |
On Tue, May 24, 2016 at 03:11:35PM -0700, Alexander Hulpke wrote:
The first of these changes removed a buggy kernel function. This is The second change avoids that in |
Here is a (huge!) concrete example of a problem (I just extracted this from @hulpke's code). This takes 66ms in 4.7.8, and a long time in master.
|
Continuing the dive:
|
I get an entirely different target to blame -- SCRSift moving into the Kernel. However, there is also something dodgy with random numbers going on in stbc, as it reaches into the old random number generator and manipulates it directly, which I can imagine would cause trouble! Continuing to investigate. |
This is fixed by #807. I think the random number change just happened to change the random order something is generated in, causing it to hit the bad case. |
@ChrisJefferson Thank you very much for fixing this (and cleaning up the RNG access)! |
Thanks for catching this @ChrisJefferson. I am just now rerunning the computation to find whether the regression is gone. |
Good news: the runtimes in |
Observed behaviour
Did not return a result in 3 days on
master
, finishes in about4000
seconds onstable-4.8
on the same hardware.Expected behaviour
Slightly more similar runtimes.
Copy and paste GAP banner (to tell us about your setup)
Is this maybe to do with the changes to group homomorphisms?
The text was updated successfully, but these errors were encountered: