#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

#trading

Про кетчуп Heinz и outside information, Local Markets было интересно.
In-sample and out-of-sample must match (про то же говорил и Том Старке, он считал корреляцию между train/test на одних и тех же параметрах торговой политики). 40% data in-sample, 60% OOS. min 50 OOS trades per TP parameter for a reliable estimate.

https://www.youtube.com/watch?v=ofL66mh6Tw0&ab_channel=ChatWithTraders

#cooking #africa

Кстати, недавно попробовал африканские блюда: сложные составы, много компонентов, необычно, вкусно. Не знал, что там живут такие гурманы ) Правда, то, что у них называется супом, у нас скорее сойдёт за рагу. Хлеба нет, вместо него нечто похожее на сваренное тесто (swallow), из необычной муки. Советую попробовать, начать с Egusi или Vegetable soup. Okro soup показался слишком уж слизистым)) .

https://cheflolaskitchen.com/egusi-soup-recipe/

#news #mts

"Напомним, что изначально сотовый оператор МТС не стал отменять плату за раздачу интернет-трафика с мобильных устройств, в отличие от тройки других крупнейших операторов: «Мегафон», «Билайн» и Tele2. В МТС мотивировали отказ отмены оплаты тем, что этот шаг, якобы, приведёт к повышению тарифов на сотовую связь и к снижению качества передачи данных. Однако, 7 ноября в компании заявили, что отменяют плату за раздачу интернет-трафика, но только для тарифов с предоплаченными пакетами трафика.

Теперь же МТС приняла решение полностью отменить взимание платы за раздачу трафика, для всех абонентов. «Учитывая социально-экономическую ситуацию и идя навстречу нашим пользователям, МТС отменяет тарификацию раздачи интернета со смартфона для всех тарифов, где предусмотрена эта опция, включая безлимитные», — пояснил оператор."

Это что же, МТС озвучили публично, что в стране жопа с экономикой?

https://3dnews.ru/1096167/mts-vsyo-ge-polnostyu-otmenit-platu-za-razdachu-interneta

#watersupply #competitions

Я уже думал, что всем похер, но внезапно 1 из 350+ участников соревнования выразил мне поддержку.
Заметьте: в основе соревнования лежит, как я понимаю, желание точнее прогнозировать наличие водных ресурсов в США для целей ирригации, снабжения питьевой водой, и прочих важных вещей. Правила соревнования явно поощряют оверфит, и делают разработанные модели малополезными для практического использования. Это ясно любому с минимальным опытом в DS. Что делает 99% участников за месяц соревнования с большим призовым фондом? Правильно, молчит и пилит оверфитнутые модели. Мне просто стало уже противно. Это как был один хер, каггл грандмастер, который выиграл очередное соревнование по оценке привлекательности питомца с помощью дата лика, а потом давал интервью в духе, мол, а чо такого. Лычку и бабки получить чтобы, всё сгодится.

"Hi Jay @jayqi,

I hope this message finds you well. I am writing to address some concerns I have regarding the current rules of the competition. Allow me to introduce myself as a machine learning specialist with a background in hydrology.

In my capacity as a hydrologist, it is evident to me that the long-term distribution of river flow exhibits a pronounced seasonality, characterized by high-water and low-water periods. This phenomenon is well-documented in hydrology articles and can be effectively described using methods such as a moving average with a multi-year window. Notably, the choice of data, whether target or USGS data, is inconsequential to this approach. However, I have observed that the current rules prohibit the utilization of such features.

I wish to bring to your attention that this restriction was imposed a month after the competition commenced. This raises two important points: firstly, the rules appear to evolve as the competition progresses, and secondly, participants who may have already implemented this approach in their models are now compelled to alter their model architectures.

In fact, this ban means it is impossible to use certain classes of models. Does it means it is impossible to use autoregressive or ESP-like models that leverage historical meteorological data?

Additionally, I comprehend the organizers’ rationale behind not permitting the use of the target to generate features. However, what perplexes me is the restriction on utilizing other approved data sources to compute long-term features or anomalies. For instance, why cannot approved data sources be employed for this purpose?

Furthermore, in the field of machine learning, it is customary to refrain from making explicit hypotheses about the impact of specific features on the studied process. Instead, assessments are typically based on an analysis of feature importance. My findings align with those of @fingoldo, and I am willing to share the feature importance chart if deemed necessary. While I acknowledge the organizers’ prerogative to impose restrictions on the source data, I find it unusual that these restrictions extend to entire classes of models or the feature engineering process. Given that we are participating in a machine learning and data analytics competition, rather than a hydrology contest, I propose that it may be more relevant to focus on the methodologies employed within ML field.

I sincerely hope you will consider these arguments, and I kindly request that the current restrictions be reconsidered. Allowing competitors the freedom to experiment with various models and approaches to feature engineering would enhance the overall quality and innovation of the submissions."

https://community.drivendata.org/t/negative-influence-of-the-hindcast-stage-possible-fixes/9249/6

#timeseries #features #otus

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

#games #returntomoria

Видел на ютубах отзывы на игру Return To Moria, такие, с недовольной миной, типа, нет ощущения духа Властелина Колец. Да вы о чём, блин! Я из этой игры больше про вселенную Властелина Колец узнал, чем из самой книги "Властелин Колец", и "Сильмариллион" впридачу ))

#aircraft #pilots

Пилоты нереально круты!

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

#earlystopping #transformedtarget #sklearn #improvement

Никогда такого не было, и вот опять: трансформация таргета в sklearn несовместима с кастомными валидационными множествами для ранней остановки, которые обычно используются в современных бустингах. Скорее всего, как принято, найдут 100 причин этого не делать, но всё же запостил feature request.