#chess

Шахматы Фишера показывают реальную силу игры человека.
Вон как эвалбар скачет даже у Магнуса. Такое редко увидишь в классике, где топовые шахматисты все дебюты уже проанализирвали мощными компами и знают лучшие линии по 15-20 ходов вперёд, да и просто хорошо понимают позиции.

Ну и да, красивый мат мог бы получиться.

https://www.youtube.com/watch?v=2bHPMDmFWjQ

#trading #chan #featureengineering

Понравилась идея превращения cs фичей в ts путём формирования синтетического портфеля из активов, отранжированных по cs признаку. Трейдерские метрики такого портфеля уже можно (путём взятия rolling stats) превратить во временнЫе (ts) признаки.

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

https://www.youtube.com/watch?v=6J9iaXNpCN8

#finance #behavioural #deprado #trading

https://www.youtube.com/watch?v=ncqnDl1VM-c

#polars #pandas

Сравнительно недавно начал по-настоящему изучать поларс, потому что пандас уже задолбал своей неповоротливостью. Хочу поделиться некоторыми замечаниями о фреймворке.

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

Какие фишки реально понравились:

Выбор столбцов.

Можно выбирать столбцы регуляркой, выбирать все столбцы одним ключевым словом, элегантно отбрасывать столбцы (в т.ч. опять же регуляркой). Этого реально не хватает в пандас, да и sql.

df.select(pl.col("ticker", "^.*_high$", "^.*_low$"))
df.select(pl.all().exclude("^day_.*$"))

Ещё больше упрощают дело селекторы:

import polars.selectors as cs
df.select(cs.string() | cs.ends_with("_high"))

Комбинации селекторов (в терминах логики множеств) уже менее интуитивны: df.select(cs.contains("_") - cs.string()),но всё равно крайне полезны.

Апдейты Поларс.

Их фигачат каждые чуть ли не 2 недели, причём там реальная работа, помногу. Что ж это будет за зверь через год?
И даже я сам уже запостил несколько issues, которые были приняты во внимание и исправлены (самим Риччи). Внёс свой скромный вклад в дело улучшения DS библ для всех 😅.

Многопоточное исполнение. Полная утилизация CPU. Оптимизация операций над lazy фреймами.

Это просто небо и земля, по сравнению с пандасом. Никогда для работы со сколько-нибудь серъёзным набором данных (от десятка гигов) я больше не буду использовать пандас. Получается, ты платишь за машину с сотней ядер, а с pandas используешь большую часть времени одно. Более того, уже есть поддержка engine="gpu", спасибо кодерам Nvidia (под капотом использует cudf. есть ограничения на виды операций и типы данных, которые можно исполнять на gpu, но потихоньку они снимаются).

Синтаксис операций.

Можно обращаться сразу к множеству столбцов, и элегантно применять ко всем одно преобразование. Можно писать генерики для сложной работы со столбцами, которые станут известны лишь в контексте. По сравнению с пандас, паттерн применения преобразований меняется - надо стараться вынести как можно больше операций в каждый вызов контекста (select, with_columns, group_by, group_by_dynamic), потому что так они параллелятся на все ядра. В операциях не обязательно использовать существующие столбцы, можно и просто выражения над ними! Вроде df.sort(pl.col("name").str.len_bytes(),descending=True).

Rust plugins.

Если какие-то операции недоступны в нативном polars, можно вызвать питоновские функции, черезе map_groups, например, но они не будут параллелиться. Для этих случаев можно написать и скомпилировать свой плагин на Расте. Я пробовал, это сложно ) В синтаксисе этого раста чёрт ногу сломит. И не одну. Но возможность есть!

Фишка которую я пока не пробовал - streaming . Работа с данными больше RAM.

#polars #pandas

Отличия от пандас в концепциях:

Нет индексов (кроме целочисленных), осей, модификаций столбцов датафреймов inplace. Хотя на самом деле при модификации столбца фрейм в памяти не пересобирается, компилируется (быстро) лишь новый мета-объект фрейма со ссылками на те же массивы arrow.

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

Поларс различает отсутствующие значения (null) и некорректные числа (NaN, что означает "не число"), и это различие сохраняется независимо от типа данных.
В результате этого пандас преобразует столбцы с целыми числами в столбцы с плавающей точкой при появлении отсутствующих значений (хотя этого не происходит с новыми типами данных arrow, в посл версиях). Это связано с тем, что тип Integer не поддерживает отсутствующие значения. Поларс такого преобразования не делает, так как поддерживает отсутствующие значения для всех типов данных (хранит битовую маску nulls для каждого поля).

