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

В этой части мы рассмотрим общие принципы построения числовых систем, как модулей над другими системами, перейдём от пар к матрицам и немного пофилософствуем над такими вопросами: «Что такое числовая система?», «Почему матрицы так хорошо подходят для сочинения новых чисел?»

Это вторая часть серии статей, посвящённой построению числовых систем, основанных на упорядоченных парах. В предыдущей статье мы рассмотрели как строится кольцо целых чисел из пары натуральных, освоившись с понятиями классов эквивалентности и факторизацией. В этой построим ещё одну знакомую числовую систему: поле рациональных чисел.

Как объяснить правила сложения, умножения и сравнения для дробей? Откуда взялись общие знаменатели, деление многоэтажных дробей, всевозможные «методы бабочки» и прочие премудрости, подстерегающие человека классе в шестом?

Материал расчитан на тех, кто учит старшеклассников или младшекурсников

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

1. В этой статье мы (признаюсь, достаточно занудно) построим из натуральных чисел целые, при этом познакомимся с важнейшими инструментами математики: упорядоченной парой, эквивалентностью и факторизацией.

2. Во второй части от целых мы перейдём к рациональным числам, которые тоже можно представить в виде пары — рациональной дроби. Главный вопрос на который мы постараемся ответить: «А чего у дробей всё так сложно-то?»

3. В третьей части мы сконструируем Гауссовы числа и порассуждаем над более общим вопросом: «Что такое число?». В этой части мы перейдём от пар к матричным представлениям чисел, что позволит нам ввести их классификацию.

4. Четвёртая часть будет посвящена эллиптическим арифметикам: комплексным числам и числам Эйзенштейна. Здесь мы порассуждаем над сакраментальным вопросом: «Реальная ли мнимая единица?»

5. В пятой части мы рассмотрим гиперболические арифметики и познакомимся с двойными числами, и немного используем их на практике, чтобы понять «Как работает формула Бине?»

6. Шестая часть завершит эту серию. Она расскажет о параболических арифметиках, в частности, о дуальных числах, которые позволят арифметике быть неточной. Кроме того, мы порассуждаем о том как вписать в нашу классификацию рациональные дроби.

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

Привет, я Антон Полухин из Техплатформы Екома и Райдтеха Яндекса. Моя команда разрабатывает userver — современный опенсорсный асинхронный фреймворк с богатым набором абстракций для быстрого и комфортного создания микросервисов, сервисов и утилит на C++.

Когда мы пишем какой‑то код для userver и для таких сложных проектов, как Boost, периодически мы сталкиваемся с нестандартными проблемами. И эти нестандартные проблемы требуют нестандартных решений. Вот о таких решениях мы сегодня и поговорим.

А именно:

— Посмотрим, как работают исключения на платформе Linux x86, и сделаем с ними что‑то интересное.

— Залезем ещё глубже под капот исключений и сделаем их ещё быстрее.

— Сделаем висячую ссылку на невалидный объект, и всё будет хорошо.

— А под конец то, что все любим, — погрузимся в шаблонное метапрограммирование.

Физический вакуум – «нематериальная» сущность, вызывающая особый интерес как у физиков, так и у мистиков, да и у простых людей тоже. С одной стороны, до сих пор распространено донаучное понимание вакуума как пустоты – отсюда мифы о том, что Вселенная – это в основном пустое пространство, все вещи пусты, мы сами состоим из одной пустоты, и вообще материи не существует – всё как по канонам буддизма. С другой стороны, многим известно о том, что вакуум состоит из «виртуальных» частиц, и это порождает другие мифы: вакуум – не пустота, а бесконечное море энергии, которую можно бесплатно извлечь, или вакуум – вместилище потенциально возможного, он содержит в себе все вещи в непроявленном виде. Естественно, находятся изобретатели вечных двигателей на вакуумной энергии и техник материализации предметов из ничего, готовые поделиться своими разработками за установленную плату. В данной статье я не только развею подобные заблуждения, но и расскажу о научно обоснованных способах получения энергии вакуума. Также мы выясним, насколько реальны «виртуальные» частицы и при каких условиях они могут становится ещё более реальными.

