01 agosto 2017

El Diluvio: The Spanish Banking Crisis, 2008-2012∗ Tano Santos

El Diluvio: The Spanish Banking Crisis, 2008-2012∗ Tano Santos Columbia University and NBER
 
This paper offers a narrative of the Spanish banking crisis between 2008 and 2012, from the early stages of the crisis to the request of financial assistance by Spain to its European partners. It centers in particular on the management of the crisis by the Spanish authorities. Though non performing loans were widespread, solvency concerns were concentrated in a particular segment of the Spanish banking system, the cajas sector. This sector was the anomaly of the Spanish banking system. The cajas had, one, faulty governance institutions, which made them subject to capture by the powerful political regional elites, and two, unclear procedures for private recapitalization, which made access to equity markets an impossibility. Crisis management suffered from an internal contradiction. The strategy was informed by two principles. First, debt holders, independently of their seniority, would suffer no losses and, second, tax payer funds available for recapitalization would be minimized. Given that private capital was not forthcoming, bank debt was not to be bailed-in and tax payer funds were to be minimized the solvency crisis could never be credibly closed. Spanish authorities operated under two tight constraints. First, the cajas brought unique political economy issues to crisis resolution. Second, Spain’s membership in the monetary union meant that Lender of Last Resort (LOLR) tools were not directly controlled by the Bank of Spain. In addition, banks and cajas depended on foreigners to refinance a substantial fraction of their liabilities, which made them subject to sudden stops. The combination of these constraints and the internal contradictions of the strategy allowed the solvency crisis to morph into a liquidity crisis, which Spain could not successfully meet given its membership in the monetary union. As a result Spain had to request a financial assistance package on June 25th, 2012.
 
https://www0.gsb.columbia.edu/mygsb/faculty/research/pubfiles/25448/El-Diluvio-05-20-2017-Part-II-L.pdf 
 

La crisis bancaria española: 2008-2012

Tano Santos  6 comentarios

Durante los días 20 y 21 de Junio tuvo lugar una conferencia organizada por los bancos centrales de Holanda y Suecia (el DNB y el Riksbank) sobre supervisión macroprudencial. Con motivo de la conferencia se me invitó a escribir un artículo sobre la crisis bancaria española que explicase los muchos capítulos de la misma así como las lecciones que de la gestión de la crisis se pudiesen extraer. El artículo lo podéis encontrar aquí.
Es buen momento para hacerlo. El Banco de España ha publicado su propio informe y se celebran estos días las reuniones de la comisión parlamentaria sobre la crisis bancaria. Puede ser por tanto útil ofrecer una visión distinta de lo que ocurrió durante los años agudos de la crisis. El objetivo del artículo es doble. Por una lado contar lo que pasó y segundo ofrecer una evaluación de la gestión de la crisis que hicieron nuestras autoridades. Tiene como objetivo último extraer lecciones y aprender para al menos no cometer los mismos errores. El artículo se centra en el periodo 2008 – 2012 y sigue a uno anterior enfocado en la evolución del sector bancario español entre los años 1998 y 2008 (del que aquí dimos referencias en su momento; ese anterior artículo lo podéis encontrar aquí). Los años del MoU, SAREB, etc los trataré en un futuro artículo. Aún así y dado el interés del tema el artículo incluye al final del mismo algunos comentarios rápidos sobre el caso del Banco Popular. Este caso muestra lo complejo que es siempre la resolución de las crisis bancarias y el largo recorrido que tienen. Los casos del Popular, Bankia y la triste historia de las preferentes (véase el gráfico que cierra esta entrada) ilustran bien la necesidad de evaluar constantemente tanto la evolución del sistema crediticio como las instituciones supervisoras y de resolución. La unión bancaria no disminuye en nada esa necesidad de constante vigilancia.
El punto central del artículo se resume en pocas frases. El sistema bancario español, compuesto de bancos y cajas, tenía un problema de pérdidas en el balance derivado de la concesión de crédito a promotores, constructores y familias ligado al enorme ciclo inmobiliario español que tiene lugar en los años anteriores a la crisis. Estas pérdidas hacen necesaria la recapitalización del sistema. Dada la falta de acceso al mercado de capitales de las cajas y el objetivo de no imponer perdidas a depositantes y tenedores de deuda senior eso hacía necesaria o bien la imposición de perdidas a los tenedores de deuda subordinada y preferentistas, la recapitalización con fondos públicos o una combinación de ambas cosas. Es porque no se hace ninguna de estas dos cosas que las distintas medidas que se tomaron durante esos años no consiguieron cerrar la crisis y se minó la credibilidad de nuestras instituciones. Al loable activismo del Banco de España en lo que se refiere a la reestructuración del sector de las cajas le faltó el ingrediente fundamental para dotar a su esfuerzo de credibilidad: capital. Esto llevó a que una crisis de solvencia se transformara en una de liquidez, lo que es letal en una unión monetaria y hacía el rescate de Junio de 2012 inevitable. De ese rescate y sus consecuencias tratará un futuro artículo.

Panel A: Emisiones de preferentes y deuda subordinada por parte de las entidades de crédito españolas entre los años 1998 y 2012. Panel B: Emisiones entre los años 2008 y 2009 por entidad. Las entidades corresponden a aquellas existentes en 2013, agrupando las emisiones de las entidades que las formaron más adelante. En miles de millones de euros. Fuente de los datos: Comisión de Seguimiento de Instrumentos Híbridos de Capital y Deuda Subordinada, 17 de Mayo de 2013.
Panel A: Emisiones de preferentes y deuda subordinada por parte de las entidades de crédito españolas entre los años 1998 y 2012. Panel B: Emisiones entre los años 2008 y 2009 por entidad. Las entidades corresponden a aquellas existentes en 2013, agrupando las emisiones de las entidades que las formaron más adelante. En miles de millones de euros. Fuente de los datos: Comisión de Seguimiento de Instrumentos Híbridos de Capital y Deuda Subordinada, 17 de Mayo de 2013.
 

09 julio 2017

Una muestra de la Economía Experimental en España José Luis Ferreira

La Revista de Economía Industrial, editada por el Ministerio de Energía, Turismo y Agenda Digital, ha publicado recientemente un monográfico dedicado a la Economía Experimental que he tenido el honor de coordinar. Aquí transcribo la introducción que escribí. Después de ella incluyo un par de reflexiones sobre la Economía Experimental y la investigación en España.
Los tiempos en que el estudio de la economía se basaba en la introspección y en la observación de hechos estilizados, acompañados de una formulación teórica formal o informal han quedado muy atrás. Las nuevas técnicas y metodologías, así como la general aceptación en la profesión de que la validación empírica es la condición para aceptar o rechazar teorías explicativas, han hecho que el porcentaje de artículos empíricos pasara del 40% en los años 80 al 72% (el 80% si se incluyen las simulaciones) en la primera década de este siglo.
Hay muchas maneras en las que la economía empírica trabaja. La más conocida y amplia es aquella que somete una base de datos a un estudio econométrico para intentar encontrar relaciones causales entre variables. Idealmente el investigador querría aislar las variables de una manera más controlada, pero los datos son los que son. De vez en cuando, sin embargo, sucede un experimento natural. Dos sociedades muy parecidas entre sí (dos países, dos regiones de un país o dos ciudades de la misma región, por ejemplo) deciden tomar decisiones económicas distintas, o dos sociedades dispares deciden tomar el mismo tipo de decisiones. El estudio de la divergencia o convergencia de resultados permite avanzar en nuestro conocimiento de la economía. El siguiente paso en controlar las variables lo ofrecen los programas pilotos para la adopción de una medida económica. En este caso tenemos un experimento de campo artificial, con un diseño detrás. Por ejemplo, las autoridades pueden seleccionar aleatoriamente entre la población aquellas personas a las que se les otorgará un bono escolar, una renta básica o se les permitirá elegir hospital, para estudiar si la medida produce los resultados deseados. Los programas pilotos pueden afectar también a empresas y servicios, como cuando se establece un control de emisiones en solamente un sector o se privatiza la gestión de un servicio. Finalmente, la manera más clara en que se pueden controlar las variables se da en un experimento de laboratorio, donde se diseña una interacción económica con todos los parámetros bajo control. La interacción económica es real y la elección de parámetros se hace de manera que se simule una situación más compleja y sobre la que queremos obtener información. El problema de la recopilación de evidencias empíricas es que, cuanto más podemos controlar las variables, menor es el conjunto de problemas económicos que podemos estudiar y menor su generalidad. Con todo, lo que se puede hacer es mucho y todavía estamos lejos de saber cuáles son los límites de lo que nos pueden decir las distintas maneras de recopilar datos.
En este número especial dedicado a la Economía Experimental presentamos una selección de artículos en los que apreciar las distintas metodologías. En una primera parte tenemos tres trabajos sobre el comportamiento experimental de los individuos. Enrique Fatas y Antonio Morales en “El papel de la información en mercados experimentales” discuten los resultados recientes en la literatura experimental sobre el papel de la información en mercados de competencia en precios y en cantidades. En los mercados estándar perfectamente competitivos los experimentos corroboran la robustez de los resultados frente a cambios en la información. Sin embargo, para mercados oligopolísticos y financieros la relación entre información y resultados es más compleja. En el siguiente artículo, “Situaciones estratégicas estrictamente competitivas”, de Ignacio Palacios-Huerta, repasa las implicaciones de los principales conceptos de equilibrio para los juegos de suma cero y cómo la literatura empírica y experimental ha evaluado esas implicaciones. En el tercer artículo de esta primera parte, “¿Qué podemos aprender sobre incentivos a través de experimentos?”, Roberto Hernán-González analiza la aportación de la economía experimental al problema de cómo responden los individuos ante el uso de incentivos tanto monetarios como no monetarios, un problema central para cualquier política regulatoria.
En la segunda parte de este número tenemos cuatro artículos dedicados a los experimentos sobre distintos tipos de mercados. El primero de ellos, “Experimentos de laboratorio y organización industrial: un panorama”, de Jordi Brandts nos ofrece, como su título indica, un resumen de lo que ha significado la economía experimental en la organización industrial. Los tres artículos siguientes se centran en distintos sectores y mercados, cada uno con su propia idiosincrasia. Aurora García Gallego, Nikolaos Georgantzis y Gerardo Sabater Grande, en “La red de ferrocarriles en el laboratorio” nos ofrecen el primer estudio sobre la eficiencia de ciertas estructuras alternativas en la provisión de servicios por parte de las empresas de ferrocarril mediante un diseño experimental inspirado en la liberación de este sector en España. Natalia Jiménez, en “Experimentos económicos en el mercado laboral”, muestra cómo la economía experimental ha analizado los problemas de los contratos incompletos y la discriminación salarial según la productividad. En el último artículo de esta parte, “Burbujas en mercados financieros experimentales”, Praveen Kujal y Owen Powell nos dan un recorrido por los experimentos realizados para detectar qué características de los mercados y de los individuos llevan a la aparición de burbujas. En este trabajo se aprecia especialmente la ventaja de la economía experimental a la hora de controlar las variables. En particular, si entendemos las burbujas como una discrepancia entre el precio observado y el valor fundamental de un activo, su observación y medición real es difícil por no disponer de información precisa del “valor fundamental” del activo, algo fácil de resolver en el diseño experimental.
El número se completa con una tercera parte dedicada a los experimentos naturales y de campo. El primer artículo, “Un análisis de modelos para financiar la educación terciaria: descripción y evaluación de impacto” de Brindusa Anghel, Antonio Cabrales, Maia Güell y Analía Viola, muestra cómo las distintas experiencias en varios países sobre la financiación universitaria permite hacer recomendaciones de política educativa. Se cierra el número con un artículo bastante distinto de todos los anteriores, “Exposición fetal a la testosterona, D2:D4 y altruismo estratégico” de Pablo Brañas-Garza. En este artículo el lector encontrará una muestra de las nuevas líneas de investigación en la economía experimental y del comportamiento y de cómo pueden arrojar luz sobre el eterno debate “naturaleza-crianza”.
Un par de reflexiones:
1. Son 16 los autores que firman los nueve artículos. Todos ellos están entre lo mejor de la investigación en Economía Experimental en el mundo y han contribuido a que España sea una potencia en esta área de investigación. De ellos, 6 están en universidades españolas, 7 en universidades extranjeras y 3 mantienen una doble filiación española-extranjera. El dato interesante es que de los que están en instituciones extranjeras, 5 estaban en España hasta hace muy poco tiempo. No tenemos a nadie en la situación inversa, con la excepción de un investigador que ha pasado de tener filiación extranjera a doble filiación española-extranjera. ¿Por qué no hemos sido capaces de mantenerlos en España?
2. Durante varios años, las convocatorias de los proyectos del Ministerio de Economía y Competitividad (ahora de Economía, Industria y Competitividad), los llamados proyectos del Plan Nacional, del que se nutren la mayoría de los equipos investigadores españoles, incluían lo siguiente en las instrucciones de ejecución y justificación del presupuesto.
No son elegibles en ninguna de las modalidades:
* Compensaciones del personal de investigación no vinculado a las entidades beneficiarias cuando participen en la ejecución de las actuaciones objeto de subvención, como por ejemplo pagos a estudiantes, sujetos experimentales, gratificaciones y honorarios.
Es decir, que los investigadores españoles no podían realizar experimentos en Economía según los estándares internacionales, que requieren que los sujetos experimentales tomen decisiones y reaccionen según las ganancias que esperan obtener.
Afortunadamente, en la última edición se permiten estos pagos entendidos como dietas (y sujetos a que no sean una parte importante de la renta de los individuos, lo que nunca sucederá dado el monto de estos pagos). Es una buena noticia que el Ministerio haya encontrado una solución al problema. Necesitamos unas cuantas más como esta para frenar la salida de experimentalistas de nuestro país.

http://nadaesgratis.es/jose-luis-ferreira/una-muestra-de-la-economia-experimental-en-espana

28 junio 2017

Guía para aprender métodos cuantitativos en economía (V)

Guía para aprender métodos cuantitativos en economía (V)

Source: "Piled Higher and Deeper" by Jorge Cham, www.phdcomics.com
Concluyo con esta entrada mi serie sobre cómo aprender métodos cuantitativos en economía (las primeras cuatro entradas se encuentran aquíaquíaquí y aquí).
En la entrega anterior me centré en los lenguajes de programación que resultaban, en mi opinión, más útiles para un estudiante o investigador en economía. Mencioné en varias ocasiones, sin embargo, que alrededor del uso de un lenguaje existía una nube de herramientas que uno tenía que manejar con cierta familiaridad y que dejaba para un análisis en mayor detalle. Este cometido es lo que pretendo hoy de manera muy sucinta y a riesgo, por restricciones de espacio, de dejarme muchas cosas en el tintero (como algunas de estas herramientas) y con todas las advertencias, además, sobre la subjetividad de muchos de mis comentarios que es pertinente repetir aquí. El lector interesado puede encontrar muchas de estas herramientas descritas también en A Gentle Introduction to Effective Computing in Quantitative Research: What Every Research Assistant Should Know de Harry J. Paarsch y Konstantin Golyaev.
guide
Sistema operativo
Antes de entrar en la parte principal de la entrada he de resaltar que yo trabajo en Mac o en Linux, pero nunca en Windows. Mac o Linux le permiten a uno, con un botón, abrir una terminal de la familia Unix (Mac es Unix puro, Linux un hermano) y tener a su alcance un sistema operativo robusto como ninguno y en el que programar un código propio no va a ser una aventura. Cada año que doy clase de métodos computacionales en economía veo a cantidad de estudiantes terminar tirando en frustración su ordenador Windows por la ventana y cambiarse a Linux (los Macs salen caros para ellos). Mientras que con un poco de paciencia uno puede normalmente conseguir que todo corra en Windows, no le he visto nunca la mínima ventaja a emplear un sistema operativo que solo da dolores de cabeza. Además aprender Unix o Linux es muy fácil: en un par de horas uno está familiarizado con las instrucciones básicas y un poco de búsqueda en Internet le dará respuesta a casi todas las preguntas adicionales que aparezcan. Una vez que uno sabe Unix, conoce un sistema operativo para siempre: no va a cambiar en la siguiente versión creada por una empresa informática para ganar dinero. Un programador que supiese Unix en 1980 podría emplear hoy mi Mac sin mayor secreto.
carpentry
Un sitio excelente para aprender Unix (y, en general, todos los temas que discuto en esta entrada) es software-carpentry, una fundación sin ánimo de lucro que organiza talleres y publica lecciones en la red sobre manejo de ordenadores para investigadores (con una hermana, Data Carpentry, más centrada en enseñar análisis de datos). Por ejemplo, está lección sobre el shell de Unix le permite a uno arrancar sin problema.
UnixMac
Para aprender más, en clase recomiendo Learning Unix for OS X: Going Deep With the Terminal and Shell (2nd ed.) de Dave Taylor, que es el que yo tengo siempre a mano y Linux Pocket Guide: Essential Commands (3rd ed.) de Daniel J. Barrett. Pero existen, eso sí, decenas de otros libros tan solventes como los que recomiendo y, además, textos más avanzados sobre Unix. Pero no creo que estos sean necesarios para la gran mayoría de los economistas. Yo tengo en la oficina Unix in a Nutshell (4th ed.) de Arnold Robbins por si acaso, pero la verdad es que no lo abro nunca.
Independientemente de si el argumento anterior en favor de Mac/Linux es convincente, sí que el lector deberá de tener en la cabeza mi estructura de trabajo cuando juzgue el resto de mis recomendaciones: toda mi experiencia es sobre el funcionamiento de las herramientas de las que hablaré en Mac o en Linux. No puedo decir mucho sobre lo bien que funcionan en Windows.
Editores
Si uno va a escribir código, necesita o bien un editor o un entorno de desarrollo integrado. Ambas rutas tienen ventajas y desventajas, pero en todo caso tener a mano un buen editor es siempre útil (aunque solo sea para abrir y modificar ficheros de texto eficazmente).
La semana pasada mencionaba alguno de los editores clásicos como GNU Emacs o Vim, que están acompañados de otras alternativas como Ultraedit y Notepad++. Mientras que los mismos siguen siendo herramientas excelentes y que se actualizan con nuevas versiones, mucha gente ha adoptado editores de nueva generación. Entre ellos destacan AtomSublime y Visual Studio Code.
Atom
Yo, en mi trabajo diario, empleo Atom, tanto para escribir en Latex como para escribir en C++ o en Julia (para R empleo RStudio y para Matlab el IDE de Mathworks, volveré a ellos en un momento).
Atom es un editor con un diseño moderno, de código abierto, que permite desde un uso muy sencillo a una adaptación a las necesidades de cada usuario muy sofisticada. Por ejemplo, es muy fácil cambiar el esquema de colores o la manera en que los archivos aparecen y uno puede compilar Latex, escribir un código en su lenguaje favorito, interactuar con Git y mantener una lista de tareas para el día sin abandonar la misma ventana y a una distancia de un golpe de pestaña. El número de paquetes es muy amplio y permite una instalación básica del editor muy ligera.
Sublime es muy similar a Atom en su concepción excepto que cuesta $70. A menos que uno tenga un motivo poderoso para emplear Sublime, es razón más que suficiente para no emplearlo; no tanto por los $70 sino por la limitación que los mismos supondrán al crecimiento de la comunidad de usuarios en el medio plazo.
La tercera posibilidad es Visual Studio Code. Aunque es un producto de Microsoft, ha sido lanzado en código abierto. Yo no lo he empleado nunca.
El lector interesado puede encontrar comparativas de estos tres editores más Vim aquí. Una lista exhaustiva de editores con puntuaciones de un grupo de evaluadores, aquí.
Entornos de desarrollo integrado
Muchos programadores prefieren emplear un entorno de desarrollo integrado, que agrupa un editor sofisticado para escribir código, un compilador, un depurador, control de código, un listado de comentarios (incluidos TODOs y otros), etc. La principal ventaja de los mismos es tener todo al alcance de un golpe de ratón o de un comando y poder implementar programación visual de una manera directa. La desventaja es que algunas veces los entornos le abruman a uno: son como esos coches modernos en los que te sientas y no sabes donde mirar de todos las indicadores que tienen.
Los dos entornos más populares son Eclipse y Visual Studio. Yo, en el pasado, cuando escribía en C++, Fortran o Scala, he empleado Eclipse. Visual Studio lo utilicé hace muchos años en una versión anterior.
Eclipse, que es de código abierto, lo tiene absolutamente todo, desde la última herramienta de programación en paralelo a una flexibilidad absoluta en configuración. Siguiendo mi analogía, es como un Mercedes S600 con todas las opciones: mires lo que mires, ahí esta. Y como un Mercedes, la ingeniería del mismo es extraordinaria. A la vez, algunas veces uno se pregunta para qué sirven esos 920 botones que no ha empleado nunca (exagero, pero solo un pelín 😉 )
Más ligeros en sus contenidos y quizás más fáciles de emplear para un economista son Netbeans y Xcode (que integra muy bien con los Mac). Uno de mis coautores lo hace todo en Netbeans y está muy contento con él. Xcode me imagino que es una buena opción si quieres escribir apps para el Iphone. Yo lo he empleado un par de veces y, al final, he terminado cerrándolo y abriendo Eclipse. Ya puestos a sacar el coche, sacas el Mercedes.
Existen además los entornos diseñados específicamente para cada lenguaje. RStudio, para R, es francamente bueno: muy facil de emplear, con todo lo que uno necesita a mano, etc. Matlab tiene su propio editor y, dado que habla con la pantalla de ejecución de manera rápida y la configuración ya te viene dada, normalmente no merece la pena emplear otro editor distinto.


Finalmente querría resaltar Jupyter, una aplicación para la red en código abierto para crear y compartir documentos con código en diferentes lenguajes, datos, ecuaciones, etc. Yo la he empleado un par de veces pero dada la popularidad que esta ganando recientemente probablemente le dedique algo de tiempo a aprender Jupyter mejor durante mis clases en otoño.
Librerías
Una idea que ha surgido varias veces en los comentarios de entradas anteriores es que muchas de las cosas que uno necesita implementar vienen ya en librerías (o paquetes, como se llaman en algunos contextos). Mi respuesta fue que, efectivamente, uno podía muy a menudo pero no siempre, emplear estas librerías (y, además, hay que ser un usuario inteligente de las mismas). Es el momento aquí de revisitar este tema.
Dos librerías muy comunes en métodos numéricos son Armadillo y Eigen (ambas herederas a distancia de BLAS y LAPACK). Armadillo, para C++ y todos los lenguajes que interactúan bien con C++ como Julia o R, es la más sencilla de emplear de las dos y tiene todas las funciones necesarias de álgebra lineal con un sintaxis deliberadamente similar a la de Matlab para conseguir una facilidad de uso de las matrices. Eigen es más poderosa pero también algo más compleja de aprender.
Otras librerías a resaltar son la GNU Scientific Library y GMP para aritmética de alta precisión (por ejemplo, en problemas de estimación, doble precisión da algunas veces problemillas).
Numerical Recipes, de la que ya hablé, es otra librería muy conocida, aunque algunas veces un poco pedestre. Matlab, Julia, R y Python tienen muchas librerías/paquetes que me resulta imposible repasar ahora. Una búsqueda en internet o algunos libros como este le dará al lector toda la información que requiera.
Control de versiones
En cuanto uno empieza a programar o, simplemente, escribir un trabajo de investigación un poco serio se encuentra con la aparición de múltiples versiones del mismo fichero. Una solución sencilla (y que solventa de vez en cuando los problemas) es ser cuidadoso y tener diferentes versiones de cada fichero identificadas con la fecha de edición o similares. Pero si esta estrategia de pobre le saca a uno de un apuro, no es escalable y cruje en cuanto tiene más de un par de coautores que van por libre. Más de una vez el insistir en el control de versiones me ha sacado de algún apuro serio y por ello lo recomiendo enfáticamente.
La solución profesional es emplear un software de control de versiones. El más popular hoy en día (y creo el más extendido entre los economistas) es Git. Existe también una variante en la red, Github, que se ha convertido en uno de los medios de difundir código más común.
Gitbook
De nuevo, existen decenas de libros sobre Git, pero el que yo recomiendo es Version Control with Git: Powerful tools and techniques for collaborative software development (2nd ed.) de Jon Loeliger y Matthew McCullough. Las ideas básicas de Git se aprenden en un par de horas.
Aunque no exactamente control de versión, es también útil tener una herramienta para actualizar todos los programas instalados en el ordenador. Yo empleo Macports: es superfacil.
Compiladores
Compiler
Cuando mencionaba, en mi entrada anterior, lenguajes de programación como C++ o Fortran pase de puntillas sobre la idea del compilador que uno necesita para generar un código ejecutable (si uno quiere aprender de verdad que es un compilador, el “el libro del dragón” sigue siendo la referencia clave).
gccegg-65
La elección clara para un economista es GCC, la colección de compiladores de GNU. Gracias a ella uno tiene compiladores para todos los lenguajes comunes de la máxima calidad, técnicamente actualizados, de código abierto y que generar código muy rápido (sí, el mismo código compilado con dos compiladores diferentes puede correr a velocidades muy diversas, con diferencias a veces de mas de 100% incluso con las mismas banderas de compilación, por ejemplo una comparativa de compiladores de Fortran aquí). Además, enlazar GCC con Atom o Eclipse es cosa de cinco minutos.
Hoy existe una alternativa: la infraestructura de compiladores LLVM, que es la que está, por ejemplo, detrás del JIT de Julia. Los compiladores de LLVM enfatizan aspectos como tamaño del ejecutable y reducción en la velocidad de compilación que son importantes en la industria pero quizás algo menos en economía. Mi experiencia es que LLVM genera ejecutables un 10% más lentos que GCC, pero tales mediciones dependen, claro, tanto de los problemas que he corrido como de mi estilo de programación. Aquíaquí y aquí hay comparativas en detalle.
Finalmente están los compiladores de Intel, relativamente populares entre los economistas porque el compilador de Fortran es el heredero directo del venerable Digital Visual/Compaq Fortran. Pero hoy en día, con GCC y LLVM en el mercado y la posibilidad de integrarlos en Atom o Eclipse, no veo razones poderosas para pagar lo que cuestan estos compiladores de Intel (y, de nuevo en mi experiencia, el ejecutable generado por GCC es ligeramente más rápido que el generado por Intel).
Antes de pasar a la siguiente materia una sugerencia: invertir un poco de tiempo en aprender a manejar bien un compilador (las distintas banderas, etc.) es enormemente rentable en términos de velocidad, eficiencia, etc. La documentación en las páginas de cada compilador es normalmente el mejor lugar para ello.
Programa para controlar la recompilación
En cuanto uno se pone a compilar, desde un programa sencillito o un fichero de LaTex, pronto se da cuenta que es tremendamente aburrido tener que teclear todos los comandos y opciones y, que además, la mitad de las veces cometes un error. Para eso están los ficheros de control de recompilación, los famosos makefiles, que te permiten recompilar de manera rápida, compilar distintas versiones de un fichero (esto es increíblemente util para mí cuando escribo mis manuscritos largos), limpiar ficheros antiguos, etc.
Mi primer trabajo como ayudante de investigación en Minnesota fue escribir makefiles uno detrás de otro. En su día me pareció aburrido hasta que aprendí que quien programó la versión original de makeStuart Feldman, lo creo en su labor de becario un verano. Estas curas de humildad son las que le ponen a uno en su sitio en la jerarquía intelectual y le impiden quejarse.
gnumake
Hay muchos programas para generar makefiles. Yo soy un clasicón con este tema y siempre empleo GNU Make, que además ya viene instalado en casi todas las distribuciones de Unix. Una referencia completa es Managing Projects with GNU Make: The Power of GNU Make for Building Anything (3rd ed.) de Robert Mecklenburg. Además uno se puede bajar un par de makefiles de internet y emplearlos como plantillas para empezar a entender cómo emplearlos.
Depuradores
“1. That can’t happen.
2. That doesn’t happen on my machine.
3. That shouldn’t happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?”

Si el lector ha llegado hasta aquí, ya le puedo contar la verdad: la primera vez que escriba el código no va a correr. Y probablemente ni la segunda ni la tercera. Y cuando ya corra, le saldrá que el tipo de interés del modelo es 
12.455+4i por ciento al mes, lo cual no tiene mucho sentido, aunque solo sea por el componente imaginario. Obviamente el programa tiene errores (“bugs”, como el que le salta a Cecilia en la tira cómica que abre esta entrada).
Uno se puede poner a buscar los errores a lo bruto corriendo el código linea a linea hasta encontrarlos. O uno puede emplear un depurador y seguir las técnicas desarrolladas por décadas para encontrar los errores de manera sistemática. Una introducción general al tema, con muchos ejemplos reales, es Why Programs Fail, Second Edition: A Guide to Systematic Debugging (2nd ed.) de Andreas Zeller.
gdb
Hay muchísimos depuradores. Como yo empleo los compiladores GCC, lo que es más conveniente para mi es emplear el depurador asociado, GDB. Una buena introducción al mismo es The Art of Debugging with GDB and DDD de Norman Matloff y Peter Jay Salzman.
RStudio y Matlab tienen sus depuradores propios (siempre me sorprende la cantidad de estudiantes e incluso investigadores que no conocen estas herramientas en entornos que emplean a diario).
Relacionados con los depuradores tenemos las herramientas de linting y pruebas unitarias. Linting sirve para detectar código sospechoso de manera estática (es decir, antes de compilarlo y/o correrlo) y obligar a seguir un estilo (más detalles sobre estilo en unos párrafos). Muchos lectores ya habrán usado una herramienta de linting sin percatarse: son esas cajitas de colores que salen en la columna de la derecha del editor de Matlab (aquí más detalles). Otras herramientas de linting incluyen Lint y Splint. Las pruebas unitarias buscan asegurarnos que un módulo del código funciona como se supone que tiene que hacerlo. Matlab tiene una suite de pruebas unitarias que están muy bien explicadas. Puede ser un primer lugar para familiarizarse con esta técnica.
Análisis de rendimiento
“Premature optimization is the root of all evil.”
Vale, ya el programa corre y nos da un resultado sensato. El problema es que tarda 3 horas. Si uno solo tuviese que correr el código una vez, esto no supondría excesivo obstáculo: un poco de paciencia y ya se soluciona. Desafortunadamente, en realidad uno tiene que correr el código muchísimas veces: para mirar que ocurre cuando cambia valores de parámetros, para anidarlo en una estimación estructural, etc. Y, a menudo, no son ni 3 horas, son 30 o 300.
La solución es optimizar el código para ver si podemos lograr que corra más deprisa. Aunque esto no siempre es posible, muchas veces hay fallos en el diseño del código que ralentizan su ejecución (aunque el resultado final sea el correcto). Estos fallos, además, pueden ser muy sutiles. En clase, por ejemplo, siempre le pido a los estudiantes que corran el siguiente código en Matlab (escrito por claridad, no por elegancia):
% Example of locality in memory allocation
m = 2000; % Try 1000, 2000, 5000
n = 10000;

