Разница в предварительной обработке с использованием рецептов и предварительной обработки карета - PullRequest
0 голосов
/ 15 мая 2018

Я изучал новый пакет recipes для преобразования переменных как часть конвейера машинного обучения. Я выбрал этот подход - обновление с использованием функции caret preProcess из-за всех новых расширений. Но я обнаружил, что пакеты дают очень разные результаты для преобразованных данных:

library(caret) # V6.0-79
library(recipes) # V0.1.2
library(MASS) # V7.3-47
# transform variables using recipes
rec_box <- recipe(~ ., data = as.data.frame(state.x77)) %>% 
  step_BoxCox(., everything()) %>% 
  prep(., training = as.data.frame(state.x77)) %>% 
  bake(., as.data.frame(state.x77)) 

> head(rec_box)
# A tibble: 6 x 8
  Population Income Illiteracy `Life Exp` Murder `HS Grad` Frost  Area
       <dbl>  <dbl>      <dbl>      <dbl>  <dbl>     <dbl> <dbl> <dbl>
1       8.19   138.     0.647   60171653.   6.89      651.   20.  56.0
2       5.90   185.     0.376   61218586.   5.52     1632.  152. 106. 
3       7.70   155.     0.527   66409311.   4.08     1253.   15.  69.4
4       7.65   133.     0.570   66885876.   5.05      609.   65.  56.4
5       9.96   165.     0.0936  71570875.   5.13     1445.   20.  75.5
6       7.84   161.    -0.382   73188251.   3.62     1503.  166.  67.7

# transform variables using preProcess
pre_box <- preProcess(x = as.data.frame(state.x77), method = c('BoxCox')) %>% 
  predict(. ,newdata = as.data.frame(state.x77)) 

> head(pre_box)
    # A tibble: 6 x 8
      Population Income Illiteracy `Life Exp` Murder `HS Grad` Frost  Area
           <dbl>  <dbl>      <dbl>      <dbl>  <dbl>     <dbl> <dbl> <dbl>
    1       8.19   118.     0.642       2383.   6.83      618.   20.  38.7
    2       5.90   157.     0.374       2401.   5.47     1538.  152.  65.7
    3       7.70   133.     0.524       2488.   4.05     1183.   15.  46.3
    4       7.65   114.     0.566       2496.   5.01      579.   65.  38.9
    5       9.96   141.     0.0935      2571.   5.09     1363.   20.  49.7
    6       7.84   138.    -0.383       2596.   3.60     1418.  166.  45.4


## Subtract recipe transformations from MARS::boxcox via caret::preProcess
colMeans(rec_box - pre_box)

> colMeans(rec_box - pre_box)
  Population       Income   Illiteracy     Life Exp       Murder      HS Grad        Frost         Area 
0.000000e+00 2.215800e+01 2.515464e-03 6.803437e+07 2.638715e-02 5.883549e+01 0.000000e+00 1.745788e+01

Так что может показаться, что в некоторых столбцах они согласны, а в других все иначе. Любая причина, почему эти преобразования могут быть такими разными? Кто-нибудь еще обнаруживал подобные расхождения?

1 Ответ

0 голосов
/ 15 мая 2018

Разница обусловлена ​​округлением lambdas в функции preProcess, округленной до одного десятичного знака.

Проверьте этот пример:

library(caret) 
library(recipes) 
library(MASS)
library(mlbench)
data(Sonar)

df <- Sonar[,-61]

с использованием preProcess функция и установка fudge в 0 (нет допусков для 0/1 приведения лямбд).

z2 <- preProcess(x = as.data.frame(df), method = c('BoxCox'), fudge = 0)

и использование recepies:

z <- recipe(~ ., data = as.data.frame(df )) %>% 
  step_BoxCox(., everything()) %>% 
  prep(., training = as.data.frame(df))

позволяет проверить лямбда-выраженияrecepies:

z$steps[[1]]$lambdas
#output
        V1         V2         V3         V4         V5         V6         V7         V8         V9        V10        V11        V12 
0.09296796 0.23383117 0.19487939 0.11471259 0.18688851 0.35852835 0.48787887 0.36830343 0.26340880 0.29810673 0.33913896 0.50361765 
       V13        V14        V15        V16        V17        V18        V19        V20        V21        V22        V23        V24 
0.49178396 0.35997958 0.43900093 0.28981749 0.22843441 0.27016373 0.50573719 0.83436868 1.02366629 1.15194335 1.35062142 1.44484148 
       V25        V26        V27        V28        V29        V30        V31        V32        V33        V34        V35        V36 
1.51851127 1.61365888 1.47445453 1.44448827 1.22132457 1.00145613 0.66343491 0.61951328 0.53028496 0.45278118 0.39019507 0.37536033 
       V37        V38        V39        V40        V41        V42        V52        V53        V54        V55        V56        V57 
0.28428050 0.23439217 0.29554367 0.47263000 0.34455069 0.44036919 0.15240917 0.30314637 0.28647186 0.16202628 0.27153385 0.17005357 
       V58        V59        V60 
0.15688906 0.28761156 0.06652761 

и лямбды для preProcess:

sapply(z2$bc, function(x) x$lambda)
#output
 V1  V2  V3  V4  V5  V6  V7  V8  V9 V10 V11 V12 V13 V14 V15 V16 V17 V18 V19 V20 V21 V22 V23 V24 V25 V26 V27 V28 V29 V30 V31 V32 V33 V34 
0.1 0.2 0.2 0.1 0.2 0.4 0.5 0.4 0.3 0.3 0.3 0.5 0.5 0.4 0.4 0.3 0.2 0.3 0.5 0.8 1.0 1.2 1.4 1.4 1.5 1.6 1.5 1.4 1.2 1.0 0.7 0.6 0.5 0.5 
V35 V36 V37 V38 V39 V40 V41 V42 V52 V53 V54 V55 V56 V57 V58 V59 V60 
0.4 0.4 0.3 0.2 0.3 0.5 0.3 0.4 0.2 0.3 0.3 0.2 0.3 0.2 0.2 0.3 0.1 

Итак:

df$V1^z$steps[[1]]$lambdas[1]

не равно

df$V1^sapply(z2$bc, function(x) x$lambda)[1]

По умолчанию fudge = 0.2 разница будет еще выше, поскольку -0.2 - 02 будет изменено на 0, то есть преобразование log, а 0.8 - 1.2 лямбда будет заменено на 1 - без преобразования.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...