Programación

Don’t be loopy! es el título de una presentación realizada en el SAS Global Forum de 2007. Tiene que ver con el motivo que me hizo en mi día abandonar SAS y buscar —entonces aún no lo conocía— el cobijo de R: sus limitaciones para todo lo que tiene que ver con simulaciones, remuestreos, jackknifes, _bootstraps _y similares.

El artículo muestra lo que debería ser el estado del arte para realizar este tipo de programas con SAS. En el primero de los problemas que estudia, que denomina bootstrap simple, muestrea 1.000 veces un conjunto de datos de 50.000 observaciones y calcula el valor de la curtosis para cada una de ellas. Finalmente, proporciona un intervalo de confianza para dicho valor.

La función plot es genérica. Uno puede aplicársela a un data.frame o a un objeto de la clase lm. Y en el fondo, plot sólo elige cuál de sus métodos, es decir, las funciones que realizan el trabajo verdaderamente, aplicar. Para ver cuáles son los métodos asociados a plot basta con ejecutar en R

methods(plot)

La salida es autoexplicativa.

Podemos hacer un pequeño experimento creando una función genérica, foo, bastante tonta:

Uno de los pasos más importantes en el desarrollo de un paquete es verificar que funciona correctamente. Un check comprueba la estructura del paquete, la consistencia entre el código y la documentación, que no faltan secciones importantes en esta última, que los ejemplos pueden ejecutarse sin problemas, etc.

De ahí que sirva para para muchos propósitos. En particular, si uno elige los ejemplos que acompañan a la documentación de las funciones con buen criterio, éstos servirán no sólo para ilustrar el comportamiento de las funciones sino, también, para verificar el funcionamiento del paquete. Además, de usar R-forge, como el sistema realiza checks en varias plataformas distintas, el elegir bien los ejemplos permite realizar comprobaciones multiplataforma del código.

La segunda entrada en mi serie sobre la creación de paquetes con R cubre los primeros pasos en la creación de uno. Bastan para tener una primera versión de un paquete en minutos. Pero antes, unos consejos generales:

1. Usar algún tipo de sistema operativo basado en Unix: Linux, Mac OS, etc. o Cygwin en el peor de los casos. Tengo que confesar que yo comencé a usar Linux precisamente por este motivo: los procedimientos y herramientas que se utilizan para construir paquetes de R están influenciadas por la tradición Unix. Es cierto que se han creado herramientas para poder desarrollarlos desde Windows pero, después de haber trabajado en Linux, me parecen incómodas y antinaturales: pasar de Linux a Windows es como pasar del Ferrari al borriquillo.
2. Registrar el proyecto en R-Forge, como ya hemos comentado previamente. Dadas sus ventajas —siendo una de las principales permitir probar el paquete sobre varias plataformas distintas (Linux, Mac y Windows) automáticamente— sólo se me ocurre un motivo para no utilizarlo: como el código está públicamente disponible, no es válido para desarrollar aplicaciones cerradas y propietarias.
3. Utilizar subversion (o git). Si el proyecto se aloja en R-Forge, subversion es la opción por defecto. Utilizar subversion permite gestionar mejor el desarrollo del paquete y facilita la colaboración entre los diversos autores.

La manera en la que recomiendo comenzar a crear un paquete es partiendo de una serie de funciones ya desarrolladas previamente. Ni siquiera hace falta que estén terminadas ni que funcionen correctamente. Por ejemplo, podemos tener las dos funciones siguientes:

Por popular demanda, voy a ilustrar en esta entrada el uso de subversion para el desarrollo colaborativo de software. Lo escribo teniendo en mente el desarrollo de paquetes alojados en R-Forge y para usuarios de sistemas operativos más o menos decentes. A quienes usan Windows les recomiendo Tortoise, cuyo uso queda fuera del alcance de lo que sigue.

En primer lugar, para los desavisados: subversion es un programa para gestionar versiones de ficheros. A usuarios particulares, les permite mantener fotos de tu trabajo (¿cómo estaba mi libro/tesis/código hace un mes?). Cuando varias personas trabajan en un mismo proyecto, les permite controlar quién ha hecho qué, cuándo y por qué; además, que cada uno de los integrantes del proyecto trabaje sobre su propia copia del código, aunque mandando su cambios a un repositorio central y recibiendo, claro está, los cambios del resto del equipo.

Muchos de mis lectores tienen, seguro, maneras distintas —y probablemente mejores— de organizar sus proyectos en R que yo. Pero me consta que a algunos les cuesta no convertir sus carpetas en un caos en los que sólo ellos se manejan —hasta que pasa el tiempo, se olvidan y tienen que volver sobre ello—. Para ellos, para sugerirles un procedimiento eficiente de trabajo, va esta entrada. En ella describo cómo organizo mis propios proyectos con R.

El otro día di con una entrada en una bitácora con cinco consejos para utilizar R en producción. Cuatro de ellos son razonables:

