Я использую его все время, на самом деле больше, чем сортировки, основанные на сравнении, но по общему признанию я - чудак, который работает больше с числами, чем с чем-либо еще (я почти никогда не работаю со строками, и они обычно интернированы, если это так, в какой точке основание сортировка может снова пригодиться для фильтрации дубликатов и вычисления пересечений множества; я практически никогда не делаю лексикографических сравнений).
Базовым примером является радикальная сортировка точек по заданному измерению как часть поиска или медианного разбиения или быстрый способ обнаружения совпадающих точек, фрагментов глубины или радикальная сортировка массива индексов, используемых в нескольких циклах, чтобы обеспечить более дружественный к кэшу доступ паттерны (не возвращаться назад и вперед в памяти, а только возвращаться и перезагружать ту же память в строку кэша). По крайней мере, в моем домене есть очень широкое применение (компьютерная графика) только для сортировки по 32-битным и 64-битным цифровым ключам фиксированного размера.
Я хотел бы сказать одну вещь: сортировка по основанию может работать с числами и отрицаниями с плавающей точкой, хотя сложно написать версию FP, которая была бы настолько переносимой, насколько это возможно. Кроме того, хотя это O (n * K), K просто должно быть числом байтов размера ключа (например, миллион 32-битных целых чисел обычно занимал бы 4 прохода размером в байт, если в корзине 2 ^ 8 записей ). Схема доступа к памяти также имеет тенденцию быть более дружественной к кэшу, чем квикорты, хотя для этого обычно требуется параллельный массив и небольшой массив сегментов (обычно второй может нормально помещаться в стеке). QS может выполнить 50 миллионов операций перестановки, чтобы отсортировать массив из миллиона целых чисел со случайными шаблонами произвольного доступа. Радикальная сортировка может сделать это за 4 линейных, дружественных к кэшу передачи данных.
Тем не менее, недостаточная осведомленность о возможности сделать это с небольшим K на отрицательных числах вместе с плавающей точкой, вполне может внести значительный вклад в отсутствие популярности радикальных сортов.
Что касается моего мнения о том, почему люди не используют его чаще, то это может быть связано со многими доменами, в которых обычно нет необходимости сортировать числа или использовать их в качестве ключей поиска. Однако, основываясь только на моем личном опыте, многие из моих бывших коллег также не использовали его в тех случаях, когда он идеально подходил, и частично потому, что они не знали, что это может быть сделано для работы с FP и негативами. Таким образом, помимо того, что он работает только с числовыми типами, его часто считают менее применимым, чем он есть на самом деле. Я бы не стал так сильно его использовать, если бы думал, что он не работает с числами с плавающей точкой и отрицательными целыми числами.
Некоторые тесты:
Sorting 10000000 elements 3 times...
mt_sort_int: {0.135 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
mt_radix_sort: {0.228 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
std::sort: {1.697 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
qsort: {2.610 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
И это только с моей наивной реализацией ( mt_sort_intэто также радикальная сортировка, но с более быстрой ветвью кода, учитывая, что он может предполагать, что ключ является целым числом). Представьте, насколько быстрой может быть стандартная реализация, написанная экспертами.
Единственный случай, когда я нашел радикальную сортировку хуже, чем в действительно быстром, основанном std::sortна С ++ сравнении, был для очень небольшого числа элементов, скажем, 32, и я считаю, что в этот момент я std::sortначинаю использовать сортировки, лучше подходящие для наименьшего числа элементов, таких как heapsorts или вставка сортирует, хотя в тот момент моя реализация просто использует std::sort.