Classical Vlad

Fireship выкатил видео про x402 — протокол internet-native криптовалютных платежей.

Мне очень нравится такая идея, и здесь это реализовано удобнее всего, что я видел.
Протокол не зависит от какого-то конкретного блокчейна, работает по HTTP.
На запрос пользователя можно ответить статусом 402 и страничкой с оплатой. Кому-то может понравиться, что это открывает AI-агентам доступ к использованию денег.

x402 решает кучу проблем по типу нужды в мониторинге блокчейна для подтверждения оплаты, защиты от повтора и связи платёж–контент, что в том числе упрощает UX.
Большую часть этой работы берёт на себя Facilitator — централизованный сервис подтверждения транзакций. В официальном SDK по умолчанию используется Facilitator от Coinbase — разработчиков протокола (легко поменять на другой при конфигурации). Сам протокол сфокусирован на USDC в EVM/SVM сетях (точнее его реализация, но этим не ограничивается).
Поддержку произвольных токенов планируют завезти в Q2 2026.

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

Explorer проектов, принимающих платежи через систему: x402scan

Kahan summation

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

Корень проблемы лежит в представлении чисел в памяти. По стандарту IEEE 754 число с плавающей точкой представляется знаком, экспонентой и мантиссой. Со знаком всё понятно (отрицательное или положительное число), экспонента, грубо говоря, показывает, где ставить точку в числе, мантисса представляет собой значащие цифры числа.

При обычном суммировании может не хватить точности мантиссы (при fp32 она занимает 24 бита).
Простой пример:

a = np.array([1e8, 1.0, 1.0, -1e8], dtype=np.float32)
print(np.sum(a))

Выведет: 0.0
на единички не хватило 24 бит, потому что log_2(10**8) — это примерно 26.5

Тут на помощь приходит Kahan Algorithm:

def kahan_sum(arr):
    total = np.float32(0.0)
    compensation = np.float32(0.0)
    
    for val in arr:
        y = val - compensation
        new_sum = total + y
        compensation = (new_sum - total) - y
        total = new_sum
    
    return total

После этого сумма будет правильной: 2.0

Почему это работает?
При обычном сложении ошибка округления теряется безвозвратно.
Алгоритм Кахана же сохраняет эту ошибку в переменной compensation и вычитает её на следующем шаге.

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

а если вкратце: была взята всеми известная статья Стоикова (на тот момент новой еще не было, поэтому старая), дальше был проведен ее бектест, который показал плохие результаты, которые наталкивают нас на очевидный недостаток стратегии - все считается исходя из текущего состояния рынка, и пока мы экзекьютимся все меняется и мы берем за щеку как и подобает на крипторынках 😄

отсюда и приходит гениальная подпивасная идея - как-то предиктить состояние рынка, чтобы сделать наши рассчеты более реальными.

Далее быстро проверяем эту гипотезу: прогоняем бектест с поменяной mid_price из будущего во всех формулах, и получаем money printer + звание бектест монки. 👍

Ну и в оставшейся части диплома я обучаю предикт модельку и получаю улучшенные результаты 😎

А теперь про меня. Я Влад, мне 18 годиков, я работаю Quantitative Researcher @ Monarq Asset Management. За жизнь щупал разработку (Python, чуть-чуть Go), классический ML, но я всегда знал, что нацелен именно на кванты.
Сначала я думал, что зарабатывать на бирже алгоритмами очень легко и что, когда я напишу что-то своё, можно будет больше не работать. Оказалось, что это намного сложнее, чем я себе представлял, но этим же и увлекательно. С 13 лет пришёл от бинарных опционов и прочей инфоцыганщины к нормальному ресёрчу в нормальной компании. Во многом это произошло благодаря сообществу better data community и людям, которых там узнал. Эти ребята вырастили меня как специалиста, в чём-то даже как человека.

Школу я как-то совсем не любил, очень уж агрессивная среда, да и интересовала меня только математика и, может быть, физика, поэтому учился по материалам, которые находил в открытом доступе: курс Карпова с основами статистики, Лекторий ФПМИ, Deep Learning School, лекции Дани Меркулова о методах оптимизации (заходите к нему, кстати). С этого момента я понял что ML люто вайбит и я хочу этим заниматься

В университет я поступил максимально рандомно, желая проверить удачу… и повезло: КНУ Шевченка считается одним из топовых украинских вузов. МехМат в моей жизни — явно кусочек чего-то светлого, где я завёл хороших друзей, с которыми не скучно.

Благодарен всем, кто со мной

