Мы предлагаем новую физическую гипотезу: в иерархических системах со вложенной самореферентной рекурсией может существовать дополнительный энергетический вклад, не сводимый к обычной попарной энергии связи. Этот вклад, обозначаемый E_rec, зависит от глубины рекурсии, межуровневой когерентности и внутренней меры связности системы.
Вчера я 4 минуты стоял в подъезде и смотрел, как два лифта одновременно поехали вверх. Все два. На табло — 12, 15, 18. Я на первом. Мне на шестой. И я подумал: вот я кучу лет пишу софт, оптимизирую запросы к базе данных, кеширую всё что движется — а эти две коробки на тросах не могут разобраться, кто из них должен спуститься за мной.
Потом я погрузился в тему. И выяснил, что они не «не могут разобраться». Они математически не способны найти идеальное решение. Вообще никто не способен. Задача диспетчеризации группы лифтов — NP-трудная. То есть буквально: не существует алгоритма, который гарантированно найдёт оптимальный маршрут за разумное время.
И вот уже 60 лет лучшие инженеры мира решают эту задачу эвристиками. По сути — догадками.
Я делаю Beetroot — клипборд-менеджер для Windows на стеке Tauri + React + Rust + SQLite. В моей ежедневной базе 1000+ записей: куски кода, URL-ы, стектрейсы, SQL-запросы, переписки из мессенджеров. Поиск по всему этому должен работать мгновенно и попадать точно в цель.
Сначала я пошёл по простому пути: подключил популярную библиотеку Fuse.js и думал, что задача решена. Но реальные данные буфера обмена оказались для неё патологическим кейсом.
Эта статья — про путь от «просто подключи готовую либу» до самописного 5-уровневого движка с мерж-скорингом. Два дня, 8 итераций, пара красивых продуктовых багов по дороге.
Когда я пишу эту статью, то чувствую себя довольно глупо. На самом деле, это история с моралью «Прежде, чем действовать, изучи вопрос и понимай, в чём заключается твоя цель, потому что иначе потеряешь много времени».
Я продолжаю работать над проектом PSRayTracing. Как ни стараюсь я положить его на полку, время от времени слышу о чём-то «новом» и задаюсь вопросом: «а можно ли засунуть это в мой трассировщик лучей, чтобы выжать из него ещё немного скорости?». На этот раз такой темой стали аппроксимации Паде. Моя цель заключалась в обеспечении более быстрых (и точных) тригонометрических аппроксимаций.
Увы, это не помогло... однако я обнаружил нечто иное, позволившее существенно ускорить мой трассировщик!
Данная статья посвящена основе основ нейронауки — линейной алгебре. Если вы когда-либо планируйте изучать искусственные нейронные сети (и не только), то вам необходимо начать именно с этого. Причем не важно, собираетесь ли вы заниматься фундаментальными исследованиями (Data Science) или просто лепить модели в продакшн на конвейере (ML Engineering), вы обязаны знать их математику хотя бы поверхностно. Любые настройки, дообучение и применение даже готовой модели, требуют понимания основ. А по сему данное знание, как минимум, не будет избыточным.
Материал рассчитан на новичка. Если вы знаете школьную математику, то сможете освоить и мой курс. В будущем я напишу статью о линейном представлении нейросетей, где мы адаптируем полученное знание под прикладные задачи, напишем некоторые слои на Python и построим настоящую модель!
В этой статье:
* Понятие вектора;
* Векторизация данных;
* Умножение на скаляр;
* Сложение векторов;
* Норма вектора;
* Скалярное умножение;
* Векторное умножение;
* Практика с кодом;
* Домашняя работа.
Все будет объяснено на красочных примерах в игровой форме. Ничего сложного. А в конце вас ждет самостоятельная практика с кодом.
Приятного чтения!
Фильтра Калмана много не бывает! По этой теме издано несколько книг, опубликовано большое количество статей, в том числе на Хабре. Разработанный в 1960-х годах алгоритм оценки состояния динамических систем по сегодняшний день считается одним из лучших, получает все более широкое применение в различных технических системах: от радиолокации до электрокардиографии.
В этой статье я хотел бы на конкретных примерах показать принцип работы фильтра Калмана, наглядно продемонстрировать, на что влияет тот или иной параметр, как работают различные модификации фильтра.
Все модели, которые я буду использовать и описывать, выполнены на языке Matlab – среде, изначально созданной для работы с матрицами. Гарантированно они будут работать на версии R2016b и выше.
Группа исследователей впервые смоделировала полный жизненный цикл живой бактериальной клетки с наномасштабным разрешением, отследив поведение каждого гена, белка и химической реакции от репликации ДНК до клеточного деления. Результаты исследования, опубликованные в журнале Cell, открывают возможность заменить сотни реальных лабораторных экспериментов одной комплексной 4D-симуляцией.
Привет, Хабр. Меня зовут Владимир, я бэкенд-разработчик. Это моя первая статья здесь — о том, как пет-проект для нишевого варианта шахмат прошёл путь от «а что, если...» до первого места в рейтинге на chess.com. Без нейронок. На чистом alpha-beta поиске, написанном на Rust.
Статья будет полезна тем, кто интересуется шахматным программированием, оптимизацией CPU-bound задач или связкой Python + Rust через PyO3.
Я был одержим процедурными картами с ещё детства, когда кидал кубики на таблицы случайных подземелий из AD&D Dungeon Master's Guide. В этом есть что-то волшебное — ты не проектируешь подземелье, а исследуешь его, помещение за помещением, а кубики решают, попадёшь ли ты в сокровищницу или в тупик с кучей крыс.
Спустя годы я решил создать собственный генератор карт. Он создаёт маленькие средневековые островные миры с дорогами, реками, побережьями, горами, лесами и деревьями. И всё это полностью процедурным образом. Генератор написан на Three.js WebGPU с TSL-шейдерами, примерно 4100 шестиугольников в 19 сетках генерируются за ~20 секунд.
Привет, Хабр! В попытках отчаянно найти подработку, которую можно было бы совмещать с учебой, листал я агрегатор стажировок, где и наткнулся на набор от Яндекса. Решив, что терять мне всё равно нечего, я быстро кликнул по ссылке, заполнил анкету, и буквально через минуту мне на почту пришло письмо с приглашением решить тестовое задание. Я подумал, что вечер наконец-то обещает быть интересным, заварил чаёк и уже собрался спокойно чилить следующие несколько часов, аристократически посёрбывая и иногда тыкая пальцем по клавиатуре.
Боже, как я ошибался.
В статье даны формальные определения понятиям задача, способ, случай, действие и его свобода, причина, измерение, предположение и его верность, игра, поведение и ум, а также еще около 80. Предлагается основанный на исконно русских словах новый язык теории вероятностей, теории игр, теории алгоритмов, математической статистики, философии. Указаны недостатки существующей терминологии.
Задачи в нашей небольшой команде разделены строго: Лев отвечает за аппаратную часть, схемотехнику и проект в целом, а Марк — за инженерию данных, разметку виброакустических датасетов и алгоритмы каскадной фильтрации.
В этой статье мы хотим поделиться набитыми шишками при проектировании прототипа: почему стримить аудио работающего двигателя фуры в облако — это экономическая утопия, как организовать непрерывный сбор данных без блокировки процессорного ядра и почему перенос цифровой обработки сигналов (DSP) на борт микроконтроллера стал для нас единственным выходом.
Кому будет полезно
Если вы живёте в Python и одновременно используете statsmodels, lifelines, pyhf, PyMC/BlackJAX, linearmodels (или что‑то похожее).
Если вам важны воспроизводимость и понятная валидация численных оптимизаций (особенно в HEP).
Если вам интересна архитектура «одно вычислительное ядро → много задач» и практические hot paths (AOT, SIMD, zero‑copy).
Sliding Window — одна из самых популярных техник на собеседованиях. Разберём её пошагово на примере задачи Longest Substring Without Repeating Characters и реализуем решение на Go с объяснением каждого шага.
«Сделайте нам строго по порядку» — эта фраза из бизнес‑требований часто становится началом долгого и дорогого инженерного триллера. В мире микросервисов и event‑driven систем классический FIFO превращается из простой очереди в проверку на прочность всей архитектуры. За обещанием «строгой последовательности» стоят сетевые задержки, алгоритмы консенсуса и суровые ограничения распределенных систем.
Представьте задачу: есть куча роботов, и им всем надо куда‑то добраться, не столкнувшись с собратьями, а мы должны придумать для этого алгоритм. Это, если упрощать, и называется многоагентным планированием или MAPF — Multi‑Agent Pathfinding.
Обычно работу принято начинать с ограничения на то, что агенты двигаются только по квадратной сетке или графу. Но для реальных приложений нам, конечно, нужно переходить к непрерывному пространству, и тут кроется одна проблема. Многие из существующих сред и симуляторов либо слишком примитивны, либо настолько физически детальны, что проводить масштабные эксперименты в них слишком долго либо даже невозможно.
В общем, мы в команде «RL агенты» Лаборатории когнитивных систем искусственного интеллекта AIRI сделали свою среду‑бенчмарк под названием CAMAR, где можно обкатывать модели многоагентного обучения с подкреплением в непрерывном пространстве. Мы представили нашу статью про CAMAR на Main Track конференции AAAI‑2026 и на воркшопе WoMAPF’26 (тоже часть AAAI-2026). Заодно я, стажер‑исследователь команды и студент магистратуры ЦКМ МФТИ по имени Артём Пшеницын, решил рассказать о нашей разработке на Хабре.
Впервые в истории человечество может генерировать программное обеспечение быстрее, чем способно понимать создаваемые системы.
На протяжении многих лет индустрию программного обеспечения волновал один вопрос:
Кто будет писать код?
Теперь искусственный интеллект способен генерировать тысячи строк кода за секунды.
Но это порождает гораздо более важный вопрос — тот, который почти никто в технологическом мире не задаёт:
Кто будет нести ответственность за жизнь программных систем, которые ИИ собирается создавать?
Потому что написать код легко.
Жить с последствиями этого кода следующие двадцать лет — значительно сложнее.
Чтобы понять, что на самом деле происходит, нужно разделить три совершенно разные роли в разработке программного обеспечения.
1️⃣ Написание кода
2️⃣ Проектирование алгоритмов и систем
3️⃣ Ответственность за жизненный цикл программного обеспечения
Эти роли часто воспринимаются так, будто это одно и то же.
Но это не так.
И появление ИИ заставляет нас наконец увидеть эту разницу.
Вступление
В прошлой статье я показывал,как мы в AGIQ Solver Enterprise применили квантово‑вдохновлённый популяционный подход на GPU для NP‑задач и получили ускорение на практических постановках в 50–100 раз по сравнению с последовательным перебором и плохо распараллеливаемыми схемами.
Сегодня — следующий шаг:покажу,как задачи машинного обучения можно кодировать в SAT/MaxSAT, а затем решать обычным NP‑солвером — тем же AGIQ Solver Enterprise.
О чём статья (и что мы НЕ делаем)
Мы не будем пытаться “запихнуть” в SAT весь мир DL (ResNet/LLM/градиенты/батчи). Это плохая идея: там, где нужна дифференцируемая оптимизация, SGD остаётся королём.
Зато есть большой класс ML‑задач, где:
модель дискретная или может быть дискретизирована,
важны ограничения (fairness/монотонность/запреты/политики),
важна проверяемость и воспроизводимость решения,
нужен глобальный поиск (а не локальная оптимизация по градиенту).
Вот здесь SAT/MaxSAT — это не экзотика,а универсальный язык “правила + ограничения + оптимизация”.
Почему SAT вообще способен “кодировать что угодно”
В теории, любой NP‑вопрос можно редуцировать к SAT. На практике это означает простую вещь:
Я аналитик данных и люблю бумажный формат книг (если есть сомнения, сначала пробую электронную версию, но, если книга заходит, всегда потом беру бумажную).
В этой статье честный обзор, без рекламы, тех книг, которые я купила не так давно в бумажном формате.
Когда вы прокладываете маршрут в горах в 2ГИС или рассматриваете вид на дом в 3D, вы вряд ли задумываетесь, что под капотом карты происходит серьёзная вычислительная работа. За каждой формой рельефа — тысячи треугольников, интерполяции и алгоритмы, которые превращают цифровую модель местности в реалистичную поверхность.
Впервые рельеф мы добавили в веб‑версию 2ГИС в 2022 году. С тех пор мы не останавливались на достигнутом: доработали алгоритмы, улучшили качество исходных данных, научили дороги и здания влиять на поверхность. А недавно мы выкатили рельеф и в мобильное приложение.
В этой статье расскажем, как мы пересмотрели подход к данным, зачем нам понадобился нерегулярный меш, что общего у RTIN с Делоне и почему даже рельеф иногда приходится «чинить».
