Чому кваксор краще, ніж злиття?

Мені було задано це питання під час інтерв'ю. Вони обидва O (nlogn), і все ж більшість людей використовують Quicksort замість Mergesort. Чому так?

У Quicksort є O ( n ² ) найгірший час виконання та O ( n log n ) середній час виконання. Однак у багатьох сценаріях перевага сортування злиття є тим, що багато факторів впливають на час роботи алгоритму, і, приймаючи їх разом, швидко виграє.

Зокрема, часто цитуються алгоритми сортування стосуються кількості порівнянь або кількості замінів, необхідних для сортування даних. Це дійсно хороший показник продуктивності, тим більше, що він не залежить від базової конструкції обладнання. Однак інші речі - наприклад, місце розташування посилань (тобто читай ми багато елементів, які, ймовірно, знаходяться в кеші?) - також грають важливу роль у поточному апаратному забезпеченні. Зокрема, Quicksort вимагає небагато додаткового місця та має гарну локалізацію кешу, і це робить його швидшим, ніж сортування об'єднань у багатьох випадках.

Крім того, дуже просто уникнути найгіршого часу запуску O ( n ² ) у найгіршому випадку , використовуючи відповідний вибір шарніра - такий, як його вибір випадковим чином (це відмінна стратегія).

На практиці багато сучасних реалізацій quicksort (зокрема, libstdc ++ 's std::sort) є насправді інтросортом , теоретичним найгіршим випадком якого є O ( n log n ), таким же, як і тип злиття. Це досягається обмеженням глибини рекурсії та переключенням на інший алгоритм ( велику частину ), коли він перевищує log n .

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

У оперативній пам’яті це припущення, як правило, не надто погано (воно не завжди відповідає дійсності кеш-пам'яток, але не дуже погано). Однак якщо ваша структура даних досить велика, щоб жити на диску, то отримує quicksort вбивається тим, що ваш середній диск робить щось на кшталт 200 випадкових прагнень в секунду. Але той самий диск не має проблем з читанням або записом мегабайт в секунду послідовно. Це саме те, що робить злиття.

Тому, якщо дані мають бути відсортовані на диску, ви дійсно хочете скористатися певним варіантом на mergesort. (Як правило, ви швидко перетворюєте підспіси, а потім починаєте об’єднувати їх між деяким порогом розміру.)

Крім того, якщо вам доведеться щось робити з наборами даних такого розміру, добре подумайте, як уникнути прагнення до диска. Наприклад, тому стандартна порада скидати індекси перед великими завантаженнями даних у базі даних, а потім індексувати індекс згодом. Підтримання індексу під час завантаження означає постійно прагнути до диска. На відміну від цього, якщо ви скинете індекси, то база даних може відновити індекс, спершу сортувавши інформацію, яку потрібно обробляти (звичайно, використовуючи об'єднання об'єднань!), А потім завантаживши її в структуру даних BTREE для індексу. (BTREE природно утримуються в порядку, тому ви можете завантажити один із відсортованого набору даних з кількома прагненнями до диска.)

Було багато випадків, коли розуміння того, як уникнути пошуку диска, дозволило мені зробити завдання з обробки даних займати години, а не дні чи тижні.

Власне, QuickSort - це O (n ² ). Його середній випадок час роботи становить O (Nlog (п)), але в гіршому випадку це O (п ² ), яке відбувається , коли ви запускаєте його в списку , який містить кілька унікальних предметів. Рандомізація займає O (n). Звичайно, це не міняє його найгірший випадок, це просто заважає зловмисному користувачеві змусити ваш вид тривати довго.

QuickSort є більш популярним, оскільки:

1. Є на місці (MergeSort вимагає додаткової лінійної пам’яті до кількості елементів для сортування).
2. Має невелику приховану константу.

"і все ж більшість людей використовують Quicksort замість Mergesort. Чому це?"

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

Так, Quicksort з потрійним розділенням, мабуть, є одним з найкращих алгоритмів сортування загального призначення, але це не перешкоджає тому, що сортування "Швидкий" звучить набагато потужніше, ніж сортування "Об'єднання".

Як зазначали інші, найгірший випадок Квіксорта - це O (n ^ 2), тоді як злиття та гипсорт залишаються в O (nlogn). У середньому випадку, однак, усі три є O (nlogn); тому вони для переважної більшості випадків порівнянні.

Що робить Quicksort кращим в середньому, це те, що внутрішня петля передбачає порівняння декількох значень з одним, тоді як для двох інших термінів обидва умови відрізняються для кожного порівняння. Іншими словами, Quicksort робить удвічі більше прочитаних, ніж інші два алгоритми. На сучасних процесорах продуктивність сильно переважає час доступу, тому врешті-решт Quicksort виявляється чудовим першим вибором.

Я хотів би додати, що з трьох згаданих до цього часу алгоритмів (сортування об'єднань, кваксор і сортування купи) лише злиття є стабільним. Тобто порядок не змінюється для тих значень, які мають однаковий ключ. У деяких випадках це бажано.

Але, правду кажучи, у практичних ситуаціях більшість людей потребує лише хорошої середньої продуктивності, а швидка швидкість - це швидко =)

Усі алгоритми сортування мають свої злети і падіння. Дивіться статтю Вікіпедії для сортування алгоритмів для гарного огляду.

З запису Вікіпедії на Quicksort :

Quicksort також конкурує з mergesort, іншим рекурсивним алгоритмом сортування, але з перевагою найгіршого Θ (nlogn) часу роботи. Mergesort - це стабільний сорт, на відміну від quicksort і gpsort, і його можна легко пристосувати для роботи в пов'язаних списках і дуже великих списках, що зберігаються на носіях з повільним доступом, таких як дисковий накопичувач або мережеве сховище. Хоча quicksort може бути написаний для роботи у зв'язаних списках, він часто страждає від поганого вибору варіантів без випадкового доступу. Основним недоліком об'єднання об'єднань є те, що при роботі з масивами він вимагає Θ (n) допоміжного простору в кращому випадку, тоді як варіант кваксорбування з місцевим розділенням та хвостовою рекурсією використовує лише Θ (logn) простір. (Зверніть увагу, що, працюючи в пов'язаних списках, об'єднанню потрібна лише невелика, постійна кількість допоміжного сховища.)

Му! Quicksort не кращий, він добре підходить для іншого типу додатків, ніж mergesort.

Mergesort варто задуматися, якщо швидкість є сутнісною, погані показники поганих ситуацій не можна допустити, і є додаткове місце. 1

Ви заявили, що вони «Вони обидва O (nlogn) […]». Це неправильно. «Quicksort використовує приблизно n ^ 2/2 порівняння в гіршому випадку». 1 .

Однак на моєму досвіді найважливішою властивістю є легка реалізація послідовного доступу, який ви можете використовувати під час сортування при використанні мов програмування з імперативною парадигмою.

1 Sedgewick, Алгоритми

Quicksort - це найшвидший алгоритм сортування на практиці, але він має ряд патологічних випадків, які можуть змусити його працювати так само погано, як O (n2).

Гайморт гарантовано працює в O (n * ln (n)) і вимагає лише обмеженого додаткового зберігання. Але є багато цитат тестів реального світу, які показують, що в середньому гипсорт значно повільніший, ніж кікспорт.

Пояснення Вікіпедії:

Як правило, quicksort на практиці значно швидший, ніж інші Θ (nlogn) алгоритми, оскільки його внутрішній цикл може бути ефективно реалізований у більшості архітектур, а в більшості реальних даних можна зробити вибір дизайну, який мінімізує ймовірність вимагати квадратичного часу .

Квікорт

Mergesort

Я думаю, що також є проблеми з обсягом сховища, необхідним для Mergesort (який є Ω (n)), якого не має реалізацій quicksort. У гіршому випадку - це однаковий алгоритмічний час, але злиття вимагає більше сховища.

Я хотів би додати до існуючих чудових відповідей деяку математику про те, як працює QuickSort, коли відходить від кращого випадку, і наскільки це можливо, що, сподіваюся, допоможе людям трохи краще зрозуміти, чому випадок O (n ^ 2) не є реальним стурбованість більш складними реалізаціями QuickSort.

Поза проблемами випадкового доступу є два основні фактори, які можуть впливати на продуктивність QuickSort, і вони пов'язані з тим, як стрижневий порівняння з даними, відсортованими.

1) Невелика кількість ключів у даних. Набір даних того самого значення буде сортувати за n ^ 2 разів у ванільному 2-роздільному розділі QuickSort, оскільки всі значення, за винятком місця розташування, розміщуються по одній стороні кожного разу. Сучасні реалізації вирішують це за допомогою таких методів, як використання сортування з 3-х розділів. Ці методи виконуються на наборі даних усіх однакових значень за O (n) час. Тож використання такої реалізації означає, що введення з невеликою кількістю клавіш насправді покращує час роботи та вже не викликає занепокоєння.

2) Надзвичайно поганий вибір шарніра може призвести до найгірших показників. В ідеальному випадку шарнір завжди буде таким, що на 50% даних менше, а на 50% - даних більше, так що вхід буде розбитий навпіл під час кожної ітерації. Це дає нам n порівнянь та разів заміни log-2 (n) рекурсій за час O (n * logn).

