Алгоритмы *

TL;DR: Sentry дедуплицирует backend-ошибки по хешу (error class + top stack frame + module). Для UI-багов этот рецепт ломается — у expect(button).toBeVisible() нет stack frame в продуктовом смысле, есть локатор + assertion + URL. В webtest-orch я собрал composite SHA-256 fingerprint из (normalized_selector | assertion type | error class | URL template | message[:80]) с тремя rules нормализации (:nth-child, UUID, /users/123 → /users/:id). Это даёт стабильный 8-hex BUG-id который выживает прогоны и даёт diff new / regression / persisting / fixed без БД и embedding’ов.

Привет, Хабр.

Сегодня познакомим вас с самой долгожданной новинкой апреля — книгой «Алгоритмы на языке Go», которую мы успели выпустить в продажу 30 числа.

Многие умеют вызывать loss.backward() в PyTorch, но не всегда понимают, что именно происходит под капотом. Как сеть вычисляет, какой из миллионов весов нужно изменить? В этой статье мы развеем магию обратного распространения ошибки (backprop). Разберем алгоритм на простых аналогиях с заводским конвейером, вспомним школьное правило дифференцирования и, чтобы закрепить понимание, напишем свой микро-фреймворк для автоматического вычисления градиентов на чистом Python с нуля.

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

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

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

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

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

Nonce Observatory: как превратить цифровые подписи в систему наблюдаемых nonce-инвариантов

Большинство историй про ECDSA/Schnorr nonce звучит одинаково: “повторили nonce — потеряли ключ”. Но реальные дефекты часто тоньше: короткие nonce, частичная утечка битов, смещение, recurrence, window-locality, prefix-семейства, ошибки в multi-signature контексте.

Мы собрали исследовательскую систему Nonce Observatory — не “кнопку взлома”, а forensic framework для анализа слабых nonce-структур в:

ECDSA • Schnorr/BIP340 • MuSig2/BIP327

Что внутри:

protocol-valid bridges affine hidden-nonce families HNP / lattice routes Q-LLL + fplll same-case checks AI sidecar на gpt-oss-20b-TurboQuant-MLX-8bit exact evidence / redaction / claim boundaries full-system audit

Главный принцип системы:

сигнал ≠ восстановление; кандидат ≠ приватный ключ; claim принимается только если d·G == public key.

В статье расскажу:

— что такое HNP и зачем он нужен для ECDSA; — как подписи превращаются в affine nonce geometry; — почему BIP340 и MuSig2 требуют protocol bridge; — как Q-LLL используется как lattice backend, а не “магический oracle”; — зачем нужен AI sidecar и почему AI не имеет права принимать d; — как мы дошли до full-range controlled HNP recovery без nonce brute force; — почему full-system audit важнее красивого demo.

Это статья не про “сломать Bitcoin”. Это статья про инженерную дисциплину в криптографической форензике: наблюдаемость, воспроизводимость, проверяемость и честные границы заявлений.

Привет, Хабр. Меня зовут Алексей, я C#-разработчик. В этой статье хочу рассказать о своём дипломном проекте очень запавшем мне в душу, который я делал на тему обработки изображений, GIS и дистанционного зондирования Земли. Даже спустя годы мне интересна данная тема и она по-прежнему остаётся очень перспективной в различных отраслях.

Идея была в том, чтобы собрать небольшое настольное приложение, которое умеет работать с реальными спутниковыми данными: Landsat 8, Sentinel-2 и AVIRIS. То есть открывать не готовую RGB-картинку, а набор спектральных каналов, собирать из них естественные и псевдоцветные изображения, считать растровые индексы, выделять эталоны прямо на снимке, классифицировать пиксели, сегментировать изображение и пробовать более исследовательские вещи вроде EMD-разложения.

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

Это статья написана дипломированным инженером‑конструктором (по первому образованию), разработчиком систем автоматизированного проектирования (САПР) и (по известным причинам) вынужденно ставшим сертифицированным специалистом по системам офисного документооборота.

С развитием интернета и всеобщей массовой коммуникации сфера интересов разработчиков сместилась в область запросов потребителей развлекательного контента. И это весьма прискорбно. А тут ещё ИИ (Ai) подоспел, и все окончательно забыли о действительно полезных задачах автоматизации инженерного проектирования. Справедливости ради стоит отметить, что есть ещё задачи бизнеса, тоже весьма популярные в определённых кругах. А также математическое моделирование, инженерная графика, различные узкоспециализированные приложения.

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

Лично я не такой уж противник того, что нынче называют нейросетевыми технологиями и ассоциируют с каким‑то искусственным интеллектом. При использовании без претензий на панацею от всего ранее не реализованного, почему бы и нет — штука полезная и облегчает многое. Но не генерацией текстов, видео и картинок, или распознаванием образов и принятием управленческих решений ограничиваются потребности общества. Когда восхищаются возможностями роботов, забывают, что это не только электронные мозги, но сложнейший и точнейший механизм. Возможно, тех, кому нужно решать более приземлённые задачи, не так уж и много, но они есть. Всё чем пользуются зависающие в социальных сетях или игроманы — создано умом инженеров самых разных специальностей (в том числе ИТ‑специалистов).

