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

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

В моём информационном пузыре больше всего ребят, занимающихся 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 и других, которых я почему-то хочу занести в ресёрчеры.

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

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

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

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

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

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

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

Часто вижу кошмарно неэффективные подсчёты 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

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

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

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

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

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

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 и вычитает её на следующем шаге.

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

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

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

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

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

Limit Order Book, он же стакан — механизм биржи, объединяющий покупателей с продавцами.

Исходя из названия, он собирает в себе лимитные заявки. У каждого ордера есть такие параметры как:
- side — всё просто, покупка или продажа.
- quantity — количество актива в заявке.
- price — очевидно, цена.
Про Time in Force и скрытые ордера чуть позже.

Когда мы хотим купить какой-то актив здесь и сейчас, мы отправляем market order на биржу, где её matching engine исполняет его, сопоставив с лимитными ордерами.

Приоритетность исполнения одних лимитных ордеров перед другими зависит от логики конкретного matching engine, но есть некоторые общие правила:
- Price–Time Priority — сначала метчим ордера с лучшей ценой, но если несколько стоят по одной цене, то из них выбирается тот, который был выставлен раньше.
- Price–Pro-Rata Priority — исполняем по лучшей цене, но если на этой цене стоит несколько крупных ордеров, то метчим их пропорционально их объёму.
- Size–Time Priority — на одинаковой цене между ордером с большим объёмом и выставленным ранее выберем тот, у кого больший объём.
- Visibility Priority — Visible > Iceberg > Hidden.

Про видимость ордеров:
- Visible — просто ордера, полностью видны всем участникам рынка.
- Iceberg — ордера, видимые в стакане лишь частично. Когда их заданная видимая часть исполняется, биржа обновляет ордер с новой видимой частью, которая будет максимум заданного в параметрах ордера размера, пока он не исполнится полностью. При обновлении ордер может терять приоритет по времени.
- Hidden — в ордербуке не видны, но трейды по ним исполняются. Можно заметить в виде сделок, которые прошли по непойми откуда взявшейся цене между best ask / best bid.

Time in Force:
- GTC (Good Till Cancelled) — ордер остаётся в стакане, пока его полностью не исполнят или пока пользователь не отменит его.
- IOC (Immediate Or Cancel) — ордер должен быть исполнен немедленно хотя бы частично; всё неисполненное сразу отменяется. Забирает ликвидность, но в отличие от простого Market ордера ставит ограничение на цену, а не просто исполняется по доступной цене.
- FOK (Fill Or Kill) — жёсткая версия IOC. Ордер должен быть исполнен полностью и сразу; если это невозможно — он отменяется полностью.

Поправляйте, может где ошибся