R's caTools Sample.Split Результаты неверны

Я хотел бы предварить свой вопрос, заявив, что это распространенная проблема:

  1. Неправильное разделение данных использование sample.split в R и проблема с логистической регрессией
  2. Результаты SplitRatio с помощью sample.split (caTools)

Тем не менее, я не могу решить свою проблему, используя решения, рекомендованные в первом вопросе, а на второй так и не ответили.

В следующем коде я ожидаю 100 наблюдений для каждого из четырех результатов, поскольку очевидно, что 100/150 = 2/3:

library(caTools)
set.seed(123)

isample <- sample.split(iris[,1], SplitRatio = 2/3, group = NULL)
iris2 <- iris[isample,]

isample2 <- sample.split(iris[,1], SplitRatio = 2/3, group = NULL)
iris3 <- subset(iris, isample2 == T)

isample3 <- sample.split(iris$Sepal.Length, SplitRatio = 2/3, group = NULL)
sepal.length2 <- iris[isample3,1]

isample4 <- sample.split(iris$Sepal.Length, SplitRatio = 2/3, group = NULL)
sepal.length3 <- subset(iris[,1], isample4 == T)

Однако я получаю 104 наблюдения как в iris2, так и в iris3, а также в векторах sepal.length2 и sepal.length3. Я каждый раз рисую новую выборку, чтобы убедиться, что это не что-то странное с округлением в функции выборки. Использование столбцов 2 и 3 из iris возвращает 100 наблюдений, а использование столбца 5 возвращает 99 наблюдений. Почему изменение столбца возвращает разные значения? Распространенная ошибка этой функции заключается в том, что она случайно передает ей весь фрейм данных, поэтому она выбирает на основе столбцов, но здесь я каждый раз задаю ей вектор. В последних двух примерах я задаю вектор, а затем определяю разбиение по вектору, и это все равно не работает.

Если это поможет, я запускаю R 3.6.0 и caTools 1.18.0 на OS X. Обычно я использую функцию sample или sample.int, поэтому я не очень хорошо знаком с caTools.


r data-partitioning
person permanently_confused    schedule 18.10.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

После поиска и небольшого тестирования исходного файла, доступного [здесь],1 Я пришел к выводу, что это происходит из-за накопления ошибок округления в том, как авторы написали эту функцию. Цикл, начинающийся с for( iU in 1:nU), округляет количество случайных отрисовок на каждой метке, так что для отношения, подобного 2/3, и метки, скажем, с 4 вхождениями в данных, мы получаем n = round(length(idx)*rat), которое округляется до 3, или 8 * 2. /3 раундов до 5. В ходе цикла это приводит к пересчету.

Перечитывая документацию sample.split, в ней говорится, что данные из вектора Y разделены на два набора в предопределенном соотношении, при этом сохраняются относительные соотношения различных меток в Y. Итак, я пришел к выводу, что эта функция вместо этого пытается сохранить соотношение каждого уникального label в векторе, что означает, что он пытается сохранить 2/3 вхождений 5,3 в длине чашелистика, 2/3 вхождений 4,9 и т. д. в каждом из тестового и обучающего набора. Пользователи этой функции предпочли бы неточное разделение тестирования/обучения и более точную ошибку тестирования в конце, так как они могут ожидать, что соотношение каждого события будет сохранено. Поскольку эта функция предназначена для классификации, я прихожу к выводу, что мне следует избегать ее использования в случаях, когда в данных много уникальных значений.

person permanently_confused    schedule 18.10.2020