На скільки впливає неідеальний вибір стрижня на час виконання?

Розглянемо випадок, коли поворот вибирається послідовно таким чином, що 75% даних знаходиться на одній стороні стрижня. Це все ще O (n * logn), але тепер основа журналу змінилася на 1 / 0,75 або 1,33. Співвідношення продуктивності при зміні бази завжди є постійною, представленою log (2) / log (newBase). У цьому випадку ця константа дорівнює 2,4. Тож ця якість вибору шарніра займає в 2,4 рази більше, ніж ідеальна.

Як швидко це погіршується?

Не дуже швидко, поки вибір стрижня не стане (послідовно) дуже поганим:

• 50% з одного боку: (ідеальний випадок)
• 75% з одного боку: в 2,4 рази довше
• 90% з одного боку: 6,6 рази довше
• 95% з одного боку: 13,5 разів довше
• 99% з одного боку: 69 разів довше

Коли ми наближаємось до 100% з одного боку, частина журналу виконання наближається до n, а все виконання асимптотично наближається до O (n ^ 2).

У наївній реалізації QuickSort такі випадки, як відсортований масив (для першого елемента повороту) або реверсивно відсортований масив (для останнього зведення елемента) надійно дадуть час виконання O (n ^ 2) у найгіршому випадку. Крім того, реалізація з передбачуваним виборотом вибору може бути піддана атаці DoS за допомогою даних, призначених для виконання найгіршого випадку. Сучасні реалізації уникають цього різноманітними методами, такими як рандомізація даних перед сортуванням, вибір медіани з 3 випадково вибраних індексів і т. Д. З цією рандомізацією в поєднанні ми маємо 2 випадки:

• Невеликий набір даних Найгірший випадок можливий, але O (n ^ 2) не є катастрофічним, оскільки n досить малий, що n ^ 2 також малий.
• Великий набір даних Найгірший випадок можливий в теорії, але не на практиці.

Наскільки ймовірно, ми побачимо жахливу виставу?

Шанси суєтно малі . Розглянемо свого роду 5000 значень:

Наша гіпотетична реалізація вибере опорну точку, використовуючи медіану з 3 випадково вибраних індексів. Ми вважатимемо стрижні, що знаходяться в діапазоні 25% -75%, "хорошими", а стрижні, що знаходяться в діапазоні 0% -25% або 75% -100%, "поганими". Якщо подивитися на розподіл ймовірностей, використовуючи медіану з 3 випадкових індексів, кожна рекурсія має шанс 11/16 закінчитися з хорошим стрибком. Зробимо 2 консервативні (і помилкові) припущення для спрощення математики:

1. Хороші повороти завжди точно розбиті на 25% / 75% і працюють в ідеальному випадку 2,4 *. Ми ніколи не отримуємо ідеального розколу або будь-якого розколу краще, ніж 25/75.

2. Погані стрижні завжди є найгіршим випадком і по суті нічого не сприяють вирішенню.

Наша реалізація QuickSort зупиниться на n = 10 і перейде до сортування вставки, тому нам потрібні 22 25% / 75% півометних розділів, щоб зламати значення введення 5000 донині. (10 * 1.333333 ^ 22> 5000) Або нам потрібно 4990 найгірших поворотів. Майте на увазі, що якщо ми накопичимо 22 хороших опори в будь-якій точці, сортування завершиться, тому найгірший випадок або що-небудь поруч з ним вимагає надзвичайно удачі. Якщо б нам вдалося здійснити 88 рекурсій, щоб реально досягти 22 хороших поворотів, необхідних для сортування до n = 10, це буде 4 * 2,4 * ідеальний випадок або приблизно в 10 разів більший час виконання ідеального випадку. Наскільки ймовірно, що після 88 рекурсій ми не досягли б потрібних 22 хороших стрибків?

