Aspiring Data Science – Telegram
Aspiring Data Science
385 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
#crypto #law

"Турецкий суд приговорил Фарука Фатиха Озера, основателя одной из крупнейших турецких криптобирж Thodex, а также его брата и сестру к 11 196 годам 10 месяцам и 15 суткам лишения свободы, признав их виновными в мошенничестве с использованием информационных систем, руководстве преступным сообществом и отмывании денег, пишет Bloomberg. Прокуратура запрашивала для Озера до 40 тысяч 462 лет тюремного заключения, но суд назначил более мягкий срок."

https://3dnews.ru/1092789/publikatsiya-1092789
#python #development

Написал большую программу на питоне, сижу, весь день вылавливаю баги. Чтобы дойти снова до момента последнего отловленной ошибки, требуется минут 40 (пока загрузятся данные, обучатся модели, потом ансамбли, создадутся прогнозы и залогятся метрики). Я одного не пойму, почему Питон называют языком быстрого прототипирования и разработки? Да, мол, он медленный и некомпилируемый, но зато разрабатывать на нём быстро. Да ни хрена не быстро. Ещё 20 лет назад Visual Basic позволял в случае ошибки исполнения спокойно поправить код на ходу и продолжать дальше, не перезапуская программу. Это казалось очень логичным, ведь это же скриптовый язык. Я сначала думал, что я чего-то не знаю, и гуру питона как-то этот вопрос решают. Но, похоже, никто его не решает. Что за деградация программирования, и, главное, почему все притворяются, что это нормально? Я подозреваю, что такой функционал какое-то время назад в питоне реализовать можно было, пока его не стали "оптимизировать", пытаясь хоть как-то спасти репутацию этого медленного говна, вместо того, чтобы сделать нормальный компилятор (взяв зв основу numba, к примеру).
"Компания Google Cloud представила на конференции для разработчиков Google I/O инстансы Google Compute Engine A3, специально созданные для обеспечения максимальной производительности рабочих нагрузок машинного обучения. Новинки используют современные CPU, быструю память, ускорители NVIDIA и IPU Intel.

Виртуальная машина A3 включает:

8 ускорителей NVIDIA H100 Hopper.
Коммутаторы NVIDIA NVSwitch с NVLink 4.0, обеспечивающие пропускную способность 3,6 Тбайт/с между ускорителями.
Процессоры Intel Xeon Sapphire Rapids.
2 Тбайт оперативной памяти DDR5-4800.
200-Гбит/с IPU, специализированный стек межсерверной связи GPU↔️GPU и оптимизации NCCL.
Помимо того, что новые инстансы используют DPU/IPU Mount Evans, разработанные совместно с Intel, кластеры A3 также задействуют фирменные оптические коммутаторы Google Jupiter с возможность переконфигурации топологии по требованию, которые компания уже использует в кластерах с собственными ИИ-ускорителями. Всё это позволяет объединять до 26 тыс. ускорителей H100 в облачный ИИ-суперкомпьютер производительность до 26 Эфлопс (TF32)."

https://servernews.ru/1086514
#trading #erema

Прогресс

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

Пока у меня такой сеттинг: есть train, val, test множества, состоящие из последовательных торговых дней. На train обучается несколько базовых моделей, с ранней остановкой по validation. Каждая базовая модель в конце делает прогнозы на все 3 множества. Для голосующих ансамблей прогнозы базовых моделей просто усредняются одним из математических средних. Для полноценного стэкинга же создаётся свой train и val наборы, в качестве признаков подаются выходы базовых моделей+их построчные аггрегаты. Разбиение на train/val для стэкинга тестировал в 5 вариантах: все комбинации train/val базовых моделей, а также train+val базовых, но со случайным отбором 15% на новый val. Я ожидал увидеть на test, что использование старого train в стэкинге токсично, и лучшие результаты покажет сплит старого val/val.

Результаты:

для стэкинга, не только старый train, но и val тоже оказался токсичным (из-за того что на нём работала ранняя остановка). то есть для стэкинга нужно выделять отдельный набор, которой вообще никак не используется при обучении базовых моделей, даже косвенно.

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

вернул xgboost в ансамбли, т.к. нашёл настройки для категориек, с которыми он не херит результаты. с дефолтными работать просто нельзя.

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

Добавил несколько новых метрик в трэкинг, исправил старые.

Уже понятно, что некоторые группы фичей избыточны. Некоторые признаки, добавленные просто для галочки, неожиданно поднялись в топ важности.

Планы

Теоретизировать и улучшать можно бесконечно, так и не начав реальных действий. Поэтому решил поскорее влезть в
рынок с тем, что уже есть.

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

Ставлю сейчас обучение по нескольким таргетам (но одному горизонту и одному рынку), 3 разных бустинга. Для самого прогнозируемого таргета сделаю новый бэктест.
👍21
Почему бустинг плохо понимает линейные зависимости?

Я подумал-подумал и решил прямо в канале отвечать на хорошие вопросы из комментариев) Начнем с вопроса про линейные зависимости в градиентном бустинге над деревьями

Условному LightGBM непросто выучить зависимость y = x по 2 причинам:

1. Нужно довольно много сплитов дерева (большая глубина / мнго деревьев), чтобы это выучить
if x < 10 then y = 9
if x > 10 then y = 11
if x > 12 then y = 13
…. (N раз)
if x > 1000 then y = 1001

