[R-es] ¿Qué hace as.numeric()?

Mauricio Monsalvo m.monsalvo en gmail.com
Vie Ago 5 04:26:05 CEST 2016 

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]]

Más información sobre la lista de distribución R-help-es