Una de mis aficiones recientes es la de echarle un vistazo a las licencias de apertura de los locales de Madrid. Son un cartelito que suelen tener colgado en la puerta (con una H verde y grande en hostelería) donde se indica, entre otras cosas, el aforo y la fecha de concesión.

(Lo del aforo no es asunto baladí: sin un aforo oficial, no existe exceso de aforo,… ¿y si luego pasa algo?).

Que la mujer promedio gana menos que el hombre promedio es un hecho conocido. A los usuarios de R que estén al tanto de mi paquete MicroDatosEs no hace falta siquiera que se lo cuenten: pueden bajar los datos de la Encuesta de Estructura Salarial del INE y hacer el cálculo por sí mismos.

Que las mujeres ganen menos en promedio aun teniendo en cuenta las variables recogidas en dicha encuesta (nivel de formación, antigüedad en el puesto de trabajo, etc.) es también un hecho. Los usuarios de R también pueden crear un modelo descriptivo: el fenómeno se manifiesta claramente. O pueden (sepan o no R) leer cualquiera de los informes publicados al respecto para llegar a la misma conclusión.

El título de esta entrada es una pregunta honesta. Yo siempre he utilizado order así:

    iris[order(iris$Petal.Length),]

Y para ordenar por dos (o más columnas), así:

    iris[order(iris$Petal.Length, iris$Petal.Width),]

Es a lo que estoy acostumbrado. Sin embargo, la construcción anterior desconcierta a quienes dan sus primeros pasos en R. dplyr dispone de la función arrange con una sintaxis un tanto más natural:

    library(dplyr)
    arrange(iris, Petal.Length, Petal.Width)

pero, de nuevo, puede resultar desconcertante tener que recurrir a paquetes avanzados: ¿es conveniente introducir a los principiantes en el proceloso mundo de los paquetes para la simple y muy natural operación de ordenar un dataframe?

Las diapositivas que compilé para esto pueden bajarse de aquí.

Son, premeditadamente, insuficientes para seguir el hilo de la charla. De todos modos, gran parte de las ideas a las que se refieren están descritas con algo más de detalle aquí.

Creo que se grabó un vídeo, pero no sé ni si ni cuándo o cómo estará disponible.

Tal será el título de la charla de una hora que daré en el Big Data Science Fighters en abril.

El título es una adaptación de este latinajo y lo usufructo más en la forma que en la sustancia, que la del original se me escapa. El mío servirá para condensar el cúmulo de problemas que he venido detectando en este mundo del análisis de datos: la falta de adecuación de las herramientas de almacenamiento, procesamiento y análisis de datos a la cosa. Y no me restringiré a las de hierro (¡o silicio!) o a las ristras de ceros y unos: también haré un repaso de algunas de las teóricas.

Me han invitado a hablar en el IV Meetup Machine Learning Spain. Será el miércoles 4 de marzo en el lugar que en el enlace anterior indica.

Mi charla será una versión extendida de un tema, la factorización no negativa de matrices y algunas aplicaciones, que mis lectores más fieles ya conocen.

No sé cuántos de mis lectores de Madrid y derredores querrán sumarse. Tampoco sé cuántos de ellos, al acabar, que ya será hora de cenar, querrán hacerlo conmigo en MartinaCocina, a un par de cuadras del lugar del evento, para hablar de cosas interesantes. Si hay quórum, reservo.

El fin de semana que viene (seis y siete de marzo) tendrá lugar el Global Urban Datafest en varias ciudades del mundo. Madrid será una de ellas.

Hay proyectos y equipos participando en ellos. Igual quieres plantear alguno de los primeros o sumarte (o conformar) uno de los segundos. Puedes deambular por las páginas a las que apuntan los enlaces anteriores para averiguar los detalles. De nuevo, una gran oportunidad para aprender cosas nuevas. Hay premios de diversa cuantía, pero eso es casi lo de menos.

Muchas cifras de interés son netos de dos magnitudes. Por ejemplo el déficit/superávit comercial, que es la diferencia entre exportaciones e importaciones; o los beneficios/pérdidas de una empresa, diferencia de ingresos y gastos.

Por un lado, las magnitudes subyacentes pueden estar sujetas a error estadístico. Incluso aunque el coeficiente de variación sea minúsculo para cada una de ellas por separado (p.e., del orden del 1%), pudiera ser que el error correspondiente a la diferencia (¡las varianzas se suman!) hiciesen del neto un valor no significativamente distinto de cero en muchas ocasiones.

Antier recibí un correo inesperado. Me agradecía el paquete bellostamisc, sabía de mi salida de eBay y me ofrecía trabajo en su empresa.

bellostamisc (miscelánea de funciones de Bellosta, i.e., yo) es un paquete para mi uso personal que recopilaba funciones auxiliares que usaba en eBay para distintos fines: conexiones a bases de datos, paralelización, etc. Nunca pensé que fuera a ser utilizado por nadie que no fuese yo. No obstante, lo documenté en condiciones, lo publiqué en nuestro GitHub corporativo y una vez vi que era estable, se lo sugerí a quien me vino con los problemas que con él había resuelto.

¿Cómo se suman los cuadrados de un vector de números en un paradigma tradicional de programación? Se crea un bucle que lo recorre y que guarda las sumas parciales en un acumulador. Sumamente económico en términos de memoria: apenas consume unos pocos bytes en la pila. La versión funcional de la cosa se parece más a sum(x^2), que implica generar un vector de cuadrados y dilapidar memoria.

Así las cosas, en C uno tiende a recorrer y construir resultados parciales. R invita a crear estructuras de datos preprocesados y aplicar sobre ellas funciones resumen. Map y reduce, si se quiere.