Мы привыкли воспринимать LLL-редукцию как «чёрный ящик»: подали целочисленный базис, получили редуцированный базис, проверили результат. Но что, если сделать процесс редукции наблюдаемым?

В статье рассказываю о Q-LLL — exact-certified алгоритме семейства LLL, где классическая корректность сохраняется, но выбор редукционных действий управляется квантизированной Gram/Lovász-геометрией.

Главная идея:

approximate geometry observes, exact arithmetic decides, certificate proves.

Q-LLL не заменяет fplll и не меняет Lovász-критерий. Вместо этого он добавляет новый слой: quantized Gram/Lovász oracle, exact gate, fair scheduler и proof-carrying certificates, которые можно независимо проверить.

В статье разбираю:

— почему обычного sequential LLL недостаточно для больших семейств lattice-вариантов; — что такое Lovász slack и как из него получается карта геометрических дефектов; — как работает quantized Gram/Lovász oracle; — почему approximate слой не принимает математических решений; — зачем нужны exact-сертификаты и independent verifier; — как Q-LLL становится lattice-core для nonce-observatory; — какие результаты уже получены и какие ограничения честно остаются.

Это не статья про «магическую кнопку» и не claim про универсальное превосходство над fplll. Это попытка показать новый взгляд на LLL: как на управляемый, наблюдаемый и проверяемый процесс, где квантизированная геометрия направляет редукцию, а exact-арифметика остаётся источником истины.

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

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

Один аналитический запрос способен испортить p99 latency всего OLTP-трафика — на время, пока горячий рабочий набор не прогреется заново с диска. Это cache pollution, и с ним рано или поздно сталкивается любая СУБД с честным LRU.

Разбираем, как мы решили эту проблему в нашем OLTP-движке: почему выбрали Clock-sweep вместо LRU, как BufferRing изолирует полные сканы от горячих данных, и почему no-steal — это не стилистический выбор, а требование корректности recovery. С кодом, инвариантами и честными оговорками про то, что ещё не сделано.

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

На локалке всё летает, а на проде ложится замертво? Дело в масштабировании. Big O — это не скучная теория для алгоритмических собеседований, а реальный инструмент, чтобы ваш код не «убивал» сервера. В этой статье я на простых примерах и без зубодробительной математики объясню, как оценивать сложность своих алгоритмов. От до — только суть, примеры на Python и немного здоровой иронии над медленным кодом.

Я много думал о том, как проектируются промежуточные представления (IR) для компилятора. В этом посте я поделюсь с вами некоторыми идеями, к которым я пришёл, и поясню, почему считаю их важными.

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

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

За одни сутки и шесть долларов алгоритм самостоятельно провёл почти две тысячи экспериментов на российском фондовом рынке.

Он не ждал команды. Сам формулировал гипотезу, сам писал запрос к данным, сам оценивал результат — и сразу задавал следующий вопрос. Цикл за циклом, пока мы спали.

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

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

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

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

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

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

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

Привет, Хабр.

У меня бывают неожиданные заказы, из неожиданных сфер на фрилансе. Недавно писал про то как прилетел большой проект по классификатору фоток. А теперь пришел запрос на реверс! Не могу вдаваться в подробности проекта - много конфиденциального - но я расскажу про конкретный разбор одного .dll файла. Открыл Ghidra, кликнул на функцию, включил декомпилятор - и передо мной встала стена.

Не метафорическая стена. Прям реально стена!

И вот пока я эту функцию ковырял, переименовывал переменные, ходил по ссылкам, открывал соседние функции, смотрел строки, в какой-то момент меня щёлкнуло.

Это же сканворд.

В этой статье дана инструкция для выполнения фазовой синхронизации в FMComms5 от Analog Devices и реализации метода пеленгации, использующего эту функцию. Оценочная плата FMComms5 обеспечивает высокую точность фазовой синхронизации. В этой статье рассказывается, как выровнять фазы двух приемопередатчиков AD9361 с помощью специальной программной библиотеки libad9361, созданной на основе инфраструктуры ввода-вывода libiio. Фазовое выравнивание необходимо для многих радиолокационных систем, таких как пеленгаторы и когерентные системы MIMO.

Исходный код GNURadio, на котором основан этот пример, был изначально разработан доктором Шрикантом Пагадараи и доктором Трэвисом Коллинзом при финансовой поддержке компании Ettus Research [1]. Недавно доктор Коллинз портировал его на платформу FMComms5, добавив документацию. В настоящее время код доступен по адресу github.com/tfcollins/gr-doa в ветке adi. Этот код распространяется по лицензии GPL3. Реализация на FMComms5 обеспечивает такую же производительность, как и предыдущая работа [1]. Технический документ из [1] также был дополнен авторами оригинальной статьи информацией о FMComms5 и стратегии его внедрения.