Programación

Ya están disponibles los vídeos de las sesiones de la conferencia BigDataSpain que anunciamos hace un tiempo en estas páginas.

http://www.youtube.com/watch?v=7efDRf4q3lk

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 :::.

En el artículo Large-Scale Parallel Statistical Forecasting Computations in R encontrarán los interesados información sobre cómo está usando Google R para realizar predicciones de series temporales a gran escala usando cálculos en paralelo.

El artículo tiene dos partes diferenciadas. Por un lado está la que describe los métodos que usan para realizar predicciones sobre series temporales. Parecen sentir cierto desdén por la teoría clásica, comprensible dado el gran número de series temporales que tratan de predecir y el mimo —entiéndase como uso de materia gris— que exige aquella. Prefieren un proceso en el que el coste sea esencialmente computacional: construir predicciones usando gran número de modelos distintos y promediándolos después para obtener resultados que, aunque lejos del óptimo para cada caso particular, resultan adecuados para su fin.

El algoritmo PSLQ se usa para resolver aproximadamente ecuaciones con coeficientes enteros $latex a_i$ de la forma

$$ \sum_i a_i x_i = 0$$

donde, obviamente, no todos los $latex a_i$ son cero. Aproximadamente significa que la solución se busca dentro de un cierto nivel de tolerancia.

No existe, que yo sepa, una implementación en R. Pero sí en Python, usando librerías que permiten utilizar números de precisión arbitraria, como [mpmath](https://code.google.com/p/mpmath/). Veamos un ejemplo:

Sin darnos cuenta, abusamos de ciertos términos. Uno de ellos es el de la varianza explicada. Después de años utilizándolo como por inercia, he venido a darme cuenta por dos vías distintas de su impropiedad: una de mis recientes lecturas y una experiencia profesional.

Tal vez sea más sencillo comenzar exponiendo la crítica realizada en esa página. Parte del análisis de la serie de muertes en Chicago entre 1987 y el 2000:

A las entradas que he hecho sobre Julia estos últimos días, quiero añadir esta en la que publico mi primer programa en dicho lenguaje.

Me ha dado por reimplementar el programa para realizar un muestreo de Gibbs que aparece en Gibbs sampler in various languages.

Lo primero ha sido instalar Julia, para lo que basta con seguir las instrucciones que aparecen en su página de github. Y aviso: tarda bastante en descargar y compilar todas sus dependencias.

Unos días después de la primera noticia acerca de Julia en esta bitácora me llegan, como suele ser habitual en estos casos, otras.

En primer lugar, hay una discusión interesante sobre R en la lista de desarrolladores de Julia. Y hay un vídeo de Jeff Bezanson sobre Julia de un seminario en Stanford que podría estar pronto disponible en el canal de Youtube de dicha universidad (y que, de momento, puede verse yendo a la bitácora de Julia y después, navegando a Stanford Talk Video y available here).

No sé si habéis visto la película argentina Nueve reinas. Trata de unos timadores que engatusan a incautos para sacarles la platica.

Pero no voy a hablar de esas nueve reinas sino de las ocho de Solve Eight Queens Puzzle With SAS Macro. De su introducción extraigo y traduzco:

The Little SAS Book contiene un excelente ejemplo para ilustrar las diferencias entre SAS como lenguaje de programación y C++ mostrando lo complicado que puede resultar procesar conjuntos de datos con un lenguaje de propósito general. Son 28 líneas de código C++ y 5 de SAS para leer un fichero delimitado e imprimirlo por pantalla. Es un ejemplo perfecto de cómo SAS es un lenguaje de cuarta generación con un alto nivel de abstracción y expresividad.

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):

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 entrada acompaña y remata para los usuarios de R la que escribí en general sobre los códigos de caracteres. Es un pequeño experimento en el que comparo lo que pasa al leer un fichero de texto codificado de dos maneras distintas en dos plataformas, Linux y Windows, que usan códigos de caracteres distintos.

Primero creo dos ficheros (en Linux) con el mismo contenido pero codificados de dos maneras distintas, utf-8 y latin1:

Unos quebraderos de cabeza en el desarrollo del paquete pxR concernientes a los distintos códigos de caracteres en que hay que transfomar los datos me han obligado a profundizar en este enojoso asunto.

En el principio, todo era felicidad. Existía el código ASCII que establecía una correspondencia entre caracteres, números y su representación binaria. Así, a la letra b le correspondía el número 98 cuya codificación binaria es el byte 01100010.