Алгоритмы *

Disclaimer: это перевод статьи, основанной на видеоэссе.

Автор — Томас Флайт

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

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

Или это инстинктивное чувство, что что‑то «не так» с «искусством», созданным ИИ, указывает на нечто более глубокое и истинное? Не сообщает ли оно нам что‑то важное о том, что такое искусство для нас, для людей? О том, что, каким бы ни было искусство, попытка создать его с помощью ИИ — это своего рода насилие?

В статье представлена параметризация всех натуральных нечетных чисел на основе приведенной системы вычетов {1, 3, 5}, которая взаимно проста с модулем 6. Показан способ описания подмножеств вычетов {1, 3, 5}, который за счет разбиения на подмножества, подпространства, уровни масштабирования и индексации внутри уровней, позволяет исчерпывающе покрыть все нечетные числа и доказывает их фрактальную структурную детерминированность.

Как-то раз моя пятилетняя дочка, вернувшись домой из детского садика, сообщила мне и моей жене, что математика — тупая штука (!). С тех пор мы не покладая рук работаем (пока что успешно), стараясь увлечь её всевозможными математическими интересностями, а теперь ещё и гордимся её успехами в математике. Одна из наших наиболее удачных находок привела к тому, что теперь дочь очень интересуется фракталами вообще. Особенно ей нравится смотреть видеоролики, где с увеличением показаны множества и оболочки Мандельброта, а вдобавок есть капусту романеско. Благодаря этому увлечению дочери, я стал больше задумываться о фракталах, а также о том, как они соотносятся с особенно волнующей меня темой — искусственными нейронными сетями.

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

Да, я знаю, тема кажется избитой. Но когда я впервые осознала, что одни и те же принципы работают на всех уровнях, от крошечного L1-кэша до распределенного Redis-кластера — это было похоже на инженерное просветление. Предлагаю и вам пройти этот путь вместе со мной.

За год ИИ-Ученые выросли из демо в рабочие инструменты: одни вынимают законы из данных, другие эволюционируют код под бенчмарки, третьи связывают литературу и анализ в проверяемые отчеты. Разбираем 3 характерных подхода: SR-Scientist, DeepEvolve и Kosmos, для чего они нужны и в чем различны. И почему именно вокруг Kosmos столько шума.

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

На сегодняшний день алгоритмические задачи встречаются не только в FAANG. Многие компании и на отечественном рынке всё чаще вводят дополнительный алгоритмический этап на собеседовании – и знание алгоритмов становится отличным «плюсиком» не только при трудоустройстве, но и в решении повседневных задач. Взглянем подробнее на эти паттерны.

В этой статье я расскажу про свой эксперимент: я создал в Unity симуляцию радиоуправляемых машинок, которые эволюционируют. «Мозгом» каждой машинки является электронная схема. Я заставил эти схемы мутировать(случайно меняться) и скрещиваться(обмениваться частями), чтобы создавать новые модели машин и улучшать их. Его «интеллект» и поведение меняются в зависимости от того, сколько блоков онa успешно поднимает.

Недавно мы переделали наши внутренние инструменты, визуализирующие компиляцию JavaScript и WebAssembly. При работе оптимизирующего компилятора Ion мы теперь можем генерировать интерактивные графы, демонстрирующие, как конкретно обрабатываются и оптимизируются функции.

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

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

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

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

Совсем недавно – в августе текущего года – Институт стандартов и технологий США NIST выпустил стандарт NIST SP 800-232 [1], описывающий четыре низкоресурсных криптографических алгоритма на базе семейства алгоритмов Ascon:

· алгоритм аутентифицированного шифрования с присоединенными данными Ascon-AEAD128;
· три алгоритма хеширования: Ascon-Hash256 (классическая хеш-функция), Ascon-XOF128 (хеш-функция с переменным размером выходного значения) и Ascon-CXOF128 (хеш-функция с кастомизацией и переменным размером выходного значения). 

Предыдущий опыт показывает, что криптографические стандарты США после их принятия обычно широко используются во всем мире, поэтому данный документ может представлять значительный интерес и достоин детального разбора (краткий обзор стандарта NIST SP 800-232 уже был опубликован на Хабре ранее здесь), который я и предлагаю вам в двух частях в этой (и следующей) статье.

