R

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:

1. Construir un cojunto de datos simples (dos vectores, x e y).
2. Hacer una regresión de y sobre x y capturar los residuos.
3. Crear 1000 vectores y' distintos añadiendo a $latex \hat{y}$ (la predicción de y) en el modelo anterior una reordenación de los residuos.
4. Crear los correspondientes 1000 modelos haciendo la regresión de cada $latex \hat{y}$ sobre x.
5. Obtener el histograma del coeficiente de la regresión.

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.

Dice el diario El País que científicos británicos desarrollan un sistema que permite saber si alguien no está diciendo la verdad analizando su rostro.

El aparato, según el artículo

[…] podría ser utilizado para cuestiones de seguridad, como, por ejemplo, en los aeropuertos para identificar a potenciales criminales o terroristas.

Añade después que

[…] el sistema será capaz de coger al 90 % de los que mienten, porcentaje similar al obtenido por el polígrafo

El otro día me preguntó una compañera el motivo por el que un proceso (de transformación de datos) se ejecutaba tan lentamente. De oficio, siempre hago lo mismo —además, lo saben: ¿para qué seguirán preguntando?—: ejecutar el proceso sólo sobre un porcentaje de los datos.

Con los que el id acababa en 123, era inmediato; con 12, también; con 1, se eternizaba. Pero con 2, 3 y 4 volvía a ser muy rápido. ¡Había muchísimos registros con id acabado en 1!

David Cabo, de Pro Bono Público colgó el otro día una hoja de cálculo en Google Docs con referencias a las declaraciones del patrimonio (véase un ejemplo) a las que están ahora obligados los senadores y que cuelgan de la página de su benemérita y utilísima institución. Dado que los datos están en un formato no legible automáticamente, solicitó la colaboración de voluntarios para tabular la información.

Rápidamente logró completarse la tarea. Y ahora me he molestado en extraer una selección de los datos (quitando columnas descriptivas, etc.) para que los aficionados a R se entretengan sacándoles punta.

Me ha llegado noticia de una entrada en un blog, Visualizing Bayesian Updating, en el que se muestra visualmente cómo se actualiza la distribución a posteriori conforme aumenta el número de ensayos en un problema bayesiano simple. Explica también los fundamentos estadísticos del asunto.

Yo me limitaré a ofrecer una nueva versión del código —que no funcionaba copiando y pegando sin más— en el que he introducido ciertas modificaciones. Es el siguiente: