Голография, как метод восстановления волнового фронта, может быть использована не только для записи и восстановления трехмерных изображений объекта. Фундаментальное свойство голографии – делимость голограммы (возможность восстановления полного изображения объекта по фрагменту голограммы) – представляет интерес для помехоустойчивого кодирования произвольных сообщений. Свойство делимости может эффективно использоваться при передаче информации по каналу связи с большим уровнем шума и/или при недостаточном уровне сигнала, когда могут быть искажены или утрачены большие фрагменты сообщения.

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

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

Кодирование информации (моделирование голограммы) и декодирование (восстановление цифрового массива) требует достаточно больших вычислительных ресурсов. Сложность вычислений можно значительно сократить, если использовать для представления исходного блока цифровой информации не двоичный, а единичный позиционный код. В этом случае оптическим объектом, для которого строится голограмма, является точечный источник на черном фоне, а информация закладывается в координаты точки на поле объекта. Результатом кодирования является простейшая голограмма – зонная пластинка Френеля, координаты центра которой несут кодируемую информацию.

▍ Спецификация испытуемого SSD

CookBook maven plugin. CDI, отладка и тестирование. Цель статьи - рассказать об опыте разработки плагина.

В прошлой статье я описывал как построить сетевую часть самодержавного сервера, пора принести в него что-то отдаленно разумное. Это руководство описывает весь процесс: от подготовки хоста Proxmox и настройки LXC-контейнера до поиска, конвертации и запуска embedding-моделей (на примере BAAI/bge-large-en-v1.5) с использованием Intel GPU для работы модели. Но будет легко запустить не одну модель или полноценного чатбота на этой основе. Главное, что будет ясно как использовать даже простое имеющееся железо домашнего сервера для этого.

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

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

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

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

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

Основная прелесть использования ПЛИС, на мой взгляд, состоит в том, что разработка аппаратуры превращается в программирование со всеми его свойствами: написание и отладка кода как текста на специализированных языках описания аппаратуры (HDL); код распространяется в виде параметризованных модулей (IP-блоков), что позволяет его легко переиспользовать в других проектах; распределенная разработка обширным коллективом разработчиков с системой контроля версий, такой же, как у программистов (Git); и, как и в программировании, ничтожно низкая стоимость ошибки.

Последнее очень важно, так как если при разработке устройства классическим методом разработчик несет вполне существенные затраты на сборку и производство изделия, и любая схемотехническая ошибка или ошибка трассировки печатной платы — это всегда выход на очередную итерацию и попадание на деньги, то при работе с ПЛИС ошибки ничтожны по своей стоимости и легко устранимы. И даже если в серийном изделии обнаруживается ошибка, то её во многих случаях можно устранить очередным апгрейдом прошивки «в поле» без замены изделия. Короче, с приходом ПЛИС разработка цифровой аппаратуры все больше и больше выглядит как программирование, а это, помимо всего прочего, существенно понижает порог вхождения в тему, и все больше программистов становятся разработчиками «железа». А новые люди, в свою очередь, приносят с собой в индустрию новые подходы и принципы.

В этой статье я хочу поделиться своим небольшим опытом «программирования» микросхем ПЛИС и тем, как я постепенно погружался в тему ПЛИСоводства. Изначально я собирался написать небольшую заметку про открытый тулчейн для синтеза Yosys. Потом — про язык SpinalHDL и синтезируемое микропроцессорное ядро VexRiscv, на нём написанное. Потом — про замену микроконтроллеров микросхемами ПЛИС на примере моей отладочной платы «Карно». Но в процессе я погрузился в историю появления Hardware Description Languages (HDL), и когда я начал писать, Остапа, как это часто бывает, понесло... В общем, получилось то, что получилось.

А еще эту статью можно рассматривать как глубокое погружение в то, что происходит вот на этом новогоднем видео.

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

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

Cейчас, когда связь с внешними сервисами работает с перебоями, а самым стабильным международным способом созвониться теперь является, внезапно, Steam, VoIP которого точно не блокируется, возникает резонный вопрос: а как коммуницировать хотя бы в рамках собственной компании? Особенно с учетом того, что Discord давно и надежно заблокирован, Slack с рынка ушел, а популярные публичные мессенджеры замедляются или рискуют отправиться в бан? Решение очевидно: поднимать собственные текстовые и VoIP-сервера, о чем мы и поговорим в статье на примере связки Matrix и Jitsi.

Когда мы пишем запрос, СУБД делает гораздо больше, чем просто ищет данные. Она оценивает десятки сценариев выполнения, сравнивает стоимость операций и выбирает оптимальный путь к результату. От этого выбора зависит, будет ли запрос выполняться секунду или минуту. Почему одни системы находят лучший план, а другие выстраивают менее эффективный алгоритм? Попробуем разобраться, как планировщики СУБД принимают решения и что определяет их эффективность.

