La gente de rOpenSci hace cosas a las que merece la pena atento. Tanto por los objetivos como por medios y las formas. Recomiendo seguir sus últimas publicaciones acerca de la profesionalización del proceso de desarrollo de código.

Llevo unos meses jugando con una idea inspirada por rOpenSci: crear un respositorio y un consorcio más o menos formal que desarrolle, mantenga y mejore herramientas (en R) de interés para el procesamiento y análisis de datos ya no científicos sino españoles. Hablo, obviamente, de INE (EPA, EPF, censo, padrón,…), CIS (barómetros, etc.), IGN (Siane,…), encuestas electorales, etc.

Una función no debería cambiar nada de cuanto la rodea. Debería devolver algo y ya. Se acepta barco como animal acuático cuando hay funciones que escriben en logs, guardan datos en disco o crean gráficos.

R deja que los usuarios se disparen en el pie permitiendo hacer cosas tan peligrosas como:

a <- new.env()

a$1     # error

foo <- function(){
  a$a <- 1
}

foo()
a$a
# [1] 1

De la misma manera, si le enseñas un cuchillo a una vieja, es posible que te dé su bolso con todo lo que contiene. Pero eso no significa que debas usar los cuchillos para tales fines.

Abundo aquí en un punto polémico de mi charla de Pamplona: el que define la estadística como una tecnología (bajo una definición bastante particular de ella).

Pero es conveniente comenzar por el concepto de técnica. Que el DRAE define horripilantemente:

Conjunto de procedimientos y recursos de que se sirve una ciencia o un arte.

Y no, no, no… No solo las ciencias o las artes se sirven de técnicas para alcanzar sus fines. También los homeópatas, los curanderos, los chamanes, los echadores de cartas, etc. se sirven de técnicas sin que su actividad pueda calificarse de ciencia (¿o es que se trata de artes?).

El título, no el de esta entrada sino el de A Comparison of Programming Languages in Economics, es una sinécdoque confusa.

Que nadie busque en él consejo sobre qué lenguaje estudiar si le interesa el mundo de la economía (en general). O fuera de ella (también en general).

Encontrará más bien la implementación de la solución a un único problema dentro de los muchos que supongo comprende esa disciplina. Uno, además, con el que no he visto (en persona) a economista alguno ganarse el pan ni en la academia ni fuera de ella.

El otro día hablé con un amigo. Estaba un tanto preocupado por lo que cuento a continuación. Trabaja en un lugar que organiza conferencias, seminarios, etc. y frecuentemente suben los vídeos a Youtube. Al examinar el perfil demográfico de los _yutuvidentes _advertía con desazón que entre los de los vídeos de unas charlas de tecnología muy friquis apenas había un 10% de mujeres.

El autor de un blog que sigo también está preocupado. El hombre lidera (no sé cómo de formalmente) una comunidad de _racionalistas _(aunque yo los catalogaría más bien como empiristas). Escribe sobre temas… imaginaos cuáles serán si me interesan a mí. Y el motivo de su preocupación no es tanto, sospecho, la escasa presencia de mujeres en la antedicha comunidad sino la posibilidad de que lo puedan acusar de lo habitual. Es decir, tener una actitud discriminadora, hostil o menospreciante.

Este es, finalmente, el anuncio de que Circiter existe. Circiter (una SL con todas las de la ley) es la empresa a través de la que voy (vamos: nótese que hablo en plural) a trabajar en el futuro.

Qué hacemos (qué nos gusta)

Esencialmente, cuatro cosas:

• Formación, si toca. No es lo más emocionante, pero mientras siga inflándose la burbuja, ahí estaremos. Tenemos varios cursos preparados (dos niveles de R, Spark, etc.) y bajo pedido, de lo que sabemos, lo que haga falta.
• Sistemas, programación, etc. Generalmente, relacionado con ciencia de datos. E incluyendo cosas como migraciones de sistemas viejunos a R o Python, aggiornamento de código, produccionalización, etc.
• Ingeniería estadística.
• Análisis de datos, cómo no. Aunque es la actividad que encuentro que peor se acomoda dentro de la consultoría, además de que comercialmente lo tenemos muy crudo de competir con los vendedores de humo que todos conocemos.

En resumen, aquello de lo que hablo por aquí.

1. Tienes acceso a la serie histórica de hospitalizaciones (p.e. en Madrid) por diversas (muchas) causas.

2. Tienes acceso a la serie histórica de mediciones de distintos factores ambientales (p.e., en Madrid): ruido, óxidos de nitrógeno, partículas en suspensión,…

3. Buscas correlaciones (y, por supuesto, las encuentras).

4. Les asocias p-valore espurios.

5. Lo escribes en inglés (frecuentemente) y publicas:

   • Effect of Environmental Factors on Low Weight in Non-Premature Births: A Time Series Analysis
   • Effects of noise on telephone calls to the Madrid Regional Medical Emergency Service (SUMMA 112)
   • Short-term association between environmental factors and hospital admissions due to Dementia in Madrid
   • Impacto de la contaminación asociada al tráfico y la temperatura sobre variables adversas al nacimiento en Madrid. Un análisis de series temporales.
   • Short-term association between road traffic noise and demand for health care generated by Parkinson’s disease in Madrid
   • Traffic noise and adverse births outcomes in Madrid
   • Evaluation of short-term mortality attributable to particulate matter pollution in Spain
   • Impact of road traffic noise on cause-specific mortality in Madrid (Spain)
   • Association between environmental factors and emergency hospital admissions due to Alzheimer’s disease in Madrid
   • Saharan dust intrusions in Spain: Health impacts and associated synoptic conditions
   • Emergency multiple sclerosis hospital admissions attributable to chemical and acoustic pollution: Madrid (Spain), 2001-2009

¡Eso es a lo que Lakatos llama un señor programa de investigación científica!

Informo de que está disponible en GitHub el paquete CatastRo para consultar la API pública del Catastro.

No es una API particularmente extensa, pero es de esperar que se amplíe el catálogo de servicios disponible cuando comencemos a machacarla (o no: a saber qué hay en la mente de esa gente).

El paquete es el trabajo de fin de máster de mi alumno Ángel Delgado Panadero en el máster de ciencia de datos de la UTAD.

El día 2017-09-20 hubo gente que tomó el autobús en Madrid. Se montó en una determinada parada y la siguiente estaba situada o bien al norte o bien al sur de la anterior.

He contado, por horas, cuánta gente viajó en ese primer tramo, hacia el norte y quién lo hizo hacia el sur y he obtenido

que es —al contrario de los resultados presuntamente basados en datos pero, en el fondo ideológicamente sesgados con los que nos quieren tan frecuentemente vender motos— totalmente compatible con lo que todos los que nos movemos por Madrid sabemos.

Con geofacet se puede hacer