Prepping tables for machine learning

#varoquaux #inria #ml #sklearn #missingvalues #imputing #perezlebel #skrub #minhashencoder #gapencoder #datetimeencoder #tablevectorizer #fuzzy_join

Общие советы, как учиться на табличных данных в экосистеме sklearn.

Оказывается, заполнение пропусков лучше всего нативное от деревянных моделей. Потом уже идут более гораздо затратные вычислительно условные импутации. Если у вас нейросеть, используйте в конвейере add_indicator=True, чтобы обработать возможные случаи, когда пропуски не случайны.

По дефолту советуют HistGradientBoosting.
Если же нет, рекомендуют QuantileTransformer НА ПРИЗНАКАХ. Такое я чёт впервые встречаю, обычно это делают на таргете... хм... +IterativeImputer (хотя только что говорили про его затратность).

Гаель предлагает как стандарт весь препроцессинг отдать трансформеру tablevectorizer из либы skrub, который знает, как обрабатывать фичи времени, строки, категории.

Для категориальных столбцов у них реализована интересная разновидность one hot, основанная на строковой близости меток. Например, Police officer I и Police officer IV попадут в одну корзину вместо разных. Семантическая близость, к сожалению, (пока?) не учитывается.

Ещё в skrub для обогащения данных из справочных таблиц есть джойнеры, которые, как я понял, заменяют featuretools по сути. Но если в featuretools чёрт ногу сломит, тут вроде попроще. Очевидное преимущество skrub - fuzzy_join (всё по той же текстовой схожести).

Что интересно, есть несколько бэкендов - pandas, polars.

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

#it

Читаю новость: В мае глава IBM Арвинд Кришна (Arvind Krishna)...
Блять, ну вы серьёзно? Почему главой (американской) ИТ-компании должен быть индус, мне кто-то может объяснить??

#agronomy

"Обучаемый машинный интеллект анализирует внешний вид яблок и даёт команду на съём только тогда, если фрукт необходимой спелости и без повреждений. Работа платформы на опытном хозяйстве показала высочайшую избирательную способность системы. Она очень сильно сокращает затраты на сбор урожая, позволяя за каждый проход выбирать плоды только лучшего качества. Обычный человек с улицы на такое не способен. А специально обученные сборщики урожая — это редкое явление."

https://youtu.be/nYl_1TMVwjw

https://3dnews.ru/1089519/iskusstvenniy-intellekt-nauchili-sobirat-spelie-yabloki-roem-dronov-na-privyazi

#trading #dl #mbo #lob #bidask

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

#trading #backtesting #ml #chan

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

Это и есть реализация идей де Прадо и Чана о том, что бесполезно применять МЛ для прогнозирования цены, т.к. то же самое пытаются сделать все. А вместо этого, мол, если тебе нравится торговать по пересечению 2 скользящих средних, то и делай это, но натренируй МЛ выяснять, в какие моменты эта стратегия имеет шансы на успех.

В данном случае, периоды этих 2 средних, ну ещё отступы и какие-нибудь дополнительные параметры, добавляются в обучающий набор (содержащий рыночные данные и фундаменталку), а таргетом выступет кэф Шарпа от применения этих торговых параметров на сл месяц.

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

Но ещё один важный аспект такого подхода в том, что традиционная идея "сначала МЛ (модель даёт прогнозы), потом бэктест (а что же делать с этими прогнозами, при каких значениях покупать/продавать) с боязнью оверфита" заменяется на "в каждой точке сэмплим сотни комбинаций управляющих параметров, смело делаем бэктестовые "виртуальные забеги" с этими параметрами, потом уже обучаем на всём МЛ, борьбу с оверфитом отдаём на откуп МЛ."

Конечно, это сильно снижает операционное пространство по сравнению с 1м подходом, т.к. МЛ исходы становится ограниченны конкретной торговой политикой. Но я придумал комбайн, как обойти это ограничение. Вторая модель! Пусть она даёт, как и обычно, прогнозы рынка и/или инструмента, и уже эти прогнозы будут считаться частью управляющий переменных. Тогда не надо будет ждать, условно говоря, пересечения 2 SMA, всегда будет некий прогноз и решающие пороги, по которым можно действовать. Такой своеобразный Double ML.

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


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

#profiling #optimisation #python #speed #sklearn #bollocks

