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]]
_______________________________________________
R-help-es mailing
listR-help-es en r-project.orghttps://stat.ethz.ch/mailman/listinfo/r-help-es
--
Saludos,
Carlos Ortegawww.qualityexcellence.es
[[alternative HTML version deleted]]
Mira este enlace que dice basicamente lo mismo que te puse: http://www.dummies.com/programming/r/how-to-convert-a-factor-in-r/ Saludos El 4 de agosto de 2016, 11:32, Fernando Macedo <fermace en gmail.com> escribió:> 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]] > > _______________________________________________ > R-help-es mailing listR-help-es en r-project.orghttps://stat.ethz.ch/mailman/listinfo/r-help-es > > -- > Saludos, > Carlos Ortegawww.qualityexcellence.es > > >-- Fernando Macedo [[alternative HTML version deleted]]
Muchas gracias, Fernando y Javier.> pami$PP <- as.numeric(as.character(pami$PP))Warning message: NAs introduced by coercion Y entonces los datos que antes convertía en labels(pami$PP) (v.g. 753,2256 a 61343 o 62,7688 ? a 17390, que me pa eran enteros del 1 al n de clases como decía Fernando), los convertía en NA.- Luego de probar también con read.table, pasé a:> pami <- read.csv2("Export.csv", header=T, sep=";", dec =",",stringsAsFactors=F, na.strings=c("NA", "-", "?"), + encoding = "UTF-8") Entendí que lo que sucede es que esa variable la importa de la forma 753,2256 (con una "," que no convierte a ".") mientras que otras de la forma correcta: con "." como sep.- O sea, R no está entendiendo que pami$PP debe considerar sep=",".- Y entonces:> pami$PP <- as.numeric(as.character(pami$PP))Warning message: NAs introduced by coercion nuevamente valor que antes convertía en su equivalente labels(pami$PP) pasa a ser NA.- Probé está opción para tampoco funcionó (de nuevo, pierde el valor y lo convierte en NA):> pami$PP.2 <- levels(pami$PP)Warning message: In `[<-.data.table`(x, j = name, value = value) : Adding new column 'PP.2' then assigning NULL (deleting it). Un callejón sin salida por lo visto... Necesitaría poder hacer "algo especial" con esa variable que se me escapa, porque evidentemente tiene distintas estructuras en el archivo de base, de las cuales R toma una inoportuna para mi. Si alguien tiene una idea al respecto, es bienvenida. Por ejemplo, parece que sería de utilidad poder indicar el parámetro sep="," cuando, una vez importados los datos, indico: pami$PP2 <- as.numeric(pami$PP) # o pami$PP2 <- as.numeric(as.character(pami$PP)) porque en ambos casos, devuelve NA.- Como concepto, me sirvió ver: https://www.r-bloggers.com/using-r-common-errors-in-table-import/ y también: https://martinsbioblogg.wordpress.com/2013/03/24/using-r-reading-tables-that-need-a-little-cleaning/ pero si en esas entradas está la solución, no alcanzo a verla. Por el lado de Access la cosa no mejora mucho hasta ahora, lamentablemente. Sobre todo porque también dejé de utilizarlo hace rato y en la versión 10 no parece tener la opción para normalizar variables que comenta Javier. Saludos! El 4 de agosto de 2016, 12:04, Fernando Macedo <fermace en gmail.com> escribió:> Mira este enlace que dice basicamente lo mismo que te puse: > > http://www.dummies.com/programming/r/how-to-convert-a-factor-in-r/ > > Saludos > > El 4 de agosto de 2016, 11:32, Fernando Macedo <fermace en gmail.com> > escribió: > > > 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]] > > > > _______________________________________________ > > R-help-es mailing listR-help-es en r-project.orghttps://stat.ethz.ch/ > mailman/listinfo/r-help-es > > > > -- > > Saludos, > > Carlos Ortegawww.qualityexcellence.es > > > > > > > > > -- > > Fernando Macedo > > [[alternative HTML version deleted]] > > _______________________________________________ > R-help-es mailing list > R-help-es en r-project.org > https://stat.ethz.ch/mailman/listinfo/r-help-es >-- Mauricio [[alternative HTML version deleted]]