Чтение правильно (альфа) числовых полей в R

Question

Текстовый файл с разделителями табуляции, который фактически является экспортом (используя bcp) таблицы базы данных, имеет такую ​​форму (первые 5 столбцов):

102 1   01  e113c   3224.96     12  
102 1   01  e185    101127.25   12
102 2   01  e185    176417.90   12
102A   3    01  e185    26261.03    12

Я попытался импортировать его в R с помощью команды, подобной

data <- read.delim("C:\\test.txt", header = FALSE, sep = "\t")

Проблема в том, что 3-й столбец, который на самом деле является полем varchar (буквенно-цифровой), по ошибке читается как целое число (так как в столбце нет букв), а начальные нули исчезают. То же самое произошло, когда я импортировал данные непосредственно из базы данных, используя odbcConnect. Снова этот столбец читался как целое число.

str(data)
$ code: int  1 1 1 1 1 1 6 1 1 8 ...

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

EDIT

Я сделал это, добавив следующий параметр в read.delim

 colClasses = c("factor","integer","factor","factor","numeric","character","factor","factor","factor","factor","integer","character","factor")

• Вы бы предложили "характер" или "фактор" для полей varchar?

• Можно ли использовать «символ» для даты и времени?

• Что я должен сделать, чтобы иметь возможность читать числовое поле, подобное этому 540912.68999999994, в точности как есть, а не как 540912.69?

Я бы хотел - как можно более автоматически - создать этот colClasses вектор, в зависимости от типов данных, определенных в схеме соответствующей таблицы.

Answer 1

Вы бы предложили "характер" или "фактор" для полей varchar?

Как упоминал Джон, это зависит от использования. Переключаться между ними очень просто, поэтому не стоит сильно беспокоиться об этом. Если столбец представляет категориальную переменную, его в конечном итоге следует рассматривать как factor. Если вы собираетесь анализировать текст (например, поля комментариев), тогда character имеет больше смысла.

Можно ли использовать "символ" для даты и времени?

Это хорошо для хранения дат во фрейме данных, но если вы хотите, чтобы они правильно обрабатывались для целей анализа, вам придется преобразовать их в Date или POSIXct/POSIXlt форму.

Что я должен сделать, чтобы иметь возможность читать числовое поле, подобное этому 540912.68999999994, в точности как есть, а не как 540912.69?

Значения считываются с обычной двойной точностью (около 15 сигналов); в данном конкретном примере 540912,69 - это лучшая точность, которую вы можете достичь. Сравнить

print(540912.68999999994)             # 540912.7
print(540912.68999999994, digits=22)  # 540912.69
print(540912.6899999994)              # 540912.7
print(540912.6899999994, digits=22)   # 540912.6899999994

---

РЕДАКТИРОВАТЬ: Если вам нужно больше точности для ваших чисел, используйте пакет Rmpfr .

---

Я бы хотел - как можно более автоматически - создать этот вектор colClasses в зависимости от типов данных, определенных в схеме соответствующей таблицы.

Значение по умолчанию для colClasses (если вы его не указали) довольно хорошо угадывает, какими должны быть столбцы. Если вы делаете что-то вроде использования 01 в качестве символа, то нет никакого способа явно указать его.

Answer 2

вопрос о характере и факторе - это то, на что только вы можете ответить. Это зависит от того, нужно ли вам использовать их позже как факторы или символы. Это также зависит от того, нужно ли вам вообще их чистить потом. Например, если вы планируете применить ряд модификаций ifelse () к фактору впоследствии, вы можете просто прочитать его как символ сейчас, а потом превратить его в фактор. Или, если вы хотите как-то конкретно кодировать фактор, вам, вероятно, будет лучше прочитать его как символ.

Кроме того, причина, по которой вы используете read.delim вместо read.table, связана с настройками по умолчанию, поэтому не беспокойтесь о том, чтобы установить sep на значение по умолчанию.