Почему быстрая сортировка более популярна, чем radix-sort? - PullRequest
37 голосов
/ 22 августа 2010

Почему быстрая сортировка (или интросортировка) или какой-либо алгоритм сортировки на основе сравнения встречается чаще, чем сортировка по основанию?Особенно для сортировки чисел.

Radix-sort не основан на сравнении, поэтому может быть быстрее, чем O (n logn).Фактически это O (k n), где k - количество битов, используемых для представления каждого элемента.И объем памяти не критичен, так как вы можете выбрать количество используемых сегментов, а требуемая память может быть меньше требований mergesort.

Имеет ли это отношение к кешированию?Или, возможно, получить доступ к случайным байтов целых чисел в массиве?

Ответы [ 6 ]

23 голосов
/ 22 августа 2010

На ум приходят два аргумента:

  1. Быстрая сортировка / интросорт более гибкая:

    Quicksort и Introsort хорошо работают со всеми видами данных. Все, что вам нужно для сортировки - это возможность сравнить товары. Это тривиально с числами, но вы можете сортировать и другие данные.

    С другой стороны, Radix sort сортирует вещи по их двоичному представлению. Он никогда не сравнивает предметы друг с другом.

  2. Для сортировки по радикалу требуется больше памяти.

    Все реализации радикальной сортировки, которые я видел, используют вторичный буфер для хранения результатов частичной сортировки. Это увеличивает требования к памяти алгоритма сортировки. Это может не быть проблемой, если вы сортируете только пару килобайт, но если вы входите в диапазон гигабайт, это имеет огромное значение.

    Если я правильно помню, на бумаге существует алгоритм радикальной сортировки.

11 голосов
/ 22 августа 2010

Один очевидный ответ заключается в том, что вы можете сортировать произвольные типы, используя быструю сортировку (то есть все, что сопоставимо), в то время как вы ограничены числами только с основанием. И быстрая сортировка IMO намного более интуитивна.

6 голосов
/ 22 августа 2010

Radix сортировка медленнее для (большинства) реальных случаев использования.

Одной из причин является сложность алгоритма:

Если элементы уникальны, k> = log (n).Даже с дублирующимися элементами набор проблем, где k

Другая реализация:

Требуется дополнительная память (что само по себе является недостатком),отрицательно влияет на производительность кэша.

Я думаю, можно с уверенностью сказать, что многие библиотеки, как и стандартная библиотека, используют Quicksort, поскольку в большинстве случаев она работает лучше.Я не думаю, что «сложная реализация» или «менее интуитивный» являются основными факторами.

4 голосов
/ 20 января 2015

Как упомянуто в Википедии

Тема эффективности радикальной сортировки по сравнению с другими алгоритмами сортировки несколько сложна и может вызвать много недоразумений. Является ли сортировка по радиусу одинаково эффективной, менее эффективной или более эффективной, чем лучшие алгоритмы, основанные на сравнении, зависит от деталей сделанных предположений. Эффективность сортировки по радиксу составляет O (d · n) для n ключей, которые имеют d или меньше цифр. Иногда d представляется как константа, что делает радикальную сортировку лучше (для достаточно большого n), чем лучшие алгоритмы сортировки, основанные на сравнении, и все они требуют O (n · log (n)) количества сравнений. Однако в общем случае d нельзя считать константой. В частности, в соответствии с общим (но иногда неявным) предположением, что все ключи различны, тогда d должно быть как минимум порядка log (n), что в лучшем случае (с плотно упакованными ключами) дает временную сложность O (п · журнал (п)) . Казалось бы, радикальная сортировка максимально эффективна по сравнению с сортировками на основе лучшего сравнения (и хуже, если ключи намного длиннее, чем log (n)).

Аргументом счетчика является то, что алгоритмы, основанные на сравнении, измеряются количеством сравнений, а не фактической сложностью времени. При одних допущениях сравнение будет в среднем постоянным, а при других - нет. Сравнение случайно сгенерированных ключей занимает в среднем постоянное время, так как ключи отличаются в первом бите в половине случаев, а во втором бите - в половине оставшейся половины, и т. Д., Что в среднем составляет два бита, которые нужно сравнивать. В алгоритме сортировки первые выполненные сравнения удовлетворяют условию случайности, но по мере сортировки сравниваемые ключи явно больше не выбираются случайным образом. Например, рассмотрим сортировку по принципу «снизу вверх». На первом проходе сравниваются пары случайных ключей, но на последнем проходе сравниваются ключи, которые находятся очень близко в порядке сортировки.