В рамках микросервисной архитектуры достаточно легко делать «реактивные» сервисы: к вам приходит событие или вызов HTTP-метода, и в ответ на это происходит какое-то действие. Однако бывают более сложные сценарии, когда надо собрать некоторое количество информации или событий прежде, чем что-то делать. В таком случае нужен пайплайн — механизм организации сложных правил обработки событий. 

Недавно нам пришлось организовать пайплайн с использованием интересных С++-трюков. О них я и расскажу в статье. 

— Как хранить в одном контейнере разные типы и использовать тип в качестве ключа контейнера 

— Как средствами метапрограммирования удобно сериализовать и десериализовать разнотипные объекты 

— Как сделать универсальный запускатель функций, который будет запускать любую функцию и сам искать, откуда «добыть» эти аргументы 

— И главное, как сделать интерфейс для написания пайплайна обработки события — удобный и полностью изолированный от инфраструктуры

Чёрная дыра… Ничто так не притягивает и не будоражит воображение, пока не погрузишься в глубины теоретической физики и не поймешь, что в реальности всё довольно скучно и прозаично. Знаю, тема буквально затёрта… до дыр, да и хайп вокруг неё поутих с тех пор, как появились первые фотографии, сделанные Телескопом горизонта событий. Но без краткого ликбеза по чёрным дырам будет трудно понять мои будущие статьи по квантовой гравитации и цифровой физике, ведь на горизонте событий пересекаются сферы применимости двух фундаментальных, но плохо совместимых физических теорий – квантовой теории поля (КТП) и общей теории относительности (ОТО). К тому же изучение чёрных дыр – это идеальное упражнение на понимание релятивистской физики Эйнштейна, в частности, принципа относительности одновременности и принципа эквивалентности инертной и гравитационной масс. Поэтому я решил систематизировать информацию о чёрных дырах и расставить все точки над «i». В данной статье мы рассмотрим чёрные дыры как астрофизические объекты. Квантовые аспекты чёрных дыр оставим на потом.

Конкурентность сложно как следует наладить, как минимум, тем из нас, кому не повезло писать на языках, непосредственно открывающих нутро конкурентного аппаратного обеспечения: речь о потоках и разделяемой памяти. Не менее сложно организовать конкурентность так, чтобы она работала и правильно, и быстро. Все, что вы знаете об оптимизации однопоточного кода, зачастую вам не поможет. На микроуровне (отдельные инструкции) просто невозможно применить обычные правила, актуальные для μ-операций, цепочек зависимостей, пределов пропускной способности и т.д. При конкурентности правила другие.

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

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

Часто ловлю себя на мысли, что рассуждаю именно в таких категориях, когда мне нужна высокопроизводительная конкурентность: каков наилучший уровень, который я реально могу достичь при решении конкретной задачи? Держать в уме эти уровни полезно и на этапе первичного проектирования (иногда небольшое изменение требований или высокоуровневого дизайна позволяют вам выйти на более выгодный уровень), а также при оценке уже существующих систем (для еще более точного понимания имеющейся производительности и выстраивания пути наименьшего сопротивления, ведущего к улучшениям).

В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда мы не можем ответить на них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»

Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.

Всем привет! A/B тестирование уже давно стало стандартом в проверке гипотез и улучшении продуктов в X5. Но, как ни странно, многие из «модных» техник, которые применяются в A/B тестировании, на самом деле, не что иное, как вариации старой доброй линейной регрессии. 

Основная идея здесь проста: правильное добавление новых переменных в модель помогает лучше контролировать внешние факторы и уменьшать шум в данных. Это позволяет точнее оценить эффект от воздействия и объединить разные статистические подходы, которые обычно рассматриваются отдельно. Но почему это работает? Почему всё сводится к тому, что добавление переменных помогает объединить, казалось бы, разрозненные техники? 

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

Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает. Цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.

В школах и университетах при изучении математики определяют операцию дифференцирования функции и производную. Это фундаментальные понятия, на которых в дальнейшим строится весь аппарат математического анализа.

Обычную производную и её обобщения используют повсеместно, например в машинном обучении, при обучении нейронных сетей.

Если продифференцировать функцию - то получится её производная. Если сделать это дважды - получится вторая производная. Но если ли что “между”? Конечно же есть, и именно про такие объекты написана эта статья.