На многих биржах остаются монеты маленькой и средней капитализации - периодически их пампят. В хороший день 10-15 монет могут дать рост больше чем на 50%.

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

Эпоха больших языковых моделей (LLM, Large Language Model) снова и снова ставит перед нами вопрос о том, что отличает великую прозу от просто хорошей.

Отвечая на этот вопрос, обычно довольно расплывчато рассуждают о «стиле»: о неуловимом, мистическом качестве, которое свойственно таким людям, как Хемингуэй, Вулф или Вудхаус. Это — как один судья сказал о порнографии: мы узнаём её, когда видим. Мы способны узнать стиль текста, мы даже можем его сымитировать. Но можем ли мы его измерить? Можем ли мы создать для него производственную функцию?

Большинство современных LLM выдаёт хорошие тексты. Даже — грамотные. Но — тексты это стандартные. Стилистически безвкусные. И что — так будет всегда? Этот вопрос меня тревожит с тех самых пор, как я начал пользоваться LLM. Они созданы из слов, и при этом не могут как следует словами пользоваться. Почему мы не способны создать ИИ, который пишет хорошие тексты?

Тут совершенно естественным образом возникает такой вопрос: можем ли мы задать какие-то (или хоть какие-нибудь) количественно измеримые, эмпирические «сигнатуры» хороших текстов? Если это возможно — значит такие вот «характеристики» можно использовать для обучения моделей, которые смогут лучше писать. Так случилось, что этот вопрос завёл меня, так сказать, в кроличью нору, породив проект, который я называю Horace.

Я выдвинул гипотезу, в соответствии с которой, приближённо говоря, волшебство текстов, написанных людьми, уместно сравнивать не с понятием «статистическое среднее», а с понятием «дисперсия». Полагаю, эту мысль нельзя назвать строгим правилом, но она, как мне кажется, ближе к истине, чем альтернативные идеи. Магия человеческих текстов заключается в осознанном, целенаправленном отступлении от ожидаемого. Речь идёт о ритме (rhythm), о темпе (pace), о музыкальности (cadence) текста.

Для разработчиков ПО diff — привычный способ представления изменений: мы используем diff для сравнения различных версий одного файла (например, во время ревью кода или когда мы пытаемся понять историю файла), для визуализации разницы между непроходящим тестом и его ожиданиями или для автоматического применения изменений к файлам исходников.

В каждом моём профессиональном и личном проекте рано или поздно требовался diff для визуализации изменения или применения патча. Однако меня никогда не устраивала ни одна из свободно доступных библиотек diff. В профессиональной деятельности это никогда не вызвало особых проблем, но в личных проектах я копировал и модифицировал из проекта в проект собственную библиотеку. Однажды я рассказал об этом коллеге, и тот наставил меня на путь публикации моей библиотеки на Go (порта библиотеки на C++, которую я раньше копировал и модифицировал). И оказалось, что я сильно недооценивал то, насколько близка моя библиотека к возможности публикации!

Как бы то ни было, я опубликовал её и узнал много нового об алгоритмах diff. Библиотеку можно найти по адресу znkr.io/diff, а в этой статье я расскажу о своих открытиях. Я ещё не завершил освоение, поэтому планирую дополнять статью в процессе изучения.

Автор: Шерстнев Павел

Что если модель могла бы проектировать саму себя? Подбирать архитектуру, параметры, операторы — без эксперта, без ручного тюнинга и десятков итераций? Эволюционные алгоритмы позволяют это сделать. Я собрал их в рабочую технологию — Thefittest — open-source проект, где эволюция используется для построения и оптимизации моделей машинного обучения.

Привет, Habr! В этой статье я хочу поделиться своим проектом — Telegram-ботом, который автоматизирует торговлю на бирже Bybit на основе сигналов из специализированного канала. Бот парсит сообщения из Telegram-канала @TokenSplashBybit, извлекает информацию о предстоящих "token splash" (это события, когда новые токены добавляются на биржу с возможностью получения airdrop), и открывает длинные позиции (лонги) в момент результата.

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

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

Всё было сделано на хранимых процедурах MySql и работает как часы без всякого обслуживания уже 14 лет.

Я верил, что с приходом ИИ жизнь разработчика превратится в сказку. ИИ будет писать код, а я — придумывать фичи и строить продукт. В реальности я полдня пишу промты, а еще полдня трачу на правки за Copilot. Быстрее написать код самому.

