Алгоритми ділення та перемоги - чому б не розділити на більшу частину, ніж дві?

У алгоритмах розділення та підкорення, таких як кваксорт і злиття, введення, як правило, (принаймні у вступних текстах) розділяється надвоє , а два менші набори даних обробляються рекурсивно. Для мене має сенс, що це дозволяє швидше вирішити проблему, якщо обидві половинки займають менше половини роботи над вирішенням всього набору даних. Але чому б не розділити набір даних на три частини? Четверо? n ?

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

Я також бачив багато посилань на тристоронній кваксор. Коли це швидше? Що використовується на практиці?

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

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

Але чому б не розділити набір даних на три частини? Четверо? n?

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

Наприклад, якщо ви робите сортування тристороннього злиття, то на етапі рекомбінації вам зараз доведеться знайти найбільший з 3 елементів для кожного елемента, для чого потрібно 2 порівняння замість 1, тож ви зробите вдвічі більше порівнянь . В обмін на це ви зменшуєте глибину рекурсії в коефіцієнт ln (2) / ln (3) == 0,63, тому у вас на 37% менше свопів, але на 2 * 0,63 == 26% більше порівнянь (і доступу до пам'яті). Добре це чи погано, залежить від того, яка вартість вашої апаратури дорожча.

Я також бачив багато посилань на тристоронній кваксор. Коли це швидше?

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

Що використовується на практиці?

У наші дні навряд чи хтось програмує власні алгоритми сортування; вони використовують один, наданий бібліотекою. Наприклад, API Java 7 фактично використовує подвійний шарнір.

Люди, які насправді програмують свій алгоритм сортування з якихось причин, як правило, будуть дотримуватися простого двостороннього варіанту, оскільки менший потенціал помилок перевищує 20% кращу ефективність більшості часу. Пам'ятайте: на сьогоднішній день найважливішим підвищенням продуктивності є те, коли код переходить від "не працює" до "працює".

Асимптотично кажучи, це не має значення. Наприклад, двійковий пошук робить приблизно  порівняння журналу ₂ n, а потрійний пошук робить приблизно  порівняння журналу ₃ n. Якщо ви знаєте свої логарифми, ви знаєте, що log _a  x = log _b  x / log _b  a, тому двійковий пошук складає лише близько 1 / log ₃ 2 ≈ в 1,5 рази більше порівнянь, ніж потрійний пошук. Це також причина, коли ніхто ніколи не визначає основу логарифму у великій О-нотації: це завжди постійний фактор, віддалений від логарифму в заданій базі, незалежно від того, яка база фактична. Таким чином, розбиття проблеми на кілька підмножин не покращує часову складність і практично недостатньо, щоб перевершити складнішу логіку. Насправді ця складність може негативно впливати на практичну ефективність, збільшуючи тиск кешу або роблячи мікрооптимізацію менш неможливою.

З іншого боку, в деяких структурах даних про дерева використовуються високий коефіцієнт розгалуження (набагато більший за 3, часто 32 і більше), хоча зазвичай з інших причин. Це покращує використання ієрархії пам’яті: структури даних, що зберігаються в оперативній пам’яті, краще використовують кеш, структури даних, що зберігаються на диску, вимагають меншої кількості зчитування HDD-> ОЗУ.

Існують алгоритми пошуку / сортування, які ділять не на два, а на N.

Простий приклад - пошук за допомогою хеш-кодування, який займає час O (1).

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

Принциповим є питання, коли програма вивчає деякі дані, а потім вводить деякі наступні стани, скільки наступних станів існує і наскільки близькі до рівних їхні ймовірності?

Коли комп’ютер робить порівняння двох чисел, скажімо, а потім або стрибає, чи ні, якщо обидва шляхи однаково ймовірні, програмний лічильник "знає" ще один біт інформації на кожному шляху, тому в середньому він "навчився" одного біт. Якщо проблема вимагає засвоєння M бітів, то, використовуючи бінарні рішення, вона не може отримати відповідь менше, ніж M рішення. Так, наприклад, пошук числа в відсортованій таблиці розміром 1024 не може бути виконано за меншими, ніж 10 бінарними рішеннями, хоча б тому, що будь-яка менша кількість не матиме достатньої кількості результатів, але це, безумовно, може бути зроблено в більшій кількості, ніж це.

Коли комп'ютер бере одне число і перетворює його в індекс в масив, він «вчиться» до лог-бази 2 числа елементів масиву, і це робить це в постійний час. Наприклад, якщо є таблиця стрибків з 1024 записів, все більш-менш однаково вірогідна, то перехід через цю таблицю "дізнається" 10 біт. Це основна хитрість хеш-кодування. Сортуючим прикладом цього є те, як можна сортувати колоду карт. Майте 52 бункери, по одному на кожну карту. Перекиньте кожну карту у свій контейнер, а потім вичерпайте їх усі. Не потрібне підрозділення.

Оскільки це питання про загальний поділ і підкорення, а не просто сортування, я здивований, що ніхто не підніс Теорему Магістра

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

Алгоритм Карацуби для множення використовує тристороннє ділення та підкорення для досягнення часу запуску O (3 n ^ log_2 3), який б'є O (n ^ 2) для звичайного алгоритму множення (n - кількість цифр у числа).

Через свою двійкову природу комп'ютер дуже ефективний при поділі речей на 2, а не на 3. Ви отримуєте поділ на 3, розділивши їх на 2, а потім розділіть одну з частин ще раз на 2. Отже, якщо вам потрібно розділити на 2, щоб отримати 3 поділу, ви також можете розділити на 2.