What is the efficiency of this sorting algorithm?

Question

Recently I thought of a different way to sort numbers. Basically it involves treating a list of numbers as a series of upwards and downwards shifts. For example 1 3 2 would be translated to up-down since from one to three there is an increase and from three to two there is a decrease.

Every number in a list (excluding repeated elements) can be represented as a number from 1 to the size of the list, where this number represents its position in the ordered list. Therefore, any list of size n can be expressed as a series of numbers from the range 1-n. Given that there are n possible entries for the first element, n-1 for the second, n-2 for the third and so on, we see there are n! possibilities for a list of size n. These possibilities can then be grouped in terms of what up-down behavior they exhibit.

3412 and 2413 can be grouped into up-down-up.

Now that we have the permutations grouped by their behavior we find a specific transformation for each group so that the greatest variety of groupings is created after the transformation. A transformation in this context means shifting the indexes of the permutation and is written as a list of size n. For example, if we apply 3214 to the permutation 4213 then we get the permutation 1243. The first index becomes the first, the second becomes the second the first becomes the third and the fourth stays the fourth. In this example the permutation 4213 had rule down-down-up and after the transformation changed to up-up-down. As long as more than one permutation belongs to a group following a given rule after one or more transformations, more transformations need to be applied. Elaboration: if we have 4 permutations of type up-down-up and we apply transformation a to them and get two of type down-down-up and two of type up-up-down, we need to apply transformation b to the down-down-up group and transformation c to the down-down-up group. Finally we have one permutation from b which changed to down-up-up, one from b which turned to up-up-down, one from c which turned to down-up-down and one from c which turned to down-down-up. Once every permutation belongs to only one group, we store the string of rules that transformation followed until becoming its own group. Moreover, we find what transformation leads to this permutation being sorted, or in up-up-up…-up. In this example the one that ended up as down-up-down would be written as (up-down-up)-(down-down-up)-(down-up-down).

Once we know how every permutation behaves given a series of transformations, we are ready to sort any list of size n. Keep in mind that the preparation process needs to be done only once. The data structure which holds it together, (im thinking a map with keys being strings of u's for ups and d's for downs and values for the permutations which follow those rules) needs to be created only once and can then be used infinitely many times to sort any list of size n.

In order to sort a list with the data structure we first look through the list in order to determine which rule it originally follows. Then we apply the transformation we previously chose for this rule and see what rule it changes to. We repeat this process until we reach a rule with only one permutation. At this point we get the sorting transformation and apply it to our list to get a sorted list.

I realize that the preparation phase for this algorithm is o(n!) but since it needs to be done only once, and after that point it works at worst-case o(nlogn) (or maybe even better, honestly not sure what the efficiency is) it may be worth it. Given that n! grows ridiculously fast, I realize the memory the backing data structure requires is a considerable problem. However, maybe it can just be used for small lists.

Answer 1

I don't follow how this becomes more efficient than simpler mechanisms. You do your N! preparation work; you now have a graph of up-down (UD) sequences; each node has a list of ordinal sequences that match that UD pattern and a preferred transformation for that node. Eventually, you can find a path to the sorted (all U) node from anywhere.

What I don't see is any magic that makes this a good idea. To sort a list,

repeat until done
    - traverse the elements to determine its UD pattern: O(n)
    - if the pattern is all U, quit; the list is sorted: O(n)
    - find the node that matches that pattern: O(1) hash function
    - apply the node's transformation to the list elements: O(n)

I see that the preparation work reduces the number of iterations to O(log n), giving an algorithm of O(n log n). However, this appears to be intrinsically slower than any one of the classic O(n log n) algorithms, such as quicksort .

Have I missed something in the intended implementation?