Guard some IdGroup calls by ID_AVAILABLE

[fingolfin]

... instead of hardcoding assumptions about the availability of IdGroup.

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 78.66%. Comparing base (b04e9ba) to head (2bfef39).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
lib/grplatt.gi	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6353      +/-   ##
==========================================
+ Coverage   78.63%   78.66%   +0.02%     
==========================================
  Files         684      684              
  Lines      292689   292707      +18     
  Branches     8686     8660      -26     
==========================================
+ Hits       230155   230254      +99     
+ Misses      60726    60641      -85     
- Partials     1808     1812       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ThomasBreuer]

The old code uses IdGroup only if the group in question has order at most 1000. The proposed code uses it also for larger groups, for example for groups of order p^4, where p is any prime. Is this intended?

[ThomasBreuer]

This is irritating:
We have hom, and here we create its image, but a few lines above we create this group as gp/nor on the fly, just in order to call IdGroup.

[fingolfin]

Yeah that's weird. I've rearranged the code now to avoid this.

[fingolfin]

The limit to 1000 seemed arbitrary, perhaps an attempt approximate ID_AVAILABLE, so I left it out. But perhaps there is a deeper reason? Anyway, I'd be happy to add it back, though ideally with a comment explaining the limit...

The code was added by @hulpke on 2013-01-25, in a commit with commit message SubgroupsTrivialFitting. Perhaps he can tell us more?

[limakzi]

@fingolfin
I do not like such hard-coded limits in the middle of the code.
Can move it to general file, like limits.gi?

[hulpke]

It is more than ID_AVAILABLE, but avoiding too large groups (where identification might take too long, e.g. 1024). No objection to provide a more general feature, but it is not just capability but time needed for such calls.

[fingolfin]

Since I'd like to move on, I've restored the limit for now (well... almost: it now restricts to order < 1000 in both cases; before, it was < 1000 in one case and <= 1000 in the other -- but I hope this tweak is acceptable).

I was not aware that IdGroup is "slow" for some orders above 1000, do we have concrete examples for that? Note that there is no IdGroup for orders which are a multiple of 512, so there is nothing to worry about that for e.g. 1024

Regarding a file limits.gi that contains all "magic constants": that goes way beyond the scope of this PR. If someone wants to tackle that, be my guest.

[ThomasBreuer]

I was not aware that IdGroup is "slow" for some orders above 1000, do we have concrete examples for that?

At the moment, I do not have concrete examples, but some time ago I made experiments in a situation where many small groups arise, and a lot of them turn out to be uninteresting, due to some conditions.
Checking these conditions can be expensive, the same isomorphism type can occur often, and in the end I want a list of group ids for the interesting groups.
Hence I thought that time could be saved by checking the IdGroup value first where possible.
However, this slowed down the computations, showing at least that IdGroup cannot be regarded as a cheap function.

[limakzi]

Regarding a file limits.gi that contains all "magic constants": that goes way beyond the scope of this PR. If someone wants to tackle that, be my guest.

Haven't found issue for that, is there?

At the moment, I do not have concrete examples, but some time ago I made experiments in a situation where many small groups arise, and a lot of them turn out to be uninteresting, due to some conditions.

I cannot find any neither, but I feel same.
I can easily imagine it will fail or be expensive for such small groups too.

However, this slowed down the computations, showing at least that IdGroup cannot be regarded as a cheap function.

Yes.

[fingolfin]

Haven't found issue for that, is there?

I am not aware of any

[fingolfin]

@hulpke is this PR OK for you then? it should not change current behaviour in an essential way (unless I messed up). If so, please approve