Почему промты занимают так много времени и как компании учат сотрудников использовать ИИ, чтобы он не портил никому жизнь — рассказываю в статье.

Автономный транспорт давно вышел за пределы закрытых полигонов и футуристичных историй. Он уже работает и приносит пользу бизнесу и людям. В России тягачи Navio два года возят реальные грузы коммерческих клиентов по трассе М-11 «Нева». А в США, Китае или Европе можно совершить поездку на роботакси. Тем не менее, восприятие технологии остается противоречивым. Видео, где автомобиль без водителя в салоне не может выехать с кольцевого перекрестка или воспринимает человека в майке с надписью STOP как команду к действию, усиливают скепсис и снижают доверие к результатам разработчиков. Почему компании, которые работают над технологией с 2009 года [больше 15 лет], не смогли добиться ее стабильной работы.

Классический подход в разработке автономного транспорта

Алгоритмический подход признан классическим в разработке автономного транспорта. Логическая архитектура построена на основе последовательности действий водителя за рулем:

восприятие окружающего мира — набор сенсоров (радары, лидары, камеры);

определение местоположения — карты, модуль позиционирования, сенсоры;

предсказывание действий других объектов вокруг — алгоритмы на базе кинематической составляющей и модели динамики объектов;

планирования пути — руководство к действию или свод правил, основанный на правилах дорожного движения (ПДД);

управление — модуль внутри автомобиля приводит его в движение. 

Этот код пишется 15 лет и никогда не будет завершен 

Несовершенность классического подхода обнаружилась на этапе планирования пути. При алгоритмическом подходе условия прописываются вручную (what-if сценарии). Автономное транспортное средство принимает решение на основе типа объекта (автомобиль, пешеход, др.), дальше добавляются такие условия, как состояние дорожного покрытия, погода, светофоры, другие объекты. Все это ведет к экспоненциальному росту проверок вложенных условий. Обладая достаточным парком автомобилей, за несколько лет разработчик может закрыть самые часто встречающиеся сценарии на дороге. Следующие несколько лет проездов выловят более редкие случаи и укрепят базу. Но остается открытым вопрос, что делать с уникальными ситуациями, как человек в футболке с надписью STOP или объездом препятствия в месте, где обгон запрещен разметкой. Невозможно вручную прописать все условия заранее, мир сегодня слишком непредсказуем. Такой подход не позволит масштабировать технологию и обеспечить ее стабильность на 100%, особенно в условиях города. Такая бесконечность сценариев называется Long Tail.

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

Все знают о Leetcode — его можно любить, ненавидеть, презирать или даже бояться, но равнодушным точно не останется никто.

Эта статья — впечатления о моём 600-дневном марафоне на этой платформе, динамике моих скилов и ответе на главный вопрос «надо ли решать там задачи?».

Все было спокойно, пока мы с другом не заключили спор — сможем ли мы решить 100 задач до конца 2023 года? А это было 50 задач всего за 1 месяц — декабрь.

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

Челлендж в 100 задач оказался достаточно легким — Новый год мы встречали уже с круглым числом выполненных задач в профиле. Так быстро мы решили не останавливаться — Покоренная вершина стимулировала покорить новую — 200 задач к началу лета (за 5 месяцев).

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

24 февраля 2024 в течении недели Leetocde предлагал неплохие и не очень сложные задачи на дейли челлендже, и у меня случайно получился стрик в районе 10 дней подряд.

Сбивать стрик было как‑то жалко — это же целых 10 дней. Так и началась долгая история в 600 дней...

1 августа 2012 года, торговая фирма Knight Capital развернула новую версию торгового ПО SMARS. Из‑за ошибки при развертывании на одном из восьми серверов осталась старая тестовая версия кода, из‑за чего торговый робот начал неконтролируемо рассылать миллионы ошибочных заявок на покупку и продажу акций. Этот процесс длился около 45 минут и привел к убыткам в размере примерно 440 миллионов долларов — почти весь капитал компании.

​Ключевая проблема мониторинга состояла в том, что система PMON (Position Monitor) полностью полагалась на ручной мониторинг: она не генерировала автоматических оповещений и не выделяла превышение лимитов. Трейдеры Knight видели аномальную активность в логах, но не понимали контекст: