[Pxr-commits] CODES, KEYS y TIMEVAL

Carlos J. Gil Bellosta cgb at datanalytics.com
Thu Aug 4 12:50:12 CEST 2011


Entenido. Veo que CODES puede ser un valor representativo y útil y no
sólo una conveniencia a la hora de almacenar los datos en ficheros
PC-Axis.

Dentro de las opciones que sugieres para que se puedan usar tanto los
VALUES como los CODES,

> 1.) Un parámetro en as.array.px y as.data.frame.px que indicara que queremos
> usar los valores de CODES en lugar del contenido de  VALUES. Y seria estos
> los que se almacenarian en los "dimnames" de la array on en los "levels" de
> los factores del data.frame.
>
> 2.) almacenar el valor de CODES en el objeto array o data.frame derivado
> desde  el px. En este caso deberíamos disponer de una función sencilla para
> cambiar contenido de dimnames o levels por los valores de CODES. Esta es la
> solución que yo adopte originalmente en mis primero desarrollos, aunque
> ciertamente no es muy limpia.

me decanto por la primera: que al crear el array/df,  se pueda optar
por cuál utilizar. Además, mientras exista el objeto px, el usuario
siempre puede recrear el objeto a su gusto. ¡Los datos ya están en el
objeto y no hay que arrastrarlos al array/df!

Sólo dos observaciones:

1) Aunque VALUES es obligatoria, CODES no lo es. Además, no es
obligatorio que haya CODES para cada variable. Entiendo que la opción
aquí sería, cuando el usuario quiera CODES, usarlos cuando existan y
utilizar VALUES cuando no.

2) En el futuro (ahora no, ¿eh?) en lugar de aceptar un parámetro
lógico (T/F), se podía usar también una enumeración de variables.
P.e., si el usuario pide

a <- as.data.frame( x, use.codes = T )

se usarían CODES donde los hubiese, pero si pide

a <- as.data.frame( x, use.codes = c( "var1", "var7" ) )

se usarían sólo en las variables indicadas (y en el resto se usarían VALUES).

Un saludo,

Carlos J. Gil Bellosta
http://www.datanalytics.com


