Задать вопрос
  • Всегда ли DP можно представить в виде DAG?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, ну если дп называть структуру мемоизации + функцию, то да. Но тут так было названо, просто потому что когда что-то такое решаешь, то контекст в голове именно про дп (хотя и состоящее не только из этапов характерных для дп (вроде вычисления конденсации графа))
    Написано
  • Всегда ли DP можно представить в виде DAG?

    Lite_stream
    @Lite_stream Автор вопроса
    Спасибо за ответ

    В ДП можно составить граф зависимостей: какие состояния участвуют в вычислении каждого. Это будет DAG. Иначе у вас надо вычислять значения через самих себя и у вас уже не рекуррентные соотношения, а система уравнений.
    В некоторых задачах эту систему уравнений можно решать иерархически, по частям, отдельно в каждой компоненте сильной связности. Это немного напоминает ДП, но им не является. Суть ДП в том, что у вас рекуррентные формулы. Это некий более общий алгоритм.

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

    Тут вопрос определений. Что считать "представить в виде DAG".

    Да, нужно было указать это. Я имел в виду dag как некоторую "проекцию" зависимостей мемоизированных состояний друг на друга через рёбра графа, не учитывая, например, условные операторы, можно сказать "максимальное по включение" множество рёбер

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

    Если я правильно понял о чём идёт речь, то можно рассуждать следующим образом: рассмотрим какую-то конкретную задачу (с точностью до набора входных данных). Пусть запустился некоторый алгоритм, использующий мемоизированные данные и завершил вычисление с некоторым результатом. Тогда можно уже после окончания алгорима, не используя условные операторы, построить dag, который потребовался для вычисления результирующего значения (опять же, с точностью до входных данных, т.к. для разных входных данных будут разные рёбра), поскольку вычисления завершены, то мы точно знаем зависимости по мемоизированным состояниям
    Написано
  • Более формальный вывод из доказательства по принципу наименьшего числа?

    Lite_stream
    @Lite_stream Автор вопроса
    Спасибо за ответ

    Просто увидев некоторую симметрию с "домино" индукции, там ведь тоже скипается очевидная часть после базы и шага индукции (что теперь нужно взять базу b0 и подставить в доказынный k-й шаг, применив переход и получив базу b1 и так далее), подумал, что мб здесь так же
    Написано
  • Покрытие графа циклами?

    Lite_stream
    @Lite_stream Автор вопроса
    https://cstheory.stackexchange.com/questions/46819...

    хотя видимо с циклами длины больше 2 есть серьёзные проблемы
    Написано
  • Покрытие графа циклами?

    Lite_stream
    @Lite_stream Автор вопроса
    Спасибо за ответ

    Или можно еще проще: разбиение на циклы равносильно перестановке, которая для каждой вершины задает следующую в цикле. Перестановка равнозначна максимальному паросочетанию.

    а, ну да, видимо про маппинг в обе стороны это и имелось в виду

    Действительно, полное парсочетание становится циклами. Да, если граф не ориентированный, или содержит "тривальные" циклы (длины 2), то они могут войти в покрытие. Если найдется не полное паросочетание, то в графе будут какие-то непересечающиеся циклы и возможно пути. Он может быть даже не весь покрыт при этом.

    как я понял, для неориентированных графов нет алгоритма, чтобы он нет включал циклы длины 2, мб только, если он нашёл дополняющий путь i->j, j->i, какую-то персистентность алгоритму добавить, чтобы он назад до некоторого состояния алгоритма откатился и попробовал пойти "в другую сторону" искать дополняющий путь, но может так получиться, что ему придётся откатиться до самого старта и просто стартовать с другой вершины
    Написано
  • Алгоритм для поиска мин. разреза?

    Lite_stream
    @Lite_stream Автор вопроса
    Да, точно, забыл про обратные рёбра, спасибо
    Написано
  • Можно ли обойтись без бин. поиска?

    Lite_stream
    @Lite_stream Автор вопроса
    Спасибо за подробный ответ

    Граф почти такой же. Раздвоенное ребро. В середину каждого ребра вход из истока пропускной способностью 1 и стоимостью 0. Вдоль ребра в обе стороны такие же ребра - пропускной способности 1 и стоимости 0. Из вершины делаем degree(v) ребер в сток. Каждое пропускной способностью 1 и прогрессивно увеличивающимися стоимостями. Первые ребра стоимостью 1. Вторые - n+1, сделующие (n+1)^2 и т.д.

    Стоимость полного потока будет тем меньше, чем меньше максимальная степень, ведь даже одно ребро стоимостью (n+1)^k для вершины степени k+1 хуже чем если бы все вершины имели степень k и ответ был бы n*(n+1)^(k-1).


    Тут кажись может быть проблема, что надо nlogn бит на число (для веса ребра), хотя для "нормальных" графов 64 бита должно хватить. Полагаю, речь всё-таки про max flow, потому что скорость работы с max flow (для самого быстрого алгоритма) должна быть (E*V)*logV, а для min cost вроде E*E*logV+E*V*log^2(V)

    Если нужен именно просто поток, а не минимальной стоимости, то возможно можно изменить алгоритм потока, чтобы искать его итеративно для всех возможных значений x в вашем графе. Ведь алгоритм итерационно ищет дополняющий путь в остаточной сети. И ответ для x можно использовать в качестве стартового потока для задачи с x+1. Т.е не надо логарифм раз запускать поток для разных графов, а после выполнения увеличить пропускные сопособности нужных ребер на 1 и запустить поток дальше. Это будет как если бы вы запустили поток один раз с максимальной пропускной способностью сразу.


    Я так понял, речь идёт именно про алгоритм Форда-Фалкерсона ? Здесь же ФФ будет только по 1-му потока прибавлять, поэтому бинарным поиском не получится, придётся линейным. Если использовать ФФ с линейным поиском, то должно быть O(Ans * E) = O(V * E), ну да, лучше, чем V*E*logV, особенно, если бы бин. поиск удалось прикрутить. Хотя мб на таком графе (где все единичные рёбра, кроме истока) и тот алгоритм быстрее отработает
    Написано
  • Как довести задачу на min cost flow?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, у меня осталось только одно направление, в какую сторону можно думать: если представить перелёты как отрезки, то если какие-то 2 пересекаются, то в оба суммарно больше k не войдёт, поэтому если сделать общую вершину вметимостью k у них, то можно ограничить, но тем не мене выглядит бесперспетивно, потому что могут быть и пары и по 3 и по 4 и т.д.. В общем идея была сделать какой-нибудь граф отрезков ну и сверху потоки прикрутить
    Написано
  • Как довести задачу на min cost flow?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, на самом деле после задач вроде этой (решение) уже не удивлюсь ни одной упоротой конфигурацией графа, в том смысле что в потоках и разрезах бывают совсем слишком неочевидные структуры решения
    Написано
  • Как свести задачу к минимальному разрезу?

    Lite_stream
    @Lite_stream Автор вопроса
    Спасибо
    Написано
  • Как доказать что мы действительно не пропустим такую пару i,j которая дает правильный ответ в методе двух указателей?

    Lite_stream
    @Lite_stream
    можно же проще, 70-80% алгоритмов с двумя указателями доказываются, тем, что, если в наборе данных (массиве) есть 2(или m) значений, то указатели их не могут пропустить

    доказательство сводится к тому, что нужно перебрать все варианты (их обычно не много) положений указателей и показать, что они обязательно не пропустят ответ
    Написано
  • Есть ли у этой задачи название?

    Lite_stream
    @Lite_stream Автор вопроса
    Спасибо. А если вместо ЛП перевести её в SAT, зафиксировав min количество вершин = k и бинарным поиском найти k, только там помимо клозов, относящихся к самой проблеме ещё будет C(k, n) клозов типа что выбрано ровно k каких-то вершин и не выбраны остальные, наверное это проблемно будет перевести в SAT
    Написано
  • Дейкстра почти за линейное время (для неориентированного графа)?

    Lite_stream
    @Lite_stream Автор вопроса
    Похоже, что с алгоритмами на графах примерно такая же проблема как и в сортировках, нужно определить паттерн данных - пример
    Написано
  • Проверка на достижимость в направленном графе?

    Lite_stream
    @Lite_stream Автор вопроса
    Вообще можно было бы попробовать бин поиском (по timeIn dfs) по вершинам, в которые можно по перекрёстным рёбрам добраться(как 4-й шаг в том алгоритме): скакать по вершинам, используя timeIn вершины to, и при каждом переходе в перекрёстную вершину, проверять timeIn у to > или <, чем, timeIn перекрёстной вершины, ну то есть выше или ниже она дереве обхода dfs

    Хотя такое, наверное не сделать, лучше чем за n*logn памяти, а это многовато
    Написано
  • Проверка на достижимость в направленном графе?

    Lite_stream
    @Lite_stream Автор вопроса
    да, я не учёл наличие красных рёбер (из картинки выше), нужно как-то это тоже проверять, боюсь, что таким образом приду как раз к тем двум алгоритмам из той статьи - Thorup's Algorithm и Kameda's Algorithm
    Написано
  • Сценарии применения Splay Tree?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, ну я как раз и спросил, что мб как раз с сильно неравномерными распределениями сплей дерево как раз лучшее, что есть, мб даже лучше статического массива при отсутствии модификации
    Написано
  • Сценарии применения Splay Tree?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, вот, кстати, что в самом верху топика про сплей деревья в вики написано:

    For random access patterns drawn from a non-uniform random distribution, their amortized time can be faster than logarithmic, proportional to the entropy of the access pattern. For many patterns of non-random operations, also, splay trees can take better than logarithmic time, without requiring advance knowledge of the pattern.
    Написано
  • Сценарии применения Splay Tree?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru,

    Если в качестве диапазоно взять ключи, то у вас будет запрос по ключам.

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

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

    вот как раз не уверен, например, если там лежит 1кк элементов, при этом 99% запросов это какие-то 1000 элементов, то для них будет в сплей дереве глубина в 2 раза меньше, чем до остальных (должна быть), а в отсортированном массиве для всех элементов будет примерно logn скачков в рандомное место памяти, ну то есть, например, в сплей дереве будет для 1кк в среднем 11 скачков на запрос, а в отсортированном массиве 20 скачков
    Написано
  • Сценарии применения Splay Tree?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, ну типа есть хеш-таблица, где можно делать запросы только на равенство, есть дерево поиска, где можно делать запросы по неравенству(самих целевых значений узлов дерева), а в дерево отрезков, где можно делать запросы по непрерывному диапазону узлов (отрезку), и вычислять какую-то функцию для этого подмножества, но в дереве отрезков запрос именно можно сказать по 2-му параметру узлов - порядковому номеру, которые вместе образуют диапазон, а не целевому значению узла, как в обычном дереве отрезков, так что это немного не то, про что я говорил
    Написано