Каковы причины для изучения различных алгоритмов / структур данных, служащих одной и той же цели?

Я задавался вопросом об этом вопросе, так как я был студентом. Это общий вопрос, но я приведу примеры ниже.

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

Для структур данных - например, куч - есть двоичные кучи, биномиальные кучи и кучи Фибоначчи, причем куча Фибоначчи имеет лучшую общую сложность.

Что меня смущает: есть ли причины, по которым мы должны знать их всех? Почему бы просто не изучить и познакомиться с лучшим из них?

Я знаю, что лучше всего, если мы знаем их всех, я просто хочу знать, есть ли какие-либо «более веские» причины, например, некоторые проблемы / алгоритмы могут быть решены только с помощью A, но не B и т. Д.

В какой-то момент есть учебник с рабочим названием Структуры данных, Алгоритмы и Компромиссы . Почти каждый алгоритм или структура данных, которые вы, вероятно, изучите на уровне бакалавриата, имеет некоторые особенности, которые делают его лучше для некоторых приложений, чем для других.

Давайте рассмотрим сортировку в качестве примера, поскольку все знакомы со стандартными алгоритмами сортировки.

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

Во-вторых, всегда есть вероятность, что вы окажетесь в ситуации, когда вы программируете в странных условиях. Мне когда-то приходилось делать квантильное извлечение из выборки небольшого размера (1000 или около того) как можно быстрее, но это было на небольшом микроконтроллере, у которого было очень мало свободной памяти для чтения и записи, так что исключалось большинство сортировать алгоритмы. Сортировка оболочки была лучшим компромиссом, поскольку она была субквадратичной и не требовала дополнительной памяти.$O(n \log n)$

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

Рассмотрим, например, какую-то 3D-визуализацию или видеоигру на современной видеокарте, где вы хотите рисовать объекты в порядке от ближайшего к камере до самого дальнего от камеры по соображениям производительности, но если вы не получите точный заказ, оборудование позаботится об этом. Если вы перемещаетесь по трехмерной среде, относительный порядок объектов не сильно меняется между кадрами, поэтому выполнение одного прохода пузыря на каждый кадр может быть разумным компромиссом. (Механизм Source от Valve делает это для эффектов частиц.)

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

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

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

Некоторые примеры:

• Mergesort стабилен там, где Quicksort нет.
• Деревья бинарного поиска дают вам итерации по порядку, хеш-таблицы - нет.
• Беллман-Форд может справиться с отрицательными весами, Дейкстра - нет.

Есть также дидактические соображения :

• Насколько легко понять более сложное решение перед более простыми? (Деревья AVL (и их анализ) без BST; Dinic без Ford-Fulkerson; ...)
• Видите ли вы те же принципы и закономерности, когда вы сталкиваетесь с одним решением на одну проблему по сравнению со многими решениями?
• Достаточно ли обучения (к овладению) дает экспозиция только по одному решению проблемы?
• Должны ли вы знать, какие решения были найдены (чтобы не изобретать колесо снова и снова?)?
• Когда вы столкнетесь с одним решением для каждой проблемы, поймете ли вы другие решения, которые вы найдете в дикой природе (скажем, в реальной библиотеке программирования)?

1. Это то , что мы видим много из типов программаторов , которые не имеют богатый CS набора инструментов в их распоряжении.

В реальном мире в какой-то момент вы, вероятно, будете работать над программным обеспечением, написанным группой других людей. Некоторые из этих программ будут написаны еще до вашего рождения!

Чтобы понять используемые алгоритмы / структуры данных, очень полезно знать большое количество алгоритмов / структур данных, включая параметры, которые больше не рассматриваются как «современные».

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

Это то, что отличает того, кто изучал информатику, от человека, который только что научился программировать. В большинстве работ, в которых я работал, было время, когда, изучая информатику, я мог решить проблему, которую не мог «программист из книг», но в 95% случаев я обнаружил, что изучение информатики не дает мне никаких преимуществ. над другими опытными программистами .

Многие справедливо отмечают, что зачастую нет одного лучшего алгоритма - это зависит от ситуации.

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

Множество хороших ответов, просто, я думаю, чего-то не хватает, хотя в ответе Рафаэля это несколько упоминается.

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