Как бороться с большим количеством факторов / категорий в рамках partykit
Я использую partykit пакет и попадаются следующие сообщения об ошибке:
Error in matrix(0, nrow = mi, ncol = nl) :
invalid 'nrow' value (too large or NA)
In addition: Warning message:
In matrix(0, nrow = mi, ncol = nl) :
NAs introduced by coercion to integer range
Я использовал пример, приведенный в этой статье, который сравнивает пакеты и их обработку с множеством категорий.
Проблема в том, что используемая переменная расщепления имеет слишком много категорий. В пределах mob() функционирует матрица со всеми возможными разбиениями. Эта матрица имеет размер p * (2^(p-1)-1)где p - количество категорий расщепляющей переменной. В зависимости от используемых системных ресурсов (ОЗУ и т. Д.) Данная ошибка возникает для разных чисел p.
В статье предлагается использование критерия Джини. Я думаю, что с целью пакета partykit критерий Джини не может быть использован, потому что у меня нет проблемы классификации с целевой переменной, но есть проблема спецификации модели.
Поэтому мой вопрос: есть ли способ найти разбиение для таких случаев или способ уменьшить количество проверок?
1 ответ
Этот прием поиска только k упорядоченных разбиений, а не 2^k -1 неупорядоченных разделов, работает только при определенных обстоятельствах, например, когда возможно упорядочить ответ по их среднему значению в каждой категории. Я никогда не смотрел на основную теорию достаточно подробно, но это работает только при определенных допущениях, и я не уверен, достаточно ли хорошо они где-то изложены. Вам, безусловно, нужна одномерная задача в том смысле, что оптимизируется только один базовый параметр (обычно среднее значение). Возможно, непрерывная дифференцируемость целевой функции также может быть проблемой, учитывая акцент на Джини.
Как mob() вероятно, чаще всего применяется в ситуациях, когда вы разделяете более одного параметра, я не думаю, что можно использовать этот трюк. Так же, ctree() может легко применяться в ситуациях с многовариантными оценками, даже переменная отклика является унивариантной (например, для определения местоположения и разницы шкалы).
Обычно я бы рекомендовал разбить фактор со многими уровнями на более мелкие части. Например, если у вас есть коэффициент для почтового индекса наблюдения: тогда можно использовать коэффициент для штата / провинции и числовую переменную, кодирующую "размер" (площадь или население), коэффициент, кодирующий сельское и городское, и т.д. Конечно, это дополнительная работа, но, как правило, она также приводит к более понятным результатам.
Сказав это, мы хотим, чтобы partykit использовал такие хитрости, если они доступны. Но это не на вершине нашей текущей повестки дня...
Я использовал способ решения проблемы путем преобразования переменной в матрицу контраста, используя model.matrix(~ 0 + predictor, data). ctree() не может управлять длинными факторами, но может легко управлять наборами данных со многими переменными.
Конечно, есть и недостатки: при использовании этой техники вы теряете возможность кластеризации факторов. ctree(); каждый узел будет использовать только один уровень, поскольку теперь это разные столбцы.