% A smart way to do it
tic
a = zeros(m,n);
toc

clear a
% A not so smart way to do it
% a = zeros(m,n); % Comment in to check latency even with preallocation

tic
for j = 1:n
    for i = 1:m
        a(i,j) = 0.d0;
    end
end
toc

clear a
% A really dumb way to do it
% a = zeros(m,n); % Comment in to check latency even with preallocation

tic
for i = 1:m
    for j = 1:n
        a(i,j) = 0.d0;
    end
end
toc
El objetivo es llenar una matriz de información (por ejemplo, que hemos leído de datos). Primero, hago todas las entradas cero de una manera eficiente y mido la velocidad de ejecución. Luego, hago lo mismo pero con dos bucles anidados, con el bucle interior iterando sobre filas. Esta segunda alternativa es lo que tendríamos que hacer si cada entrada es diferente y viene de otra parte del código o de un fichero externo (algunas veces se puede cargar la matriz entera de una vez, pero imaginemos que no se puede en el problema concreto al que nos enfrentamos). Finalmente, repito el ejercicio pero iterando sobre columnas en el bucle interior. Esta última manera de implementar el código es mucho más lenta que la segunda. Si tiene, querido lector, un Matlab a mano, corra usted el código y compruébelo por si mismo.
¿Cuál es el motivo de esta más que considerable diferencia en velocidad cuando los dos códigos hacen lo mismo? La manera en la que Matlab guarda la información en memoria y como accede a ella. Las matrices pueden ser guardadas en un orden de dominancia de fila o columna (row- and column-major order). Matlab implementa una dominancia de columna y por eso el tercer ejemplo nos da tan malos resultados. Dedicarle 5 minutos a averiguar cómo le gusta a nuestro lenguaje guardar matrices en memoria es una de las mejores inversiones que un programador en economía puede hacer.
Más en detalle, uno puede aprender a emplear una herramienta de análisis de rendimiento como el profiler de Matlab, el de R o el de los compiladores GCC. Hace unos años había una institución famosa en economía (no quiero decir el nombre) que tenía que correr un programa que les demoraba en exceso y estaban pensando en paralelizarlo todo (con el consiguiente coste en horas y dinero). Desafortunadamente no tenían a nadie en plantilla que supiese de estas cosas (su informático sabía de redes y wifi, que es para lo que le pagan y de lo que yo lo desconozco casi todo) y, aprovechando que yo pasaba por ahí, el director me pidió que le diese un vistazo al código. Con el profiler de Matlab encontré el problema en 5 minutos, un “hot spot” un poco tonto que habían creado y que no tenía mayor secreto en re-escribirse con un par de lineas. No cuento esta anécdota para presumir, pues no fue mérito mío. Todo el mérito fue emplear una herramienta adecuada para el problema. El fallo de la institución no fue crear un “hot spot” innecesario. El fallo fue no emplear una herramienta para eliminarlo.
JuliaHP
Matlab tiene unas páginas muy útiles sobre este tema y la mayoría de las lecciones en las mismas sirven para casi todos los lenguajes. Varios de los libros que recomendé la semana pasada también incluyen secciones sobre este tema. En Julia tenemos Julia High Performance de Avik Sengupta.
hpc
Más globales son Introduction to High-Performance Scientific Computing, de Victor Eijkhout, que tiene la ventaja de estar colgado gratis en Internet, e Introduction to High Performance Computing for Scientists and Engineers de Georg Hager (cuya página tiene mucho material adicional de gran utilidad) y Gerhard Wellein (una segunda edición está a punto de salir).
Programación en paralelo
Las referencias anteriores me obligan a tratar, de manera muy rápida, la programación en paralelo. Hoy en día la problemas de más alta dimensionalidad se implementan no en ordenadores con procesadores muy potentes, sino en ordenadores con muchos procesadores. Incluso la mayoría de los teléfonos móviles actuales vienen de fábrica con varios procesadores.
Dada la longitud de esta entrada y que programar en paralelo es algo un poco más avanzado, voy solo a dar dos pinceladas. En el futuro quizás vuelva a este tema (mi propio papel sobre el tema aquí).
MPI
Para las técnicas clásicas de OpenMP y MPI, uno tiene An Introduction to Parallel Programming de Peter Pacheco más las dos páginas que he enlazado, que incluyen muchos tutoriales. Para las técnicas más avanzadas de paralelización masiva, sobre todo en GPUs, Programming Massively Parallel Processors: A Hands-on Approach (3rd ed.) de David B. Kirk (que es alguien que de verdad sabe de esto) y Wen-mei W. Hwu (que tiene una clase en internet a la que yo me apunté hace unos años).
GPU
Finalmente, emplear AWS es una opción excelente desde el punto de vista de coste-eficiencia. Amazon tiene mucha documentación en la red sobre cómo AWS funciona.
Libro de estilo
Uno quiere siempre escribir código que sea:
1. Claro.
2. Robusto.
3. Fácil de mantener.
4. Fácil de compartir.
5. Con menos errores.

