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
#numba #codegems #shuffle #random #numpy

На удивление, нумба ускоряет и функции нампай для работы со случайными числами. Пользуйтесь!
#distributions #brokeback

Как вам такое распределеньице? )
#trading #backtesting #masters

"Thank you Dr. Masters for an outstanding sharing of your insight and experience and for agreeing to be interviewed! The clear denoscriptions of Monte Carlo Permutation Tests (MCPT-3 variants) and application BEFORE looking at precious out-of-sample data, Parameter Sensitivity, Stationarity, Entropy, Predictive Indicators and Bootstrapping are tremendously helpful to me as a strategy developer. I realize now that MCPT needs to be added to my strategy development process as well as the other elements you've articulated. Thank you, Andrew, for continually bringing gifted trading professionals to Better System Trader here on Youtube!"

https://www.youtube.com/watch?v=1RKz9v_0WDo
Есть большой массив Numpy с результатами вычислений. На очередной итерации вам надо его обнулить. Что сработает гораздо быстрее:
Anonymous Quiz
47%
a = np.zeros(shape)
17%
a[:,:] = 0
36%
a.fill( 0)
#featureselection #diogenes

Кипит работа над отборщиком признаков. Вчера провел много тестов, профилирования, оптимизаций. План на сегодня:

1) модуляризировать, разбив на мелкие хорошо читаемые функции. а то пока что это огромное полотно кода.
2) подключить многоядерность (numba или joblib/dask)
3) добить постанализ: больше мерности, добавить показатели иерархии, сделать доп. вывод деревом.
4) сделать этот FS совместимым с sklearn

Ну ладно, будем реалистами, это не на сегодня, а скорее на несколько ближайших дней. Кстати, после консультаций с AI определилось имя проекта: Диоген )

Diogenes of Sinope (c. 412-323 BCE) was a Cynic philosopher known for his extreme simplicity, ascetic lifestyle, and highly selective approach to life. He rejected societal norms, material possessions, and conventional values, living in minimalistic conditions.

One of the most famous anecdotes about Diogenes highlights his selectiveness and disregard for social conventions. He was known to carry a lantern during the day, claiming to be searching for an honest person but never finding one. This act symbolized his highly critical and selective stance toward human behavior and moral integrity.

Diogenes also practiced what he called "autarky," which meant self-sufficiency. He believed in rejecting desires and wants, demonstrating a selective attitude towards material possessions and comforts. He was known for living in a large ceramic jar, or "diogenes," which further emphasized his rejection of societal norms and his selectiveness in embracing only what was essential.

Through these behaviors and attitudes, Diogenes exemplified a highly selective and discerning approach to life, values, and human interaction. His actions challenged conventional ideas and highlighted his commitment to living in accordance with his own principles, even if they were unconventional or extreme.
1
#numpy #numba #codegems #calloc

Итак, выяснилось, что numpy.zeros делегирует вызов сишной calloc, и на самом деле читит. Если тестировать инициализацию массива с реальной записью хотя бы 1 элемента, всё стаёт на свои места. .zeros() чуть медленнее остальных, .fill(0) несущественно быстрее двоеточий. Но удивительно, что нумба медленнее в 2-8 раз.

shape = (10000, 10000)
a = np.zeros(shape, dtype=np.int64)

def alloc_new(a):
a = np.zeros(shape, dtype=np.int64)
a[500, 500] = 1
return a

def numpy_fancy_assign(a):
a[:, :] = 0
a[500, 500] = 1
return a

def numpy_fill(a):
a.fill(0)
a[500, 500] = 1
return a

def cyclces_assign(a):
for i in range(a.shape[0]):
for j in range(a.shape[1]):
a[i, j] = 0
a[500, 500] = 1
return a

njitted_funcs = []
funcs = (alloc_new, numpy_fancy_assign, numpy_fill, cyclces_assign)
for func in funcs:
njitted_func = njit(func)
njitted_func(a) # test call
njitted_funcs.append(njitted_func)
1
#numpy #numba #codegems #zeros