В пандас можно иметь несколько столбцов с одинаковым именем. В Поларс имена столбцов должны быть уникальными.

Странности поларса:

nan vs null. Не уверен, что это хорошая идея. Но вполне в духе строгостей поларса.

animals_pl.unique(subset="class") вместо animals_pd.drop_duplicates(subset="class")

sort(...,descending=). Зачем было отклоняться от привычного в пандас acscending? too much.

sum_horizontal() и подобные функции (вследствие отсутствия axis).

Из интересного вам глянуть:

df.to_dict vs df.to_dicts
approx_n_unique()
glimpse()
.set_sorted()
stacking vs pl.concat vs extending

#polars #pandas #codegems

Что в поларс НЕ понравилось.

Активное переименование методов от версии к версии. Это сводит с ума все AI, которые пробуешь использовать для генерации кода.

Мало примеров в доке к сложным методам типа .over и .group_by, .group_by_dynamic. Реально непонятно, как и на каких принципах оно отработает. В документации расписано слабовато.

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

И самое главное. Если у вас большие фреймы и много операций (математических, group_by), поларс отработает быстро, но гарантированно забьёт вам всю оперативку. То же сделает и пандас, но за ним неиспользованную память можно хотя бы (если повезёт) подчистить вызовом ctypes.CDLL("libc.so.6").malloc_trim(0)

Поларс же, похоже, создаёт какие-то маленькие и разбросанные в адресном пространстве арены памяти, которые таким способом не подчищаются. И вообще никаким не подчищаются, только завершением процесса. К примеру, у меня после интенсивных расчётов и джойнов фрейм в 100 гигов, а занято памяти на терабайт. И освободить её на линуксе никак нельзя, я уже и аллокаторы пробовал альтернативные типа jemalloc, tmalloc - без толку. Это я считаю большой проблемой вычислений и big data, и странно, что никого это не колышет особо. По факту сбора мусора в линукс нет, если вы не знали, ребята. По крайней мере после отработки поларса. "Спасибо" странным авторам аллокаторов памяти.

Что забавно, на винде этот вопрос решается!!! )) Используйте

def trim_windows_process_memory(pid: int = None) -> bool:
    """Causes effect similar to malloc_trim on -nix."""

    # Define SIZE_T based on the platform (32-bit or 64-bit)
    if ctypes.sizeof(ctypes.c_void_p) == 4:
        SIZE_T = ctypes.c_uint32
    else:
        SIZE_T = ctypes.c_uint64

    # Get a handle to the current process
    if not pid:
        pid = ctypes.windll.kernel32.GetCurrentProcess()

    # Define argument and return types for SetProcessWorkingSetSizeEx
    ctypes.windll.kernel32.SetProcessWorkingSetSizeEx.argtypes = [
        ctypes.wintypes.HANDLE,  # Process handle
        SIZE_T,  # Minimum working set size
        SIZE_T,  # Maximum working set size
        ctypes.wintypes.DWORD,  # Flags
    ]
    ctypes.windll.kernel32.SetProcessWorkingSetSizeEx.restype = ctypes.wintypes.BOOL

    # Define constants for SetProcessWorkingSetSizeEx
    QUOTA_LIMITS_HARDWS_MIN_DISABLE = 0x00000002

    # Attempt to set the working set size
    result = ctypes.windll.kernel32.SetProcessWorkingSetSizeEx(pid, SIZE_T(-1), SIZE_T(-1), QUOTA_LIMITS_HARDWS_MIN_DISABLE)

    if result == 0:
        # Retrieve the error code
        error_code = ctypes.windll.kernel32.GetLastError()
        logger.error(f"SetProcessWorkingSetSizeEx failed with error code: {error_code}")
        return False
    else:
        return True

и спите спокойно.

Следующая жёсткая проблема - производительность с dtype=category. Не храните паркетные файлы с этим типом данных, лучше конвертируйте в string (с compression='zstd', конечно). Иначе потом они будут склеиваться ВЕЧНОСТЬ, при любых настройках StringCache.

#polars #pandas

Запостил мини-серию о polars по сравнению с pandas:

Преимущества polars
Отличия от pandas
Недостатки polars

Заключение.

Несмотря на его сыроватость, по умолчанию теперь всегда буду использовать в своих ds-проектах polars. Людям, которые пишут pandas, наплевать на производительность, я это знаю по личному общению с одним таким человеком. Их принцип Кнутовкий, premature optimization is the root of all evil, поэтому, чтобы избежать зла, они не оптимизируют вообще. С таким кредо вам не библиотеки для работы с данными писать, уважаемые. Ну вот история вас и оставляет на обочине.

