Posts

Este documento consta de 2232 caracteres. Al escribirlo, he incrementado la cantidad de información disponible en el mundo en 2232 bytes. De haber empleado dicho tiempo en tomar una foto al sol poniéndose con Carabanchel como horizonte, la habría incrementado en unos 100 Kb. Quien compone una canción, la incrementa en unos 4 MB. Y así, todos, diariamente, al escribir un correo electrónico, al hacernos una radiografía, terminar ese dichoso informe, o, incluso, comprar con la tarjeta de crédito incrementamos –consciente o inconscientemente– dicha cantidad de información. ...

Hoy he encontrado una cifra en el periódico: 153 días. Se refiere al tiempo que presuntamente tarda un aerogenerador en producir la energía que consume su construcción. Como curioso que soy, por el interés que tengo en la materia y porque nunca, nunca, nunca me creo un número que veo publicado, he hecho algunas comprobaciones por si el autor me trataba de colar un bulo. Es que, además, me ha sorprendido la cifra por pequeña, por demasiado favorable a la causa de las energías renovables cuando, años atrás, hablando del tema con mi antiguo profesor de física, habíamos llegado a una conclusión bastante distinta haciendo cuentas en la servilleta del bar. ...

Me enteré de esta iniciativa y me ha faltado tiempo para divulgarla entre los lectores de mi blog: StatProb, una enciclopedia de estadística y probabilidad patrocinada por varias asociaciones con interés en la materia. Más que a la Wikipedia, se parece a los proyectos Citizendium o Knol: los artículos son elaborados por expertos y aparecen firmados. Esto tiene las sobradamente conocidas consecuencias: un desarrollo más cuidado pero, a la vez, mucho más lento. Aunque tal vez esto no sea totalmente indeseable para una enciclopedia dedicada a temas tan técnicos y herméticos como los de ésta. ...

Por salvaguardar del olvido algunas entradas que hice en un blog que ya no existe años ha, reproduzco acá otra que solo se entenderá retrasando las manecillas de los relojes y reemplazando hojas en los anaqueles hasta hará cosa de cinco años atrás. Fue tal como sigue: JDM es un proyecto de especificación de una API unificada y estandarizada para facilitar el desarrollo de actividades de minería de datos. Actualmente, la versión 2.0 de dicha API está en proceso de discusión. Colaboran en su desarrollo algunas de las principales empresas del sector. ...

La próxima reunión anual de usuarios de R tendrá lugar del 16 al 18 de agosto de 2011 en la Universidad de Warwick, Inglaterra. Los conferenciantes invitados de este año van a ser Adrian Bowman, Lee Edlefsen, Ulrike Grömping, Wolfgang Huber, Brian Ripley, Jonathan Rougier, Simon Urbanek y Brandon Whitcher. Los usuarios de R están invitados a preparar charlas y presentar pósters ilustrando el uso de R. ¿Cuándo tocará en España? (Ramón Díaz Uriarte, que forma parte del comité organizador, me ha confirmado en comunicación personal que tardará, que hay una larga lista de candidatos a alojarlas y que vamos a tener que esperar todavía, me temo).

Últimamente me están llegando conjuntos de datos para analizar con muy pocos registros. He aquí un subconjunto de uno de ellos (de hoy y debidamente anonimizado): nivel.proteina <- c( 11.56, 10.43, 11.00, 10.92, 10.08, 9.98, 10.35, 9.55, 9.19, 7.00, 6.72, 6.43, 7.43, 7.26, 6.67, 7.49, 8.03, 8.17, 6.79, 7.68, 7.01, 7.51, 6.90, 7.27, 7.56, 8.61, 8.16, 7.12 ) grupo <- c(0,0,0,0,0,0,0,0,0, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1) datos <- data.frame( nivel.proteina, grupo ) Le he estado dando vueltas a la manera de representar gráficamente este tipo de conjunto de datos de la manera en que deben hacerse estas cosas: que con un mero golpe de vista pueda hacerse uno con ellos. ...