Эскалёрновские волшебники-программисты в деле. Столкнулся с неприемлемо низкой скоростью построения отчёта классификационных метрик на 8M примеров. 15 секунд, ну куда это годится? Проверил кирпичики расчётов по нисходящей. Матрица ошибок считается за полторы секунды. Это чем же надо угандошить процессор, чтобы простое деление пары чисел и упаковка в словарь выполнялись больше 10 секунд и делали расчёты в ДЕСЯТЬ раз длиннее? Такое и специально не сразу сделаешь.

#optimisation #sklearn #python #numba #codegems

Итак, то, что у кудесников машинного обучения считается 15 СЕКУНД, на самом деле должно занимать 50 МИЛЛИСЕКУНД. Но зато они сотни строк качественного кода написали, наверное, покрытого тестами, и прочим. Почему я считаю это важным? Да потому что мне предстоит обсчитывать сотни моделей, и оказалось, что качество обучения (classification report, roc auc, калибрация по всему сету + в разбивке по группам) на test set оценивается для 1 модели.. 5 минут, и основным тормозом был classification_report. Мне вовсе не улыбается платить за кластер, ожидающий сотни и тысячи раз по 5 минут. Спасибо, что у нас хотя бы есть numpy и numba. Без нумбы, кстати, этот код на языке программирования, созданном "гениальным" Ван Россумом, выполняется даже не знаю сколько, я прождал минут 5-10 и забил.

Скорее всего, напрасная трата времени, но всё же запостил issue. Как обычно, похерят, видимо.

#hardware #flash

Кажется, у меня 8TB NVME SSD Sabrent в компе стоит. Его покупка в 2021-м стала моим самым полезным IT приобретением года. А то и многих. Скорости посл чтения в районе 4Гб/сек, прошу заметить. А для грядущего X5 пропускная способность даже случайного чтения (многопоточного) уже 6 Гб/с.

"Производитель показал результаты тестов накопителя Rocket X5 объёмом 2 Тбайт в утилите CrystalDiskMark 8.0.4. Новинка достигла скорости последовательного чтения в 14 179 Мбайт/с. Показатель скорости последовательной записи в свою очередь у неё составил 12 280 Мбайт/с. Цифры производительности в операциях случайного чтения и записи блоков данных объёмом 4 Kбайт тоже оказались высокими."

https://3dnews.ru/1089630/sabrent-vipustit-nvmenakopiteli-rocket-x5-so-skorostyu-chteniya-vishe-14-000-mbayts

#astronomy #biology #venus #lifeorigin

"На ежегодном собрании Королевского астрономического общества в Кардиффе астроном Джейн Гривз из Кардиффского университета в Уэльсе сообщила, что её группа снова обнаружила фосфин в атмосфере Венеры. Ранее она сообщала о таком же открытии в 2020 году, но тогда оно вызвало шквал критики и не было подтверждено сторонними наблюдениями. Учёная утверждает, что искать это химическое соединение необходимо глубже в атмосфере Венеры, и она его там нашла. По словам Джейн Гривз, искать нужно было на другой высоте. Её группа снова обнаружила следы фосфина «примерно в середине облачного покрова Венеры». Ждём реакции научного мира. Жаль, что миссия компании Rocket Lab к Венере отложена до 2025 года или на большее время. Они как раз собирались туда лететь в этом году для поиска неуловимого фосфина."

https://3dnews.ru/1089637/v-oblakah-veneri-snova-obnarugili-priznaki-sushchestvovaniya-gizni-okazalos-chto-ranshe-iskali-ne-tam

#trading #lob

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

#trading #zhang #finance

Недавно постил лекцию Жихонг Жанга по DL на MOB, вы только посмотрите, насколько плодовит данный учёный!
Мама мия, 37 работ, и многие очень интересны уже по заголовкам. А, или то был Жихао. Все молодцы, в общем )
С нетерпением начту прочтение их совместной работы с Хуйлинь Юанем, не побоюсь этого имени, "Forecasting security's volatility using low-frequency historical data, high-frequency historical data and option-implied volatility".

https://arxiv.org/search/q-fin?searchtype=author&query=Zhang%2C+Z

#games

Bramble: The Mountain King — дуб, терновник и ясень.

"Не ходите, дети, ночью в лес гулять. Терновник запутает, терновник опутает, терновник утащит в чащу. Так предупреждает книга, которую на ночь читают брат и сестра — Олле и Лиллемор. Теперь Олле стоит перед книгой один, за окном ночь, ставни приоткрыты. Лиллемор нигде не видно. Что делать? Остается только спуститься по простыне из окна вниз, на полянку, — без сестры как-то не по себе. Да и сказки всё это, кто в них верит. Ну а родители… Какие родители?.."

