Які причини вивчати різні алгоритми / структури даних, що відповідають одній цілі?

Мене цікавить це питання ще з часів студентства. Це загальне питання, але я докладно поясню приклади нижче.

Я бачив багато алгоритмів - наприклад, для проблем з максимальним потоком я знаю близько 3 алгоритмів, які можуть вирішити проблему: Ford-Fulkerson, Edmonds-Karp & Dinic, причому Dinic має найкращу складність.

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

Що мене бентежить: чи є причини, чому ми повинні їх знати? Чому б не просто навчитися та ознайомитись із найкращою складністю?

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

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

Візьмемо сортування як приклад, оскільки всі знайомі зі стандартними алгоритмами сортування.

По-перше, складність - не єдина проблема. На практиці важливі постійні фактори, і саме тому, скажімо, швидкий сорт, як правило, використовується більше, ніж нагромадження, хоча швидкий сорт має жахливі складні випадки.

По-друге, завжди є шанс опинитися в ситуації, коли ви програмуєте в умовах дивних обмежень. Мені колись довелося зробити видобуток з чисельних розмірів зі скромного розміру (1000 або більше) колекцій зразків якомога швидше, але це було на невеликому мікроконтролері, який мав дуже мало запасної пам’яті для читання-запису, що виключало більшість алгоритми сортування. Сорт Shell був найкращим компромісом, оскільки він був субквадратичним і не потребував додаткової пам'яті.$O(n \log n)$

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

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

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

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

Окрім того, що на безлічі машинних моделей (TM, RAM, PRAM, ...) існує безліч витрат на затрати (час роботи, використання пам'яті, помилки кешу, помилки галузей, складність впровадження, можливість перевірки ...) Середній показник по відношенню до найгіршого, а також міркування амортизації для зважування один на одного, часто існують також функціональні відмінності, що виходять за межі базової специфікації підручника.

Деякі приклади:

• Mergesort стабільний там, де його немає.
• Двійкові пошукові дерева дають вам ітерацію порядку, а хештелі - ні.
• Bellman-Ford може впоратися з негативними вагами, Dijkstra не може.

Існують також дидактичні міркування :

• Наскільки легко зрозуміти більш задіяне рішення перед більш простими? (Дерева AVL (та їх аналіз) без BST; Dinic без Ford-Fulkerson; ...)
• Чи бачите ви однакові принципи та зразки, коли ви піддаєтесь вирішенню лише одного рішення на проблему порівняно з багатьма рішеннями?
• Чи виставлення лише одного рішення на кожну проблему забезпечує достатню підготовку (до майстерності)?
• Чи повинні ви знати ширину рішень, які були знайдені (щоб запобігти вам винаходити колесо знову і знову¹)?
• Якщо ви піддаєтесь лише одному вирішенню кожної проблеми, чи зрозумієте ви інші рішення, які ви знайдете в дикій природі (скажімо, в реальній бібліотеці програмування)?

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

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

Для розуміння алгоритмів / структур даних, які використовуються, дуже корисно знати велику кількість алгоритмів / структур даних, включаючи параметри, які вже не вважаються "сучасними".

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

Це те, що відрізняє когось, хто вивчав інформатику, від того, хто щойно навчився програмувати. У більшості робіт, над якими я працював, був час, коли вивчав інформатику, я міг вирішити проблему, яку програміст, який навчався «книгам», не міг, але 95% часу я виявив, що вивчаючи інформатику не давав мені переваги над іншими досвідченими програмістами .

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

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

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

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