En general lo que yo uso en esos casos es as.numeric(as.character(X))
No se los términos correctos pero los factores aunque se muestren con los
nombres de las diferentes clases, internamente son clases separadas que se
nombran como enteros por ejemplo del 1 al n de clases. Cuando usas
directamente as.nuemric sobre un factor, este toma los numeros de las
clases y no el valor de clase.
Fijate en el código que te mando a continuación y lo verás mejor:
x=as.factor(letters[8:18])
levels(x)
labels(x)
as.numeric(x)
as.character(x)
x=as.factor(8:18)
levels(x)
labels(x)
as.numeric(x)
as.character(x)
as.numeric(as.character(x))
Usé labels en el código aunque no se si son exatamente las labels de los
factores, pero usandola ejemplifica justamente lo que digo.
Para evitarme algunos problemas en general uso stringAsFactor=F cuando
levanto datos porque algunas identificaciones alfanumericas las levanta
como factores y si te comes eso luego gráficos por id o cosas asà te salen
con las labels de los factores y no con los valores en sÃ.
Espero que fuera de ayuda, saludos
Fernando Macedo
El 04/08/16 a las 09:40, Mauricio Monsalvo escribió:
Hola.
Muchas gracias, Carlos y Javier.
Les paso el scrip que utilicé y genera el problema raro, por si algún otro
parámetro está mal indicado. La forma dec="," sà estaba indicada, pero
podrÃa estar en conflicto con otro parámetro, sin que yo lo sepa.
No adjunto un pequeño recorte del archivo, porque al ser solo una parte, el
problema no aparece... Y siendo más de 4,5 millones de registros, no es
posible compartirlo con la lista y nomás abrirlo con un bloc de notas es
molesto:
pami <- read.table("Export.csv", header=T, sep=";", dec =",",
# colClasses=c("Factor", "int", "int", "Factor",
rep("numeric", 2),
# rep("int", 4), rep("Factor", 3),
"numeric", rep("Factor", 3)),
encoding = "UTF-8", quote="\"", comment.char = "")
Importé los datos con Acccess y por lo que veo, tengo razones para
sospechar que parte de ese .cvs se generó a partir de .xls que tienen o
bien totales o bien tablas dinámicas, en lugar de matrices de datos
regulares. Básicamente, porque para algunas variables de interés
(factores), aparecen las filas el nombre de la variable y (v.g., en la
variable LABORATORIO no aparece el nombre de un laboratorio sino el "valor"
LABORATORIO y en PRODUCTO aparece el valor PRODUCTO mientras que el resto
de las variables dan NULL).-
Si eso es cierto, entonces, ¿puedo indicarle al R que importe todos los
registros salvo aquellos en los que las variables a,b tengan los valores
i,j? ¿tengo alguna forma de utilizar un ifelse al importar? De esa forma
evitarÃa que read.table incorpore filas que vaya uno a saber qué tipo de
datos tienen y eso podrÃa ser que antes o luego, al convertir los tipos de
datos, solo pierda aquellos que son basura pero no que el resultado sea
impredecible.
Un plan b que utilicé (siempre me fallan los planes b!!) es colClasses pero
me apareció el problema de "valor inesperado: se espera un real y se obtuvo
un 4,5%", etc. Si pudiera indicarle que al R que yo también espero un tipo
de datos dado (v.g. un entero, un número, un factor) y que estamos de
acuerdo en eso, asà que cuando encuentro algo que no sea lo esperado lo
convierta en NA, creo que también podrÃa resolver la otra parte del
problema que tiene mi archivo.
Con importar los datos desde el access resolvà mi problema, pero no mi
duda: ¿por qué as.numeric "transforma" los valores? ¿Qué puede hacer que
transforme 753,2256 a 61343 o
62,7688
? a
17390? ¿Es alguna forma de "corrupción" o en alguna variante es algo
esperable?
Es claro que lo mejor que puedo hacer es volver a generar ese .csv sin
errores, pero no estarÃa dentro de mis posibilidades a mano.
Perdón por tantas dudas y preguntas, pero al ser un archivo de mucho peso,
cada prueba y error consume demasiado tiempo (y memoria!!!), asà que una
mejor comprensión previa, teórica, del proceso me ayuda mucho.
Gracias.
El 3 de agosto de 2016, 18:28, Carlos Ortega <cof en qualityexcellence.es> <cof en qualityexcellence.es>
escribió:
Tranquilo que no te han hackeado tu "R"...
Simplemente que al importar tu CSV, no has indicado que los decimales son
las ",". Y ese campo lo importa como un character (un string). Y cuando lo
conviertes a numeric, el resultado es un tanto impredecible.
Si utilizas read.table para importar, simplemente incluye el parámetro
"dec" de esta forma "read.table(..... , *dec = ","*). Esta vez, esa
columna será numeric directamente.
Saludos,
Carlos Ortegawww.qualityexcellence.es
El 3 de agosto de 2016, 23:05, <javier.ruben.marcuzzi en gmail.com> <javier.ruben.marcuzzi en gmail.com> escribió:
Estimado Mauricio Monsalvo
Usted dice que el csv es muy pesado y sucio, por lo cuál es posible que
su trabajo en R sea correcto, pero como los datos son ?malos en su calidad
de almacenamiento?, hay problemas.
CSV es leÃdo por planillas de cálculo y bases de datos, las primeras son
fáciles pero si los datos son muchos dan problemas, las segundas tienen
alguna herramienta que facilita su importación.
Si usted logra importar los datos a una base de datos podrá leerlos desde
R, es probable que desde R o desde la misma base de datos pueda encontrar
valores inadecuados, o en su defecto la importación a la base de datos
soluciona el problema, pensando en por ejemplo que en el CSV hay datos 2,3
y 2.3, siendo ambos iguales pero en informática no son lo mismo.
Javier Rubén Marcuzzi
De: Mauricio Monsalvo
[[alternative HTML version deleted]]