https://3dnews.ru/1089436/bramble-the-mountain-king-retsenziya

#chess #analytics #streaks

Занимался весь день какой-то чепухой. Недавно был блиц-турнир шахматных стримеров, победителя обвинили в читерстве. Одним из критериев было озвучено 13 побед кряду над соперниками со сравнимым или более высоким рейтингом. Скачал все игры обвинителя, обвиняемого, и занявшего второе место (30 тыс игр). Показал, что выполнение такого "критерия" не такая уж редкость.

#ml #competitions #kaggle #dl #cnn

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

#hardware #amd #ml

"C выходом обновлённых версий фреймворка PyTorch 2.0 и платформы ROCm 5.4+ ситуация изменилась — обучение LLM стало возможным на ускорителях AMD Instinct MI250 без изменений кода при использовании её стека LLM Foundry Некоторые основные моменты:

Обучение LLM было стабильным. С высокодетерминированным обучающим стеком LLM Foundry обучение LLM MPT-1B на ускорителях AMD MI250 и NVIDIA A100 дало почти идентичные кривые потерь при запуске с одной и той же контрольной точки. Исследователи даже смогли переключаться между ускорителями AMD и NVIDIA в течение тренировочного прогона.
Производительность была конкурентоспособной с существующими системами A100. Исследователи профилировали пропускную способность обучения моделей MPT с параметрами от 1 до 13 млрд и обнаружили, что скорость обработки MI250 на один ускоритель находится в пределах 80 % от A100-40GB и в пределах 73 % от A100-80GB. Как ожидает компания, этот разрыв сократится по мере улучшения программного обеспечения AMD."

https://servernews.ru/1089341

#trading #finance #lob #dl

Очень интересные открытия: нет следов большой нестационарности (даже для 1 года OOS), 1 модель для всех активов лучше отдельных моделей для каждого актива. Использование моделек с памятью типа LSTM улучшает точность (от 100 до 5000 тиков, к примеру, на 1% - path dependence/long memory effects).

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

#optimization #ml #metrics #python #numba #codegems

В общем, sklearn-овские метрики оказались слишком медленными, пришлось их переписать на numba. Вот пример classification_report, который работает в тысячу раз быстрее и поддерживает почти всю функциональность (кроме весов и микровзвешивания). Также оптимизировал метрики auc (алгоритм взят из fastauc) и calibration (считаю бины предсказанные vs реальные, потом mae/std от их разностей). На 8M сэмплов всё работает за ~30 миллисекунд кроме auc, та ~300 мс. Для сравнения, scikit-learn-овские работают от нескольких секунд до нескольких десятков секунд.

@njit()
def fast_classification_report(
y_true: np.ndarray, y_pred: np.ndarray, nclasses: int = 2, zero_division: int = 0
):
"""Custom classification report, proof of concept."""

N_AVG_ARRAYS = 3 # precisions, recalls, f1s

# storage inits
weighted_averages = np.empty(N_AVG_ARRAYS, dtype=np.float64)
macro_averages = np.empty(N_AVG_ARRAYS, dtype=np.float64)
supports = np.zeros(nclasses, dtype=np.int64)
allpreds = np.zeros(nclasses, dtype=np.int64)
misses = np.zeros(nclasses, dtype=np.int64)
hits = np.zeros(nclasses, dtype=np.int64)

# count stats
for true_class, predicted_class in zip(y_true, y_pred):
supports[true_class] += 1
allpreds[predicted_class] += 1
if predicted_class == true_class:
hits[predicted_class] += 1
else:
misses[predicted_class] += 1

# main calcs
accuracy = hits.sum() / len(y_true)
balanced_accuracy = np.nan_to_num(hits / supports, copy=True, nan=zero_division).mean()

recalls = hits / supports
precisions = hits / allpreds
f1s = 2 * (precisions * recalls) / (precisions + recalls)

# fix nans & compute averages
i=0
for arr in (precisions, recalls, f1s):
np.nan_to_num(arr, copy=False, nan=zero_division)
weighted_averages[i] = (arr * supports).sum() / len(y_true)
macro_averages[i] = arr.mean()
i+=1

return hits, misses, accuracy, balanced_accuracy, supports, precisions, recalls, f1s, macro_averages, weighted_averages