Біноміальні розподіли ймовірностей можуть відповісти на це, а відповідь приблизно 10 ^ -18. (n - 88, k - 21, p - 0,6875) Ваш користувач приблизно в тисячу разів більший за удар блискавкою за 1 секунду, що потрібно натиснути [SORT], ніж вони, щоб побачити, що 5000 сортування елементів працює гірше ніж 10 * ідеальний випадок. Цей шанс стає меншим, оскільки набір даних збільшується. Ось кілька розмірів масиву та їх відповідні шанси працювати довше, ніж 10 * ідеально:

• Масив з 640 елементів: 10 ^ -13 (потрібно 15 хороших точок зведення з 60 спроб)
• Масив з 5000 елементів: 10 ^ -18 (потрібно 22 хороших повороту з 88 спроб)
• Масив з 40000 елементів: 10 ^ -23 (потрібно 29 хороших поворотів із 116)

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

Нарешті, як згадували інші, навіть ці абсурдно малоймовірні випадки можна усунути, перейшовши на сортування купи, якщо стек рекурсії надто глибокий. Таким чином, TLDR полягає в тому, що для хорошої реалізації QuickSort найгірший випадок насправді не існує, оскільки він був розроблений і виконання завершується за O (n * logn) час.

Чому Quicksort хороший?

• QuickSort приймає N ^ 2 в гіршому випадку, а середній - NlogN. Найгірший випадок трапляється при сортування даних. Це можна зменшити випадковим переміщенням перед початком сортування.
• QuickSort не потребує додаткової пам’яті, яка приймається шляхом злиття.
• Якщо набір даних великий і є однакові елементи, складність Quicksort зменшується, використовуючи тристоронній розділ. Більше немає однакових елементів, краще сортування. Якщо всі елементи однакові, вони сортуються за лінійним часом. [Це реалізація за замовчуванням у більшості бібліотек]

Чи завжди Quicksort кращий за Mergesort?

Не зовсім.

• Mergesort стабільний, але Quicksort - ні. Тож якщо вам потрібна стабільність у випуску, ви б використовували Mergesort. Стабільність необхідна у багатьох практичних програмах.
• Пам'ять сьогодні дешева. Отже, якщо додаткова пам'ять, яку використовує Mergesort, не є критичною для вашої програми, не буде шкоди для використання Mergesort.

Примітка. У java функція Arrays.sort () використовує Quicksort для примітивних типів даних та Mergesort для типів даних об'єктів. Оскільки об'єкти споживають пам'ять накладних витрат, тому для Mergesort додані невеликі накладні витрати можуть не бути проблемою для точки зору продуктивності.

Довідково : Перегляньте відео QuickSort 3-го тижня, Курс алгоритмів Принстона на Coursera

Quicksort НЕ кращий, ніж злиття. При O (n ^ 2) (найгірший випадок, що трапляється рідко), швидкий вибір коротко повільніше, ніж O (nlogn) роду злиття. У Quicksort менше накладних витрат, тому з невеликими n та повільними комп’ютерами це краще. Але комп’ютери сьогодні настільки швидкі, що додаткові накладні витрати об'єднаних об'єднань незначні, а ризик дуже повільного швидкого вибору значно переважає незначні накладні витрати об'єднання в більшості випадків.

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

Відповідь дещо нахилиться до quicksort wrt до змін, внесених із DualPivotQuickSort для примітивних значень. Він використовується в JAVA 7 для сортування в java.util.Arrays

It is proved that for the Dual-Pivot Quicksort the average number of
comparisons is 2*n*ln(n), the average number of swaps is 0.8*n*ln(n),
whereas classical Quicksort algorithm has 2*n*ln(n) and 1*n*ln(n)
respectively. Full mathematical proof see in attached proof.txt
and proof_add.txt files. Theoretical results are also confirmed
by experimental counting of the operations.

Ви можете знайти вкладення JAVA7 тут - http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/util/Arrays.java

