Programación

Unos días después de la primera noticia acerca de Julia en esta bitácora me llegan, como suele ser habitual en estos casos, otras.

En primer lugar, hay una discusión interesante sobre R en la lista de desarrolladores de Julia. Y hay un vídeo de Jeff Bezanson sobre Julia de un seminario en Stanford que podría estar pronto disponible en el canal de Youtube de dicha universidad (y que, de momento, puede verse yendo a la bitácora de Julia y después, navegando a Stanford Talk Video y available here).

No sé si habéis visto la película argentina Nueve reinas. Trata de unos timadores que engatusan a incautos para sacarles la platica.

Pero no voy a hablar de esas nueve reinas sino de las ocho de Solve Eight Queens Puzzle With SAS Macro. De su introducción extraigo y traduzco:

The Little SAS Book contiene un excelente ejemplo para ilustrar las diferencias entre SAS como lenguaje de programación y C++ mostrando lo complicado que puede resultar procesar conjuntos de datos con un lenguaje de propósito general. Son 28 líneas de código C++ y 5 de SAS para leer un fichero delimitado e imprimirlo por pantalla. Es un ejemplo perfecto de cómo SAS es un lenguaje de cuarta generación con un alto nivel de abstracción y expresividad.

R dispone de un conjunto de herramientas para depurar (debug) programas. Yo suelo usar la función debug de manera casi exclusiva y sistemática, pero leyendo The Art of R Programming he dado con una discusión sistemática sobre el proceso de depuración así como algunas herramientas adicionales.

Una de las primeras que menciona el libro es la función stopifnot, que puede ser intercalada en el código para verificar condiciones necesarias (y lanzar un error en caso de que no se cumplan):

He leído estos días el capítulo 14 de The Art of R Programming que trata problemas y trucos para mejorar el rendimiento de R en términos de velocidad y memoria. Menciona la función tracemem de la que nos ocupamos el otro día.

Menciona el capítulo cómo uno de los estranguladores del rendimiento de R es su política de copiar al cambiar (copy-on-change). Generalmente, cuando modificamos un objeto, R realiza una copia íntegra de él (¿y qué pasa si realizamos pequeñas modificaciones en un objeto muy grande?):

Muchos usuarios de R se enfrentan en alguna ocasión a problemas con el uso y gestión de la memoria. La función tracemem es útil a la hora de identificar ineficiencias en el código.

En su página de ayuda se lee:

Esta función marca un objeto de forma que se imprime un mensaje cada vez que se llama a la función interna duplicate. Esto sucede cuando dos objetos comparten la misma memoria y uno de ellos se modifica. Esta es una causa de uso de memoria difícil de predecir en R.

Esta entrada acompaña y remata para los usuarios de R la que escribí en general sobre los códigos de caracteres. Es un pequeño experimento en el que comparo lo que pasa al leer un fichero de texto codificado de dos maneras distintas en dos plataformas, Linux y Windows, que usan códigos de caracteres distintos.

Primero creo dos ficheros (en Linux) con el mismo contenido pero codificados de dos maneras distintas, utf-8 y latin1:

Unos quebraderos de cabeza en el desarrollo del paquete pxR concernientes a los distintos códigos de caracteres en que hay que transfomar los datos me han obligado a profundizar en este enojoso asunto.

En el principio, todo era felicidad. Existía el código ASCII que establecía una correspondencia entre caracteres, números y su representación binaria. Así, a la letra b le correspondía el número 98 cuya codificación binaria es el byte 01100010.

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, plotsolo 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:

    foo <- function( x ) UseMethod( "foo", x )
    foo.data.frame <- function( x ) plot( x )
    foo.integer <- function( x ) sum( x )
    foo.default <- function( x ) print( "Bu!" )

    foo( iris )
    foo( 1:7 )
    foo( "hola" )

También es posible crear nuevos métodos para funciones genéricas existentes. Por ejemplo,

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 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 nosolo 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.