Алгоритмы *

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

Оказалось, что классика вроде «Съешь ещё этих мягких французских булок» не подходит — в моём наборе каждая буква была только один раз. А те панграммы, где буквы не повторяются (можно найти, например, у Лебедева в «Ководстве») — «Эй, жлоб! Где туз? Прячь юных съёмщиц в шкаф.» или «— Любя, съешь щипцы, — вздохнёт мэр, — кайф жгуч» — они, скажем так, на любителя. Слишком много восклицаний, междометий и прямой речи. Хотелось чего-то более пристойное и связное.

У меня получилось найти следующую панграмму:

«Съев мяч, щипцы, эльф‑конюх ждёт груз шайб»

В ней все 33 буквы русского алфавита, каждая по одному разу. В статье — как я её искал, фильтры словаря и то, как устроен поиск.

Я хотел просто пожарить кесадилью. В холодильнике лежали зеленые оливки (солено-кислые), сулугуни и фарш, а на полке консервированная кукуруза. И вот стою я над сковородкой и думаю: а оливки с кукурузой вообще сочетаются? А сулугуни не пересолит блюдо вместе с оливками? Сколько чего вообще класть?

В любой другой ситуации я бы загуглил рецепт. Но не тут-то было, я же великий комбинатор оптимизатор, и у меня в голове сразу всплыло: «это же задача оптимизации». Тем же вечером у меня был ноутбук с обученной нейросетью вместо ужина. Рассказываю, как дошел до жизни такой, и как из этого, внезапно, получился реально вкусный рецепт.

Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.

Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.

И самое интересное заключается в том, что так было не обязательно.

В июле 2024 года французская компания Kyutai опубликовала речевую модель Moshi с нейронным аудиокодеком Mimi. Это был первый в мире голосовой end-to-end AI с открытыми исходниками, способный вести диалог в реальном времени и свободный для использования всеми желающими, демо.

Вместо прямого предсказания сэмплов аудиокодек работает в три этапа:

1. Токенизация звука.

2. Предсказание следующих токенов в LLM.

3. Восстановление оригинала.

Голосовая активация в умных колонках — задача в целом решённая: несколько микрофонов, стабильное питание от розетки, хороший процессор. А вот перенести то же самое в наушники оказалось совсем другой историей.

Крошечный аккумулятор, мало памяти, чип с жёсткими ограничениями по тактовой частоте, да ещё и с кое‑какими неожиданным сюрпризами на уровне SDK. Всё это потребовало переосмыслить с нуля архитектуру споттера (компонента, который распознаёт обращение «Алиса» прямо на устройстве). 

Меня зовут Григорий Афанасенко, я работаю в команде голосовых технологий Яндекса. Сегодня мы запустили Яндекс Дропс — первое носимое ИИ‑устройство с Алисой AI. В этой статье я расскажу, как мы адаптировали споттер под железо наушников, какие решения пришлось принять, где мы наступили на грабли и что планируем делать дальше. 

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

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

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

Люди тоже их создают. Для меня один из самых удивительных паттернов, которые мы придумали — это дороги.

Иногда я представляю инопланетян из далёких галактик, которые откроют Землю уже спустя много времени после нашего ухода. Леса, снова занятые природой, города, превратившиеся в развалины; однако между ними всё равно заметен слабый паттерн — сеть дорог. Мне нравится думать, что они будут чувствовать то же самое, что и я, когда смотрю на природные паттерны: «Ого, кто-то действительно это продумал».

Градостроительные симуляторы и их дороги

Должен сказать, что дороги восхищали меня с детства.

До сих пор помню, как в возрасте шести-семи лет впервые играл в SimCity 2000. Я понял не особо многое и не знал, что такое зонирование, налоги и спрос. Но дороги сразу меня восхитили.

Я считаю, что дороги — основа каждого градостроительного симулятора. Ткань, из которой создаются города. С того времени я играл почти во все градостроительные симуляторы, действие которых происходит в наше время. Тем временем я начал замечать дороги в реальном мире. Исследовать их более детально.

