#featureselection
Для проблемы мусорных факторов вижу 2 решения:
1) модифицировать критерий приёмки, чтобы он смотрел условные MI не по одиночным факторам, а по 2-way сочетаниям. Это уже отсеет значительный % мусорных факторов, которые коррелируют с 1 или 2 другими предикторами. Обязательно повторить эти расчёты по завершении отбора, когда сформирован полный набор факторов. Это наверняка отсеет некоторых кандидатов. Главное, учитывать, кто стал причиной отсева, чтобы не удалить причину и следствие одновременно )
2) делать пост-анализ по всем попавшим в финал кандидатам: кто связан с каким количеством других факторов, какое количество информации с ними разделяет, в % к своей собственной энтропии. Можно даже спуститься вниз по уровню и посчитать взвешенные суммы тех же метрик для его партнёров. Тем самым можно косвенно определить, какие фичи скорее всего просто сливные бачки, и попробовать их выбросить. В итоге мы получим:
ценные фичи, которые ни с кем другим не связаны, кроме мусорных и таргета. они содержат уникальное знание;
потенциально мусорные X, которые связаны с множеством других, и шарят очень много общей инфы с другими факторами Z, при том, что эти другие факторы имеют много уникального знания о таргете помимо X: sum(I(Y;Z|X))>e;
все остальные "середнячки".
Лучше идеи у меня пока нет, т.к. если это будет задача на временные ряды, где есть зависимость по 100+ лагам, я не знаю способа, как высчитать именно уникальную информацию фичи. Ладно бы 2-3, для этой мерности MI и CMI я посчитать ещё могу, но что-то мне подсказывает, в реальности будет сотни и тысячи. Буду рад советам.
Ах да, упомянутый недавно алгоритм PLD/MIFS для учёта избыточности просто считает среднюю взаимную информацию уже отобранных факторов с кандидатом. Но это тоже не идеальное решение, т.к. если кандидат А связан с факторами Б и В, усреднение (или суммирование) сработает только если Б и В независимы.
Для проблемы мусорных факторов вижу 2 решения:
1) модифицировать критерий приёмки, чтобы он смотрел условные MI не по одиночным факторам, а по 2-way сочетаниям. Это уже отсеет значительный % мусорных факторов, которые коррелируют с 1 или 2 другими предикторами. Обязательно повторить эти расчёты по завершении отбора, когда сформирован полный набор факторов. Это наверняка отсеет некоторых кандидатов. Главное, учитывать, кто стал причиной отсева, чтобы не удалить причину и следствие одновременно )
2) делать пост-анализ по всем попавшим в финал кандидатам: кто связан с каким количеством других факторов, какое количество информации с ними разделяет, в % к своей собственной энтропии. Можно даже спуститься вниз по уровню и посчитать взвешенные суммы тех же метрик для его партнёров. Тем самым можно косвенно определить, какие фичи скорее всего просто сливные бачки, и попробовать их выбросить. В итоге мы получим:
ценные фичи, которые ни с кем другим не связаны, кроме мусорных и таргета. они содержат уникальное знание;
потенциально мусорные X, которые связаны с множеством других, и шарят очень много общей инфы с другими факторами Z, при том, что эти другие факторы имеют много уникального знания о таргете помимо X: sum(I(Y;Z|X))>e;
все остальные "середнячки".
Лучше идеи у меня пока нет, т.к. если это будет задача на временные ряды, где есть зависимость по 100+ лагам, я не знаю способа, как высчитать именно уникальную информацию фичи. Ладно бы 2-3, для этой мерности MI и CMI я посчитать ещё могу, но что-то мне подсказывает, в реальности будет сотни и тысячи. Буду рад советам.
Ах да, упомянутый недавно алгоритм PLD/MIFS для учёта избыточности просто считает среднюю взаимную информацию уже отобранных факторов с кандидатом. Но это тоже не идеальное решение, т.к. если кандидат А связан с факторами Б и В, усреднение (или суммирование) сработает только если Б и В независимы.
#featureselection
Работаю над пост-анализом кандидатов в предикторы, отобранных FS алгосом. Решил представить их как граф друзей )
Размер узла=энтропии фактора. Толщина и цвет ребра=взаимной инфе 2 факторов.
Направление стрелки зависит от ADC.
Зелёные узлы - уникальные факторы, красные - предположительно "мусорки".
Работаю над пост-анализом кандидатов в предикторы, отобранных FS алгосом. Решил представить их как граф друзей )
Размер узла=энтропии фактора. Толщина и цвет ребра=взаимной инфе 2 факторов.
Направление стрелки зависит от ADC.
Зелёные узлы - уникальные факторы, красные - предположительно "мусорки".
#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
"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
YouTube
"How to avoid trading strategies that degrade quickly" - Timothy Masters
Numerical Computing specialist and author Timothy Masters joins us (in his only ever interview) to discuss trading strategy development and validation techniques, including:
• Why trading strategies fall apart in live trading,
• How luck impacts trading…
• Why trading strategies fall apart in live trading,
• How luck impacts trading…
Есть большой массив 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) модуляризировать, разбив на мелкие хорошо читаемые функции. а то пока что это огромное полотно кода.
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 раз.
Итак, выяснилось, что 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, чтобы основную работ вести внутри контекста. К примеру,
Выводы из прошлого поста подтвердились: numba-версии действительно медленнее numpy-евских, КРОМЕ
Оптимальная тактика на сегодня: массив создавать надо вне numba с помощью .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, когда с уже выбранными факторами у кандидата считается информация не по таргету условная по фактору взаимная, а просто средняя взаимная кандидатов и фактора.
Придумал ещё несколько полезностей для Диогена:
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
#facebooks #ads
https://3dnews.ru/1091463/norvegiya-nachala-shtrafovat-meta-na-100-tis-v-den-za-narushenie-pravil-konfidentsialnosti-polzovateley
https://3dnews.ru/1091463/norvegiya-nachala-shtrafovat-meta-na-100-tis-v-den-za-narushenie-pravil-konfidentsialnosti-polzovateley
3DNews - Daily Digital Digest
Норвегия начала штрафовать Meta✴ на $100 тыс. каждый день за таргетинг рекламы
Управление по защите данных Норвегии начинает взимать штраф в размере 1 млн норвежских крон (около $100 тыс.
😁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
А тем временим готовится к релизу Постгре 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
PostgreSQL Documentation
E.12. Release 16
E.12. Release 16 # E.12.1. Overview E.12.2. Migration to Version 16 E.12.3. Changes E.12.4. Acknowledgments Release date: 2023-09-14 E.12.1. Overview # PostgreSQL 16 …
#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
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
YouTube
Legenden
Provided to YouTube by Trisol
Legenden · Mantus
Wölfe
℗ Trisol Music Group GmbH
Released on: 2012-11-16
Composer: Martin André Schindler
Lyricist: Martin André Schindler
Auto-generated by YouTube.
Legenden · Mantus
Wölfe
℗ Trisol Music Group GmbH
Released on: 2012-11-16
Composer: Martin André Schindler
Lyricist: Martin André Schindler
Auto-generated by YouTube.
#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
Artificial contrasts with ensembles - примечательный метод. Ещё интересна идея, что в обёрточных методах FS оценивать важность признаков надо не тем классом моделей, который будет в итоге обучаться для решения самой ML задачи.
https://www.youtube.com/watch?v=ZRa7-F5PvRk&list=PLaRUeIuewv8CMFox0oEjlyePUhUmo-x0h&index=28
YouTube
ПЗАД2020. Лекция 25. Важность признаков в ансамблях деревьев
курс "Прикладные задачи анализа данных", ВМК МГУ, Дьяконов Александр (https://dyakonov.org/ag/)
страница курса: https://github.com/Dyakonov/PZAD/blob/master/README.md
страница курса: https://github.com/Dyakonov/PZAD/blob/master/README.md
#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:
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))https://docs.cupy.dev/en/stable/user_guide/basic.html
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)))
#zuck #sport #martialarts
"Джиу-джитсу — не единственное увлечение Цукерберга. Недавно глава популярных соцсетей с состоянием 89,9 миллиарда долларов удивил подписчиков брутальными снимками с экстремальной тренировки. На фотографии, опубликованной 31 мая, изможденный бизнесмен с капельками пота на лице и рельефными бицепсами сделал селфи в бронежилете весом около девяти килограммов. Миллиардер рассказал, что прошел челлендж Мерфи, выполнив в этом самом бронежилете за неполные 40 минут 100 подтягиваний, 200 отжиманий и 300 приседаний, а после этого пробежал километр."
Про боевое кряхтение позабавило )
https://lenta.ru/news/2023/06/07/zucker/
"Джиу-джитсу — не единственное увлечение Цукерберга. Недавно глава популярных соцсетей с состоянием 89,9 миллиарда долларов удивил подписчиков брутальными снимками с экстремальной тренировки. На фотографии, опубликованной 31 мая, изможденный бизнесмен с капельками пота на лице и рельефными бицепсами сделал селфи в бронежилете весом около девяти килограммов. Миллиардер рассказал, что прошел челлендж Мерфи, выполнив в этом самом бронежилете за неполные 40 минут 100 подтягиваний, 200 отжиманий и 300 приседаний, а после этого пробежал километр."
Про боевое кряхтение позабавило )
https://lenta.ru/news/2023/06/07/zucker/
Lenta.RU
Марк Цукерберг бегает в бронежилете и дерется на ринге. Как миллиардер из гика превратился в Рэмбо?
Миллиардер с состоянием около 90 миллиардов долларов Марк Цукерберг уходит от образа домашнего интеллигентного парня и приобретает славу «дикого зверя» и опасного противника. Теперь основатель популярной социальной сети занимается спортивными единоборствами…
#cuda #gpu #architecture #programming
Напоминалка, как устроена программная модель Cuda. Что такое потоки, блоки, сетки.
https://developer.nvidia.com/blog/cuda-refresher-cuda-programming-model/
Напоминалка, как устроена программная модель Cuda. Что такое потоки, блоки, сетки.
https://developer.nvidia.com/blog/cuda-refresher-cuda-programming-model/
NVIDIA Technical Blog
CUDA Refresher: The CUDA Programming Model
This is the fourth post in the CUDA Refresher series, which has the goal of refreshing key concepts in CUDA, tools, and optimization for beginning or intermediate developers.
#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 будет ещё выгоднее для больших датасетов.
Докладываю новости о проекте Диоген. Вчера добавил бюджет времени, переписал функции покрасивее, потестировал все ветки. С указанием допустимого времени работает просто отлично.
Сегодня ещё добавил функциональность 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