words, syllables, letters and their inverse for fpgroup and pc group elems in all variations

[fingolfin]

Just talked with @fieker: we have syllables(g::Union{FPGroupElem, SubFPGroupElem}) and letters(g::FPGroupElem)

1. both of these should be available for FPGroupElem and SubFPGroupElem
2. but ideally also both for PcGroupElem and SubPcGroupElem (as a subcase of the old issue PcGroups as FPGroups #952)
3. I just noticed there is also a nice WeylGroup type with a word method (cc @lgoettgens) -- it would make sense to have syllables and letters for those, too
4. conversely, there is a word method for WeylGroup which looks similar to letters (except it returns a Vector{UInt8} -- of course if the generators are involutions one doesn't need inverses. Anyway: perhaps there should also be a word method for fp and pc (sub) group elems (to be decided what it should return
5. in all these case, we also want a "reverse" function that takes the output of one of these function, plus a parent (sub)group, and re-constructs a group element.
6. ... and the docstrings for these functions should always also mention their "inverse" (and ideally include an example showing a roundtrip)

@ThomasBreuer perhaps you can have a look?

[ThomasBreuer]

Yes.

[thofma]

(There is already a word method for fp groups, which seems to do the same as letters.)

Edit: Isn't the reverse function just map_word?

[fingolfin]

It seems syllables can be inverted by passing its output to the group, like so:

julia> F = @free_group(2)
Free group of rank 2
julia> w = f1^2 * f2
f1^2*f2

julia> syllables(w)
2-element Vector{Pair{Int64, Int64}}:
 1 => 2
 2 => 1

julia> F(syllables(w))
f1^2*f2

But the same doesn't work for letters because while there is a constructor taking a vector of integers (which strikes me as a potential source of errors)

[ThomasBreuer]

Isn't the reverse function just map_word?

The question refers to the (undocumented) method of map_word that takes a description of the word in question as its first argument (the format of this description could be defined as an "external representation" format in the sense of #4151).
This map_word method is intended for evaluating the word in some generators (for example some matrices), and it computes the result by powering and multiplying. For creating a word-like object, one does not want to do this.

Yes, we can try to install special map_word methods for the case that the images of the generators are (arbitrary?) words, but is this the right point of view?

[fieker]

On Thu, Sep 26, 2024 at 02:36:12PM -0700, Thomas Breuer wrote: > Isn't the reverse function just `map_word`? The question refers to the (undocumented) method of `map_word` that takes a description of the word in question as its first argument (the format of this description could be defined as an "external representation" format in the sense of #4151). This `map_word` method is intended for evaluating the word in some generators (for example some matrices), and it computes the result by powering and multiplying. For creating a word-like object, one does not want to do this. Yes, we can try to install special `map_word` methods for the case that the images of the generators are (arbitrary?) words, but is this the right point of view?

It's about having tools. Mathematically, map_word is (or should be) a homomorphism from a freep group into s.th. evaluated. To implement this homomorphism, I have to evaluate, in general, a word in the new images, hence map_word Over the course of batteling with the cohomology stuff this happened quite a bit, ie. I needed to evaluate word in weired situations, especially when building up to morphisms: taking a relation in a small group and evaluating in a large group to get the "tails". This pattern is frequent enough to warrant support, but note: map_word uses arithmetic in the group. The proposed group(data) as an inverse to "syllable" would not perform arithmetic at all. It might do a normalization in the end, but it generally should not need it. When moving between pc and fp groups this is magnitudes faster...

…

-- Reply to this email directly or view it on GitHub: #4150 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[ThomasBreuer]

@fieker What I wanted to say in the last sentence of my comment: For the case that the generator images are words, one can in principle provide a method that creates the result without group arithmetics; this approach would still require the handling of cancellation etc. in order to get a valid result. Thus I think the idea from #4151 is more suitable than (mis)using map_word.

[fieker]

On Thu, Sep 26, 2024 at 11:58:10PM -0700, Thomas Breuer wrote: @fieker What I wanted to say in the last sentence of my comment: For the case that the generator images are words, one can in principle provide a method that creates the result without group arithmetics; this approach would still require the handling of cancellation etc. in order to get a valid result. Thus I think the idea from #4151 is more suitable than (mis)using `map_word`.

I'd argue that this askes more to provide an efficient version of map_word when the images are in fp/pc/(sub) groups...

…

-- Reply to this email directly or view it on GitHub: #4150 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[thofma]

I agree with @fieker. It is the same reason we want a fast evaluate for polynomials in specific situations.