2. Сложно прогнозировать out-of-distribution
Вторая проблема хорошо видна из “крайних” условий на х:
if x <10 then y = 9
if x > 1000 then y = 1001

Бустинг довольно плох для значений Х, которых не было в трейне (out-of-distribution). И если у вас, например, продажи с растущим трендом, то прогнозировать больше, чем было раньше - очень проблемно

Можно конечно для продаж прогнозировать не сами продажи, а их прирост. Но и это не всегда решает проблему: представьте, что на товар была скидка не более 10%, а сейчас стала 30%. Можно неаккуратно переобучиться на историю скидок именно этого товара и не прогнозировать бОльший рост, даже если на всех товарах (где бывают любые скидки) есть около-линейная зависимость от скидки

Рубрика “Ответы на вопросы из комментариев” #answers
❤‍🔥1👍1
#arm #ipo

"К выходу на биржу компанию Arm оценили по верхней границе в $54,5 млрд, а цена одной акции была установлена на уровне $51. Ещё на стадии предварительных торгов стоимость акций выросла примерно на 10 % — до $56,1. Рост продолжился и даже усилился во время торговой сессии, в результате чего Arm завершила свой первый торговый день с ценой $63,59 за акцию. Капитализация составила $67,9 млрд.

Компания, торгующаяся под тикером «ARM», выпустила на биржу около 95,5 млн акций. Компания SoftBank, которая приобрела Arm в 2016 году, сохранила контроль над 90,6 % акций, а в результате IPO заработала $4,9 млрд. Среди инвесторов, купивших крупные доли в Arm значатся компании Apple, Google, NVIDIA, Samsung, AMD, Intel, Cadence, Synopsis и TSMC."

https://3dnews.ru/1093065/aktsii-arm-vzleteli-na-25-v-perviy-den-torgov-na-birge
Неклассические бустинги над деревьями (hybrid regression tree boosting)

У бустингов над деревьями есть некоторые проблемы с линейными зависимостями. Почему бы тогда не совместить бустинг, деревья и линейную регрессию?

Идея такая: в классическом дереве для задачи регрессии для прогноза в каждом листе берется среднее таргетов (для rmse loss). Что если вместо простого среднего строить в листе линейную регрессию? И в качестве прогноза брать прогноз линейной регрессии

Так и возник подход hybrid regression tree (HRT) - это дерево, в каждом листе которого есть линейная регрессия. Пример работы можно посмотреть на картинке к посту. Ну и конечно это можно обобщить до бустинга

Штука прикольная, и как-то в универе мы с ребятами даже запилили код hybrid regression tree. Ни о какой оптимизации по скорости и памяти в студенческом проекте речи конечно нет, но поиграться можно

И внезапно наша репа до сих пор топ-1 по запросу ”hybryd regression tree” в гугле аж с 2 звездочками 😅

Это говорит скорее о непопулярности подхода - по метрикам чуть лучше классического lightGBM / CatBoost, но сииииильно медленнее: может работать только на небольших наборах данных до 10-100к строк. Можете, кстати, посчитать сложность алгоритма в комментариях - удивитесь 😄

UPD: В комментариях подсказали, что этот алгоритм завезли в lightGBM. Что ж, очень радует!)


#answers - ответы на вопросы из комментариев
Формирую набор на курс по рядам, разбираю вопросы. Отвечаю на вопрос, почему нельзя выбирать, пропускать материал, который знаешь. Во-первых, курс у меня не шведский стол, когда вы «выбираете» или мы «это пропускаем, это я знаю» вы рвете мне нить повествования, потому что у меня все достаточно жестко, системно спланировано. Во-вторых, и это более важно, а вы уверены, что вы знаете? На своем примере расскажу. Я довольно неплохо знаю ARIMA (пруф – пособие в посте выше), могу очень приличную модель сделать. Устроился в Capital, вторая неделя пошла, коллеги делятся опытом, там у нас есть ARIMA guys, и я думаю, ну чему они меня еще могут научить. Выясняется, я совсем забыл про применение сплайнов в качестве признаков для ARIMA, я неправильно делал интеракции Фурье и календарных признаков (календарные брал в лоб, тогда как эффективнее их переводить в формат десятичных дробей), у меня были предубеждения (ошибочные) в отношении оптимизации с ограничениями для ARIMA и, позор мне, я делал совершенно бездарное сглаживание для ARIMA (с выбросами бороться), а потом и вовсе его бросил, потому что оно не помогало, а оно, естественно, помогало, просто нужно было делать его по-другому. Еще я игнорировал правило про проверку на единичный корень в AR и MA-части, ребята показали убедительные примеры, как важно его проверять. И я не знал толком техник деагрегации прогнозов, когда для того, чтобы модель по очень шумному ряду не шпарить, делаем агрегацию ряда, но тогда прогнозы будут для агрегированного ряда и надо деагрегировать. Знал, что в Greykite применяют, а как руками делать не видел. И это я с немалым опытом работы c ARIMA. У ребят было свое преимущество, они проводили воркшопы, разбирали кучу научных статей, сами писали статьи и взяли на вооружение очень много подходов, которые не всегда выведешь в лоб эмпирически. Представьте, я б себя индюком повел, мол, "я тут все знаю", этих важных тонкостей не узнал бы. Так что не переоцениваем себя, слушаем, мотаем на ус.
3👍1
👀1