En el siguiente vídeo Wolfram habla del lenguaje de Wolfram. Siento repetirme, pero quiero dejar claro que puede haber un sesgo. Porque como no lo haya, el Sr. Wolfram me va a tener como admirador (y puede que hasta como cliente).
Mirad lo que cuenta:
¿Es o no casi increíble?
Hoy viernes vuelvo a traer a mis páginas cuatro enlaces interesantes. El primero de ellos es como las malas películas: un arranque espléndido, un planteamiento prometedor y, al final, humo. Pero no trata de chico-conoce-chica sino de qué hacer con esas variables que tienen una varianza casi nula (a la hora de crear modelos estadísticos, se entiende). Me llegó tan oportunamente que pensé que alguien que vela por mí desde lo alto me lo enviaba para sacarme de mi semanal atolladero. Pero no fue el caso.
Hoy traigo a mis páginas cuatro enlaces que apuntan a recetarios y tutoriales sobre la solución a cuatro problemas que pueden encontrar los usuarios de R:
LaF)snow¡Espero que os resulten útiles!
Inspirado en esto aunque con la intención de mejorar el horrible código adjunto, escribí el otro día esto:
library("biOps")
library("cluster")
# leo una foto usando readJpeg de biOps
# el objeto devuelto es un array mxnx3 dimensional
# la última dimensión es el rgb de cada pixel
tmp <- tempfile()
download.file("http://blog.guiasenior.com/images/Retrato_Garber.jpg", tmp)
x <- readJpeg(tmp)
# si quieres mostrar la foto como un gráfico...
#plot(x)
# convertimos el array 3D nxmx3 en uno 2D (nm)x3
# luego buscamos 5 clústers
# esencialmente, buscamos 7 "píxels representativos"
d <- dim(x)
clarax <- clara(array(x, dim = c(d[1] * d[2], d[3])), 7)
# reemplazamos cada rgb de cada cluster por su
# "píxel representativo" (medioide) correspondiente
rgb.clusters <- clarax$medoids[clarax$cluster,]
# convertimos la matriz resultante en un array 3D
# (invirtiendo la transformación anterior)
# y representamos gráficamente
plot(imagedata(array(rgb.clusters, dim = d)))Obviamente, podéis cambiar la foto y hacer variar el número de clústers. Pero conviene recordar que:
Creo que muchos hemos tropezado con las macros alguna vez. Yo conocía las del preprocesador de C o el tinglado que tiene SAS. Y nunca fui muy amigo de ellas.
Pero el otro día leí Stop Writing JavaScript Compilers! Make Macros Instead y se me alargaron los dientes. Así que he buscado información adicional hasta hacerme una idea de la diferencia entre una macro que se limita a reemplazar texto, una macro procedural —como las del lenguaje PL/I, antecesor e inspirador de SAS— y las sintácticas, como las que tiene Lisp (¿cuándo tendré tiempo para aprenderlo en condiciones?).
Por referencia mía y de otros, voy a dejar acá escrito y explicado cómo gestiono mis copias de seguridad. Porque los discos duros se rompen y los ordenadores desaparecen. Etc.
Primero, mi instalación: tengo un ordenador de bajomesa (tiramisu) y un netbook (kropotkin). Ambos corren la misma versión de Xubuntu, la última estable.
Mi primera línea de defensa contra las pérdidas de información es la sincronización de ambas máquinas. Aquellos directorios que contienen cosas que no quiero perder (documentos, fotos, código, ¡copias de seguridad de otras máquinas, incluido esto que lees ahora!, cosas que no son documentos en desarrollo, etc.) se guardan en el directorio .bck de ambos ordenadores. Los directorios que veo son enlaces blandos (vía ln) a subdirectorios de .bck.
No sin descaro, me atrevo a aportar una definición alternativa a eso que llaman big data y que yo traduzco en ocasiones como grandes datos.
No obstante, para comprenderla, considero necesaria una pequeña digresión de dos párrafos —con la que muchos, espero, no aprenderán nada que no traigan ya sabido— sobre los lenguajes de programación declarativos e imperativos.
En los primeros, programar consiste esencialmente en escribir con cierta notación aquello que quieres: la suma de los elementos de un vector, el promedio de los valores de una columna de una tabla, la suma de los saldos de los clientes de Soria, etc. El intérprete se encarga de servirte los resultados en la proverbial bandeja.
Sigo con mi lacónica serie sobre data.table.
La protagonista:
frases[sample(1:nrow(frases), 3),]
#pos.es pos.en length.es length.en en es frase tfe qjilm num
#1: 15 43 72 72 i de 2632 4.881416e-02 0.01369863 6.686871e-04
#2: 33 48 46 48 X países 5321 2.726146e-06 0.02040816 5.563563e-08
#3: 2 35 53 66 in preguntar 4582 2.424379e-08 0.01492537 3.618476e-10
dim(frases)
#[1] 6340091 10El tiempo:
system.time({
setkey(frases, "frase", "es")
denominadores <- frases[, sum(num), by = key(frases)]
setnames(denominadores, c("frase", "es", "den") )
frases <- merge(frases, denominadores)
frases$delta <- frases$num / frases$den
})
#user system elapsed
#5.628 0.208 5.841En particular,
El otro día tropecé con un problema de rendimiento con R y al utilizar Rprof() encontré muchas llamadas a funciones que yo no hacía directamente.
La principal sospechosa era la función daply (del paquete plyr) que parecía depender de bastantes otras. Uno puede navegar el código de las funciones para identificar esas dependencias, pero, mirad qué maravilla:
library(mvbutils)
library(plyr)
foodweb(find.funs("package:plyr"), prune = "laply")genera
Ahí se ve la dependencia de daply con respecto a laply. Y uno adquiere, además, una visión panorámica del paquete plyr.
Los protagonistas (tres tablas grandecitas):
dim(qjilm)
# [1] 3218575 5
dim(tf)
# [1] 6340091 7
dim(tfe)
#[1] 1493772 3
head(qjilm, 2)
#pos.es length.en length.es pos.en qjilm
#1 1 2 1 1 0.8890203
#2 1 2 1 2 0.1109797
head(tf, 2)
#frase es pos.es length.es en pos.en length.en
#1 996 ! 42 42 ! 43 44
#2 1231 ! 37 37 ! 37 38
head(tfe, 2)
#en es tfe
#1 ! ! 4.364360e-01
#2 ! !" 4.945229e-24El objetivo (cruzarlas por los campos comunes):
Rubén Martínez, viejo conocido (fue instrumental en la organización del concurso de análisis de datos de las III Jornadas de Usuarios de R) me ha hecho llegar la siguiente infografía sobre el estado del mundo de los grandes datos (big data) y, en particular, sobre las conferencias Big Data Spain en cuya organización colaboró. Es la siguiente (hay que hacer clic en ella para verla en tamaño completo):
Esperemos que el año que viene no coincida con las jornadas de R y podamos compatibilizar ambas…
Ya están disponibles los vídeos de las sesiones de la conferencia BigDataSpain que anunciamos hace un tiempo en estas páginas.
Hace unos días implementé un proceso MapReduce usando mincedmeat, un pequeño entorno en Python para desarrollar este tipo de procesos distribuidos. El código y los datos pueden descargarse de este enlace.
Los datos de partida están en 249 ficheros de unos 25kb que contienen filas del tipo
journals/algorithmica/HarelS98:::David Harel::Meir Sardas:::An Algorithm for Straight-Line of Planar Graphs
es decir, publicación, autor (o autores) separados por :: y título de la publicación. Los tres campos están separados por :::.
