Technicality about cycle of a permutation, for coding purposes

Question

A meta-question: If I were to ask, "What is the effect on 3 by the following permutation?"

$\sigma = (1 2)$

Answer one: It sends 3 to 3. Answer two: It is undefined.

Answer one is correct in the context of $S_k$ for $k > 2$, whereas answer two is correct when $k=2$.

I'm asking because it affects the way I will implement it in code. I'm wondering if I need to include a "context" by suppling a value $k$, or if I should ignore that and just treat any cycle as the identity for any value not present in the cycle, no matter how large. Perhaps I should have two different implementations: one for a $k$ context, one without? Or is there common agreement about how to interpret this question mathematically (and unambiguously) so that I can choose one implementation over the other? N.B. that I don't care at this point about efficiency, this is purely a kind of "mathematics/software design" impedance mismatch clarification.

Edit:

To be more clear: if one is being hyper-pedantic, not for the sake of pedantry per se but for the sake of coding accuracy since computer languages are very particular about how an idea is expressed, whereas humans (especially mathematicians) are masters of overloading symbols, would a fully unambiguous notation for cycles require that its containing symmetric group be notated, say like: $$\sigma=(1 2)_3$$ to indicate that it is a cycle in $S_3$, leaving a statement like $$\sigma=(1 2)$$ as technically undefined (but in the hands of a good writer the context will be clear so that the subscript will be inserted "in your mind", so to speak, automatically)? Or is that statement unambiguous in the sense that it is the same 2-cycle for all permutations $S_n$, no matter the value of $n$?

To put it another way, if a model theorist were notating this and wanted to ensure that the symbols all line up properly with the signatures in the formal language, would there be a single cycle $(1 2)$ that would mean the same thing in every symmetric group, or is there in fact an uncountable number of such cycles: $(1 2)_2, (1 2)_3, (1 2)_4 $ etc, one for each of the countably many symmetric groups for $n \geq 2$?

Answer 1

It ultimately is your choice.

When storing permutations, they are typically stored in a particular degree $n$ (that is, as a list of images of the points $1$ to $n$). There is no problem (i.e. everything will stay consistent, basically working in $S_\infty$) in allowing to apply such permutations to points larger than $n$ (keeping them fixed), rather than issue an error message.

A more interesting question arises when multiplying. If you interpret all permutations to be elements of $S_\infty$, and you multiply two permutations of different storage degree, there is a slight extra work in handling the different $n$'s for the two permutations. Its not hard, but it is extra code and might impose a minimal extra cost. (One issue is to allocate the right amount of memory for the product.)

On the other hand, the group $S_n$ clearly has permutations, say $(1,2)$, that only act on a small subset of points. While you could store such permutations in smaller degree, you will want to keep the storage degree the same to avoid a permanent increase/shrink of storage degree. From there the step towards fixing a degree is not far.

Indeed the two main systems for computational group theory, GAP and Magma, take a slightly different approach:

• In GAP, every permutation has an internal storage degree (the user cannot see) and when multiplying permutations of different storage degree, the larger one is chosen. This means that mathematically every permutation group is subgroup of $S_\infty$. A problem however can arise if you consider (say) $S_4$ as a subgroup of $S_{10^6}$, since suddenly every element of $S_4$ is wasting lots of storage. (There is a function RestrictedPermNC that can be used to rebuild a permutation in a smaller storage degree.)

• In Magma, every permutation lives in a particular symmetric group $S_n$. If you encounter permutations of different degree you must force them into a common, sufficiently large, degree to multiply them. The result is that magma code contains a significant number of degree-cast operations that would not be necessary in GAP. On the plus size there is likely a small speed gain when multiplying and no loss of memory issue.