Aspiring Data Science – Telegram
Aspiring Data Science
386 subscribers
465 photos
12 videos
12 files
2.15K links
Заметки экономиста о программировании, прогнозировании и принятии решений, научном методе познания.
Контакт: @fingoldo

I call myself a data scientist because I know just enough math, economics & programming to be dangerous.
Download Telegram
#книга
Simon J.D. Prince "Understanding Deep Learning"
Незаслуженно малоизвестная книга. Но это самое лучшее, что в последние годы писалось по глубокому обучению. Материал очень современный (GPT3, диффузионные модели, графовые сети есть). Повествование с основ и до этических проблем, очень широкий охват. Текст и рисунки авторские. Достаточно подробная библиография. Ну разве что примеров кода нет (книга теоретическая). Настоятельно рекомендую!
https://udlbook.github.io/udlbook/
#geology #astronomy

"В недавнем прошлом учёные уже проводили расчёты, которые могли бы подсказать происхождение двух гигантских аномалий на стыке ядра Земли и нижних слоёв её мантии. Ещё в 80-х годах прошлого столетия геофизики с удивлением выяснили, что в глубинах нашей планеты находятся два гигантских континента протяжённостью несколько тысяч километров каждый. На это указали сейсмические волны, которые в этих загадочных областях перемещались иначе, чем в окружающей мантии. Эти «объекты» назвали крупными областями с низкой скоростью сдвига (LLSVP, Large low-shear-velocity provinces) и стали разрабатывать гипотезы об их образовании.

Параллельно шло изучение Луны, благо к тому времени «Аполлоны» доставили на Землю образцы с её поверхности. Выяснилось, что Луна и земные мантийные породы имеют одинаковое происхождение и состав, что заставило задуматься об ударном появлении Луны. Расчёты показали, что Луна могла образоваться около 4,5 млрд лет назад при падении на Землю планеты размером с Марс. Поиски других остатков этой гипотетической планеты, которой дали имя Тейя, не увенчались успехом. Их не было в околоземном пространстве и в главном поясе астероидов.

Учёные предположили, что остатки Тейи погрузились в недра тогда ещё расплавленной Земли. Новое и более подробное моделирование, проведённое под руководством учёных из Калтеха, показало, что области LLSVP с большой вероятностью — это действительно остатки Тейи. Они сохранили свою монолитную структуры благодаря тому, что нижний мантийный слой Земли не был достаточно горячим, чтобы произошло смешивание, и остатки успели кристаллизоваться. Благодаря этому мы сегодня можем увидеть их в процессе сейсмических исследований.

Появление в недрах Земли таких гигантских инородных вкраплений очевидным образом повлияло на все последующие геологические процессы на нашей планете. Учёным ещё предстоит оценить это влияние на раннюю эволюцию Земли."

https://youtu.be/k4dQW_fUgik
👍1
#aws

Облачный провайдер Amazon Web Services (AWS) объявил о запуске новой модели потребления EC2 Capacity Blocks for ML, предназначенной для предприятий, желающих зарезервировать доступ к ускорителям вычислений для обработки кратковременных рабочих нагрузок ИИ.

Решение Amazon EC2 Capacity Blocks for ML позволяет клиентам зарезервировать доступ к «сотням» ускорителей NVIDIA H100 в кластерах EC2 UltraClusters, которые предназначены для высокопроизводительных рабочих нагрузок машинного обучения. Клиенты просто указывают желаемый размер кластера, дату начала и окончания доступа. Таким образом повышается предсказуемость доступности ИИ-ресурсов и в то же время нет необходимости оплачивать доступ к мощностям, когда они не используются. AWS тоже в выигрыше, поскольку такой подход позволяет более полно использовать имеющиеся ресурсы.

https://servernews.ru/1095352
#scipy #global #optimization #diogenes

Продолжаю работать над отборщиком признаков Диоген.

Столкнулcя с плохой работой методов глобальной оптимизации.

Кто работал с численной оптимизацией в сайпай, подскажите, что не так делаю. Пока кажется, что глобальная оптимизация из scipy не способна найти экстремум даже относительно простой гладкой функции 1 переменного. Хотелось бы что-то для поиска экстремума функции с очень высокой стоимостью оценки, в идеале когда можно задать бюджет поиска.