История с zeros не закончилась )) Открылись новые факты. Я подумал, нумба показалась медленной из-за переключения контекста, поэтому внутри каждой функции выше просто сделал цикл до 10, чтобы основную работ вести внутри контекста. К примеру,

def numpy_fancy_assign(a):
for _ in range(10):
a[:, :] = 0
a[500, 500] = 1
return a

и т.д.
Выводы из прошлого поста подтвердились: numba-версии действительно медленнее numpy-евских, КРОМЕ a[:, :] = 0, которая одна-единственная при выполнении в контексте numba в 5 раз быстрее зануляет numpy-массив, чем сам numpy.

Оптимальная тактика на сегодня: массив создавать надо вне numba с помощью .zeros(), а обнулять его вызовом a[:, :] = 0 внутри numba (если, конечно, это надо делать много раз). Feature request чтобы нумба редиректила на np.zeros.
#featureselection #diogenes

Придумал ещё несколько полезностей для Диогена:

1) мультитаргет. у меня уже и так можно использовать в качестве таргета многомерный вектор (что бы это ни значило), в таком случае влияние факторов будет оцениваться совместно на все указанные компоненты. но иногда есть много таргетов, для которых надо найти лучшие факторы (и потом построить модельки) по отдельности. В таком случае для энтропийных методов можно СИЛЬНО сэкономить время, меняя только часть слагаемых в формулах. Это, кстати, позволит эффективно просчитывать факторы для multilabel classification.

2) бюджет времени. у меня сейчас можно искать лучшие факторы с остановкой по 3 критериям:

пока ценность новых кандидатов не станет меньше порога;

пока самые перспективные кандидаты не "провалятся" при перестановочном тестировании более N раз подряд

пока не исчерпается лимит взаимодействий, которые хочется проверить (обычно от 1 до 3).

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

3) GPU. Можно попробовать cuda-возможности numba. И/или заюзать cupy, я в бою ещё не пробовал это.

4) Dask. Пока ещё думаю, как реализовать многоядерность на CPU. Наверное, лучше сразу на joblib делать, чтобы было совместимо с Dask.

У меня несколько блоков, подлежащих параллельным вычислениям:

предварительная оценка всех кандидатов против уже отобранных - можно разбивать поровну на число воркеров, по завершении синхронизировать кэши

финальная оценка лучшего кандидата MCPT с большим количеством перестановок - можно разбивать повторения по воркерам, результаты суммировать

пост-анализ, когда все прошедшие отбор кандидаты пересчитываются против остальных финалистов:
а) еще раз по критерию Fleuret, на этот раз на полном множестве конкурентов, с возможным отсевом
б) на предмет коллинеарности по критерию взаимной информации, с возможностью учета 2-, 3-way связей

ну тут тоже параллелится весьма очевидно

5) Если ограничиться 1-way взаимодействиями, то можно применять и другие критерии вместо энтропийных. corcoeff, ftest, Kendall’s Tau, Spearman’s rho, etc. Избыточность оценивать можно ещё с помощью метода PLD, когда с уже выбранными факторами у кандидата считается информация не по таргету условная по фактору взаимная, а просто средняя взаимная кандидатов и фактора.
Тест на знание английского! Не заглядывайте в словарь ) Что означает слово trepidation?
Anonymous Quiz
13%
трепет
0%
репутация
16%
гнев
42%
воздержание
29%
такого слова в английском нет
👍1
#postgres #db

А тем временим готовится к релизу Постгре 16.

Из интересного:

Allow parallelization of FULL and internal right OUTER hash joins (Melanie Plageman, Thomas Munro)
Allow optimization of always-increasing window functions ntile(), cume_dist() and percent_rank() (David Rowley)

Add system view pg_stat_io view to track IO statistics (Melanie Plageman)
Record statistics on the last sequential and index scans on tables (Dave Page) This information appears in pg_stat_all_tables and pg_stat_all_indexes.