2011/8/3 Francisco Viciana <franciscoj.viciana at juntadeandalucia.es>:
> Respondo abajo:
>
> El 03/08/2011 3:20, Carlos J. Gil Bellosta escribió:
>>
>> Hola, ¿qué tal?
>>
>> Estoy modificando la función read.px para que lea ficheros con CODES y
>> KEYS. Luego incluiré TIMEVAL.
>>
>> Veo que CODES es una cosa interna, un sustituto de VALUES. Supongamos
>> que tenemos datos así:
>>
>> DATA =
>> "ZARAGOZA", 8
>> "HUESCA", 2
>> "TERUEL", 1;
>>
>> donde ZARAGOZA, HUESCA y TERUEL son los VALUES de la variable
>> provincia. Es posible también codificar esos datos de esta otra
>> manera:
>>
>> DATA =
>> "A", 8
>> "B", 2
>> "C", 1;
>>
>> en cuyo caso, aparecería en algún sitio del fichero
>>
>> VALUES( "provincia" ) = "ZARAGOZA", "HUESCA", "TERUEL";
>>
>> CODES( "provincia" ) = "A", "B", "C";
>>
>> KEYS( "provincia" ) = CODES;
>>
>> La última línea indica que la variable "provincia" está codificada con
>> sus CODES y las anteriores definen un diccionario para decodificar los
>> CODES.
>>
> Correcto. Si aparece la clave KEYS implica que los datos del DATA vendrán en
> una estructura por fila y columnas parecida a una data.frame. Esta opcion es
> muy util almacenar matrices dispersas (sparse matrix) con muchos ceros
> estruturales.
>
> El campos  "CODES" también puede aparecer sin la clave "KEYS".
>
>> En resumen, CODES no parece ser importante... una vez se deshaga la
>> correspondencia entre los códigos y sus valores.
>
> El campo CODES, en muy experiencia es muy util, ya que suele representar una
> "nomenclatura abreviada" y mas manejable de la denominación de las
> categorías de una variable. Por lo que puede ser util tanto en la generacion
> de salidas en forma de tablas y graficos mas adecuadas que las generadas por
> las largas etiquetas de VALUES.  Asi mismo para realizar selección de
> valores es generalmente mas sencillo nombrar los código que las etiquetas de
> texto por ejemplo en más facir selecionar las provincias andaluzas con la
> lista de CODES c('04','11','14','18','21','23','21','41') que con
> c('Almería',' Cadíz', 'Córdoba' . ...
>
> px.read lee correctamente el CODES. el problemas es cuando pasamos a array o
> data.frame es que esta información se pierde en el nuevo objeto creado.
> Tendríamos dos alternativas para solucionar esto:
>
> 1.) Un parámetro en as.array.px y as.data.frame.px que indicara que queremos
> usar los valores de CODES en lugar del contenido de  VALUES. Y seria estos
> los que se almacenarian en los "dimnames" de la array on en los "levels" de
> los factores del data.frame.
>
> 2.) almacenar el valor de CODES en el objeto array o data.frame derivado
> desde  el px. En este caso deberíamos disponer de una función sencilla para
> cambiar contenido de dimnames o levels por los valores de CODES. Esta es la
> solución que yo adopte originalmente en mis primero desarrollos, aunque
> ciertamente no es muy limpia.
>
>> El problema que veo
>> es que importar un fichero con KEYS implica extender lo que es posible
>> introducir en un objeto de la clase px. Hasta ahora guardábamos los
>> datos en un vector numérico. Ahora ya no se puede porque los CODES son
>> caracteres.
>
> Pero conceptualmente la información representada en un DATA con KEYS es una
> matriz (aunque puede que algunas veces con muchos ceros) y por lo tanto se
> puede almacenar en forma de vector en un $DATA de un objeto PX.  Puede que
> ocasionalmente este sistema de almacenamiento sea poco eficiente, pero la
> mayoría de las veces creo que va a funcionar bien, por lo que no había que
> hacer transformación en la estructura actual de objeto px.
>
>
>> Se me ocurren dos ideas para leer este tipo de datos en este caso
>> particular:
>>
>> 1) Guardar la parte DATA como un data.frame (tal vez sería la más
>> sencila).
>> 2) Separar los datos por un lado (como vector) y la estructura de
>> datos (como df) que indica qué filas se han leído por otro.
>>
>> Ambas implicarían cambios aguas abajo, en las funciones as.array y
>> as.data.frame.
>>
>> ¿Alguna otra?
>>
> Como comente arriba. Podemos no modificar la estructura de objeto PX y
> seguir almacenando el DATA como un vector ordenado que es realmente una
> array cuyas dimensiones quedan definidos por las claves VALUES.
>
> Mi idea para hacer esto es almacenar la información del DATA (en caso de que
> haya clave KEYS) en un objeto data.frame temporal, con todos los campos
> VALUES como columnas de facores y una columna FREQ con los valores
> numéricos. A continuación solo tendríamos que usar xtabs(FREQ~ ..+..+.. )->
> data y luego as.vector(data) para obtener el vector nuemrico que hay que
> almacenar en el DATA (con los posibles ceros estructurales rellenos)
>
>> Por otra parte, creo que podríamos prescindir de CODES y KEYS en los
>> objetos que nosotros creemos y escribamos. Eso haría las cosas más
>> simples.
>>
> De momento es lo que estamos haciendo, yo no he visto en el INE muchos casos
> de uso de la clave KEYS,  por lo que quizas no es muy prioritario
>
>> Un saludo,
>>
>> Carlos J. Gil Bellosta
>> http://www.datanalytics.com
>>
>
> Salud.
>
> Fran.
>
> --
> +--------------------------------------------------------------
> | Francisco J. Viciana Fernández
> | Coordinador del Registro de Población
> | Servicio de Estadísticas Demográficas y Sociales
> | Instituto de Estadística y Cartografía de Andalucía
> | Leonardo Da Vinci, nº 21. Isla de La Cartuja.
> | 41071 SEVILLA.
> | franciscoj.viciana at juntadeandalucia.es
> | Tlf.: +(34) 95 503 38 21
> +--------------------------------------------------------------
>
>


More information about the Pxr-commits mailing list