Repugna un tanto ver a R entre las palabras Oracle y Enterprise. Sobre todo siendo Oracle una compañía tan opuesta al espíritu del software libre. Pero es de celebrar que nuestra herramienta de elección esté penetrando el sancta sanctorum del software propietario. Y eso que Oracle se hizo años ya con Thinking Machines, empresa pionera en el campo de la minería de datos y cuyos algoritmos acabaron integrados en Oracle Data Mining.
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):
Efectivamente, necesitamos una Asociación de Usuarios de R. Por ejemplo, durante la organización de las III Jornadas de Usuarios de R nos hemos enfrentado a muchos problemas que habrían sido mucho más llevaderos de contar con el paraguas institucional de un NIF. El número de actividades a las que una asociación podría dar cobertura es, con un poco de imaginación y generosidad, sumamente amplio.
Después de un par de arranques en falso, la cosa va en serio. Tenemos una propuesta de estatutos. Y durante las III Jornadas se procederá a su aprobación de manera que comience a andar. Por eso invito a quienes siguen esta bitácora a echarles un vistazo, acudir a las jornadas e implicarse en el desarrollo de la asociación.
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 es la tercera entrega de una serie de artículos en los que comparo SAS y R a la hora de realizar diversos tipos de simulaciones basados en Don’t Be Loopy: Re-Sampling and Simulation the SAS® Way.
Esta vez toca compararlos a la hora de aplicar el método del jackknife.
Primero, el código SAS que recomienda el autor del artículo, que calcula la curtosis de un conjunto de datos trivial (una muestra de 10k valores que siguen una distribución uniforme):
Continúo en esta la primera de las entradas que hice sobre el artículo Don’t Be Loopy: Re-Sampling and Simulation the SAS® Way.
Trata sobre lo siguiente:
x e y).y sobre x y capturar los residuos.y' distintos añadiendo a $latex \hat{y}$ (la predicción de y) en el modelo anterior una reordenación de los residuos.x.Es un caso de _bootstrap _en el que no se muestrean directamente los valores iniciales sino los residuos del modelo.
Hace años que no leo Expansión con la frecuencia de antaño. Los motivos son muchos. Pero el otro día, casi por nostalgia, pagué los 1.60 euros que no vale.
De entre los gañanes que trabajan en dicho diario hay uno que lo es más que todos: el responsable de las gráficas. En tiempos me irritaba. Luego me fui acostumbrando. Al final, casi, casi, le cogí cariño. Acabé interpretando sus gañanadas casi como si me dijese: “pues por aquí andamos, trabajando; de saludo, bien; y tus cosas ¿cómo van?”.
Revisito mi artículo sobre la ley de Benford no tanto por hacer mención a las entradas una, dos y tres que hizo Gregorio Serrano en su bitácora ni al oportunísimo artículo de The Guardian al respecto. Ni siquiera para mencionar la existencia de este sesudo artículo sobre el tema.
Lo hago porque me pliego a la demanda popular: voy a explicar con más detalle el código que dejé allí escrito y que, por referencia, es
benford <- function( foo, ..., n = 100000 ){
tmp <- foo( n, ... )
tmp <- as.character( tmp[ tmp > 0] )
tmp <- strsplit( tmp, "" )
leading.digit <- function( x )
x[ ! x %in% c( "0", "." )][1]
tmp <- unlist( lapply( tmp, leading.digit ) )
100 * table( tmp ) / length( tmp )
}
benford( rcauchy )
benford( rexp, rate = 2 )
benford( rexp, rate = 5 )
benford( rnorm, sd = 40 )
benford( rweibull, shape = 1 )Puede llamar la atención que el primer argumento de la función benford sea, precisamente, otra función. Nada del otro mundo. El siguiente es un ejemplo en el que se muestra el uso aislado para una mejor comprensión:
No sé si seguir leyendo libros. Sus autores los llenan de letras. Y es un lujo poder disponer del tiempo de leerlas todas.
Uno de esos libros llenos de letras es Linked, de Barabasi. Es un libro estupendo y recomendable. Pero podría ocupar 20 páginas si el autor fuese un poco más escueto y no se empeñase de llenarlo todo de anécdotas y colores.
Su primer capítulo trata sobre las redes sociales aleatorias, también conocidas como redes de Poisson o de Erdös-Rényi. Una de tales redes aleatorias es una colección de n nodos y enlaces entre ellos de manera que la probabilidad de que dos nodos x e y al azar estén unidos es p.
