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.
R es un lenguaje de programación de alto nivel que se usa principalmente en aplicaciones estadísticas y para la generación de gráficos. El objetivo de esta guía de estilo es que nuestro código sea más fácil de leer, compartir y analizar. Las reglas de esta guía fueron consensuadas con la comunidad de usuarios de R en Google.
Resumen de las reglas de estilo
.Rvariable.name, FunctionName, kConstantName<-, no =# seguido de un espacio; los comentarios dentro del código necesitan dos espacios delante de #TODO(username)Resumen de las reglas de programación
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.
Hace no mucho, Radford Neal publicó pqR, una versión de R más rápida. Y algunos os preguntaréis qué es y de dónde salió esa reimplementación.
La respuesta breve es la siguiente: no hace tanto, cuando R iba por la versión 2.13, Neal sugirió una serie de modificaciones (patches) para mejorar el rendimiento de R en algunos aspectos. Creo recordar que eran catorce, aunque bien pudo haber habido otros posteriores. Los desarolladores de R, sin embargo, rechazaron algunos (si no todos) de ellos por motivos de diversa índole pero que se resumen en lo siguiente:
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):
Fresco aún en nuestro recuerdo el fiasco de Excel del que nos ocupamos hace unos días, los partidarios de la reproducibilidad, el software subversivo y gratuito, los detractores de las herramientas propietarias y otras estirpes han agudizado su campaña en pro de lo que denominan una mayor transparencia en el proceso de creación científica.
Como contrapeso a tanto despropósito, traigo a la consideración de mis lectores una visión alternativa que desnuda los desatinos de la caterva y recoge diez motivos incontestables por los que compartir código es una sinrazón. Es obra de Randall J. LeVeque que puede ser consultada como artículo o, para los impacientes, como presentación.
La función textConnection de R es útil para leer el contenido de una variable como si fuese un fichero de texto. Verbigracia,
zz <- textConnection(LETTERS)
readLines(zz, 2)Pero cuando uno hace
?textConnectiony lee con detenimiento, encuentra la siguiente nota:
As output text connections keep the character vector up to date line-by-line, they are relatively expensive to use, and it is often better to use an anonymous file() connection to collect output.
Vamos, que desaconseja usar dicha función por motivos de rendimiento cuando no vayan a usarse todas las sus características de las que file carece. Pero, ¿será cierto que el rendimiento es tan malo? Y de serlo, ¿cómo usar file?
Algunos usuarios del paquete pxR han avisado de un error de implementación. Según las especificaciones del formato de datos PC-Axis, las líneas de ese tipo de ficheros acaban en punto y coma (y no necesariamente en un salto de línea).
Así que era natural leer los ficheros íntegramente, concatenar sus líneas físicas y luego partirlas usando strsplit para obtener las líneas lógicas.
Sin embargo, ciertos ficheros contienen descripciones (entrecomilladas) que contienen puntos y comas. Y eso produce caos.
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…
