#wisdom #thales

#musk #war

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

По поводу оценки вероятности акулы быть убитой ракетой - интересно. Оказывается, звуковые волны - афродизиаки для морских котиков ) Как этот котик потом объяснит своим друзьям, что произошло?!

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

#featureselection #hyperopt

Интересный факт: дефолтный сэмплер hyperopt-a, а именно, tpe, существенно хуже tpe из optuna (возможно, потому, что в hyperopt у него нет настроек)? Зато адаптивный TPE, то есть, atpe, на одномерной задаче FS зарулил всё остальное и из оптуны, и из скопта - правда, только для 50 итераций. Для 20 он хуже оптуны. + имеет самое долгое время работы (20 секунд на 50 итераций) и загрузку процессоров.

#optimization #global #benchmarks #python #cuckolds

Набрёл на вот какое классное питоновское сравнение оптимизаторов! Оказывается, не гипероптом и оптуной едиными! )
Открылись питоновские оптимизаторы, о которых никогда раньше не слышал: Facebook Ax, PySOT, PyMoo, Platypus, pattern.

Автор бенчмарка тоже не в восторге от поведения функций глобальной оптимизации scipy, но он себя успокаивает, что там по-другому, наверное, просто нельзя было сделать:
Evaluating "naughty" optimizers. In this discussion, a naughty optimizer is one that does not limit function evaluations to precisely what the user might desire. As an aside, this isn't a critique. Often the optimizers cycle through parameters, or perform some other subroutine that involves multiple function evaluations - so they only stop periodically to see whether the user-supplied maximum has been exceeded. It may not be sensible to do otherwise, depending on the details of the algorithm.

Я же ответственно вам заявляю, что можно было. Даже если у тебя внутри вложенные процедуры, никаких проблем передать в них максимальное и текущее количество оценок и выйти по условию НЕТ, в процедуре более высокого уровня можно проверку повторить. Это просто мудаки-разработчки. Если параметр у тебя называется max_evals, будь добр, обеспечь, чтобы это количество не превышалось, иначе ты мудак. Хм, или куколд? ) На твои параметры можно только смотреть, они все равно ни хрена не делают )

Кстати, странно, что автор не нашёл идеи нормализовать результаты на реальное количество оценок функции, он же вместо этого для куколдовских алгоритмов scipy итеративно подбирал max_evals так, чтобы реальное max_evals примерно подходило. Также большой недостаток, что у оптуны и гиперопта не проверялись разные сэмплеры и параметры (как их назвать-то? метапараметры?), видимо, всё взяли по дефолту. И шакала оценок совершенно непонятная, если честно, в таблицах не найденные экстремумы, как я думал, а какие-то странные скоры с привязкой ко времени поиска. А, или в основной таблице скоры, а в куколдовских средние найденные экстремумы...

Но ближе к делу, факт в том, что очень хорошо себя показали pysot, pattern из pymoo и shgo+powell из scipy. А значит, их надо затестить тоже.

https://www.microprediction.com/blog/optimize

#optimization #global #benchmarks #python #humpday

Продолжение оптимизационного банкета от того же автора. Он подготовил единый интерфейс для сравнения работы алгосов из доброго десятка оптимизационных пакетов. Я даже не имел понятия, что их СТОЛЬКО, реально под полсотни.

Ну и я посмотрел, что он в итоге советует. В топ-10 автора вошли optuna-cmaes и skopt-gp_minimize, которые на моей одномерной задаче сработали вообще хуже всего... Неужели они так раскрываются с повышением мерности?

https://www.microprediction.com/blog/humpday

#optimization #global #nevergrad

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

Интересный человек, кстати:

"Dr. Peter Cotton, a career quant, entrepreneur and leading authority on crowdsourcing, is the creator of microprediction.com and founder of Micropredictions, a division of Intech Investments. Dr. Cotton is Intech's former Chief Data Scientist and is the developer of multiple financial modeling patents.

Before joining Intech®, Dr. Cotton spent six years at JPMorgan, where he served as executive director of data science. He created ROAR, a collective intelligence platform with over 1,000 contributing data scientists within JPMorgan; also initiating the privacy preserving computation research, and the use of optimal control in trading. Previously, he was the founder of Benchmark Solutions, a company that pioneered large-scale financial data assimilation and was later sold to Bloomberg. Peter began his career at Morgan Stanley where he was one of several independent inventors of closed-form synthetic CDO pricing.

Dr. Cotton earned an undergraduate degree in physics and mathematics from the University of New South Wales and a PhD in mathematics from Stanford University."

https://github.com/facebookresearch/nevergrad/blob/main/docs/opencompetition2020.md

Ну и сам сайт его просто фантастика, затрагивает очень интересные темы. Жаль, не знал раньше.

On Joint Distributions and 3-margins

"In a live prediction challenge running at Microprediction.org, algorithms try to predict bivariate and trivariate relationships between five minutely returns of Bitcoin, Ethereum, Ripple, Cardano and Iota. Can you beat them?

It is hoped that out of a collection of interrelated statistical contests, a picture of the fine structure of two-way, three-way and five-way dependencies will emerge. This detailed understanding might surpass what one model or person could achieve. This post comprises two parts:

A discussion of the study of joint behavior, and why trivariate margins might help reconstruct five-way relationships, and why correlation modeling isn't always enough.
A Python walkthrough for those who want to try their hand.
Rules are on the competition page."

https://www.microprediction.com/blog/copula

#featureengineering #python #architecture

Возникла архитектурная задача. Мне нужно рассчитывать признаки на большом количестве дней. Сырые данные по дню лежат в 3 отдельных файлах. Что делается сейчас в цикле по дням:

1) файлы дня последовательно открываются как фреймы пандас, делается фильтрация и простой общий препроцессинг. работает 1 ядро. занимает 30 секунд.
2) обработанные файлы направляются в joblib.Parallel уже на все ядра с указанием, какой кусок данных просчитывать конкретному воркеру (ядру). работают все ядра, фаза занимает на текущем железе 10 минут. как происходит направление файлов: 2 передаются просто как параметры, их numpy прозрачно memmap-ит (в течение нескольких секунд). третий содержит столбец массивов (dtype=object), не родной тип numpy, поэтому memmap не происходит. приходится обработанный файл сохранять как временный(в паркет, это оказалось быстрее всего), и уже изнутри каждого рабочего потока открывать по ссылке. как и при сериализации, здесь дублируется RAM, но работает быстрее.

Неизбежно какие-то ядра заканчивают работу быстрее остальных, и в итоге утилизация процессора на какое-то время падает со 100% до, скажем, 30%. Ну и пока файлы готовятся, утилизация составляет жалкие проценты. Рабочие потоки, кстати, возвращают результаты как фреймы панадас, которые потом сливаются в 1 фрейм в главном потоке (2сек) и дампятся в файл (15сек). Итого выходит, что до 10% времени железо простаивает.

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

Пока думаю в отдельном потоке готовить файлы и складывать в очередь, если её длина меньше 3. иначе спать минуту. А уже в основном потоке брать из очереди и засылать на параллельное выполнение. Да, вспомогательный поток уменьшит на 1 число рабочих потоков, но так кодить будет проще, утилизация повысится с 90% до 99%. Также надо подумать об асинхронном мёрдже и сохранении результатов. Может, как раз в тот же вспомогательный поток результаты засылать? Пока остальные молотят расчёты, этот пусть будет завхозом, который файлы открывает, готовит, результаты собирает и сохраняет...

#sports #football

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

#nvidia

"Акции NVIDIA дорожают десятую биржевую сессию подряд, что является самым продолжительным периодом роста с момента рекордного скачка в декабре 2016 года. В ходе этих сессий ценные бумаги выросли на 20 %, увеличив рыночную стоимость компании примерно на $200 млрд. Вчерашний анонса обновлённого ИИ-ускорителя NVIDIA H200 лишь подстегнул рост — за день акции выросли на 7 %. С начала года акции NVIDIA выросли на 230 %, что сделало их самыми эффективными как в Nasdaq 100, так и в S&P 500."

https://3dnews.ru/1095958/s-nachala-goda-aktsii-nvidia-podorogali-na-230-a-kapitalizatsiya-na-poslednih-torgah-virosla-na-200-milliardov-dollarov

#lightgbm #bugs

ЛайтГБМ может херить категориальные входы при предсказании (хотя он менять входы вообще никак не должен). Сколько же крови мне этот баг попил... Думаю, откуда чёртовы нули эти берутся, я же датасет вообще не меняю.

Но как же армия кэгглеров, которые юзают ансамбли, почему этого никто не заметил и давно не зарепортил?

Мне теперь только в XGBoost-е ошибку найти осталось, и закрою гештальт.

UPD.

"jmoralez commented 18 minutes ago
Hey, thanks for using LightGBM and sorry for the troubles. We used to take a shallow copy there but it wasn't obvious that the predict step depended on that and a recent refactor removed it. We'll work on a fix."

Странно, и вовсе не полгода им понадобилось, чтобы отреагировать. Катбуст/Яндекс, учитесь.

https://github.com/microsoft/LightGBM/issues/6195

#trading

"Practical points from 014:
- A lot of computational power is usually needed to find all the opportunities offered by the US stock market (talking about scanners?).
- Currency markets offer juicy margin levels that allow higher exposure, a good place for emotionless systems. Ilan hints the use of an algorithmic hedged approach for FX.
- The expectancy life for most systems on the FX markets : 3 to 6 months (one year at best).
- There are always new methods to be tested on FX.
- Ilan mixes mean reversion and trend systems in a basket to reduce risk.
- It is almost impossible to avoid trading news, Ilan avoids trading on the higher impact news (considers it gambling).
- Professionals have better access to backtesting tools to actually simulate close-to market environments (floating spreads, real drawdowns, portfolio impact, etc...)
- The idea of creating a model should be to test past performance and avoid losses.
- High frequency traders help to lower trading costs by injecting volume into the markets.
- Most retail traders are very lazy, as they don't bother understanding the rules of trading in detail, including basics (a pip value) and macro-economic factors.
- People having the secret sauce won't try to sell it to you, that doesn't make sense.
- Indicator based system are worthless, unless you are willing to put an effort in constant optimization and adjustment."

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

#rust #python

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

Python:

df.write_json("docs/data/output.json")
df_json = pl.read_json("docs/data/output.json")
print(df_json)

Rust:

let mut file = File::create("docs/data/output.json").expect("could not create file");
JsonWriter::new(&mut file).finish(&mut df)?;
let f = File::open("docs/data/output.json")?;
let df_json = JsonReader::new(f)
.with_json_format(JsonFormat::JsonLines)
.finish()?;
println!("{}", df_json);

#pandas #performance #parquet #codegems

Как побыстрее прочитать много файлов данных паркет (с одной схемой) и объединить их в один фрейм данных в памяти?

Базовое решение в Pandas (работает последовательно, грузит лишь 1 ядро):

df =pd.concat([pl.read_parquet(file) for file in files], ignore_index=True)

И сразу лучшие решения.

Pandas с многопоточной загрузкой:

with concurrent.futures.ThreadPoolExecutor() as executor:
    df = pd.concat([future.result() for future in concurrent.futures.as_completed([executor.submit(pd.read_parquet, file) for file in files])], ignore_index=True)

Сработало вдвое быстрее последовательного пандас.

Polars:

df = pl.read_parquet( f"mask*.parquet"))

На моих файлах это не сработало, т.к. у меня некоторые поля записались по-разному как float32/float64, и поларс не смог их состыковать. Запросил эту фичу. Но зато уже сработало

df =pl.concat([pl.read_parquet(file) for file in files], how="vertical_relaxed")

причем вдвое быстрее мультипоточного панадас! Грузило CPU на 100%.

Если файлы с трудом влезают в оперативку, и на слияние уже не хватает RAM, можно их сначала последовательно записать в 1 большой файл, и уже потом открыть разом (работает в 5 раз медленнее худшего из предыдущих вариантов, но не требует RAM):

schema = pq.ParquetFile(files[0]).schema_arrow
with pq.ParquetWriter(join(datapath, "output.parquet"), schema=schema) as writer:
for file in files:
writer.write_table(pq.read_table(file, schema=schema))

#parquet #pyarrow #bugs

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

https://github.com/apache/arrow/issues/38736