1

One easy way to store a permutation of a sequence of distinct elements is as a string (or list) like, "acb" which is clearly a permutation of "abc". However, if I use a string to represent my permutation, I will end up with the possibility of strings like "abb" which do not correspond to any permutation. As a result, the representation of permutations in strings is not dense, so to speak. Lists of indices like [2,3,1] have the same problem.

Alternatively, I could recognize that over N elements there are N! permutations, which can be enumerated in some way. Then, I could store the permutation as an integer. However this is not ideal because the integer would be opaque to interpretation (nobody would know what "permutation number 43" meant), and also because the group structure of the integers over addition is nothing like the group structure of permutations.

Is there a way to represent permutations in a computer that does not have the drawbacks of the methods that I have suggested?

Display Name
  • 209
  • 2
  • 9
  • 1
    Yes. In fact there is a mapping from the integers to all permutations of 1 to n. Look up "rank/unrank of permutations" or "calculating the nth lexicographical permutation." – Joseph Wood Jan 28 '19 at 02:21
  • 1
    I don't see the problem you have with a single integer from 0 to N!-1. It's pretty easy to map an integer **i** to the **ith** permutation in lexographic order, for example, and that seems to be less "opaque" than any other "dense" alternative. – Matt Timmermans Jan 28 '19 at 03:33
  • @MattTimmermans Can it be mapped in O(1) time? I have only seen O(n) algorithms. – Display Name Jan 28 '19 at 16:10
  • 1
    The only O(1) solution I know of, is a lookup table but I think this defeats the purpose. You could check Fischer Yates for sub O(n) complexity – Joseph Wood Jan 28 '19 at 22:45
  • I think I was mistaken about the time complexity of Fisher-Yates and confused it with a post that @MattTimmermans appeared in not too long ago that referred to the Feistel cipher that exhibits sub O(n) _memory_ complexity. Anywho, this may help : https://stackoverflow.com/a/51414162/4408538 – Joseph Wood Jan 29 '19 at 02:44
  • 1
    @DisplayName O(n) would be the size of the *output* of any mapping, so you won't be able to do better than that in very many cases -- essentilaly you'd have to store the permutation in whatever form you can use directly. – Matt Timmermans Jan 29 '19 at 02:51
  • The other thing that needs to be considered is what is your group operator on your permutations? – Joseph Wood Jan 29 '19 at 03:09

0 Answers0