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 Ortega www.qualityexcellence.es El 3 de agosto de 2016, 23:05, <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 list > R-help-es en r-project.org > https://stat.ethz.ch/mailman/listinfo/r-help-es >-- Saludos, Carlos Ortega www.qualityexcellence.es [[alternative HTML version deleted]]
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>
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 Ortega
> www.qualityexcellence.es
>
>
>
>
> El 3 de agosto de 2016, 23:05, <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 list
>> R-help-es en r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>
>
>
>
> --
> Saludos,
> Carlos Ortega
> www.qualityexcellence.es
>
--
Mauricio
[[alternative HTML version deleted]]
Estimado Mauricio Monsalvo Hace años que no uso Access, pero si no recuerdo mal hay una opción para sacar variables, normalizar los datos (desde el punto de vista de la base de datos, no estadístico), había una opción donde por ejemplo a todos los laboratorios le colocaba 1, a los centros 2, y relacionaba a otra tabla donde estaba 1 laboratorio, 2 centro (esta última generada automáticamente por access). Otra cosa que se me ocurre es que abra con Excel, puede utilizar la opción borrar duplicados (una copia del original). Son dos formas que se me ocurren para que limpie los datos antes de importarlos a R. En R se podría pero da mucho trabajo, casi impracticable, salvo que una persona quiera crear ?EL Paquete? para importar datos. Cuándo tenga bien ordenados los datos, una alternativa es agrupar o desagrupar en archivos, utilizar merge, sqlitedf, utilizar if, etc. Ordenar los datos es el 80 % del trabajo. Javier Rubén Marcuzzi De: Mauricio Monsalvo [[alternative HTML version deleted]]
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]]