Add encode and pc_group for encoding finite pc groups into integers and back

[varuntrehan7]

I've added functions to wrap CodePcGroup and PcGroupCode and the doctoring,testsets with respect to it. let me know for any corrections, also unsure where I need to import so for the time being they're inside my testset

[varuntrehan7]

the new changes that I made are probably too clunky and overloaded, please let me know if they're right if not what's the correct approach.

[fingolfin]

the new changes that I made are probably too clunky and overloaded

Could you clarify what you mean by that?

[ThomasBreuer]

Is the return value H of pcgroup_code only guaranteed to be isomorphic with the group G from which the code was computed, or is H in fact guaranteed to have the same polycyclic presentation as G?

In the latter case, we could check that hom(G, H, gens(H)) does not throw an error, which is both stronger and cheaper.
If we document this stronger property then this property can be mentioned as a reason why code_pcgroup is not defined for groups of type SubPcGroup: The generators list of a SubPcGroup is in general not a polycyclic generating sequence, and GAP's CodePcGroup is defined w.r.t. such a sequence for its input.

[fingolfin]

Yes the same polycyclic presentation -- so, good point! well, we also should then add order(G) == order(H) to make sure we don't get a proper quotient.

And also good point about SubPcGroup.

[fingolfin]

Although.. GAP does support this on subgroups of pc groups, it delegates to CodePcgs( Pcgs( G ) ) -- so from that vantage point, it would be good to also support it. The hom test would still work though, wouldn't it?

[varuntrehan7]

Thank you for the clarification, I'll update my tests according to all the suggestions made. I will also document the restricted support for now.

[ThomasBreuer]

In general not.

julia> g = small_group(24, 12);

julia> s, _ = pcore(g, 2)
(Sub-pc group of order 4, Hom: s -> g)

julia> gens(s)
3-element Vector{SubPcGroupElem}:
 f3
 f4
 f3*f4

julia> GAP.Globals.Pcgs(GapObj(s))
GAP: Pcgs([ f3, f4 ])

The code for s will be computed w.r.t. the pcgs of s, and the PcGroup created from the code will have a pcgs as its gens value.
Then hom will be asked to map the 3-element gens(s) to the 2-element gens value of the new group.

I think supporting code_pcgroup for SubPcGroups would be asking for trouble.
It is safer to request explicitly switching from a given SubPcGroup to a PcGroup before creating the code, because this is then the group whose presentation will correspond to that of the group created from the code.

(The GAP documentation of CodePcGroup and PcGroupCode should also be made more precise.)

[varuntrehan7]

hi, sorry if I don't respond for a day. I have a flight in an hour, I see a lot of tests are failing, I will get to them immediately as soon as I land in Germany tomorrow. Apologies for the delay.

[lgoettgens]

This PR has a lot of open comments. @varuntrehan7 please have a look at all of them again, and if you think that you did that change in a commit, click on "resolve conversation". That way we (and in particular you) can more easily see which comments you missed.

[lgoettgens]

Meta-question to @fingolfin and @ThomasBreuer: I don't quite like the names of the two new functions; they don't seem to fit in the OSCAR naming scheme. To me, a more appropriate name for the direction "(code, order) -> group" would be pcgroup or PcGroup, for the other direction I suggest code.

@varuntrehan7 please do not attempt to do any renamings here, until we have resolved the naming discussion!

[lgoettgens]

In your latest commit, you again contradict with yourself. The docstring change there is not reflected in the code!

[varuntrehan7]

In your latest commit, you again contradict with yourself. The docstring change there is not reflected in the code!

Apologies for the late response. I think I was able to fix the mistake I was making, please let me know if this was what you were referring to

[lgoettgens]

In your latest commit, you again contradict with yourself. The docstring change there is not reflected in the code!

Apologies for the late response. I think I was able to fix the mistake I was making, please let me know if this was what you were referring to

No, you didn't fix it. The docstring claims that the input is converted to GapInt, but in the code the input is converted to Int...

[varuntrehan7]

In your latest commit, you again contradict with yourself. The docstring change there is not reflected in the code!

Apologies for the late response. I think I was able to fix the mistake I was making, please let me know if this was what you were referring to

No, you didn't fix it. The docstring claims that the input is converted to GapInt, but in the code the input is converted to Int...

does this work?

[lgoettgens]

In your latest commit, you again contradict with yourself. The docstring change there is not reflected in the code!

Apologies for the late response. I think I was able to fix the mistake I was making, please let me know if this was what you were referring to

No, you didn't fix it. The docstring claims that the input is converted to GapInt, but in the code the input is converted to Int...

does this work?

No. If you input eg ZZ(2)^65, you will get an overflow when converting to the Int and don't even reach the GapInt conversion

[varuntrehan7]

In your latest commit, you again contradict with yourself. The docstring change there is not reflected in the code!

Apologies for the late response. I think I was able to fix the mistake I was making, please let me know if this was what you were referring to

No, you didn't fix it. The docstring claims that the input is converted to GapInt, but in the code the input is converted to Int...

does this work?

No. If you input eg ZZ(2)^65, you will get an overflow when converting to the Int and don't even reach the GapInt conversion

In this new commit I have tested conversions from ZZRingElem, BigInt, and Int all successfully reaching GapInt with no overflow.

[fingolfin]

encode / encoding for mapping a PcGroup to a code (I don't like encoding_pcgroup or pcgroup_encoding because the input type already indicates this)

@ThomasBreuer points out that that in the future this function could support arbitrary finite solvable groups / "pcgs" -- then it could be encode_solvable_group or encode_pcgs ("pcgs" - "pc-group generating system"). Or maybe encode_presentation ?

Perhaps this is a discussion we can have in the future, and for now we just do encode ?

For the reverse, we can just have pc_group(order, code) (yes, with that order of arguments -- because that matches what small_group, transitive_group, primitive_group etc. all do -- of course that case is a bit different, but I feel that's what I'd guess).

[fingolfin]

As @lgoettgens pointed out this is inefficient. We will add a GAP.GapInt constructor in GAP.jl so that one can directly write GAP.GapInt(code)

[lgoettgens]

See oscar-system/GAP.jl#1283. Once that and oscar-system/GAP.jl#1284 are merged (and further 20 minutes have passed), this line can be changed to

Suggested change

	return PcGroup(GAP.Globals.PcGroupCode(GAP.GapInt(BigInt(code)),GAP.GapInt(BigInt(order))))
	return PcGroup(GAP.Globals.PcGroupCode(GapInt(code), GapInt(order)))

At the same time, please change

Oscar.jl/Project.toml

Line 38 in c0fadd1

GAP = "0.16.0"

to "0.16.1"

[fingolfin]

GAP.jl 0.16.1 is out now, so this can be done.

[fingolfin]

Suggested change

Both `order` and `code` can be of type `Int`, `BigInt`, or `ZZRingElem`.

[lgoettgens]

@varuntrehan7 If you think that this is finished and CI passes (apart from any "nightly" and the "Enforce PR labels" jobs), please mark this PR as "ready to review" to get a final round of reviews.

[ThomasBreuer]

encode and decode should eventually appear in the manual, for example in the section "Functions for (subgroups of) pc groups".

[fingolfin]

@varuntrehan7 this still needs to be hooked up in the .md files. Please ask questions if you have trouble with that.