Me es más que grato anunciar que he alcanzado la segunda posición en el IEEE ICDM Contest: TomTom Traffic Prediction for Intelligent GPS Navigation (sección de tráfico): La competición constaba de tres partes (o subcompeticiones) distintas relacionadas con la predicción de ciertos aspectos relacionados con el tráfico en Varsovia: una para predecir el número de coches circulando por diez segmentos de calle de Varsovia a partir de recuentos durante los minutos previos; otra para predecir segmentos de calle donde se van a producir atascos a partir de la lista de otros que han ido atascándose previamente y una final para predecir la velocidad media del tráfico en determinadas calles a partir de datos de posición y velocidad enviados por sistemas de GPS instalados en un porcentaje de los vehículos a un servidor central. He logrado la segunda posición en la primera de ellas (usando R, obviamente) y espero redactar pronto un informe sobre la estrategia y métodos utilizados de cara a su posible publicación en las actas de la IEEE International Conference on Data Mining 2010 (ICDM10), que tendrá lugar en Sydney en diciembre.

Si el otro día anuncié la próxima integración de RapidMiner con R, hoy quiero dar a conocer un vídeo en el que se ilustra: Tiene buena pinta, la verdad.

El otro día escribí sobre WPS, un clon de SAS con unos costes de licencia sustancialmente menores. KDNuggets ha publicado los resultados de una encuesta entre usuarios actuales y potenciales de SAS en la que se les preguntaba por su disposición a migrar a dicha plataforma. Habedlos: ¿Cuál será la anomalía de la empresa española que no tengo noticia de ningún ERE en SAS? ¡Con la que está cayendo! Nota: he modificado la página de Datanalytics y ahora, en la sección de servicios, dentro del apartado de consultoría SAS, detallo específicamente la migración a WPS como uno de ellos. ¡A ver si pronto suena el teléfono!

El otro día dejé planteada una tarea para mis lectores (que han sido menos diligentes que yo, incluso). Trataba de una comparación entre varios métodos para acceder a diccionarios (o hashes) de datos desde R para tratar de identificar el más eficiente en términos de velocidad de acceso. Acá van los resultados: n <- 100000 dat <- data.frame( id = paste( "id", 1:n, sep = "_" ), valor = rnorm( n ), stringsAsFactors = F ) n.sample <- 20000 seleccion <- sample( dat$id, n.sample ) ### Con vectores: system.time( res <- sapply( seleccion, function( x ) dat$valor[ dat$id == seleccion ] ) ) # user system elapsed # 84.79 5.24 90.14 ### Con listas: mi.lista <- sapply( dat$valor, I, simplify = F ) names( mi.lista ) <- dat$id system.time( res <- sapply( seleccion, function( x ) mi.lista[[x]] ) ) # user system elapsed # 19.15 0.00 19.20 ### Con entornos: mi.entorno.0 <- new.env() invisible( sapply( 1:n, function(i) assign( dat$id[i], dat$valor[i], env = mi.entorno.0 ) ) ) system.time( res <- sapply( seleccion, function( x ) mi.entorno.0[[x]] ) ) # user system elapsed # 67.89 0.03 68.06 ### Con el paquete data.table: require( data.table ) tmp.dat <- dat tmp.dat$id <- factor( tmp.dat$id ) mi.data.table <- data.table( tmp.dat ) setkey( mi.data.table, id ) system.time( res <- sapply( seleccion, function( x ) mi.data.table[ J(x) ]$valor ) ) # user system elapsed # 371.07 25.91 400.39 ### Con hashes: mi.entorno.1 <- new.env( hash = T ) invisible( sapply( 1:n, function(i) assign( dat$id[i], dat$valor[i], env = mi.entorno.1 ) ) ) system.time( res <- sapply( seleccion, function( x ) mi.entorno.1[[x]] ) ) # user system elapsed # 0.14 0.00 0.14 Los números son tan concluyentes que me excusan de la necesidad de ofrecer explicaciones y distingos. Aunque para que mis lectores no tengan que ir subiendo y bajando por la entrada para realizar comparaciones, los resumo en un gráfico: ...