У остальных участников не было этапов 2 и 3. А была только заявка в виде описания и файла с презентацией. Как бэ возможности для представления информации о проекте немного разные.
В куче push_heap добавляет за логарифм, сохраняя свойство кучи.
Если сценарий использования таков, что данные сначала добавляются, а только потом осуществляется поиск — то да, тут красно-черные деревья будут излишними.
Рассмотрите сценарий, когда операции вставки идут вперемешку с поиском. Т.е. вы заранее не знаете, какая операция будет следующей — вставки или поиска. А может, удаления. Тогда после каждой операции вставки вектор надо приводить в сортированный вид.
Мне кажется, что в таком случае он проиграет.
Пардон, совсем невнимательно прочитал.
Нода относится только к сообществу ее соседей, поэтому сложность линейна по числу линков.
Так что по сути это просто аггломеративная кластеризация/построение дендрограммы с таким особым функционалом, определяющим сливающиеся кластеры.
Ну как бэ…
Если посмотреть на работы последних лет, то одно из направлений работ по указанным Вами алгоритмам — это как подобрать/варьировать это число без существенной трудоемкой перестройки найденного при данном значении параметра решения.
Если смотреть на их статью, то «Assume that we start with a weighted network of N nodes. First, we assign a different community to each node of the network. So, in the initial partition there are as many communities as there are nodes.»
N человек-> N нод-> на первом этапе N сообществ => N^2 сложность первой итерации. И все, приплыли…
Если Вы строите массив за линейное время (например, алгоритм Фарача), то он лучше — время и память не зависят от размера алфавита. Особенно важно последнее обстоятельство. Но это нетривиальный алгоритм. Тот алгоритм построения массива, который чаще встречается и проще в реализации, строит за O(NlogN), что медленнее, чем построение дерева.
Вообще, массив вроде как и появился для оптимизации потребления памяти.
У ICC тоже есть возможность использовать оптимизацию вычислений с плавающей точкой: strict (без оптимизации), safe (оптимизация, не влияющая на результат), fast (с потерей точности). Причем именно последняя опция стоит по дефолту при включении оптимизации.
Если сценарий использования таков, что данные сначала добавляются, а только потом осуществляется поиск — то да, тут красно-черные деревья будут излишними.
Мне кажется, что в таком случае он проиграет.
Нода относится только к сообществу ее соседей, поэтому сложность линейна по числу линков.
Так что по сути это просто аггломеративная кластеризация/построение дендрограммы с таким особым функционалом, определяющим сливающиеся кластеры.
Если посмотреть на работы последних лет, то одно из направлений работ по указанным Вами алгоритмам — это как подобрать/варьировать это число без существенной трудоемкой перестройки найденного при данном значении параметра решения.
Если смотреть на их статью, то «Assume that we start with a weighted network of N nodes. First, we assign a different community to each node of the network. So, in the initial partition there are as many communities as there are nodes.»
N человек-> N нод-> на первом этапе N сообществ => N^2 сложность первой итерации. И все, приплыли…
Есть плагины для разных систем.
Вообще, массив вроде как и появился для оптимизации потребления памяти.
Также надо учитывать, что решение зависит линейно от размера a алфавита (O(na) ). В отличие от, например, суффиксного массива.