Для большинства стандартных контейнеров перебор элементов можно осуществлять просто с помощью цикла for с диапазоном прямо во время выполнения. Но что насчет кортежей (std::tuple)? В этом случае мы не можем использовать обычный цикл, так как он не «понимает» список аргументов кортежа во время компиляции. В этой статье я покажу вам несколько приемов, которые вы можете использовать для итерации по элементам кортежа.

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

В мире программирования создание собственных библиотек — это не просто возможность пополнения своего портфолио или способ структурировать код, а настоящий акт творческого самовыражения (и иногда велосипедостроения). Каждый разработчик иногда использовал в нескольких своих проектах однообразный код, который приходилось каждый раз перемещать. Да и хотя бы как упаковать свои идеи и знания в удобный и доступный формат, которым можно будет поделиться с сообществом.

Если вы ловили себя на мысли: «А почему мне бы не создать свою полноценную библиотеку?», то я рекомендую прочитать вам мою статью.

Эту статью вы можете использовать как шпаргалку для создания проектов, и не только библиотек.

Некоторые из вас могут подумать, что мы изобретаем велосипед. А я в ответ спрошу — сможете ли вы прямо сейчас, без подсказок, только по памяти, нарисовать велосипед без ошибок?

Добро пожаловать во вторую, скорее всего финальную часть статьи! Здесь мы окончательно допишем код, исправим некоторые ошибки.

После недавней статьи о шаблонах С++ для начинающих осталось жгучее желание показать что-нибудь похожее, но на практическом примере, да так, чтобы и порог входа был не высоким, и чтобы скучно не было. А так как в голове крутится задача перевода чего бы то ни было в строку, то этим и предлагаю заняться всем, кто хочет потрогать компилятор за шаблоны.

В мире программирования создание собственных библиотек — это не просто возможность пополнения своего портфолио или способ структурировать код, а настоящий акт творческого самовыражения (и иногда велосипедостроения). Каждый разработчик иногда использовал в нескольких своих проектах однообразный код, который приходилось каждый раз перемещать. Да и хотя бы как упаковать свои идеи и знания в удобный и доступный формат, которым можно будет поделиться с сообществом.

Если вы ловили себя на мысли: ‭«А почему мне бы не создать свою полноценную библиотеку?‭», то я рекомендую прочитать вам мою статью.

Эту статью вы можете использовать как шпаргалку для создания проектов, и не только библиотек.

Некоторые из вас могут подумать что мы изобретаем велосипед. А я в ответ скажу — сможете ли вы прямо сейчас, без подсказок, только по памяти, нарисовать велосипед без ошибок?

Ошибки программистов C++ — это отдельный вид искусства, вроде бы простой язык, но стоит отвлечься на чашечку кофе, как компилятор начинает вываливать простыню ворнингов пополам с ошибками, и иногда это больше похоже на древнеегипетские письмена, чем на нормальный выхлоп. Вы наверное и сами не раз сталкивались с разыменованием nullptr или перепутали (= и ==) по недосмотру. Часто причиной ошибкой является лень или невнимательность, или усталость - не зря появились суеверия "не комитить в пятницу вечером", "не кодить в состоянии изменного сознания" или "избегать кода под кофейным угаром", ну это когда три-четыре кружечки кофе навернул и пошел нести добрый код направо и налево.

Вообще статья планировалась про то как можно поиздеваться над switch оператором - была у меня запись разговора с одного питерского митапа, проходившего несколько лет назад и где присутствующим предложили написать "невозможный", но работающий код со switch. И вот в поисках этой записи я наткнулся на файл с описанием "пятничных" багов и комитов, которые бы в трезвом уме посреди недели врядли бы проскочили в мастер. А еще была статья тоже про ошибки "Федя, дичь", где уважаемый хабрачитатель угадывал причину разных ошибок, явных или не очень. Поэтому я решил продолжить в том же стиле, вопрос - ответ, а вам предлагаю также поучаствовать в отгадывании возможных причин. Все примеры из реальных проектов, игр, движков и пятничных комитов.

C++ не прощает ошибок, но именно в этом его "шарм". В большинстве приведенных примеров сохранен стиль и названия параметров, только немного подчищены коментарии, дабы не палить контору.