• Crear un sistema de validación, monitorización y alertas. Y, en particular, desarrollar un mecanismo para que R notifique los problemas encontrados por correo electrónico. En la entrada original hay código que puede utilizarse para tal fin.
• Usar la función sink para facilitar la detección y corrección de los errores.
• Usar Linux de 64 bits con mucha, mucha memoria. Aunque el autor de la entrada que comenta no lo diga, añado yo de mi cosecha que es conveniente utilizar rm y gc explícitamente cuando dejen de utilizarse objetos voluminosos para eliminarlos más satisfactoriamente y facilitar labor del recolector de basura.
• Usar sentencias tryCatch.

El último de los consejos del autor es más cuestionable: utilizar —más bien se refiere a reescribir— tus propias funciones. Pone como ejemplo la función glm, que no tiene mucho éxito de crítica, al parecer.

Parcialmente en agradecimiento a Revolution Analytics por haber concedido una subvención a las III Jornadas de usuarios de R voy a discutir en esta entrada cómo paralelizar bucles usando los paquetes foreach y doMC desarrollados por dicha empresa.

El paquete foreach contiene, esencialmente, una única función, foreach, que, en su forma más básica, permite ejecutar bucles con una sintaxis un tanto peculiar:

foreach( i = 1:3 ) %do% log( i )

Volveré sobre algunas operaciones interesantes y bastante útiles que permite realizar esta función porque, de todas ellas, hoy me ocuparé sólo de una: la que abre la puerta de una manera sencilla a la paralelización de bucles.

A esa gente le había hecho falta, en efecto, un matemático. Les hubiera bastado saber mi número de teléfono y no habrían cometido tamaña tontería y habrían tenido a sus accionistas más satisfechos. Explicaré el asunto. Será muy instructivo para quienes opinan que no valemos para gran cosa.

Hace mucho, mucho tiempo, tanto que las neuronas que se acuerdan de eso están llenas de polvo, en un país muy, muy lejos de éste, trabajé en un proyecto cuya naturaleza no viene al caso. Sí que lo hace el que habían codificado el campo identificador de los contratos en su base de datos con un CHAR(26). Sí, efectivamente, usaban veintiséis caracteres para identificar un único contrato.

Conforme se populariza el uso de R, cobran creciente importancia las cuestiones concernientes a su rendimiento, su gestión de la memoria, etc. Hasta el punto que incluso uno de sus creadores, Ross Ihaka, ha expresado últimamente su descontento con las limitaciones de R (el enlace es gentileza de Daniel Castro) sugiriendo que sus componentes puramente estadísticos deberían construirse sobre la base de un lenguaje distinto, posiblemente Lisp.

Dentro de este contexto de preocupación sobre el rendimiento de R, han aflorado algunas cuestiones acerca de la eficiencia del intérprete a la hora de resolver expresiones matemáticas. Por ejemplo, Radford Neal estudió el desigual desempeño de R frente a ciertas expresiones matemáticas equivalentes: en particular, la expresión

En un hilo reciente en la lista de desarrollo de R ha habido una discusión interesante acerca de buenas prácticas a la hora programar con R y concretamente, para desarrollar paquetes que contuviesen llamadas a código desarrollado en C/C++.

En particular, el autor del primer mensaje del hilo criticaba varios usos que consideraba inadecuados a la hora de programar en R:

1. El uso de variables misteriosas surgidas de la nada. En particular, el uso de variables que aparecen en el cuerpo de la función pero que no han pasado como argumentos.
2. El uso de <<-
3. El uso de bucles for cuando el código podía haberse vectorizado.
4. El uso de return al final de una función
5. Código desordenado y antiestético. En particular, el no dejar que respire mediante el uso de espacios.

Al respecto, Hadley Wickham, recomendó leer los consejos que ha recogido en su wiki. Gabor Grothendieck recomendó una discusión en Stackexchange.

En esta entrada voy a mostrar tres maneras (que vienen a ser la misma) de ordenar los niveles de un factor en R:

1. La básica
2. La sofisticada
3. El atajo

Antes, responderé a una pregunta: ¿por qué reordenar niveles en factores? La mejor respuesta que se me ocurre: si no la sabes, deja de leer ya. Te aseguro que, a poco que trabajes con R, acabarás retomando la lectura.

La forma básica es la siguiente:

Puede que a alguien le resulte sencillo, pero jamás ameno: trabajar con fechas y horas es, cuando menos, una molestia con cualquier lenguaje de programación. Y como mi compañero Raúl ofreció en su bitácora una pequeña guía de cómo operar con ellas usando SAS/WPS, me dispongo yo a hacer lo propio con R.

Leyendo fechas y horas: strptime

El primer encontronazo con el insidioso problema de las fechas y las horas suele ser el tener que leerlas de algún fichero de texto. En tales casos la función strptime siempre es útil: