`Blocks` should either work for intransitive actions or consistently reject them

[wilfwilson]

Should Blocks work for intransitive groups? Currently, it is documented to only work for transitive actions (understandably). If not, what should be the behaviour of Blocks given an intransitive group?

Note that the behaviour of Blocks, given an intransitive action, is inconsistent:

gap> G := Group([(1,2)(3,4)]);
Group([ (1,2)(3,4) ])
gap> Blocks(G, [1..4], OnPoints);
Error, <G> must operate transitively on <D> at /Users/Wilf/gap/lib/oprtperm.gi:178 called from
BlocksOp( G, D, [  ], gens, acts, act ) at /Users/Wilf/gap/lib/oprt.gi:2209 called from
orbish( G, pnt, gens, acts, act ) at /Users/Wilf/gap/lib/oprt.gd:858

gap> G := Group([(1,2,3,4)]);
Group([ (1,2,3,4) ])
gap> Blocks(G, [1..5], OnPoints);
[ [ 1 .. 5 ] ]

[fingolfin]

This looks like a bug to me. Indeed, for the same group G, I get this depending on the set Omega:

gap> Blocks(G, [1..5], OnPoints);
[ [ 1 .. 5 ] ]
gap> Blocks(G, [1..4], OnPoints);
Error, <G> must operate transitively on <D>

So it seems that perhaps something is wrong about the transitivity check?

I also wonder why the documentation for MaximalBlocks and RepresentativesMinimalBlocks doesn't mention don't mention transitivity at all, given that they seem to have the exact same restrictions as Blocks...

That said, of course in principle we could make these operations more general, but I have my doubts about how useful that is:

The definition of block system given in the GAP manual works for intransitive groups, too. However, it doesn't seem terribly useful to me to support the intransitive case: if I am not mistaken, then the set of block systems of a group G acting on a domain Omega splits into the direct product of the sets of block systems of action of G restricted to the orbits o_1, o_2, ..., o_k of the group on Omega. So if the number of block systems is n_1, ..., n_k on each orbit, we get n_1*...*n_k in total -- but I'd imagine that for most applications, it'd be more useful to have the n_1+...+n_k separate block systems at hand.

That said, it might be worthwhile to at least expand the manual a bit to discuss why the operations are only working for transitive actions, and how one could/should handle intransitive actions, possibly with an example. Well, or we just support intransitive actions... shrug

I wonder whether @hulpke has any additional thoughts on this?

[hulpke]

What happens is that the routine, before computing an orbit, checks whether domain has prime length, and in this case returns the full domain (without checking transitivity). One could add an explicit test (at extra cost if the degree is prime). My preference would be to document that the result of Blocks is undefined if the action is not transitive.