[Pxr-commits] cambios en read.px --- cleanDat

[Oscar Perpiñan Lamigueiro]

El Wed, 24 Aug 2011 15:04:52 +0200
"Carlos J. Gil Bellosta " <cgb at datanalytics.com> escribió:
> Hola, ¿qué tal?
> 
> Es cierto que cleanDat es subóptima. Hace varias pasadas por encima de
> la cadena. Incluso estoy seguro de que alguna de ellas es innecesaria.
> 
> Pero permite hacer algunas cosas que no sé si scan puede. Por ejemplo,
> NA puede codificarse de varias maneras:  no sólo como "." sino también
> como ".." y otras. ¿Funcionaría scan en estos casos?

Sí, funciona. El argumento na.strings de scan espera un vector, no un
único elemento. He modificado read.px (después de probarlo) para que sea
capaz de gestionar hasta cuatro "dots".

Por cierto, lo pruebo con este fichero:
http://www.ine.es/inebase/fic/px/l0/EPA_es_25.px, y lo lee bien. Pero
al usar write.px sin ningún cambio intermedio obtengo un error. Ah, y
creo que nos falta añadir un close() en write.px para cerrar la
conexión (obtengo un warning tiempo después). Perdonad, no he tenido
tiempo para arreglarlo yo mismo.

> 
> Estuve trabajando un poco en maneras de leer partes DATA cuando vienen
> especificadas las KEYS (una especie de formato "sparse"). En tal caso,
> scan dejaría de funcionar pero cleanDat podría modificarse para
> aceptar ese tipo de datos. (Aunque tengo tamibén dudas de si el
> formato "sparse" se usa realmente: ni Francisco ni yo creemos haberlo
> visto por ninguna parte fuera de las especificaciones del formato).
> 
Ok. Pero creo que podríamos hacer que scan también lo leyese...en todo
caso, busquemos algún fichero que nos sirva para trastear.

> Existiría una alternativa híbrida más eficiente que la actual que es
> cambiar cleanDat para que:
> 
> 1) en una pasada sustituyese los caracteres equivalentes a NA por "NA"
> usando expresiones regulares (en lugar de una sucesión de
> sustituciones)
> 2) usar textConnection + scan para leer los datos finalmente.
> 

> Habría 2 pasadas por la cadena en lugar de la una actual, pero podría
> resolverse el problema de los diversos tipos de NA. Pero habría muchas
> menos pasadas por la cadena que en la versión original (en la que,
> todo ha de decirse, no se tuvieron en cuenta cuestiones de eficiencia
> porque el problema tampoco se había planteado).
> 

Como digo, scan admite un vector, y por tanto creo que no es necesario
este híbrido. 

Saludos.

Oscar

> Un saludo,
> 
> Carlos J. Gil Bellosta
> http://www.datanalytics.com
>