Попробую, наверное, запилить универсальный модуль с 3 опциями: гауссов процесс, бустинг с квантильной регрессей, и случайный поиск. Для первых двух будет какой-то начальный эквидистантный сэмплинг, чтоб было на чём учиться. Ну и плюс варианты выбора следующего кандидата, конечно же: expected improvement, ucb, etc.

Просто очень странно, что такого пакета ещё нет готовенького.

https://github.com/scipy/scipy/issues/19467
🥴1
#math #fun

Учитель алгебры очень расстроился, когда нашёл свою жену с двумя неизвестными.
❤‍🔥2
#global #optimization #benchmarks

Дали ссылку на такое вот иллюстрированное сравнение численных оптимизаторов

https://infinity77.net/go_2021/thebenchmarks.html
#global #optimization
Реализовал Гауссов процесс и квантильный бустинг в рамках той же задачи. Последний выглядит получше, есть надежда довести до боя.
🔥1
#featureselection #diogenes #rfecv

Вот так, кстати, выглядит зависимость ML-метрики от числа признаков в Diogenes. Это пример с реальными данными, но синтетическими зависимостями. Пока кандидаты для проверки генерятся полным случайным перебором, подключаю более интеллектуальные методы.
#featureselection #rfecv

Некоторые мысли по поводу процесса отбора признаков в RFECV

1) Количество проверяемых признаков имеет свою стоимость. Проверить nfeatures=10 стоит гораздо дешевле, чем проверить nfeatures=1000 (скажем, на терабайтном датасете). С другой стороны, проверка 1000 фичей даст больше информации об их рейтинге, что будет полезно при выборе следующих кандидатов. Но опять же, за время проверки 1000 можно проверить сразу несколько более мелких комбинаций... Надо как-то учитывать этот баланс.
Пока ограничусь проверкой начальных сэмплированных значений (для обучения базы) в порядке возрастания, чтобы при срабатывании лимита времени успеть проверить больше комбинаций.

2) Можно ли совмещать FS с HPT прямо в процессе FS? Скажем, пока мы с помощью интеллектуального алгоритма из 1000 признаков проверяем 50 комбинаций nfeatures, можем ли мы одновременно варьировать гиперпараметры базового оценщика, чтобы собрать дополнительную ценную информацию? С точки зрения выбора следующего кандидата варьирование HPT обычно ничего не изменит (за исключением случаев когда HPT совсем уж явно изменит лидеров), т.к. всё равно будут использоваться ранги. А вот для последующего обучения на финальном наборе это может дать очень ценную информацию бесплатно, особенно если базовый оценщик тоже будет использоваться на финальной стадии конвейера. Плюс это повысит вариативность, и, соответственно, реалистичность оценок CV.

Проще говоря, если собирать инфу о рейтингах признаков неизбежно надо, причём обучая модельки, так давайте заодно менять при каждом обучении HP и дополнительно собирать данные о чувствительности итоговых метрик к гиперпараметрам?
Планирую сэмплить HP из допустимого множества для заданной базовой модели. Возможно, придётся вести список "опасных" значений HP, которые сильно увеличат время расчётов. Итоговые кортежи (hp,feature_stats,train_time,ml_perf) сохранять в отборщике признаков для посл старта в HPT.

3) А можно ли как-то ещё заюзать эти десятки и сотни промежуточных моделек из фазы FS? Понятно, они все обучены на разных количествах признаков, да ещё и лишь на CV частях train set. Но всё-таки даже на них будут затрачены большие ресурсы, и они представляют собой ценный актив. Ну хотя бы с точки зрения последующего ансамблирования, или точечной оценки уверенности в прогнозах (когда модельки расходятся во мнениях)?
Думаю опционально сохранять их в памяти и/или на диске, с указанием входных признаков.

4) Есть ли смысл в RFECV использовать сразу несколько базовых алгоритмов? Скажем, и catboost, и lgbm.