Create a predefined role and grantable privilege with permission to perform maintenance operations (Nathan Bossart) The predefined role is is called pg_maintain.
Add predefined role pg_create_subnoscription with permission to create subnoscriptions (Robert Haas)

Add support for regular expression matching on database and role entries in pg_hba.conf (Bertrand Drouvot)

Allow NUMERIC to process hexadecimal, octal, and binary integers of any size (Dean Rasheed) Previously only unquoted eight-byte integers were supported with these non-decimal bases.
Allow underscores in integer and numeric constants (Peter Eisentraut, Dean Rasheed) This can improve readability for long strings of digits.
Accept the spelling "+infinity" in datetime input (Vik Fearing)

Allow parallel application of logical replication (Hou Zhijie, Wang Wei, Amit Kapila)

Allow the STORAGE type to be specified by CREATE TABLE (Teodor Sigaev, Aleksander Alekseev) Previously only ALTER TABLE could control this

Allow subqueries in the FROM clause to omit aliases (Dean Rasheed)

Change date_trunc(unit, timestamptz, time_zone) to be an immutable function (Przemyslaw Sztoch) This allows the creation of expression indexes using this function.
Add functions array_sample() and array_shuffle() (Martin Kalcher)
Add aggregate function ANY_VALUE() which returns any value from a set (Vik Fearing)
Add function random_normal() to supply normally-distributed random numbers (Paul Ramsey)
Add error function erf() and its complement erfc() (Dean Rasheed)

Add libpq option sslcertmode to control transmission of the client certificate (Jacob Champion) The option values are "disable", "allow", and "require".

Add LZ4 and Zstandard compression to pg_dump (Georgios Kokolatos, Justin Pryzby)
Allow pg_dump and pg_basebackup to use "long" mode for compression (Justin Pryzby)

Add support for SSE2 (Streaming SIMD Extensions 2) vector operations on x86-64 architectures (John Naylor) вот это странно, этой поддержки не было, чтоль?
Add support for Advanced SIMD (Single Instruction Multiple Data) (NEON) instructions on ARM architectures (Nathan Bossart)

Require Windows 10 or newer versions (Michael Paquier, Juan José Santamaría Flecha) Previously Windows Vista and Windows XP were supported. Вот это вряд ли можно считать улучшением.


https://www.postgresql.org/docs/16/release-16.html
#poetry #music #mantus #deutsch #translation

An empty vessel by the shore's edge roams,
A forgotten orphan left to wither alone,
Tulips, decayed, on asphalt they lie,
The night wraps itself in a mute lullaby.

Birds circle and then take their flight,
From the sky descends the final rite,
The owl flees its forest domain,
Blood drips from trees like crimson rain.

Words that once echoed now faded away,
Legends of unity in disarray,
A darkened sea consumes dreams in decay,
Of us, not a trace, all led astray.

The deceased repose in their earthen bed,
A stranger's gaze, a fleeting shred,
Drawn into solitude, voices worn thin,
All that remains is the quiet within.

Elven fury scalds the pale moon's light,
The black plague reigns, a grievous blight,
In damp warmth, a sultry shimmering gloom,
And the stool falls silently in the room.

оригинал

"Ein leeres Boot, das am Ufer treibt
Ein Waisenkind, das vergessen bleibt
Die Tulpen modern auf dem Asphalt
Die Nacht hüllt sich in Schweigen

Die Vögel kreisen und ziehen fort
Vom Himmel tönet der Schlussakkord
Die Eule flüchtet aus ihrem Wald
Das Blut tropft von den Bäumen

Die Worte sind schon längst verhallt
Legenden von Zusammenhalt
Ein dunkles Meer verschluckt den Traum
Von uns ist nichts geblieben

Der Tote sinkt ins Grab zurück
Den Fremden streift ein letzter Blick
Man schließt sich ein, man redet kaum
Von uns ist nichts geblieben

