Optimization for small permutation groups

[vdelecroix]

This ticket proposes micro optimizations for small permutation groups. The rationale is to handle the situation where we have billions of combinatorial objects and need to run through their automorphism groups most of which are trivial or let's say have size at most 100. An even more concrete application is given by ​admcycles MR 14 where there is an attempt to use graph automorphisms from Sage instead of a handmade implementation. This turns out to result in a major slowdown! For example

sage: from admcycles.admcycles import Hyperell
sage: %time H = Hyperell(3)

takes 13.5 s on master but with MR 14 takes 17.4 s.

The profiling points to

• the constructor __init__ of PermutationGroupElement: see #28652
• the subgroup method of PermutationGroupElement
• the product p1 * p2 when p1 is a symmetric group element and p2 is a permutation group on the same domain: see #28652 (and also the bug #28544)
• __iter__ for PermutationGroupElement (that currently involves computing a strong generating scheme): see #28652 and #28653

The optimizations proposed in this ticket noticeably speed up the Hyperell(3) computation mentioned above: from 17.4 s with the previous Sage implementation or 13.5 s with admcycle's previous handmade implementation, the timing goes down to 9 s.

[vdelecroix]

New commits:

​f67ffcc

WIP: make small perm group faster

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​096659c	28539: rework constructor of PermutationGroupElement
​2d23d92	28539: faster multiplication and iteration
​d00d370	28539: fix some doctests
​5888249	28539: mark not tested bug tracked in #28544
​0dbcc33	28539: reynolds operator and Galois conjugation

[vdelecroix]

hmm some py2/py3 issue I guess.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​2c62905	28539: rework constructor of PermutationGroupElement
​55d3e8a	28539: faster multiplication and iteration
​b027f91	28539: fix some doctests
​5d77c23	28539: mark not tested bug tracked in #28544
​6ca3833	28539: reynolds operator and Galois conjugation

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​44bd863

28539: fix more doctests (python2 and python3)

[chapoton]

Still failing. And proliferation of #py2 and # py3 does not seem to be a good solution.

[tscrim]

I agree with Frédéric that adding a whole bunch of # py2 and # py3 tags is not a good solution. I am assuming this comes from this change:

-        return self.iteration(algorithm="SGS")
+        if len(self._gens) == 1:
+            return self._iteration_monogen()
+        elif self.cardinality() <= 100:
+            return self.iteration(algorithm="BFS")
+        else:
+            return self.iteration(algorithm="SGS")

and the BFS option calls RecursivelyEnumeratedSet, which has consistency problems on Python3 IIRC. So we have to solve that bigger problem first.

I have some other comments:

I don't see the point of going to cycles just to convert back here:

return grp.element_class(self.to_cycles(singletons=False), grp, check=False)

I know this was already done, but it seems useless as the PermutationGroupElement stores things internally as a list in essentially the same way.

I would probably Cythonize from_cycles.

Is there a reason why _set_identity and _set_list_images are cpdef and not just cdef (which is faster when being called by C code)? By being cpdef, they also need doctests.

[vdelecroix]

Thanks for the feedback. I will cut the ticket and start by optimizing the constructor. Optimizing the iterator will be postponed to another one.

[gh-mwageringel]

See also #28674 which should eventually solve the consistency problems of RecursivelyEnumeratedSet.

[vdelecroix]

Replying to gh-mwageringel:

See also #28674 which should eventually solve the consistency problems of RecursivelyEnumeratedSet.

I don't think that the enumeration order is relevant here. This is convenient for doctests and only shows the weakness of them.

[embray]

Ticket retargeted after milestone closed

[mkoeppe]

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

[slelievre]

Supporting Python 2 is no longer needed now.

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

Setting a new milestone for this ticket based on a cursory review.