5) Как выяснилось недавно, у lgbm есть режим, когда листья дерева заменяются наклонными линиями регрессии. По идее, это позволит лучше моделировать связи, особенно на небольшом числе точек. Стоит ли попробовать такой сплайновый режим?
#tradig #chan

Интересно про модель на инструмент, стратегии которые продержались в бою 4 года, плавную аллокацию капитала для новой стратегии.

https://www.youtube.com/watch?v=DW9zQ8Hz6gQ
#hpt #optuna #codegems

Добавляю в сравнение по текущей задаче FS современные библиотеки оптимизации, в частности, очень популярная ныне (как б даже не лидер?) Optuna. Дабы освежить память, заглянул в доку. Привлёк внимание рецепт от создателей Оптуны, как бороться с дублированными кандидатами, которых иногда выдаёт Оптуна же. Ну это просто жопа, господа.
😁1
#skopt #optuna #global #optimization

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

The total number of evaluations, n_calls, are performed like the following. If x0 is provided but not y0, then the elements of x0 are first evaluated, followed by n_initial_points evaluations. Finally, n_calls - len(x0) - n_initial_points evaluations are made guided by the surrogate model. If x0 and y0 are both provided then n_initial_points evaluations are first made then n_calls - n_initial_points subsequent evaluations are made guided by the surrogate model.

initial_point_generatorstr, InitialPointGenerator instance, default: ‘random’
Sets a initial points generator. Can be either

"random" for uniform random numbers,
"sobol" for a Sobol sequence,
"halton" for a Halton sequence,
"hammersly" for a Hammersly sequence,
"lhs" for a latin hypercube sequence

Интересно будет увидеть её в сравнении. Ещё из интересных находок авторов: по умолчанию у них acquisition function не просто одна из известных EI, PI UCB/LCB, а т.н. gp_hedge, которая на каждом шаге сэмплит одну из указанных, по идее предлагая лучшее из 3 миров )
#hpt #hpo #bayesian #gaussianprocess

Раскрыты недостатки GP:

1) чувствительность к масштабу параметров
2) чувствительность к выбранному ядру (по сути, приор определяет догадки о виде истинной black box функции)
3) плохая работа с категориальными параметрами (Hamming kernel?)

Когда докладчика спросили про параллелизацию, мне кажется, он лопухнулся, сказав, что тут у случайного поиска преимущество, ведь его можно выполнять параллельно, а gp - нет. Ну сам же показывал графики Expected Improvement, кто запрещает брать из них вместо единичного argmax батч argsorted()[:batch_size]?

https://www.youtube.com/watch?v=jtRPxRnOXnk
🤔1
#trading #chan

Imho "capital allocation, not primary signal generation" thing is a BS. It's just a different name for the same thing. Say, I have 3 strategies that normally get allocated $1 each. Then at some moment my ML model suggest to allocate $100 to model #2. I can, of course, call this "capital allocation", but it's in essence a signal generation as well, 'cause the rest of allocations are close to noise. But maybe I misunderstood Ernest and he meant allocations like 0.3, 0.3, 0.4? But hard to believe such high % can be given to strategies that are not expected to work well. Also predicting "whether certain trading parameters will perform well today' seems like, still, indirect prediction of market movement. It can't be other way round, 'cause every trading policy should be based on expected asset price movements. Having a 'certain parameters' filter works 2-ways: it reduces train dataset size for ML (which is bad), but it theoretically allows ML to focus more on particular search space (which is probably good, as the model transitions from jack of all trades, master of none, to master of some). Which force prevails, is a matter of experimentation and asset/TP subtleties.

https://www.youtube.com/watch?v=BhaJVZNpL4M
#gaussianprocess #optimization #global

Честно говоря, пока что кажется, что толку от "байесовости" гауссовых процессов в задаче глобальной оптимизации не так уж много. Да, рассчитывается неопределённость в каждой точке, ну так она:

1) зачастую крайне слабо отражает реальное положение относительно искомой функции
2) пропорциональна расстоянию до ближайших исследованных точек, так что её можно оценить и для "классических" ml алгосов.

Есть ещё аргумент, что функции приобретения в случае gp рассчитываются аналитически, но ведь их можно заменить эвристикой. Скоро узнаем.