PEP-0810 ты чево(((

Любители временных рядов, это для вас.

Часто вижу кошмарно неэффективные подсчёты rolling-признаков при обработке time series данных.
Например, использование rolling mean в pandas без доработок, std, корреляции, медианы и прочее туда же.

Почему?
Обычно соседние окна почти полностью пересекаются, отличаясь на 1 шаг. Пример: мы считаем суточное среднее какого-то ряда каждую минуту → тогда на первом шаге мы проанализируем промежуток [0:1440], на втором шаге — [1:1441], итого 1438 повторений вычисления. Таким образом, сложность подсчёта признака будет O(N*K), где N — количество точек в наборе данных, а K — количество наблюдений для подсчёта одной итерации фичи.

Как делать хорошо?
Решить простенькое уравнение рекурсии, в котором каждое последующее значение признака зависит от предыдущего.
То есть по-честному расписываем X_t - X_{t-1}.

Для rolling mean за k наблюдений тогда получится: mean(X)t = mean(X){t-1} + 1/n (X_t - X_{t-k})
Тогда первое значение мы по-прежнему считаем честно полным проходом, а все последующие стоят O(1).
Тогда посчитать статистику на всю историю будет стоить всего O(N), то есть в K раз дешевле.

Нюанс: накапливается ошибка, особенно с fp16 или fp32.
Чинится либо использованием fp128, если память позволяет, либо чекпоинтами, на которых мы пересчитываем значение «честно»
(в примере размер окна 1000)

Хорошо описано тут: https://laurentrdc.xyz/posts/rolling-stats.html

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

Вышло интересно. Можно таким образом найти что-то новое для себя и подписаться на интересующие темы

Интересно как форматы каналов "плывут" от одного к другому: блоги компаний, конкретных людей из ML, о количественных финансах, мемные каналы

Сама тулза, конечно, не была задумана как что-то более чем на 1 вечер, но если захотите поиграть, то вот ссылка:
https://github.com/VladKochetov007/TelegramNetwork

А вообще полезно почитать Max Dama on Automated Trading

Окей, тогда про квантиков.

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

В моём информационном пузыре больше всего ребят, занимающихся High-Frequency Trading — использованием краткосрочных аномалий в цене для маленького заработка на каждой сделке при огромном количестве этих самых сделок. Краткосрочные понимают все по-разному, но я определяю это как торговлю в секундах–миллисекундах–микросекундах. Также существует Mid- и Low-Frequency — понимают опять же по-разному: у кого позиция на часы — это уже Low-Frequency, а у кого и один день ещё Mid-Freq.

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

По работе всё ОЧЕНЬ зависит от компании. Зависит от процессов, которые успели отладить (если, конечно, успели). Где-то ресерчер сам перепишет свои стратегии под продакшн-контур, где-то они сразу пишут в подходящем формате.

- Quantitative Developer. Человек на инфраструктуре. Пишет бэктесты, шустрое исполнение, походы в БД, коннекторы к биржам и провайдерам данных. Обычно на C++/Rust по причине критичности производительности.

- Quantitative Researcher (это я). На C++ можно не писать, ведь задача этих ребят — находить закономерности и полезные признаки, на которых можно системно зарабатывать. Почти всегда полностью Python. Всегда линал + статы, эконометрические модели, если не применять, то хотя бы знать и думать о них полезно (хоть сколько-то учит думать о рынке). Иногда машинное обучение, которое выглядит просто в готовом варианте, но совсем неочевидно, пока эти системы придумаешь.

Это такие два основных типа, которых видел везде. Некоторые компании заводят ещё и:

- Quantitative Trader. Работа с готовыми решениями. Тоже может проверять интересные гипотезы. Мониторит запущенные стратегии, переливает деньги из стратегии в стратегию в зависимости от поведения рынка.
- Quantitative Risk Analyst. Гораздо больше во всяких инвест-банках и у ребят с долгим удержанием позиции (в HFT просто сильно больше риска в задержках, дисконнектах и микроструктуре).

Можно выделить ещё квантов в DeFi, которые анализируют on-chain данные и пишут смарт-контракты; Derivatives Pricing и других, которых я почему-то хочу занести в ресёрчеры.

Больше об этом писал Егор

Написал на сабстек разбор почему Альфа Арена это смешно, стыдно и грустно.

Распространите

https://borisagain.substack.com/p/why-alpha-arena-is-literally-the

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

1. Данные. Индикаторы представлены слишком узко: мало параметров, сами значения не отмасштабированы.

2. Логика сделок. Множество решений реализовано неряшливо. Тейк-профит, стоп-лосс (даже если их использование обосновано) и условие выхода по индикаторам не дают модели изменить позицию после открытия. Создать две одновременно по одному активу нельзя.

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

4. Нулевая статистическая строгость. Одиночные запуски, никакой воспроизводимости. Нужно проверить, что прибыль — не случайное блуждание 😶

5. Отсутствие бейзлайна. Не сравниваются с базовыми стратегиями: momentum, mean reversion, SMA cross и другими.

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


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

Channel photo updated

Channel created