Пунктуация что ты, делаешь ахаха. Ну серьёзно, ну нельзя же так.
И да, для переводов есть специальная галка при редактировании и даже специальное поле, в котором указывается оригинал — это позволяет проще искать и фильтровать статьи.
Не совсем: предположим, по оси X откладываем младшие биты, по оси Y — старшие (подсеть). Тогда адреса, например, вида xxx.yyy.*.* (/16) будут занимать отрезок строкиxxx.yyy. То есть, за исключением граничных случаев, близкие адреса будут находиться рядом на прямой. И со столбцами тоже спорно — по-моему, довольно распространенный случай, когда одному регистратору принадлежит агрегат диапазонов типа 70.121.0.0/16 + 126.120.128.0/24 + ...
Но вы, вероятно, правы, т.к. необходимо разрешение порядка 65536 (216), чтобы разглядеть маленькие подсети (состоящие всего из одной-двух строк). Можно ли где-то найти сырые данные? Не проверишь, не узнаешь :)
Кстати говоря, помимо кривой Гильберта есть ещё много других семейств заполняющих кривых, и с разными элементарными паттернами — возможно, какие-то из них могут быть более или менее выразительны для визуализации/кластеризации именно диапазонов ip. Но тут уже можно улететь во фрактальную размерность, опять-таки минимизацию энтропии и прочие интересные дебри.
Ммм, а зачем пытаться уложить линейный диапазон в кривую? Как мне кажется, проще и нагляднее, например, на одной оси отмечать первые 16 бит адреса (шкала от 0 до 65536), а на второй — хвост из тех же 16 бит. Дыры и плотные блоки как раз тогда должны выглядеть непрерывными более-менее прямоугольными «кирпичами», а не зигзагообразными паттернами. Можно даже поиграться и выбрать разные диапазоны (подсети, старшие биты) для рисования, хотя и получатся уже прямоугольники, а не квадраты (и можно даже при выборе пропорций руководствоваться минимизацией энтропии в результирующем изображении :).
Radare2 тоже это умеет (а ещё он open source и просто вкусняшка). Да и вообще, ужель кто-то с гордым именем "дизассемблер" сейчас не сможет ветвление нарисовать?
Во-первых, как было осторожно предположено выше, квантовое "программирование" крайне далеко от повседневного понятия программирования (будь то разработка ядер Linux на C, дизайн железа на VHDL/Verilog, или тем более это ваше модное смуззи-based web/front-/back-end). UPD: хотя вот как раз к проектированию схем на VHDL/Verilog это всё же довольно близко, похоже.
Во-вторых, экосистема ещё только начинает осторожно выходить в свет:
прикладное направление (физическая реализация кубитов, гейтов, оракулов, все эти адиабатические шкафы, лазеры и платы при абсолютном нуле);
теоретическое (разработка алгоритмов, пример — разрекламированные алгоритмы Гровера, Шора, и ещё несколько десятков более специфичных и менее известных простым смертным);
… и такое вот "прикладное", которое про реализацию и оптимизацию (!) квантовых схем (вот это как раз про языки, схемы и эмуляцию — то, что уже сейчас можно потрогать).
В первые два направления, очевидно, нельзя просто взять и прийти (нужна серьёзная подготовка в соответствующих учебных заведениях и на соответствующих кафедрах). Однако, определенную минимальную базу можно получить, изучая открытые источники. Крайне рекомендую курс от СПбГУ "Квантовые вычисления" (ссылки в посте выше) и онлайн-редактор квантовых схем Quirk — очень наглядный и удобный инструмент.
Если в сорцах coturn поискать число 500, то найдется кое-что интересное.
Эм, usleep описан в man 3 usleep, и он просто усыпляет текущий thread на 500 микросекунд (а в контексте этой функции, похоже, это часть какой-то примитивной защиты или эмуляции DoS-атаки, судя по результатам поиска в репозитории, но это не точно), так что 500 секунд надо искать в другом месте.
Справедливо, не спорю :) Просто, как мне кажется, на волне зарождающегося хайпа на "квантовую" тему далеко не все и не сразу понимают (а после выпада "сложнаа" — и не поймут), что же лежит в основе пресловутых квантовых вычислений — а ведь это банально последовательность унитарных преобразований над векторами гильбертова пространства (именно так, матан-концентрат), со всеми вытекающими последствиями: линейность, обратимость, экспоненциальный рост размерности и т.п.
К сожалению (или к счастью?), да, квантовую "чуйку" развить с нуля простому смертному будет довольно трудно — нужен сильный царь мат. аппарат в голове и соответствующие навыки линейной алгебры. Увы, все мы в детстве складывали кубики и делили яблоки, а не эволюционировали волновые функции и не вращали вектора состояний в 2n-мерном пространстве — по этому поводу весьма занятно высказался К.Мухин в потрясающей книге «Занимательная ядерная физика»: "квантовую механику — младенцам!"
Возможно, заблуждаюсь, но… Что общего в понятиях "квантовое программирование", "линейное программирование" и "объектно-ориентированное программирование"? Правильный ответ — в их названиях есть слово "программирование" =) Думаю, в шутке таки есть щепотка истины.
Есть достаточно много открытых и не только материалов для приобщения к квантовому миру, но от себя хочу порекомендовать замечательный русскоязычный курс от СПбГУ "Квантовые вычисления" (Coursera, Stepic) и онлайн-редактор квантовых схем Quirk — курс даёт начальное представление о том, что вообще происходит и зачем мы всё это делаем, а редактор позволяет вдоволь поиграться с вентилями и реализовать простые квантовые схемы и алгоритмы.
Спойлер: бам, это всё линейная алгебра и жонглирование операторами, а эти ваши модные "квантовые" языки программирования — всего лишь синтаксический сахар над матричными операциями!
Похоже это просто перегрузка operator/, уже есть заготовка на cppreference (или вот ещё примеры). При желании даже сейчас это можно реализовать, фактически просто синтаксический сахар.
В статье неверно указана ссылка на нужнуюформулу Эйлера Вообще, этих одноимённых "формул Эйлера" огромное количество в различных областях науки — в экстренной ситуации, если не помнишь название, можно сказать "по формуле Эйлера..." и с ненулевой вероятностью попасть в точку :) Шутка.
Обидно, в этом месте допустил ошибку — и про гармонический ряд знал, и про расходимость, но с асимптотикой частичных сумм промахнулся (почему-то думал, что это O(n²)).
Вот про конкатенацию строк (и добавочный множитель из-за этого) — интересный момент, действительно, легко проморгать. Хотя это, наверное, больше вопрос к реализации и выбору контейнеров (например, меня, не очень знакомого с C# и Java, даже не сразу триггернуло в этом месте). Как верно заметили выше, можно (и нужно!) тогда копать ещё глубже, и решение становится всё менее очевидным.
Всё-таки автор более корректен в объявлении deleter'а: во-первых, как было отмечено, второй аргумент теперь будет являться обязательным в конструкторе, а во-вторых, размер такого unique_ptr'а раздувается на размер хранимого указателя на функцию-удалитель (несмотря на то, что fclose по сути является глобальной свободной функцией). Сравнение размеров.
Если такой unique_ptr является членом RAII-класса, то размер может иметь значение. Однако если обработка выполняется только в фиксированном {}-скопе (т.е. C-указатель не покидает блока), действительно можно обойтись указанным объявлением, хотя выигрыш в количестве кода при хорошем форматировании сомнителен.
Вызывает вопросы «новый интересный алгоритм» обработки пакетов. Можете ли вы прояснить некоторые моменты?
На каждой итерации полинга сокетов, мы читаем не более чем заранее установленное N-ое количество байт
Не означает ли это, что здоровая конкурентная очередь на входе в ядро намеренно превращается планировщиком в очередь курильщикакарусель (Round-robin)?
… означает ли это, что биржа в такой ситуации будет вынуждена обслуживать только одного клиента? Определенно — нет, ведь это было бы нечестно по отношению к менее быстрым участникам торгов.
Если я не ошибаюсь, именно для этого существует flood-контроль (с весьма весомыми санкциями) и логины с разными пропускными способностями; данное же заявление (вкупе с предудыщим), имхо, практически нивелирует преимущества логинов, и звучит одновременно как маркетинговый лозунг и оправдывание Биржи в неспособности (нежелании?) обеспечить достаточную производительность для конкурентной обработки заявок.
можно накапливать в памяти, например, класть в очередь в оперативной памяти.… Не самый эффективный способ работы с сообщениями, может потребоваться много памяти и лишние копирования сообщений.
В новом шлюзе… мы читаем из сокетных буферов только те сообщения, которые можем обработать. В случае большой нагрузки… забьется TCP буфер на стороне сервера
клиент при забитых буферах… получит ошибку EAGAIN и сможет сам принять решение о том стоит ли… продолжать торговать… или сменить стратегию
Серьёзно? То есть вместо того, чтобы честно формировать очередь заявок (да, именно в памяти!), шлюз признаётся в DoS при большой нагрузке, оправдывая это «неэффективностью» способа разгребания буферов? И да, EAGAIN, скорее всего, выльется в тот же самый пресловутый флуд (по крайней мере, первые несколько отказов), возвращая нас к предыдущим вопросам логинов и карусели, и вряд ли приведёт к «смене стратегии»: участник торгов далеко не один, и крайне маловероятно, что именно он вызовет DoS (а если и он, то ему ничтоже сумняшеся прописывается живительный flood-бан).
Часто встречал подобное мнение и не считаю его справедливым и конструктивным: всё-таки А.А. сыграл значительную роль в развитии языка (см. спойлер «Лирическое отступление»). В конце концов, никто не заставляет программистов городить воздушные замки из шаблонов: они, как и любой инструмент, имеют свою область применения, а большинство задач может быть решено разными способами (и с разным соотношением время/универсальность/расширяемость/производительность).
ИМХО, гораздо более «страшным» мне видится виртуально-интерфейсный фарш, бездонные иерархии и километровые определения приезжих в C++ из C#/Java, обычно и пышущих ненавистью к углоскобочному миру.
Уоу, это действительно круто, вроде как кейс попадает под «statement is a type-dependent expression» + функция-то шаблонная, но сходу вообще не очевидно.
Вангую, что подобные фичи опять будут открываться методом проб и ошибок a la «ребят, тут фарш инстанцировался, получился Coq».
Пожалуй, скажу ещё пару слов о constexpr if. В описании есть несколько важных моментов, и самыми вкусными являются эти:
The return statements in a discarded statement do not participate in function return type deduction.
...if condition is not value-dependent after instantiation, the discarded statement is not instantiated when the enclosing template is instantiated.
т.е. constexpr функции отныне действительно смогут «конструировать» типы и останавливать рекурсию по типам (с некоторыми оговорками). Рис возвращается в плов.
Энтузиасты пилят совершенно нереальные вещи. Например, паттерн матчинг на C++, даже синтаксис приемлемый, и без макросов (!).
Ещё посмотрите на constexpr if — фича C++17. Вообще, по мощности C++17 должен получиться тортом. Ждём и желаем удачи (и душевных сил) разработчикам компиляторов!
А, то есть вы предлагаете хранить генератор вместе с Treap'ом? Хорошо, я же имел в виду внешний «настоящий» генератор, никак не связанный с контейнером. В таком случае ваше решение, безусловно, несоизмеримо проще, это правда.
не вижу большой разницы между counter::next() и Random::next. Что-то вам все равно придется хранить и передавать
Более того я привел пример того как ее можно сгенерировать
Как раз не придётся. То, что вы описали, просто не будет работать: вам либо придётся руками считать вызовы Random<...>, либо подсовывать предыдущие псевдонимы в параметр шаблона. Упомянутые статьи как раз и описывают реализацию счётчика, способного инкрементироваться без посторонней помощи.
Пунктуация что ты, делаешь ахаха. Ну серьёзно, ну нельзя же так.
И да, для переводов есть специальная галка при редактировании и даже специальное поле, в котором указывается оригинал — это позволяет проще искать и фильтровать статьи.
Не совсем: предположим, по оси X откладываем младшие биты, по оси Y — старшие (подсеть). Тогда адреса, например, вида
xxx.yyy.*.*(/16) будут занимать отрезок строкиxxx.yyy. То есть, за исключением граничных случаев, близкие адреса будут находиться рядом на прямой. И со столбцами тоже спорно — по-моему, довольно распространенный случай, когда одному регистратору принадлежит агрегат диапазонов типа70.121.0.0/16 + 126.120.128.0/24 + ...Но вы, вероятно, правы, т.к. необходимо разрешение порядка 65536 (216), чтобы разглядеть маленькие подсети (состоящие всего из одной-двух строк). Можно ли где-то найти сырые данные? Не проверишь, не узнаешь :)
Кстати говоря, помимо кривой Гильберта есть ещё много других семейств заполняющих кривых, и с разными элементарными паттернами — возможно, какие-то из них могут быть более или менее выразительны для визуализации/кластеризации именно диапазонов ip. Но тут уже можно улететь во фрактальную размерность, опять-таки минимизацию энтропии и прочие интересные дебри.
Radare2 тоже это умеет (а ещё он open source и просто вкусняшка). Да и вообще, ужель кто-то с гордым именем "дизассемблер" сейчас не сможет ветвление нарисовать?
Нельзя просто взять и "покопаться" :)
Во-первых, как было осторожно предположено выше, квантовое "программирование" крайне далеко от повседневного понятия программирования (будь то разработка ядер Linux на C, дизайн железа на VHDL/Verilog, или тем более это ваше модное смуззи-based web/front-/back-end). UPD: хотя вот как раз к проектированию схем на VHDL/Verilog это всё же довольно близко, похоже.
Во-вторых, экосистема ещё только начинает осторожно выходить в свет:
В первые два направления, очевидно, нельзя просто взять и прийти (нужна серьёзная подготовка в соответствующих учебных заведениях и на соответствующих кафедрах). Однако, определенную минимальную базу можно получить, изучая открытые источники. Крайне рекомендую курс от СПбГУ "Квантовые вычисления" (ссылки в посте выше) и онлайн-редактор квантовых схем Quirk — очень наглядный и удобный инструмент.
Эм,
usleepописан вman 3 usleep, и он просто усыпляет текущий thread на 500 микросекунд (а в контексте этой функции, похоже, это часть какой-то примитивной защиты или эмуляции DoS-атаки, судя по результатам поиска в репозитории, но это не точно), так что 500 секунд надо искать в другом месте.Тайминг-атака не пройдёт :)
Справедливо, не спорю :) Просто, как мне кажется, на волне зарождающегося хайпа на "квантовую" тему далеко не все и не сразу понимают (а после выпада "сложнаа" — и не поймут), что же лежит в основе пресловутых квантовых вычислений — а ведь это банально последовательность унитарных преобразований над векторами гильбертова пространства (именно так, матан-концентрат), со всеми вытекающими последствиями: линейность, обратимость, экспоненциальный рост размерности и т.п.
К сожалению (или к счастью?), да, квантовую "чуйку" развить с нуля простому смертному будет довольно трудно — нужен сильный
царьмат. аппарат в голове и соответствующие навыки линейной алгебры. Увы, все мы в детстве складывали кубики и делили яблоки, а не эволюционировали волновые функции и не вращали вектора состояний в 2n-мерном пространстве — по этому поводу весьма занятно высказался К.Мухин в потрясающей книге «Занимательная ядерная физика»: "квантовую механику — младенцам!"Возможно, заблуждаюсь, но… Что общего в понятиях "квантовое программирование", "линейное программирование" и "объектно-ориентированное программирование"? Правильный ответ — в их названиях есть слово "программирование" =) Думаю, в шутке таки есть щепотка истины.
Есть достаточно много открытых и не только материалов для приобщения к квантовому миру, но от себя хочу порекомендовать замечательный русскоязычный курс от СПбГУ "Квантовые вычисления" (Coursera, Stepic) и онлайн-редактор квантовых схем Quirk — курс даёт начальное представление о том, что вообще происходит и зачем мы всё это делаем, а редактор позволяет вдоволь поиграться с вентилями и реализовать простые квантовые схемы и алгоритмы.
Спойлер: бам, это всё линейная алгебра и жонглирование операторами, а эти ваши модные "квантовые" языки программирования — всего лишь синтаксический сахар над матричными операциями!
Похоже это просто перегрузка
operator/, уже есть заготовка на cppreference (или вот ещё примеры). При желании даже сейчас это можно реализовать, фактически просто синтаксический сахар.В статье неверно указана ссылка на нужную формулу Эйлера Вообще, этих одноимённых "формул Эйлера" огромное количество в различных областях науки — в экстренной ситуации, если не помнишь название, можно сказать "по формуле Эйлера..." и с ненулевой вероятностью попасть в точку :) Шутка.
Обидно, в этом месте допустил ошибку — и про гармонический ряд знал, и про расходимость, но с асимптотикой частичных сумм промахнулся (почему-то думал, что это
O(n²)).Вот про конкатенацию строк (и добавочный множитель из-за этого) — интересный момент, действительно, легко проморгать. Хотя это, наверное, больше вопрос к реализации и выбору контейнеров (например, меня, не очень знакомого с C# и Java, даже не сразу триггернуло в этом месте). Как верно заметили выше, можно (и нужно!) тогда копать ещё глубже, и решение становится всё менее очевидным.
deleter'а: во-первых, как было отмечено, второй аргумент теперь будет являться обязательным в конструкторе, а во-вторых, размер такогоunique_ptr'а раздувается на размер хранимого указателя на функцию-удалитель (несмотря на то, чтоfcloseпо сути является глобальной свободной функцией). Сравнение размеров.Если такой
unique_ptrявляется членом RAII-класса, то размер может иметь значение. Однако если обработка выполняется только в фиксированном {}-скопе (т.е. C-указатель не покидает блока), действительно можно обойтись указанным объявлением, хотя выигрыш в количестве кода при хорошем форматировании сомнителен.Не означает ли это, что здоровая конкурентная очередь на входе в ядро намеренно превращается планировщиком в
очередь курильщикакарусель (Round-robin)?Если я не ошибаюсь, именно для этого существует flood-контроль (с весьма весомыми санкциями) и логины с разными пропускными способностями; данное же заявление (вкупе с предудыщим), имхо, практически нивелирует преимущества логинов, и звучит одновременно как маркетинговый лозунг и оправдывание Биржи в неспособности (нежелании?) обеспечить достаточную производительность для конкурентной обработки заявок.
Серьёзно? То есть вместо того, чтобы честно формировать очередь заявок (да, именно в памяти!), шлюз признаётся в DoS при большой нагрузке, оправдывая это «неэффективностью» способа разгребания буферов? И да,
EAGAIN, скорее всего, выльется в тот же самый пресловутый флуд (по крайней мере, первые несколько отказов), возвращая нас к предыдущим вопросам логинов и карусели, и вряд ли приведёт к «смене стратегии»: участник торгов далеко не один, и крайне маловероятно, что именно он вызовет DoS (а если и он, то ему ничтоже сумняшеся прописывается живительный flood-бан).ИМХО, гораздо более «страшным» мне видится виртуально-интерфейсный фарш, бездонные иерархии и километровые определения приезжих в C++ из C#/Java, обычно и пышущих ненавистью к углоскобочному миру.
Вангую, что подобные фичи опять будут открываться методом проб и ошибок a la «ребят, тут фарш инстанцировался, получился Coq».
constexpr if. В описании есть несколько важных моментов, и самыми вкусными являются эти:т.е.constexprфункции отныне действительно смогут «конструировать» типы и останавливать рекурсию по типам (с некоторыми оговорками). Рис возвращается в плов.Ещё посмотрите на
constexpr if— фича C++17. Вообще, по мощности C++17 должен получиться тортом. Ждём и желаем удачи (и душевных сил) разработчикам компиляторов!Random<...>, либо подсовывать предыдущие псевдонимы в параметр шаблона. Упомянутые статьи как раз и описывают реализацию счётчика, способного инкрементироваться без посторонней помощи.Спасибо! Задача действительно интересная.