Развязки. Перекрёстки с круговым движением. Эстакады. Сужения полос. Замечал каждую мелочь.

Хотя в каждой новой игре происходит шаг вперёд по сравнению с предыдущей, что-то всё равно продолжало казаться неестественным.

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

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

Во многом красота математики заключается в том, что благодаря произвольному выбору можно связать две кажущиеся далёкими концепции. Впервые я увидел этот паттерн в вопросе на Math Stack Exchange. Его задал пользователь dwymark, а ответил на него Грег Мартин; вопрос связан с распределением простых чисел, а также с рациональными аппроксимациями .

Этот пользователь баловался с созданием графиков данных в полярных координатах, то есть нанесением точек в 2D-пространстве, но не по обычным координатам XY, а по расстоянию от точки начала координат, обычно называемому (радиус), и по углу прямой относительно горизонтали, обычно называемому «тета», .

10 апреля 2019 года человечеству показали оранжевый бублик. Журналисты назвали его «первой фотографией черной дыры». Через час картинка была у всех — мемы про глаз Саурона, шутки про пончик, антропоморфизация,  заголовки «ученые сфотографировали невидимое».

Проблема в том, что это не совсем фотография.Точнее сказать, это очень странная фотография: если бы вы использовали телескоп горизонта событий (англ. EHT — далее по тексту) «как камеру» и нажали кнопку, вы бы получили черный квадрат и никакого бублика. Потому что он делает измерения, из которых алгоритм уже собирает изображение…  которого нет.

Вот про этот алгоритм и про то, как 3,5 петабайта данных летели в Бостон самолетом, и пойдет речь.

При работе с современными CPU устранение ошибочного предсказания ветвления — ключевой способ повышения скорости программ. Один из самых эффективных способов снижения количества ошибочных предсказаний— полное устранение ветвлений.

Возьмём для примера простую задачу: итеративный обход массива и копирование всех чисел меньше 500 в новый массив. Если числа распределены случайно, то результат условия if становится непредсказуемым для блока предсказания ветвления CPU. Из-за этого показатель ошибочного предсказания будет высоким, существенно препятствуя производительности, потому что процессору многократно приходится сбрасывать конвейер и начинать исполнение повторно.

Начну с признания: истории формата «природа оптимизирует лучше людей» меня обычно раздражают, слишком уж часто это все притянуто за уши. Но с муравьями история действительно странная, и мне ее захотелось проверить.

Короткая справка по нашему герою. Аргентинский муравей Linepithema humile в миллиметр длиной, с глазами у него все плохо, а в мозге около 250 000 нейронов (у нас, напомню, 86 млрд). Карты местности он не помнит. 

В 1989 году четверо бельгийских биологов поставили этим муравьям простой эксперимент — гнездо, еда, два мостика, где один длиннее другого в два раза. Через несколько минут вся колония сошлась на короткой ветке в 100% прогонов. И все это без координатора, без плана и без голосования. 

Через три года этот эксперимент превратится в Ant Colony Optimization — алгоритм, который я сегодня натравлю на классический TSP-бенч и получу 0,10% отставания от оптимума. А в 2023, через 34 года после наблюдений в Брюсселе, тот же алгоритм вернулся на NeurIPS в качестве бэкбона для графовых нейросетей. Что же, приступим.

Всем привет! Меня зовут Андрей, я финалист ICPC (Международной студенческой олимпиады по программированию), разработчик Техплатформы Городских сервисов Яндекса. Эта статья — концентрат неочевидных (а порой и контринтуитивных) советов по подготовке к соревнованиям. Годами я тренировался, набивал шишки на контестах и набирался мудрости у топовых тренеров, чтобы собрать этот опыт в одном месте.

Д-р наук, профессор Эдсгер Дейкстра (Edsger W. Dijkstra, 1930−2002) — легендарный голландский и американский учёный, труды которого заложили фундамент современного программирования. Среди всех учёных прошлого Дейкстра оказал самое большое влияние на современную информатику. Он один из разработчиков концепции структурного программирования, формальной верификации, распределённых вычислений, построения компиляторов, графовых алгоритмов, дизайна алгоритмов, дизайна ПО, дизайна математических аргументов, языков программирования и операционных систем.

