А помогло бы от вредоносного трафика просто введение лимитов, например от одного участника — не более n действий в минуту? Или требуются более сложные схемы фильтрации?
Учитывая, что в этом исследовании также не приветствуется общение по локальной сети, то искать друг друга они вообще не должны — оба идут на сервер производителя, а он их соединяет.
Я, правда, такой подход совершенно не одобряю — во-первых, мы намертво привязываемся к производителю, и после прекращения им поддержки устройства получаем тыкву. И во-вторых, мы получаем задержку отклика всегда и невозможность работать без интернета/соединения с сервером производителя.
То есть сначала мы надеялись на браузеры (что они отправляют правильный referer). Потом этого оказалось недостаточно. Теперь нам опять предлагают надеяться на браузеры?
Чтобы гипотетический зачинщик конфликта смог спланировать превентивный удар и полностью защититься от удара ответного? А ведь с полностью открытыми данными так он и сделает.
Так что опасения России тоже не менее понятны.
Как бы учитывая, что ракета действительно летит все 480 километров, железное доказательство «она не летит 500+» выглядит весьма нетривиальным. Как мне кажется, для этого нужно как минимум продемонстрировать двигатель ракеты(он не может расходовать меньше X на км) и емкости для топлива(вмещают не больше Y). А это уже определенно военная тайна либо нарушение интеллектуальной собственности (и через год такой же двигатель стали производить в Китае, например).
С другой стороны, заявления «Томагавки можно пускать с позиций ПРО в Европе» и прочее — тоже не могут быть опровергнуты без предоставления большого объёма данных. И насколько я знаю, никто такого не делал. Что вполне логично, на самом деле.
Как следует из примеров комментов ранее — блокчейн дешевле, чем централизованное решение, когда централизованного решения нет, и нет доверенной стороны, которая могла бы выступить посредником и создать такое решение. В таком случае может оказаться проще создать блокчейн, чем доверенного посредника.
Знаете, это у вас заплатки получаются какие-то, причем даже не в том месте. Ваша реализация всё ещё работает некорректно. Пример — пары (1, 2), (3, 4), (1, 3),. Получается parents = {{1,2},{3,1}}, и проверим are_synonymous(2, 4) — выдаёт false. Да даже are_synonymous(3, 4) теперь выдаст false, хотя у нас есть прямо такая пара.
Забавное. Заметил, что DisjointSet в статье на самом деле написан неправильно.
В этой структуре есть две эвристики — сжатие путей и подвешивание по рангу/весу. Первая — что при поиске корня мы записываем корень в предки всех, по кому прошли — в коде есть. А вторая — что мы выбираем, какой корень записать в parent другому при слиянии по рангу, или по весу множеств, или хотя бы случайно(это тоже работает, хотя сложнее доказывается) — отсутствует. То есть среднее время на операцию в написанной в статье структуре — O(logn), а вовсе не O(a(n)).
В питоне я тоже не особо, так что не беспокойтесь.
Во-первых, ваша реализация работает некорректно. Проверим на парах (1, 2), (3, 4), (2,4). После добавления всех трёх у вас parents = {{1, 2}, {3, 4}, {4, 2}}, и root_values = {2, 4}. are_synonymous(1, 3) выдаёт false, хотя должен true. Сами догадаетесь, что не так?
Во-вторых, в настоящем DisjointSet, примерно как в статье, время одной операции действительно может быть большим — как из-за увеличения словаря (хотя его обычно заполняют сразу, parent[w] = w]), так и из-за длинного цикла (не больше O(logn)). Но при этом в среднем запрос выполняется за константу — точно так же, как хотя иногда добавление в массив выполняется за О(n), в среднем оно выполняется за O(1).
Не совсем к тому же. У вас запрос O(1), у них запрос O(a(1)). С другой стороны, у них одна пара синонимов обрабатывается за те же О(1), а у вас как бы не О(n) будет. Так что такую структуру, как у вас — придется долго строить.
Так если бы шутка. Это просто наглядный пример, почему не стоит мешать языки.
Впрочем, если у вас была табличка «сарказм» или «пример написания плохого комментария» — извините, не разглядел.
Другое дело, что лично я просто знал.
Я, правда, такой подход совершенно не одобряю — во-первых, мы намертво привязываемся к производителю, и после прекращения им поддержки устройства получаем тыкву. И во-вторых, мы получаем задержку отклика всегда и невозможность работать без интернета/соединения с сервером производителя.
Так что опасения России тоже не менее понятны.
С другой стороны, заявления «Томагавки можно пускать с позиций ПРО в Европе» и прочее — тоже не могут быть опровергнуты без предоставления большого объёма данных. И насколько я знаю, никто такого не делал. Что вполне логично, на самом деле.
В этой структуре есть две эвристики — сжатие путей и подвешивание по рангу/весу. Первая — что при поиске корня мы записываем корень в предки всех, по кому прошли — в коде есть. А вторая — что мы выбираем, какой корень записать в parent другому при слиянии по рангу, или по весу множеств, или хотя бы случайно(это тоже работает, хотя сложнее доказывается) — отсутствует. То есть среднее время на операцию в написанной в статье структуре — O(logn), а вовсе не O(a(n)).
Во-первых, ваша реализация работает некорректно. Проверим на парах (1, 2), (3, 4), (2,4). После добавления всех трёх у вас parents = {{1, 2}, {3, 4}, {4, 2}}, и root_values = {2, 4}. are_synonymous(1, 3) выдаёт false, хотя должен true. Сами догадаетесь, что не так?
Во-вторых, в настоящем DisjointSet, примерно как в статье, время одной операции действительно может быть большим — как из-за увеличения словаря (хотя его обычно заполняют сразу, parent[w] = w]), так и из-за длинного цикла (не больше O(logn)). Но при этом в среднем запрос выполняется за константу — точно так же, как хотя иногда добавление в массив выполняется за О(n), в среднем оно выполняется за O(1).
Впрочем, если у вас была табличка «сарказм» или «пример написания плохого комментария» — извините, не разглядел.