Задать вопрос
  • Алгоритм для поиска мин. разреза?

    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-му параметру узлов - порядковому номеру, которые вместе образуют диапазон, а не целевому значению узла, как в обычном дереве отрезков, так что это немного не то, про что я говорил
    Написано
  • Сценарии применения Splay Tree?

    Lite_stream
    @Lite_stream Автор вопроса
    Wataru, да не, я под range запросами имел в виду неравентсво, а не интервал )
    Написано
  • Сценарии применения Splay Tree?

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

    на всякий случай уточню: range запрос имелось в виду запрос на неравеснство (>, <, >=, <=)
    Написано
  • Сценарии применения Splay Tree?

    Lite_stream
    @Lite_stream Автор вопроса
    mayton2019, имелось в виду, что на find'ы будут приходить range запросы, а не запросы на равенство (поэтому хеш таблица не подойдёт)
    например, autocomplete
    Написано
  • Когда целесообразно использовать именно такую реализацию DSU?

    Lite_stream
    @Lite_stream Автор вопроса
    вот, кстати, нашёл задачу, где dsu не асимптотически, но быстрее. чем dfs, ну и даже сам код лаконичнее и яснее

    конечно не очень хороший бенчмарк, но leetcode для dsu выдаёт в среднем 150 милисекунд, а для dfs 190 милисекунд, там для dfs, в частности, нужно ещё в список смежности превратить исходный массив, нужна мапа (медленная) для vertex To component, сет для used ну и сам код намного длинее выходит

    вынесу этот коммент наружу топика, чтобы если кому понадобилось - сразу увидел
    Написано
  • Когда целесообразно использовать именно такую реализацию DSU?

    Lite_stream
    @Lite_stream Автор вопроса
    в общем, спасибо за ответ )
    вроде примерно устаканилось в голове )
    Написано