На сдачу от пятерочки покупаем ПК на Ryzen AI 9 HX 370 c ОЗУ от 64Гб, устанавливаем LM Studio, скачиваем модель qwen3-coder-30b, в mcp.json указываем путь до нашего mcp-server и вуаля: можно попросить ИИ поискать информацию в интернете или среди pdf, docx, xlsx, pptx файлов в локальной папке.
А как написать этот инструмент развязывающий руки ИИ, мы сейчас с вами и узнаем...

Конец осени, первый снег и идеальный момент, чтобы заглянуть под капот системного софта. 22 ноября в Москве соберем системных инженеров, исследователей и разработчиков, чтобы обсудить, как устроены компиляторы, ядро Linux и драйверы. Митап разделен на два потока: С++ и C/Linux kernel. Регистрируйтесь и подключайтесь — офлайн или онлайн.

MCP без воды и шаблонного кода на практике: разбираем протокол, поднимаем сервер, тестируем через Inspector и учим LLM торговать через Finam API. Разберёмся, когда MCP выгоднее «обычных функций», как изолировать интеграции и упростить отладку инструментов.

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

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

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

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

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

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

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

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

Приветствую, Хабр!

Так много уже было сказано о стандарте 10BASE-T1L, но я не нашел ни одного решения (я именно про схемотехнику, которую можно применить в своем устройстве). И вот, как по заказу, потребовалась реализация передачи данных на длинные расстояния. Как альтернатива рассматривались, конечно, DSL и RS-485, но так как гнать нужно звук, я решил попробовать 10BASE-T1L.

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

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

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

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

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

Когда отлаживаешь программу, речь идет про использование отладчика в студии или другой IDE, то почти всегда имеешь дело с точками останова (breakpoint, бряками) — механизмом, когда выполнение программы приостанавливается, чтобы можно было заглянуть внутрь и понять, что происходит. Точек останова есть всего два основных типа, программные и аппаратные, а остальные все сделаны на их основе. Эти два базовых типа могут вести себя похоже, но устроены по-разному.

Программные точки останова — это то, с чем сталкивается каждый разработчик, когда вы ставите красную точку в среде разработки (в основном я использую большую студию) или используете команду bp под WinDbg. В этом случае отладчик просто подменяет один байт машинного кода в нужной инструкции на команду int 3. Это специальная инструкция для вызова прерывания отладки (Debug Interrupt), имеет машинный код 0xCC и говорит процессору: “Остановись, я хочу передать управление отладчику”, соответственно когда выполнение доходит до этой инструкции, срабатывает прерывание, и управление передаётся в отладчик. Отладчик "просыпается" и видит, что программа остановилась из-за исключения EXCEPTION_BREAKPOINT , возникшего по конкретному адресу, проверяет свой внутренний список точек останова и находит ту, которая была установлена по этому адресу.

Аннотация. В работе предлагается новая архитектура искусственного перцептрона — SAAR-Perceptron (Self-Recursive Associative Adaptive Reservoir Perceptron), развивающая классическую модель Розенблатта (S–A–R). Ключевая особенность архитектуры заключается во введении ассоциативного слоя с саморекурсивным отображением (A→A), формирующего динамический граф признаков. В отличие от традиционных рекуррентных моделей, эти связи не обучаются, что обеспечивает устойчивую динамику и выполняет роль адаптивного резервуара, расширяющего пространство признаков.

Ассоциативный слой использует пороговую активацию, эквивалентную ReLU, что позволяет выделять только положительные реакции. Однако обучение осуществляется не на «сырые» выходы, а на их нормализованные значения, что адаптирует величину корректировки весов к относительной значимости каждого признака. Такой механизм предотвращает доминирование отдельных элементов и обеспечивает сбалансированное обучение.

Процесс обучения в перцептроне SAAR реализован без использования градиентных методов. Для связей S→A применяется стохастическое правило коррекции, расширяющее принцип Розенблатта: активные элементы подавляются, если их активация увеличивает ошибку, и возбуждаются, если их возбуждение потенциально уменьшило бы ошибку. Важную роль играет энтропийный критерий обновления весов: вероятность коррекции пропорциональна бинарной кросс-энтропии активаций, что позволяет выделять наиболее информативные признаки. Такой подход напоминает механизм отбора в генетических алгоритмах, где «побеждает» наиболее информативный элемент. Для связей A→R используется простое локальное корректирующее правило, а вклад ассоциативных элементов оценивается через информационный выигрыш; нерелевантные элементы исключаются из работы.