Алгоритмы *

CLL в ISPA — переносимый язык семантических действий для генераторов парсеров. Объявление переменных, условий и циклов, генерация AST и кода на C++ без привязки к языку парсера. Пример, разбор и сравнение с ANTLR, Bison.

Мне очень нравится знаменитая цитата Ричарда Фейнмана:

«То, что я не могу создать, я не понимаю»

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

Сегодня, в 2025 году, красота и ремесло написания ПО подвергаются разрушению. ИИ угрожает тем, что заменит нас (или, по крайней мере, заберёт все самые приятные аспекты нашего ремесла), а разработка ПО становится всё более стандартизированной, выверенной, упакованной и индустриализированной. Разработке программного обеспечения нужно больше простых удовольствий. Я выяснил, что создание хобби-программ — отличный способ снова напомнить себе, почему вообще я начал работать с компьютерами.

LLM требуют все больше данных для обучения, но обучаться постепенно становится не на чем: аппетиты ИИ-систем превосходят возможности человечества по генерации контента, к тому же использовать реальные данные в одних случаях дорого, в других — не очень-то законно.

Спасти ситуацию может «синтетика», но и с ней не все гладко. Мы в beeline cloud решили разобраться, какие риски несут в себе подобные датасеты, что такое «ML-аутофагия» и как с ней борются разработчики LLM.

Как вычислить экспоненциальную функцию быстро и с минимальной погрешностью? Пишем векторизованный код.

Разработка парсер генератора ISPA: что реализовано и какие планы на будущее.Гибкий парсер нового поколения с теми функциями, которых давно не хватает существующим решениям.

Как вы, наверно, знаете, из-за наличия в компьютере различных кэшей (L1, L2, L3...) и того, что операции с памятью выполняются с линиями кэша размером примерно 64 байт каждая, для обеспечения максимальной производительности мы должны писать программы, обеспечивающие локальность.

(Разумеется, диск здесь не показан)

Но насколько хорошо вы это осознаёте? Допустим, у нас есть массив чисел с плавающей запятой и массив индексов первого массива. Есть программа, складывающая числа из первого массива в порядке, определяемом вторым массивом. То есть в этом примере мы будем складывать ε + α + δ + ζ + β + γ в таком порядке:

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

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

2. Сколько в среднем тратится на каждый элемент в порядке от первого до последнего?

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

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

5. Достаточно ли стандартного тасования Фишера-Йейтса для массивов перемешанных индексов для получения произвольного порядка?

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

7. Максимально ли быстры файлы с отображением в память?

Если вы уже знаете ответы на эти вопросы, то это замечательно! Если же нет, то делайте ваши предположения и проверьте их, прочитав пост.

Почему при сложениии одинаковых чисел в разном порядке получаются разные результаты?
Как мининмизировать ошибки округления или избавиться от них совсем?

Интервалы, интервалы,‑ где тут лево, где тут право...

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

На практике однако встречаются и более сложные задачи. Допустим, например, что в некой гостинице есть два свободных номера. Но один свободен со 2-го по 5-е число, а второй - с 6-го по 10-е. Клиент интересуется, есть ли возможность поселения на 8 дней? Правильный ответ - "да, есть, но с переселением (лесенкой)". Для такого ответа программа должна уметь распознать, что интервалы [2, 5] и [6, 10] являются смежными , а значит, их можно сложить, получив общий доступный интервал [2, 10], длина которого (9) превышает запрашиваемый.

Другая более редкая, но и более интересная задача - определить область пересечения двух множеств интервалов. Сложность в том, что количество интервалов в сравниваемых множествах может быть произвольным. Программист, который умеет только в сравнения "на меньше/больше" (или даже в between), столкнется при реализации с трудностями формализации.

В данной статье мы сфокусируемся на выводе формулы пересечений множеств интервалов. Опираться будем на линейную алгебру и ее объекты - векторы и формы. Кому интересен в первую очередь итоговый результат, - могут сразу двигать в конец, не вникая в промежуточные выкладки.

Привет, Хабр! В предыдущей части мы рассматривали базовые методы цифровой обработки изображений для задачи сегментации спутникового снимка.

В этой статье рассмотрим ещё парочку методов решения этой задачи, всё ещё «классических», то есть без применения машинного обучения или нейросетей. Помогут нам во всём разобраться, как и в прошлый раз, язык программирования Julia и среда технических расчётов Engee!