Un buen camino para ello es emplear un estilo de escritura consistente y lógico. Hay distintas maneras de conseguir este objetivo y las convenciones a seguir son, en buena medida, materia de gustos. Pero hay que seleccionar un estilo que le venga bien a uno y ser consistente con el mismo a lo largo del tiempo. El secreto es auto-recordarse que lo que es obvio para uno a 21 de Junio de 2017 puede no serlo en dos años cuando el papel llegue de vuelta de la revista con peticiones de cambio. Uno tiene que ser capaz de leer su propio código (o el de sus coautores) en el futuro.
La mayoría de las empresas líderes tienen libros de estilo que uno puede copiar. Por ejemplo, aquí está el de Google para C++ o para Python.
c++
Libros que tratan de estos temas incluyen The Elements of C++ Style de Trevor Misfeldt, Gregory Bumgardner y Andrew Gray y The Elements of MATLAB Style de Richard K. Johnson.
Latex
Como un breve apéndice, y aunque no es estrictamente cuantitativo: uno tiene que aprender Latex. Es la única manera de escribir ecuaciones o de integrar gráficos y tablas con un mínimo de elegancia (o simplemente, sin que Word decida de manera unilateral cambiar de formato).
lamport
A pesar de tener muchísimos años, LaTeX: A Document Preparation System (2nd ed.) de Leslie Lamport sigue siendo una introducción magnífica. Mi copia original murió de uso y la segunda no va por mucho mejor camino, aunque la verdad es que ahora suelo mirar en internet más. Libros más avanzados son este y este.
Para escribir en Latex, uno puede emplear un editor normal (como yo en Atom) o uno especializado como TexShop (que empleo para transparencias, porque me resulta más cómodo con Beamer que Atom). Aquí hay una comparativa de los mismos. Overleaf permite escribir Latex de manera colaborativa en la red.
Ahora una pequeña confesión: yo por muchos años no empleé BibTex. Me daba pereza teclear las entradas. En retrospectiva, es de las cosas más bobas que he hecho nunca y he terminado, con los años, malgastando mucho tiempo. Además, hoy, sitios como IDEAS o casi todas las revistas tienen las citas directamente en BibTex y no hace falta nada más que bajárselas. Así que lo mejor es empezar a emplear BibTex desde el día uno.
Conclusión
Ha sido este un largo camino, tanto para mí (escribir cada una de estas entradas es bastante esfuerzo de tiempo, aunque solo sea por organizar las imágenes) como para el lector, que si ha seguido las cinco entradas habrá leído más de 15.000 palabras (18000 si uno incluye la entrada de aprendizaje automático de Diciembre que motivo la serie) y me he dejado muchas cosas sin explicar). Además la información podrá haber abrumado a estudiantes jóvenes que tienen mucho camino que recorrer.
La idea, sin embargo, no es aprenderlo todo de la noche al día. Es ir, pasito a pasito, afianzándose en una serie de competencias que son claves para un investigador moderno. Es increíblemente fácil escribir una columna en el periódico o una entrada en un blog postulando que “A causa B”. Es mucho más difícil sentarse y escribir un modelo lógicamente consistente (las matemáticas nos descubren una y otra vez que mecanismos que parecían obvios en la discusión verbal se caen como una torre de naipes una vez que vemos los efectos de todos los agentes interactuando entre ellos), ponerlo en el ordenador y que las cosas salgan con el efecto cuantitativo que tienen que salir. Los modelos son tozudos y las restricciones impuestas por los datos mucho más. Lo normal es que las 10 primeras cosas que se te ocurran no funcionen como explicación del mundo. Pero de alguna manera ahí está la gracia y para eso sirven los métodos cuantitativos. Como dice Guillermo de Baskerville en El Nombre de la Rosa, si tuviera una única respuesta a mis preguntas, estaría enseñando teología en París y no economía en Penn.
http://nadaesgratis.es/fernandez-villaverde/guia-para-aprender-metodos-cuantitativos-en-economia-v