Решающим фактором является распределение ключей. Наилучший случай для сортировки по основанию состоит в том, что они принимаются как последовательные битовые комбинации. Это сделает ключи настолько короткими, насколько они могут быть, все еще предполагая, что они различны. Это делает радикальную сортировку O (n · log (n)), но сортировки, основанные на сравнении, не будут такими эффективными, так как сравнения не будут постоянными по времени в этом предположении. Если вместо этого мы предположим, что ключи представляют собой битовые комбинации длиной k · log (n) для константы k> 1 и базы 2 log, и что они являются равномерно случайными, то радикальная сортировка все равно будет O (n · log (n)). ), но то же самое можно сказать и о сортировках, основанных на сравнении, так как «дополнительная» длина приводит к тому, что даже ключи, которые являются последовательными в отсортированном результате, отличаются настолько, что сравнения в среднем имеют постоянное время. Если ключи длиннее, чем O (log (n)), но случайны, то сортировка по основанию будет хуже. Существует также много других предположений, и большинство из них требуют тщательного изучения, чтобы сделать правильные сравнение.

0 голосов
/ 26 декабря 2016

Эффективность сортировки по корням = O (c.n) где c = наибольшее количество цифр среди набора клавиш ввода. n = количество клавиш в наборе клавиш ввода.

Лучший вариант быстрой сортировки = O (n. Log n) где n = количество клавиш в наборе клавиш ввода.

Предположим, что 16 номеров должны быть отсортированы по 6 цифр в каждом:

Radix sort = 16 * 6 = 96 единиц времени. Быстрая сортировка = 16 * 4 = 64 единицы времени.

Урок: Когда «с» меньше, Radix действительно побеждает. Когда оно высоко, оно проигрывает. Быстрая сортировка не зависит от количества цифр в ключе, что делает ее несколько лучше и практически приемлемой

0 голосов
/ 27 апреля 2016

Баллы, сделанные в других ответах, действительны, но, насколько это касается вас, упомянутых в нескольких комментариях

... тот факт, что алгоритмы сортировки по умолчанию для чисел реализованы с использованием быстрой сортировки.Особенно реализации в библиотеках ...

Quicksort - «безопасный» выбор.Потенциальная среда выполнения радикальной сортировки на основе счетной сортировки очень привлекательна, да, но радикальная сортировка чувствительна к плохой работе с вредоносными / неудачными наборами данных.Если количество разрядов сортируемых ключей приближается к количеству сортируемых ключей, радикальная сортировка выполняется на n ^ 2 вместе с немалой сложностью пространства и имеет тенденцию иметь довольно высокие встроенные константы времени выполнения, отличные от числацифр сортируемых ключей.
Mergesort привлекателен, потому что его поведение в некотором роде аналогично быстрой сортировке, которая выбирает оптимальный поворот при каждой возможности (медиана).Однако, это идет с заметной космической сложностью.Он не так восприимчив к злонамеренным / неудачным данным, как radix, но также не предлагает привлекательного возможного времени выполнения.Базовая быстрая сортировка очень хорошо работает с большинством наборов данных, за исключением почти (или полностью) отсортированных, и имеет небольшую сложность пространства.
Уязвимость быстрой сортировки легко устраняется путем преобразования ее в рандомизированную быструю сортировку.Уязвимость сортировки Radix устраняется путем наложения ограничений на сортируемые ключи, что по сути ограничивает пользователей библиотеки.Быстрая сортировка более производительна, чем слияние на небольших наборах данных, и работает разумно, когда слияние может быть быстрее.
При реализации библиотеки вы хотите сделать ее в общем полезной.Возьмите эти примеры, веб-приложение и небольшое устройство с чрезвычайно ограниченным микроконтроллером.Веб-приложения должны регулярно обрабатывать вредоносные данные, а также иметь широкий спектр потребностей.Библиотека с предопределенными ограничениями с меньшей вероятностью будет полезна.В случае с микроконтроллером, он может быть ограничен по пространству и не способен отбросить малейший бит, где его можно сохранить.Быстрая сортировка экономит место и завершается только медленнее с помощью постоянного множителя, ЕСЛИ возникает ситуация, что она медленнее.
В сумме -
1.) Библиотеки часто кодируются для максимально возможного общего удобства использования
2.) Хорошая производительность в целом приемлема, особенно если во многих случаях это лучшая производительность
3.) Пространство не всегда является основной проблемой, но когда это так, часто это явно ограничительно, поэтому

...