Коли використовується кожен алгоритм сортування? [зачинено]

Які випадки використання, коли певний алгоритм сортування віддається перевагу порівняно з іншими - сортування злиття проти QuickSort проти Heapsort проти «введення сортування» тощо?

Чи є рекомендований посібник щодо їх використання залежно від розміру, типу структури даних, наявної пам'яті та кешу та продуктивності процесора?

По-перше, визначення, оскільки це досить важливо: стабільний сорт - це те, що гарантовано не переставляє елементи однаковими ключами.

Рекомендації:

Швидкий сортування: коли вам не потрібен стабільний сортування, а середня ефективність випадку має значення, ніж найгірша ефективність. Швидкий сорт - в середньому O (N log N), у гіршому - O (N ^ 2). Хороша реалізація використовує O (log N) допоміжне сховище у вигляді простору стеку для рекурсії.

Сортування сортування: Коли вам потрібен стабільний, O (N log N) сортування, це лише ваш єдиний варіант. Єдиним недоліком цього є те, що він використовує допоміжний простір O (N) і має трохи більшу константу, ніж швидкий сортування. Існують деякі різновиди злиття на місці, але AFAIK всі вони або не стабільні, або гірші, ніж O (N log N). Навіть сорти O (N log N) мають настільки велику константу, ніж звичайний старий сорт злиття, що вони більше теоретичні цікавості, ніж корисні алгоритми.

Сортування купи: Коли вам не потрібен стабільний сорт, і вам більше важливо гірший показник, ніж середній показник. Це гарантовано O (N log N), і він використовує допоміжний простір O (1), це означає, що вам несподівано не вистачить місця з кучі чи стеку на дуже великих входах.

Introsort: Це швидкий сорт, який переходить до сортування купи після певної глибини рекурсії, щоб обійти найгірший випадок швидкого сортування (N ^ 2). Це майже завжди краще, ніж звичайний старий швидкий сорт, оскільки ви отримуєте середній випадок швидкого сортування, із гарантованою продуктивністю O (N log N). Напевно, єдина причина використовувати сортування купи замість цього - в сильно обмеженій пам'яті системах, де O (log N) простір стеків практично значний.

Сортування вставки : Коли N гарантовано буде невеликим, в тому числі в якості базового випадку швидкого сортування або сортування. Хоча це O (N ^ 2), він має дуже малу константу і є стабільним сортом.

Сортування бульбашок, сортування вибору : коли ви робите щось швидке і брудне, і ви чомусь не можете просто використовувати стандартний алгоритм сортування бібліотеки. Єдиною перевагою, яку вони мають перед сортуванням вставок, є те, що вона трохи легша у виконанні.

Сортування порівняння: За деяких досить обмежених умов можна зламати бар'єр O (N log N) і сортувати в O (N). Ось кілька випадків, коли варто спробувати:

Сортування підрахунку: Коли ви сортуєте цілі числа з обмеженим діапазоном.

Сортування радікса: Коли log (N) значно більший за K, де K - кількість цифр радіасу.

Сортування відра: Коли ви можете гарантувати, що ваш внесок приблизно рівномірно розподілений.

Як правило, Quicksort є найшвидшим в середньому, але він має дуже неприємні поведінки в гіршому випадку. Тож якщо вам доведеться гарантувати, що погані дані не дають вам O(N^2), вам слід уникати цього.

Злиття-сортування використовує додаткову пам’ять, але особливо підходить для зовнішнього сортування (тобто величезні файли, які не вміщуються в пам'ять).

Heap сортування можна сортувати на місці і не має найгірший випадок квадратне поведінки, але в середньому повільніше , ніж швидке сортування в більшості випадків.

Там, де задіяні лише цілі числа в обмеженому діапазоні, ви можете використовувати якийсь сорт радіації, щоб зробити його дуже швидким.

У 99% випадків вам буде добре з бібліотечними видами, які, як правило, базуються на швидкості.

Сторінка Вікіпедії щодо алгоритмів сортування має чудову діаграму порівняння.

http://en.wikipedia.org/wiki/Sorting_algorithm#Comppare_of_algorithms

Надані посилання на порівняння / анімації не враховують, коли кількість даних перевищує доступну пам'ять ---, в цей момент кількість переходів над даними, тобто витрати вводу / виводу, домінують під час виконання. Якщо вам потрібно це зробити, читайте про "зовнішнє сортування", яке зазвичай охоплює варіанти сортування злиття та купи.

http://corte.si/posts/code/visualisingsorting/index.html та http://corte.si/posts/code/timsort/index.html також мають кілька цікавих зображень, що порівнюють різні алгоритми сортування.

@dsimcha пише: Підрахунок сортування: Коли ви сортуєте цілі числа з обмеженим діапазоном

Я змінив би це на:

Сортування підрахунку: Коли ви сортуєте додатні цілі числа (0 - Integer.MAX_VALUE-2 за рахунок голубого отвору).

Завжди можна отримати значення max і min як евристику ефективності в лінійний час.
Також вам потрібно принаймні n додаткового місця для проміжного масиву, і він очевидно стабільний.

/**
* Some VMs reserve some header words in an array.
* Attempts to allocate larger arrays may result in
* OutOfMemoryError: Requested array size exceeds VM limit
*/
private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;

(навіть якщо це фактично дозволить MAX_VALUE-2) див .: Чи мають масиви Java максимальний розмір?

Також я б пояснив, що складність радіоскопічного сортування становить O (wn) для n клавіш, які є цілими числами розміру слова w. Іноді w подається як константа, яка б зробила сортування radix кращим (для достатньо великого n), ніж найкращі алгоритми сортування на основі порівняння, які виконують порівняння O (n log n) для сортування n клавіш. Однак загалом w не можна вважати постійною: якщо всі n клавіш чіткі, то w має бути принаймні log n, щоб машина з випадковим доступом могла зберігати їх у пам'яті, що дає в кращому випадку складність часу O (n журналу n). (з Вікіпедії)