Подальше дивовижне читання на DualPivotQuickSort - http://permalink.gmane.org/gmane.comp.java.openjdk.core-libs.devel/2628

Загальний алгоритм при злитті сортування:

1. Сортувати лівий підмасив
2. Сортуйте правий підмасив
3. Об'єднайте 2 відсортовані підмасиви

На верхньому рівні об'єднання 2 відсортованих підмасивів передбачає справу з N елементами.

Один рівень нижче цього, кожна ітерація кроку 3 включає взаємодію з N / 2 елементами, але вам потрібно повторити цей процес двічі. Отже, ти все ще маєш справу з 2 * N / 2 == N елементами.

На один рівень нижче цього ви об’єднуєте 4 * N / 4 == N елементів тощо. Кожна глибина в рекурсивному стеку передбачає об'єднання однакової кількості елементів на всіх закликах до цієї глибини.

Розглянемо замість цього алгоритм швидкого сортування:

1. Виберіть точку зрізу
2. Розмістіть точку зрізу в потрібному місці в масиві, з усіма меншими елементами зліва, а більшими елементами праворуч
3. Сортувати лівий підрядок
4. Сортуйте правий підряд

На верхньому рівні ви маєте справу з масивом розміром N. Потім вибираєте одну точку зведення, ставите її у правильне положення, а потім можете повністю ігнорувати її для решти алгоритму.

Один рівень нижче цього, ви маєте справу з двома підмасивами, які мають комбінований розмір N-1 (тобто віднімайте попередню точку зрізу). Ви вибираєте точку зрізу для кожного підмасиву, яка містить до 2 додаткових точок зведення.

Один рівень нижче цього, ви маєте справу з 4 підмасивами з комбінованим розміром N-3 з тих же причин, що і вище.

Потім N-7 ... Потім N-15 ... Потім N-32 ...

Глибина рекурсивного стека залишається приблизно однаковою (logN). За допомогою сортування злиття ви завжди маєте справу з злиттям N-елементів на кожному рівні рекурсивного стека. При швидкому сортуванні кількість елементів, з якими ви маєте справу, зменшується під час спуску стека. Наприклад, якщо дивитися на глибину середини через рекурсивний стек, кількість елементів, з якими ви маєте справу, становить N - 2 ^ ((logN) / 2)) == N - sqrt (N).

Відмова від відповідальності. Під час сортування об'єднань, оскільки ви поділяєте масив на 2 точно рівні частини, кожен раз рекурсивна глибина точно logN. При швидкому сортуванні, оскільки навпаки точка зведення навряд чи буде точно посередині масиву, глибина рекурсивного стека може бути трохи більшою, ніж logN. Я не зробив математики, щоб побачити, яку велику роль цей фактор і фактор, описаний вище, насправді відіграють у складності алгоритму.

На відміну від злиття сортування Швидкий сортування не використовує допоміжний простір. Тоді як сортування об'єднань використовує допоміжний простір O (n). Але Злиття Сортування має найгірший за часом складність O (nlogn), тоді як найгірша складність Швидкого Сортування - O (n ^ 2), що відбувається, коли масив вже відсортований.

Quicksort має кращу середню складність випадку, але в деяких додатках це неправильний вибір. Quicksort вразливий до відмови в сервісних атаках. Якщо зловмисник може вибрати вхід для сортування, він може легко побудувати набір, який займає найгірший час складності o (n ^ 2).

Середня складність випадку Мергесота та найгірша складність випадку однакові, і як такий не зазнає однієї і тієї ж проблеми. Ця властивість сортування злиття також робить його найкращим вибором для систем у режимі реального часу - саме тому, що немає патологічних випадків, які змушують його працювати набагато, набагато повільніше.

З цих причин я більший фанат Мергесорта, ніж я з Кіксорта.

