Что касается алгоритма сортировки: первая часть алгоритма настолько жадная, что трудно придумать разумно устроенную вторую часть алгоритма - граф сортировки хоть и может сохранять свойство "дерево", но структура леса становится столь нерегулярной - сильно зависит от входных данных. При любом дальнейшем алгоритме придется использовать дополнительную память для хранения истории сравнений (=структура графа сравнения).
Предлагаю придерживаться алгоритма со следующими свойствами:
1. Сравнивать между собой только корни деревьев - это позволит поддерживать свойство структуры данных "лес".
2. Структуру графа сравнения хранить в массиве
, где
- это номер элемента в сортируемом массиве
.
- это число вершин, входящих в поддерево
-го элемента. Чтобы перейти к следующему дереву или поддереву, достаточно увеличить
на величину
. Если происходит выход за пределы, то значит деревьев и поддеревьев больше нет.
3. Сравнивать корни двух крайних левых деревьев леса. Пусть
- это номер корня самого левого дерева.
3.1. Если корень самого левого дерева больше следующего (
), то достаточно изменить
этого корня:
- это операция сращивания двух левых деревьев.
3.2. Иначе придется обменивать самое левое дерево с корнем дерева правее. Довольно затратная операция, но все же. После обмена также изменить
по формуле выше (операция сращивания).
Возможно данный алгоритм очень даже оптимальный по нашему критерию?
-- 06.09.2015, 22:02 --arseniiv писал(а):
Для «почти сортировки» разве поле алгоритмов не распахано, если уже не поперёк, то хотя бы вдоль? Кажется, краем уха что-то на эту тему слышал.
Может речь шла о сортировке частично сортированных массивов? Про такие алгоритмы я слышал, например, алгоритм TimSort применяется в ОС Android.
arseniiv писал(а):
Сортировки «до конца» с минимумом сравнений хотя бы у Кнута в «Искусстве…» (том 3) рассматриваются, хотя особо не вчитывался, чтобы сравнить.
Спасибо, еще раз загляну в этот труд.