Всё же, полностью от пандас отказываться неразумно, часто там определённые вещи можно закодить быстрее в силу большей гибкости (axis) или наличия индексов. Но, как правило, я pandas в этом ключе использую лишь для маленьких фреймов. Ещё он понимает больше форматов данных. И у поларса к нему есть быстрый интероп.

Так что используйте оба, но приоритет отдавайте polars. Жизнь слишком коротка, чтобы грузить лишь 1 ядро CPU из 100 )

Из новостей: компания Риччи работает над polars cloud, это будет что-то типа dask/coiled, похоже.

#hardware #datacenters

"Современная стандартная стойка 42U с набором оборудования весит порядка 680–1150 кг, максимально допустимая масса для многих составляет около 1360 кг. При этом стойка для ИИ-серверов в полной комплектации с системами охлаждения и сетевыми модулями может весить более 1800 кг. Десятки или даже сотник таких стоек в среднем ЦОД гиперскейлера могут серьёзно повлиять на всё устройство помещения.

В Dell'Oro Group отмечает, что в машинных залах всё реже используются фальшполы, под которыми часто размещают кабели, элементы системы охлаждения и др., поскольку установка такой конструкции — довольно дорогая задача. В JLL оговаривают, что во многих ЦОД фальшполы всё же используются, поскольку они нужны для кабелей и труб, но их высота может быть уже в районе 30 см, а не традиционных 60 см. Операторы по-прежнему опасаются прокладывать трубы сверху из-за возможных протечек."

https://servernews.ru/1123925

#politics

Интересный прогноз

https://youtu.be/CkLMnnLQX7I?si=VIfsNhN2uSTmkOWl

#automl #itmo #fedot

Оказывается, ещё и Федот есть у нас )))
itmo я знаю по библиотечке отбора признаков, она не производительная, но богатая.

Пока в Федоте понравились только анимированные графики прогресса.

Надо бы его с Ламой посравнивать на реальных задачах.

https://www.youtube.com/watch?v=_hQtoVgT6Q4

#automl #autogluon #lama

Маленькая история о том, как я неудачно пытался протащить automl в проект в последний момент.

В проекте использовали библиотеки своей разработки над бустингами, я запланировал в следующем релизе добавить automl. Ролики Autogluon, где авторы долго хвастаются, какой у них хороший фреймворк, засорили мне мозг (и, видимо, отпечатались на подкорке), а с LaMa у меня был позитивный личный опыт (правда, давно).

Я вспомнил слова Саши Рыжкова, автора LaMa, с презенташки годовой давности, что на бенчмарках autogluon себя плохо показал, т.к. забивал диск моделями, которые его никто не просил сохранять. Но как-то подумал, ну за год же это глупое поведение исправили или позволили отключать, правда?

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

Ну с Ламой-то проблем не возникло? Тоже не так. ML-сервер с окружением был настроен с python 3.13, что уже казалось рискованным решением, так и вышло, LaMa на этой версии просто не пошла, а пересоздавать окружение не было возможности ) Так что до сл релиза.

Эрго: не берите последнюю версию Питона для ML проектов, берите хотя бы last-1.

#trading #options

https://www.youtube.com/watch?v=TBXYYR_uxLw

#polars

Пробую протолкнуть альтернативный аллокатор в Поларс. Ну или хотя бы просто напомнить про проблему.

https://github.com/pola-rs/polars/issues/23128

#astronomy #physics

https://youtu.be/5LmVZcbsNjg?si=iKnDx-X80ni88z9f

#trading #go

https://polygon.io/blog/case-study-algorithmict-trading-with-go

"Creating an automated trading tool has been nothing short of an adventure that crosses multiple domains, from finance and programming to data analytics. Through this project, I have come to learn and appreciate the complexity of the stock market and how hundreds of billions of dollars change hands each day. There are countless trading strategies out there and having your own platform to play around with them is incredibly cool. Once you have a system like this you cannot easily go back to a normal broker since you feel blind. I wanted to share of the key lessons out of all this:

Understanding Abstractions: The stock market, and exchanges like NYSE are NASDAQ, are not monolithic entities but are actually large distributed systems built up from 19+ exchanges, each with its own quirks and features. Candlestick data is a massive abstraction built from raw trade or tick data, and understanding these abstractions at a deep level is essential. Then you have market trading times such as pre-market, regular market, or after-hours where different rules apply. Getting as close to the source data as possible and thoroughly understanding its origins and usage will significantly enhance your ability to leverage it.
Order Management: It is not as simple as sending buy and sell orders. Factors such as pre-computed position sizing (the number of shares to buy and your total money percentage), the ability to quickly buy and sell shares, having the ability to manage 25+ active positions and act on them instantly, tax and commission calculations, slippage management, and order state monitoring all contribute significantly to successful trading.

