Как определить, приводит ли добавление ребра к направленному графу к циклу?

Если я правильно понял ваш вопрос, то новое ребро (u,v) вставляется только в том случае, если раньше не было пути от v до u (т. е. если (u,v) не создает цикл). Таким образом, ваш граф всегда является DAG (направленный ациклический граф). Использование алгоритма Тарьяна для обнаружения сильно связанных компонентов (http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm) звучит как перебор в этом случае. Перед вставкой (u, v) все, что вам нужно проверить, есть ли является направленным путем от v К u, что можно сделать с помощью простого BFS/DFS.

таким образом, самый простой способ сделать это следующий (n = | V|, m = |E/):

• вставка (u, v): проверьте, есть ли путь от v до u (BFS/DFS). Сложность: O (m)
• удаление ребра: просто удалите их из графика. Сложность: O (1)

хотя вставка (u, v) занимает O (m) время в худшем случае, это, вероятно, довольно быстро в вашей ситуации. При выполнении BFS / DFS, начиная с v, чтобы проверить, достижим ли u, вы посещаете только вершины, которые достижимы из v. Я бы предположил, что в вашей настройке граф довольно разрежен и что количество вершин, достижимых другим, не так велико.

однако, если вы хотите улучшить теоретическое время работы, вот несколько подсказок (в основном показывая, что это будет не очень просто). Предположим, мы стремимся проверка в O(1) времени, существует ли направленный путь от v до u. Ключевым словом в этом контексте является транзитивное замыкание DAG (т. е. граф, содержащий ребро (u, v) тогда и только тогда, когда в DAG есть направленный путь от u до v). К сожалению, поддержание транзитивного закрытия в динамической настройке кажется не таким простым. Есть несколько документов, рассматривающих эту проблему, и все документы, которые я нашел, были документами STOC или FOC, что указывает на то, что они очень участвует. Самый новый (и самый быстрый) результат, который я нашел, находится в документе динамическое транзитивное замыкание через динамическую матрицу Inverse Санковского (http://dl.acm.org/citation.cfm?id=1033207).

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

Итак, почему я упоминаю этот подход поддержания транзитивного закрытия, если он не соответствует вашим потребностям? Ну, это показывает, что поиск алгоритма, потребляющего только O(1) время запроса, вероятно, не приведет вас к решению быстрее, чем простой с помощью BFS/DFS. Вы можете попробовать получить время запроса быстрее, чем O(m), но хуже, чем O(1), в то время как обновления также быстрее, чем O(m). Это очень интересная проблема, но мне кажется, что это очень амбициозная цель (поэтому, возможно, не тратьте слишком много времени на ее достижение..).