Привет, Хабр! Мы – Даниил Соловьев и Михаил Никитин из команды направления распознавания лиц. Сегодня фокусируемся на задаче распознавания лиц на изображениях низкого разрешения (low resolution face recognition, low-res FR). Она актуальна в первую очередь при анализе данных видеонаблюдения, так что если перед вами сейчас стоит подобная задача (или просто интересно, как она решается) — статья для вас. Расскажем про проблемы и сложности распознавания лиц низкого разрешения, подходы к решению задачи, в том числе свежий PETALface с конференции WACV 2025. Также поделимся ссылками на исследования, которые подробнее освещают каждый подход.

Крупнейшие инвестиционные компании, успешные трейдеры, матерые волки с Уолл-Стрит и прочие серьезные участники рынков используют в торговле алгоритмы. В первом материале я приводил конкретные примеры, цифры, аргументы – если пропустили, почитайте, будет полезно. 

А если кратко, то суть в следующем: игроки, которые до сих пор торгуют на рынке исключительно «вручную» или при помощи готовых, общедоступных инструментов – неконкурентны. Хочется оставаться в игре? Придется подключать коды и роботов.

Собственно, моя серия материалов именно об этом. А цель – научить вас превращать свои торговые идеи в уникальные, рабочие алгоритмы. Даже если раньше вы не программировали.

Что, если навигатор перестанет упрямо твердить «Развернитесь!», когда  вы свернули с маршрута и предложит новый, более вам подходящий?

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

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

Времени мало, объема много, цели амбициозные - нужно научиться легко и быстро объяснять, но так же не лишая полноты!

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

Будет здорово получить ваши задачи и в следующих выпусках разобрать!

Мы продолжаем. Обязательно испытайте себя в предыдущей [1] части!

Недавно меня заинтересовала такая задача: как лучше всего определить, что в строке есть гласная?

Казалось бы, тривиальный вопрос, правда?

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

В этом посте я рассмотрю 11 способов обнаружения гласных, алгоритмический анализ, дизассемблирование байт-кода Python, реализацию CPython и даже исследую опкоды скомпилированного регулярного выражения. Поехали!

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

Что может заставить обратить внимание на красно-чёрные деревья, и как их реализовать? Статья ответит на оба эти вопроса. Бонусом будет показано, как на основе красно-чёрного сконструировать дерево интервалов.

В 2006 году АНБ скрыла в криптографическом стандарте Dual EC DRBG математический бэкдор. Агентство отрицало его наличие восемь лет. Затем утечки Сноудена подтвердили его существование.

Двойные эллиптические кривые (Dual Elliptic Curve) используются как безопасные генераторы случайных чисел (RNG). Математический бэкдор позволял правительству США расшифровывать SSL-трафик Интернета (Green 2013)¹.

Эта статья будет технически глубоким исследованием для программистов. Мы реализуем и исходную правительственную научную статью (SP 800-90 2006)², и бэкдор, обнаруженный исследователями Microsoft (Shumow & Ferguson 2007)³.

На моём домашнем компьютере для взлома 28 байт (не бит) при помощи этого бэкдора требуется 2 минуты. Представьте, какой объём Интернет-трафика правительство США могло расшифровывать при помощи суперкомпьютеров Министерства обороны.

Привет! Меня зовут Кирилл Хрыльченко. Я руковожу командой, которая занимается R&D для рекомендательных технологий в Яндексе. Одна из наших основных задач — развивать трансформерные технологии в контексте рекомендательных систем, и мы активно занимаемся этим уже примерно пять лет. Не так давно у нас произошёл новый виток в развитии рекомендательных технологий, которым мы хотим поделиться с вами в этой статье.

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

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

Привет, Хабр! Мы в команде «Вычислительная семантика» в AIRI сфокусированы на исследовании галлюцинаций и решении проблем доверительной генерации. Мы учимся находить галлюцинации и бороться с ними. Большие языковые модели (LLM) вроде GPT-4 стали незаменимыми помощниками в повседневной жизни — от генерации текстов до поддержки в кодинге и ответов на вопросы. Однако у них есть ахиллесова пята: они часто галлюцинируют.

В этом посте мы разберем нашу последнюю работу Will It Still Be True Tomorrow?, посвященную тому, как на надёжность моделей влияет феномен неизменного вопроса (evergreen question)  — то есть вопроса, ответ на который не зависит ни от времени, когда вы его задаёте, ни от места, вопроса про факт, который зафиксирован в истории и не меняется от обстоятельств.

В рамках этой работы мы совместно с MWS AI собрали датасет изменяемых и неизменных вопросов EverGreenQA (открытый доступ), обучили классификатор на базе многоязычного энкодера E5, и применили его для оценки собственных знаний модели. Наши результаты показывают, что большие языковые модели чаще всего правильно отвечают на неизменные вопросы, не прибегая к помощи RAG пайплайна.