Некоторые статьи Дейкстры всего лишь на несколько страниц становились источником целых новых исследовательских направлений. Ряд современных концепций были впервые выявлены Дейкстрой и носят придуманные им названия. Например, параллельные вычисления.

На вашем диске лежит семь одинаковых моделей птицы Додо. Не благодарите — это ARK заботливо положил их вам в каждое DLC.

Раньше Super Mario Bros весила 40 КБ. Сейчас одно обновление Chrome — это ~7 000 таких Марио. Как мы дошли до жизни такой, и почему все идет по кругу?

В статье пройдем путь от тайлов NES до Neural Texture Compression и рассмотрим змейку в трех версиях: по трем вехам сжатия. Одна из них в 1 120 раз меньше первой. И это не та, в которой ИИ.

Я работал над Pizza Legacy — опенсорсным воссозданием игры 1994 года Pizza Tycoon для DOS. В игре есть вид на улицы города, при скроллинге которого игрок наблюдает постоянный поток машин. Это примерно 20-30 маленьких спрайтов, однако они едут по дорожной сети, создают очереди на перекрёстках и в целом выглядят как оживлённый город. Да, симуляция иногда глючит, машины проезжают друг через друга, но этого достаточно, чтобы придать карте ощущение жизни. И всё это на процессоре 386 с частотой 25 МГц.

Когда я приступил к реализации своего проекта в 2010 году, то первым делом создал этот вид улиц, но мне понадобилось ещё четырнадцать лет, прежде чем машины начали двигаться по нему так, как это меня устраивало; за эти годы я совершил множество попыток, но каждый раз сталкивался с проблемами и заходил в тупик из-за создания переусложнённой системы.

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

Всё это время мне не давала покоя одна мысль: если оригинальная Pizza Tycoon работала на процессоре с частотой 25 МГц, то почему мои версии всегда оказывались столь сложными?

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

В предыдущей статье о Vinyl я рассказывал об архитектуре LSM-движка Tarantool. Восемь лет, прошедшие с момента с написания статьи, показали, что Vinyl сразу получился идеальным и менять его не нужно :). Если серьёзно, сегодня я расскажу о тех изменениях, которые мы внесли в алгоритм в форке Tarantool от Picodata, и неизбежно коснусь более глубокой проблематики работы LSM-деревьев, а конкретнее – работы планировщика слияний (compaction scheduler).

Откройте ваш плейлист и нажмите play на любом треке.

Эта песня попала в ваши наушники благодаря одной идее. Той самой, за которую француза в 1807 году высмеяли на заседании Парижской академии наук. Лаплас был «за», но Лагранж встал и сказал: «Это невозможно.» Француза звали Жан-Батист Жозеф Фурье. Его идея была настолько простой, что учёные отказались ей поверить.

Pac-Man — полностью детерминированная игра. Как я объяснял в своём видео об этой игре, все движения призраков зависят от того, где на текущий момент находится Pac-Man. Следовательно, обладая этими знаниями, можно точно спрогнозировать, куда будут двигаться призраки в любой момент времени. Но так ли это? Когда Pac-Man съедает большой шарик («энерджайзер»), призраки пугаются и начинают двигаться по паттерну, который кажется случайным и непредсказуемым. Это единственный момент, когда в игре используется генератор случайных чисел (RNG): для определения того, в каком направлении повернёт испуганный призрак на перекрёстке лабиринта. Хоть это решение тоже детерминировано, это единственный непредсказуемый элемент Pac-Man.  

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

Представьте: вам дают 10 терабайт текста и говорят — запихни это в файл на 70 гигабайт. Так, чтобы потом по любому вопросу можно было восстановить нужный кусок. Не точно, но близко. Не побайтово, но по смыслу.

Вы бы сказали: «это lossy-компрессия, часть данных неизбежно потеряется».

И были бы правы. Потому что именно это делает LLM.