Це важко сказати. Найгіршим з MergeSort є n (log2n) -n + 1, що є точним, якщо n дорівнює 2 ^ k (я це вже довів). А для будь-якого n він знаходиться між (n lg n - n + 1) і (n lg n + n + O (lg n)). Але для quickSort найкращим є nlog2n (також n дорівнює 2 ^ k). Якщо ви розділите Mergesort на quickSort, він дорівнює одиниці, коли n нескінченно. це як би гірший випадок MergeSort кращий, ніж найкращий випадок QuickSort, чому ми використовуємо quicksort? Але пам’ятайте, що MergeSort не стоїть на місці, він вимагає 2n мемерой простору. А MergeSort також потрібно робити багато копій масиву, які ми не включайте в аналіз алгоритму. Словом, MergeSort насправді швидше, ніж quicksort у theroy, але насправді вам потрібно врахувати меморіальний простір, вартість копіювання масиву, злиття повільніше, ніж швидке сортування. Я одного разу зробив експериментуйте, коли мені дали 1000000 цифр у java класом Random,і це займало 2610 мс по об'єднанню, 1370 м по кваксорту.

Швидке сортування є найгіршим випадком O (n ^ 2), проте середній випадок, який послідовно виконується, виконує сортування злиття. Кожен алгоритм - це O (nlogn), але вам потрібно пам’ятати, що, говорячи про Big O, ми залишаємо нижчі коефіцієнти складності. Швидкий сортування суттєво покращився порівняно з сортуванням злиття, коли мова йде про постійні фактори.

Сортування сортування також вимагає O (2n) пам'яті, тоді як швидке сортування може бути зроблене на місці (вимагає лише O (n)). Це ще одна причина, що швидке сортування в основному віддається перевазі порівнянню порівняння.

Додаткова інформація:

Найгірший випадок швидкого сортування трапляється, коли шарнір вибраний погано. Розглянемо наступний приклад:

[5, 4, 3, 2, 1]

Якщо виворіт обраний як найменше або найбільше число в групі, то швидке сортування буде виконуватися в O (n ^ 2). Імовірність вибору елемента, який знаходиться у найбільшому чи найменшому 25% списку, становить 0,5. Це дає алгоритму 0,5 шансу бути хорошим стрижнем. Якщо ми використовуємо типовий алгоритм вибору стрижня (скажімо, вибір випадкового елемента), у нас є 0,5 шансу вибрати хороший шар для кожного вибору стрижня. Для колекцій великого розміру ймовірність вибору поганого стрижня становить 0,5 * n. На основі цієї ймовірності швидкий сорт є ефективним для середнього (і типового) випадку.

Це досить давнє питання, але оскільки я нещодавно розглядався з обома, тут є мій 2с:

Потрібно об'єднати сортування в середньому ~ N log N порівнянь. Для вже (майже) відсортованих відсортованих масивів це зменшується до 1/2 N log N, оскільки під час об’єднання ми (майже) завжди вибираємо "ліву" частину 1/2 N разів, а потім просто копіюємо праву 1/2 N елементи. Додатково я можу припустити, що вже відсортований вхід змушує передбачуваного гілки процесора блищати, але вгадувати майже всі гілки правильно, тим самим запобігаючи затримках конвеєра.

Швидке сортування в середньому вимагає ~ 1,38 N журналу N порівнянь. Це не має великої користі від вже відсортованого масиву з точки зору порівнянь (однак це стосується свопів та, ймовірно, з точки зору прогнозування галузей всередині процесора).

Мої орієнтири щодо досить сучасного процесора показують наступне:

Коли функція порівняння є функцією зворотного виклику (як у qsort () libc реалізації), то quicksort повільніше, ніж об'єднання, на 15% при випадковому введенні та 30% для вже відсортованого масиву для 64-бітових цілих чисел.

З іншого боку, якщо порівняння не є зворотним дзвінком, мій досвід полягає в тому, що хитросхистка перевершує злиття на 25%.

Однак якщо у вашого (великого) масиву є дуже мало унікальних значень, сортування злиття починає набирати більше швидкості у будь-якому випадку.

Тож, можливо, підсумок: якщо порівняння дороге (наприклад, функція зворотного виклику, порівняння рядків, порівняння багатьох частин структури, головним чином потрапляючи до другої-третьої-четвертої "якщо", щоб змінити значення) - шанси на те, що вам стане краще з сортуванням злиття. Для більш простих завдань швидкий вибір буде швидшим.

Це сказано, що все сказане було вірно: - Quicksort може бути N ^ 2, але Седжевік стверджує, що хороша рандомізована реалізація має більше шансів на комп'ютер, який виконує сортування, вдарившись блискавкою, ніж піти N ^ 2 - Mergesort вимагає додаткового простору