Ein kalter Abend zieht schnell heran
Ein Krieger rudert durch tiefen Schlamm
Der weiße Magier sucht das Exil
Ein Haus versinkt im Nebel

Der Zorn der Elfen verbrennt den Mond
Die schwarze Pest über allem thront
Und feuchte Wärme, sie flimmert schwül
Und lautlos fällt der Schemel

Die Worte sind schon längst verhallt
Legenden von Zusammenhalt
Ein dunkles Meer verschluckt den Traum
Von uns ist nichts geblieben"


https://www.youtube.com/watch?v=Br1LgdnmQcQ
#ml #applied #dyakonov #pzad #featureselection #permutationimportance #mid #pfi #boruta #ace

Artificial contrasts with ensembles - примечательный метод. Ещё интересна идея, что в обёрточных методах FS оценивать важность признаков надо не тем классом моделей, который будет в итоге обучаться для решения самой ML задачи.

https://www.youtube.com/watch?v=ZRa7-F5PvRk&list=PLaRUeIuewv8CMFox0oEjlyePUhUmo-x0h&index=28
#gpu #cupy #codegems

How to write CPU/GPU agnostic code
CuPy’s compatibility with NumPy makes it possible to write CPU/GPU agnostic code. For this purpose, CuPy implements the cupy.get_array_module() function that returns a reference to cupy if any of its arguments resides on a GPU and numpy otherwise. Here is an example of a CPU/GPU agnostic function that computes log1p:

# Stable implementation of log(1 + exp(x))
def softplus(x):
xp = cp.get_array_module(x) # 'xp' is a standard usage in the community
print("Using:", xp.__name__)
return xp.maximum(0, x) + xp.log1p(xp.exp(-abs(x)))


https://docs.cupy.dev/en/stable/user_guide/basic.html
#zuck #sport #martialarts

"Джиу-джитсу — не единственное увлечение Цукерберга. Недавно глава популярных соцсетей с состоянием 89,9 миллиарда долларов удивил подписчиков брутальными снимками с экстремальной тренировки. На фотографии, опубликованной 31 мая, изможденный бизнесмен с капельками пота на лице и рельефными бицепсами сделал селфи в бронежилете весом около девяти килограммов. Миллиардер рассказал, что прошел челлендж Мерфи, выполнив в этом самом бронежилете за неполные 40 минут 100 подтягиваний, 200 отжиманий и 300 приседаний, а после этого пробежал километр."

Про боевое кряхтение позабавило )

https://lenta.ru/news/2023/06/07/zucker/
#featureselection #diogenes #optimisation #gpu #cuda #cupy

Докладываю новости о проекте Диоген. Вчера добавил бюджет времени, переписал функции покрасивее, потестировал все ветки. С указанием допустимого времени работает просто отлично.

Сегодня ещё добавил функциональность random seed. Выяснилось, что нумба не подтягивает его из нампай "обычного" режима, надо в njit-нутой функции его ещё раз выставлять.

Отпрофилировал код на глубинах 1-2 взаимодействий признаков. Оказалось, что 80% времени кушает оценка кандидатов, и 20% времени - расчёт надёжности для лучших кандидатов. Из этих 80% основные опять же ~80% тратятся в прямой оценке MI кандидата и таргета.

Дальше они распадаются так: 20% на слияние многомерного вектора, 70% на перемешивание таргета (np.random.shuffle), 10% на сам расчёт MI из совместного распределения.

Очевидно, выгоднее всего оптимизировать шаффл таргета. Решил попробовать cupy как замену numpy: просто перенести таргет в память gpu и шаффлить прямо там. Улучшения таймингов это не дало, т.к. перемешанный, пусть и быстро, массив 120k элементов всё равно надо было копировать обратно в RAM для подсчёта MI.

