#fantasy #zelazny #comics

Оказывается, есть классные комиксы по Хроникам Эмбера!

https://comiconlinefree.org/roger-zelazny-s-amber-nine-princes-in-amber/issue-1

#pandas #optimization #joblib #numpy #memmap

Хорошие новости! после экспериментов выяснилось, что в последних версиях joblib умеет дампить в общую память не просто отдельные массивы numpy, а (что не указано в доке) и целиком фреймы пандас!

И даже не обязательно прописывать операции вручную. Достаточно просто передать фрейм в конструктор Parallel joblib-a как параметр, и, если он больше max_nbytes, joblib его автоматически сдампит и правильно загрузит уже в рабочих процессах! Советую в качестве temp_folder указывать быстрый NVME SSD диск, типа Parallel(n_jobs=32,max_nbytes=0, temp_folder=r'R:\Temp' ). В моих тестах отработали по сути все базовые типы столбцов: int, float, datetime, categorical.

Единственное - проблема со сложными типами, вроде массива массивов numpy (итоговый тип object), такое не работает и включается обычная сериализация. Но этого желать было бы уж слишком нереалистично, я и так не могу себе представить, как удалось победить нерадивых программистов пандас, ведь раньше даже просто инитнуть фрейм с разнородными типами столбцов было невозможно без копирования.

Вывод: если у Вас не экзотические типы данных и есть nvme, большие фреймы в свежих версиях библиотек можно спокойно передавать как параметры, и они не буду побайтово сериализоваться, более того, RAM будет расходоваться в десятки раз экономнее.

#fantasy #zelazny #comics

https://comiconlinefree.org/roger-zelazny-s-amber-the-guns-of-avalon/issue-1/

#fantasy #zelazny #comics

https://comiconlinefree.org/roger-zelazny-s-amber-the-guns-of-avalon/issue-2/full

#fantasy #zelazny #comics

https://comiconlinefree.org/roger-zelazny-s-amber-the-guns-of-avalon/issue-3/full

#trading #rl

Обзор различных направлений прикладного ML в трейдинге, на базе дипломных студентов колледжа. Познавательно. Некоторые весьма креативны.

Про hedonistic learning system, trading as dimensionality reduction забавно )

Ну и сам профессор отжигает. Кто из вас бы увязал в одном абзаце определение кибернетики, 2-й закон термодинамики, принцип неопределённости Гейзенберга, и дилемму смещение-разброс? А он смог, только фракталов не хватает для полного счастья )

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

#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