Коли я експериментував з обома алгоритмами сортування, підраховуючи кількість рекурсивних викликів, quicksort послідовно має менше рекурсивних викликів, ніж об'єднання. Це відбувається тому, що у quicksort є повороти, а шарніри не включаються до наступних рекурсивних викликів. Таким чином, квакісорт може досягти рекурсивної базової справи швидше, ніж злиття.

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

1- Допоміжний простір: Швидке сортування - алгоритм сортування на місці. Сортування на місці означає, що для сортування не потрібно додаткового місця для зберігання. Сортування сортування з іншого боку вимагає тимчасового масиву для об'єднання відсортованих масивів, а значить, він не є на місці.

2- Найгірший випадок: найгірший випадок кікспорту O(n^2)можна уникнути, використовуючи рандомізований кваксор. Це можна легко уникнути з високою ймовірністю, вибравши правильний шарнір. Отримання середньої поведінки у випадку випадків вибору правильного елемента зведення дозволяє йому імпровізувати продуктивність та стати настільки ж ефективним, як сортування злиття.

3- Локальність посилання: Quicksort, зокрема, демонструє хорошу локальність кешу, і це робить швидше, ніж сортування об'єднань у багатьох випадках, як у середовищі віртуальної пам'яті.

4- Рекурсія хвоста: QuickSort є рекурсивним хвостом, тоді як сортування злиття - ні. Хвостова рекурсивна функція - це функція, де рекурсивний виклик - це останнє, що виконується функцією. Хвостові рекурсивні функції вважаються кращими, ніж не хвостові рекурсивні функції, оскільки хвоста-рекурсія може бути оптимізована компілятором.

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

Однак! Особисто я часто використовую варіант злиття або кваксорт, який погіршує стан злиття, коли кексорт робить погано. Пам'ятайте. Quicksort тільки О (п увійти п) в середньому . Найгірший випадок - це O (n ^ 2)! Mergesort завжди O (n log n). У випадках, коли продуктивність або реагування в режимі реального часу є обов'язковим, і ваші вхідні дані можуть надходити з шкідливого джерела, не слід використовувати звичайний швидкодіючий корок.

При рівних обставинах я б очікував, що більшість людей використовуватиме те, що є найзручнішим, і це, як правило, qsort (3). Крім того, що квакісорт, як відомо, є дуже швидким на масивах, подібно до того, що об'єднання є загальним вибором для списків.

Мені цікаво, чому так рідко можна побачити радіацію чи відра. Вони O (n), принаймні, у пов'язаних списках, і все, що потрібно, - це певний метод перетворення ключа на порядковий номер. (струнні та поплавці працюють чудово.)

Я думаю, що причина пов'язана з тим, як навчають інформатику. Мені навіть довелося продемонструвати моєму викладачеві з аналізу алгоритму, що дійсно можна сортувати швидше, ніж O (n log (n)). (Він мав доказ того, що ви не можете порівняти сортування швидше, ніж O (n log (n)), що правда.)

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

Редагувати: Насправді, ось ще більш порочний спосіб сортування floats-as-integers: http://www.stereopsis.com/radix.html . Зауважте, що біт-гортаючий трюк можна використовувати незалежно від того, який алгоритм сортування ви фактично використовуєте ...

Невеликі доповнення до швидких та об’єднаних сортів.

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

Наприклад, ми сортуємо елементи за допомогою мережевого протоколу на віддаленому сервері.

Крім того, у спеціальних контейнерах, таких як "пов'язаний список", це не є користю для швидкого сортування.
1. Об’єднати сортування у зв’язаному списку, не потрібна додаткова пам'ять. 2. Доступ до елементів у швидкому сортуванні не є послідовним (у пам'яті)

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

На відміну від масивів, у список сподобалися ми можемо вставляти елементи посередині з пробілом O (1) та O (1), тому операція злиття у сортуванні злиття може бути реалізована без зайвого місця. Однак виділення та виділення додаткового простору для масивів негативно впливає на час виконання сортування злиття. Сортування об'єднань також надає перевагу пов'язаному списку, оскільки доступ до даних відбувається послідовно, без особливого доступу до пам'яті.