К счастью, подумал я, cupy позволяет писать и запускать произвольные ядра Cuda в C++ прямо из питона. Почему бы не выполнить расчёт гистограммы и MI прямо на GPU? Капец я с этим намучался ) Я же совсем забыл, что программирование для GPU - это сущий ад после "обычного", в поточной парадигме: ваша программа выполняется сразу на тысячах потоков, куча ограничений и условий, разделяемая память,синхронизация, атомики, блоки... Плюс я совсем забыл С++ (даже то немногое, что знал). Да ещё cupy иногда радовал перлами типа невозможности подсчитать сумму массива без Visual Studio 2019 (хотя максимум считался нормально).

В итоге всё же добил эту идею, и сейчас у меня есть реализация критической части на Cuda )

Что же по скорости?

%timeit показывает, что массив 120k элементов ноутбучная 1050Ti шаффлит в 4 раза быстрее, чем i7-7700HQ. То есть я могу ожидать, что 0.8*0.8*0.7=40% всего времени исполнения сократится в 4 раза. Если поиск на CPU идёт 15 минут, то можно ожидать, что на GPU это будет 15*0.6+15*0,4/4=11 минут.

Напрямую сравнить CPU и GPU не получается, т.к. у разных библ разные сиды и порядок выполнения операций, а длительность всего поиска зависит от случайных решений. Пара запусков дала новое время 12.5-13.0 минут вместо 15. Возможно, где-то налажал, буду ещё профилировать. Но timeit шаффла массива 1M элементов даёт выигрыш уже не в 4, а в 40 раз, т.е., по идее, GPU будет ещё выгоднее для больших датасетов.
1
#nvidia

"В настоящий момент стоимость каждого ускорителя NVIDIA H100 в зависимости от региона продаж и поставщика в среднем составляет $25–30 тыс. При этом речь идёт о менее дорогой PCIe-версии указанного решения. По оценкам Raymond James, стоимость использующегося в этом ускорителе графического процессора, а также дополнительных материалов (печатной платы и других вспомогательных элементов) составляет $3320. К сожалению, Ким не уточняет глубину анализа расчёта стоимости и не поясняет, включены ли в этот показатель такие факторы, как затраты на разработку, зарплата инженеров, а также стоимость производства и логистики.

Разработка специализированных ускорителей требует значительного времени и ресурсов. По данным того же портала Glassdoor, средняя зарплата инженера по аппаратному обеспечению в NVIDIA составляет около $202 тыс. в год. Речь идёт только об одном инженере, но очевидно, что при разработке тех же H100 работала целая команда специалистов, а на саму разработку были затрачены тысячи рабочих часов. Всё это должно учитываться в конечной стоимости продукта.

И всё же очевидно, что сейчас NVIDIA в вопросе поставок аппаратных средств для ИИ-вычислений находится вне конкуренции. На специализированные ускорители «зелёных» сейчас такой спрос, что они распродаются ещё задолго до того, как попадают на условные полки магазинов. Поставщики говорят, что очередь за ними растянулась до второго квартала 2024 года. А с учётом последних оценок аналитиков, согласно которым к 2027 году рынок ИИ-вычислений вырастет до $150 млрд, ближайшее будущее NVIDIA видится точно безбедным.

С другой стороны, для рынка в целом высокий спрос на ускорители ИИ-вычислений имеет свои негативные последствия. В последних отчётах аналитиков говорится, что продажи традиционных серверов (HPC) в глобальном масштабе сокращаются. Основная причина падения спроса заключается в том, что гиперскейлеры и операторы ЦОД переключают внимание на системы, оптимизированные для ИИ, в которых используются решения вроде NVIDIA H100. По этой причине тем же производителям памяти DDR5 пришлось пересмотреть свои ожидания относительно распространения нового стандарта ОЗУ на рынок, поскольку операторы ЦОД сейчас активно инвестируют именно в ускорители ИИ, а не в новый стандарт оперативной памяти. На фоне это ожидается, что уровень внедрения DDR5 достигнет паритета с DDR4 только к третьему кварталу 2024 года."

https://3dnews.ru/1091667/nvidia-h100-1000-procentov-viruchki