Edge Cases: Order execution, tracking, modifications, cancellations, partial orders, market halts and more, there are so many edge cases to consider and these cost you money if you miss something. It is absolutely essential to test these scenarios with simulated money, also known as paper trading, rather than real funds to minimize potential losses. I lost a lot of money when my system detected a trend in the pre-market and the stock jumped 40%, I bought at the absolute high, and then it quickly dropped, and my system did not adjust the sell order correctly. I basically lost 40% on that trade in minutes. You can make and lose money extremely fast in pre-market or after hours trading sessions since the normal market rules are different and you can see wild swings take place extremely quickly.

Embrace Randomness: Many of us might be tempted to think that the key to a successful trading bot lies in discovering some secret, all-powerful strategy. While strategies are undeniably important, they are not everything. One of the most valuable lessons I learned was the utility of random buying to test the core functionalities of the system. For example, try to make 1000 trades per day across random stocks for a week and you'll learn so much about your system. By introducing random buy orders into the system, you can effectively test your buying and selling logic, manage partial fills, test cancel logic, and critically evaluate the overall position tracking system. Does your system keep track of them as expected? Can you delve into the trade details? Do the positions exit based on the established criteria? Is the logging working as intended? I incorporated random stock buying using my paper trading account into my testing process, which turned out to be an incredibly efficient way to verify multiple aspects of the system simultaneously. Not to mention, it made testing a lot more unpredictable and fun."

#trading #go

https://polygon.io/blog/case-study-algorithmict-trading-with-go

"Tick Bars vs Time Bars: When you look at a candlestick bar offered by your broker, it will have an open, high, low, close, number of trades, volume, etc, this covers a known time frame, for example 30 seconds. However, the issue here is that there are times where the market is moving extremely quickly and not all bars are created equally, some might have 100 trades while others have 1,000s of trades in the same time span. So, I am taking the raw tick and quote data and building my own bars based off a set number of trades. This not only provides much better resolutions during times of increased trade activity, like market open and close, but also enables me to add in things like price spread, and other custom metrics. This is where really understanding the data you are using comes in and you can build your own abstractions rather than using someone else's.

Going In-Memory: In the early stages, I faced numerous challenges attempting to maintain state in a database because of the large spikes in activity around market open and close. Eventually, I decided to go entirely in-memory, utilizing a large map with mutex locking that virtually every component of my system interacts with. Although it was very challenging to construct and debug, this solution ultimately solved all my scalability issues. I configured the system to dump the struct that holds all data into a compressed gob file for storage, with a method to reload it in case I needed to restart the application. It can grow to be 40GB+ throughout the day and I needed to patch the Go build to support dumping gobs this large. This ensured no loss of my stateful data. Another lesson learned the hard way was the need for uninterruptible power supply. I found this out when a power outage occurred while my system was live. Without power, I lost all state data, leaving my positions unmonitored. A proper power backup system became a necessity to prevent such incidents from occurring in the future.

Complex and Lonely: This project proved much more challenging and time-consuming than initially anticipated. As I said, this has turned from a minor hobby into a full blown obsession. It can be lonely too. All you are basically doing is trying to increase the money in your account. This can be an extremely wild roller costing.

Using Go and Python: I have moved to a hybrid approach where my trading system is written in Go but I do most of my data exploring in Python just because it has extensive data science libraries, and it simplified certain aspects of looking at data or trying to find patterns.
Leveraging Personal Computers: Modern desktop PCs are extremely powerful and able to handle real-time monitoring of the entire stock market if you hack on it enough.

ChatGPT enters the Chat: ChatGPT has been a game-changer for me. With it, I can easily ask questions, use it for sanity checks, and even have it generate code. I went from not knowing how to solve a problem, blindly googling around and reading books, to just telling ChatGPT the problem, and then asking how it would solve it, then asking it to code the solution. This is absolutely insane and has easily 3x my productivity.
In retrospect, I would probably keep adding things here. For example, hunting down all types of market anomalies, things like the meme stock adventures, wild IPO events, market booms and busts, Fed news and interest rate hikes, all this just in the last few years. It’s pretty cool to have your own system to look at all this stuff, detect it, and then see it appear in the news. You definitely feel like you have a front row seat when market events are unfolding right in front of you."