Швидке сортування, з іншого боку, вимагає багато випадкового доступу до пам'яті, і з масиву ми можемо безпосередньо отримати доступ до пам'яті без будь-якого обходу, як того вимагає пов'язаний список. Також швидке сортування при використанні для масивів має хороший орієнтир, оскільки масиви постійно зберігаються в пам'яті.

Незважаючи на те, що обидва алгоритми сортування середньої складності складають O (NlogN), зазвичай люди для звичайних завдань використовують масив для зберігання, і саме тому швидке сортування повинно бути алгоритмом вибору.

EDIT: Я щойно з'ясував, що сортування злиття найгірший / кращий / avg випадок завжди nlogn, але швидке сортування може змінюватися від n2 (найгірший випадок, коли елементи вже відсортовані) до nlogn (avg / кращий випадок, коли pivot завжди ділить масив на два половинки).

Розгляньте складність часу та простору. Для сортування злиття: часова складність: O (nlogn), просторова складність: O (nlogn)

Для швидкого сортування: Часова складність: O (n ^ 2), складність простору: O (n)

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

Таким чином, швидке сортування є кращим у багатьох програмах замість сортування з’єднання.

У землі c / c ++, коли не використовуються контейнери stl, я, як правило, використовую quicksort, тому що він вбудований у час виконання, тоді як mergesort - ні.

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

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

Одна з причин - більш філософська. Quicksort - це філософія Top-> Down. З п елементами для сортування, є n! можливості. З двома перегородками m & nm, які взаємно виключаються, кількість можливостей зменшується на кілька порядків. м! * (нм)! менший на кілька порядків, ніж n! поодинці. уявіть 5! проти 3! * 2 !. 5! має в 10 разів більше можливостей, ніж 2-х розділів по 2 і 3 у кожній. і екстраполювати до 1 мільйона фабричних проти 900 К! * 100 К! vs. Отже, замість того, щоб турбуватися про встановлення будь-якого порядку в межах діапазону або розділу, просто встановіть порядок на більш широкому рівні в розділах і зменшіть можливості в розділі. Будь-який порядок, встановлений раніше в межах діапазону, буде порушений пізніше, якщо самі розділи не будуть взаємовиключними.

Будь-який підхід до порядку "знизу вгору", наприклад сортування злиття або сортування купи, схожий на підхід робітників або службовців, коли можна починати порівнювати на мікроскопічному рівні рано. Але цей порядок повинен бути втрачений, як тільки пізніше знайдеться елемент між ними. Ці підходи дуже стабільні та надзвичайно передбачувані, але роблять певну додаткову роботу.

Швидкий сортування - це такий, як Управлінський підхід, коли спочатку не турбується жодне замовлення, а лише виконання широкого критерію, не враховуючи порядок. Потім перегородки звужуються, поки ви не отримаєте відсортований набір. Справжня проблема в Quicksort - це пошук розділу чи критерію в темряві, коли ви нічого не знаєте про елементи для сортування. Ось чому нам або потрібно докласти певних зусиль, щоб знайти середнє значення, або вибрати 1 навмання, або якийсь довільний "управлінський" підхід. Щоб знайти ідеальну медіану, можна зажадати значних зусиль і знову привести до тупого підходу знизу вгору. Отже, Quicksort каже просто вибрати випадковий стрижень і сподіваємось, що він буде десь посередині або зробити якусь роботу, щоб знайти медіану 3, 5 або щось більше, щоб знайти кращу медіану, але не плануйте бути ідеальним & don ' t не витрачайте часу на початкове замовлення. Це, здається, добре, якщо вам пощастило або іноді погіршується до n ^ 2, коли ви не отримуєте медіани, а просто ризикуєте. Будь-який спосіб є випадковим. правильно. Тож я більше погоджуюся з верхнім -> внизу логічним підходом швидкого вибору, і виявляється, що шанс, який він вимагає щодо вибору стрижнів та порівнянь, який він заощаджує раніше, здається, працює краще, ніж будь-який ретельний та ретельний стабільний низ -> підхід, як злиття сорту. Але порівняння, які він економив раніше, здається, працюють краще, ніж будь-який ретельний та ретельний стабільний підхід знизу -> вгору, як сортування злиття. Але порівняння, які він економив раніше, здається, працюють краще, ніж будь-який ретельний та ретельний стабільний підхід знизу -> вгору, як сортування злиття. Але