Los pocos usuarios de SAS que lo utilizan para hacer propiamente estadística con él cuentan con un chuletario muy útil que relaciona temas de estadística con funciones, código y documentación relativa al asunto (dentro del universo SAS, por supuesto). Por ejemplo, para el llamado Bivariate Tobit model remite al procedimiento SAS/ETS PROC QLIM.

¿Conocerá alguno de mis lectores un recurso similar para R? Más aún, ¿se animaría alguno a emprenderlo?

Quiero compartir con mis lectores dos enlaces relacionados. Puede que a alguno le interese su sustancia misma. A mí no tanto. A mí me interesan en cuanto que ilustran la emergencia de R y el papel protagónico que está asumiendo en el universo de las cosas analíticas. Tan protagónico que hasta dos viejos dinosaurios pasan voluntariamente por su aro.

Tradicionalmente, para analizar grandes bases de datos empresariales, se realizaba en primer lugar una extracción masiva de datos. Luego se procesaban con herramientas específicas (SAS, por ejemplo). En muchas ocasiones los resultados eran volcados nuevamente en el sistema de partida.

El proceso es manifiestamente mejorable: ¿qué necesidad existe de realizar tantas extracciones e importaciones de datos? ¿No podría realizarse el análisis en el mismo entorno? Además, en tal caso, los desarrolladores de sistemas de bases de datos podrían depredar el lucrativo nicho de las empresas que ofrecen soluciones de análisis de datos.

A este voluntarista proyecto le dieron incluso un nombre (en inglés, claro): in database analytics.

De hecho, por eso estuvieron tan cerca SAS y Teradata —que vende unos gestores de bases de datos ridículamente caros a empresas cuyos directivos se preocupan más de dejarse invitar a congresos chachiguays que de sus accionistas— de fusionarse. Y puede que también por eso lo desestimasen.

Lo que es cierto es que Oracle, Teradata y otras empresas del ramo han desarrollado sus propios algoritmos de minería de datos. Y ahora —ahora llegan mis dos anunciados enlaces— nos brindan una interfaz a dichos algoritmos desde R:

• Así, Teradata ha desarrollado el paquete paquete TeradataR.
• Y Oracle, que lleva años desarrollando sus propios algoritmos de minería de datos —desarrollados a partir del trabajo original de Thinking Machines— ha desarrollado y liberado RODM.

A pesar del escepticismo que muestra el empresariado patrio frente a la emergencia de R, el que dos dinosaurios corporativos hayan pelado sus barbas puede ser el indicio de que telefónicas, santanderes, bebeuveás y demás tienen que ir poniendo las suyas a remojar.

El reto lanzado por Revolution Analytics a SAS está relacionado con el lanzamiento por parte de la primera empresa de un paquete, RevoScaleR, diseñado para permitir el análisis de conjuntos de datos grandes. La lectura más detallada de uno de los pocos documentos técnicos que circulan sobre el paquete me invita a compartir con mis lectores mis impresiones más allá de las primeras y más someras que realicé hace unos días.

La primera es que sigo sin entender claramente cómo es y cómo funciona el nuevo formato de almacenamiento de tablas, XDF. Al menos, no es público. Aunque es un tema de investigación candente (de lo que son prueba esto, esto, esto o el mismo paquete ff de R), no está claro si reaprovecha desarrollos previos o si es una implementación desde cero.

La segunda impresión es que el nuevo paquete utiliza una notación muy SAS:

# Create function to transform data
myTransforms <- function(data){
       data$Late    <- data$ArrDelay > 15
       data$DepHour <- as.integer(data$CRSDepTime)
       data$Night   <- data$DepHour >= 20 | data$DepHour <= 5
       return(data)
}

# The rxDataStepXdf function read the existing data set, performs the
# transformations, and creates a new data set.
rxDataStepXdf( outData="ADS2",
              inData=dataName,
              transformFunc=myTransforms,
              varsToKeep=c("ArrDelay","CRSDepTime","DepTime"))

rxShowInfoXdf("ADS2", numRows=5)
# Run a logistic regression using the new variables
logitObj <- rxLogit(Late~DepHour+Night, data="ADS2", verbose=TRUE )

Pensé en un primer momento que podía ser intencional y buscando facilitar la migración de un sistema a otro. Luego, preguntándome a mí mismo qué tipo de interfaz hubiese usado yo para implementar algo parecido, no se me ocurrió nada radicalmente distinto: al tener la información en disco, los ficheros de datos se leen y se escriben: ya no se cargan en memoria. Por lo tanto, es necesario especificar fuentes y destinos de datos, qué transformaciones realizar sobre ellos, etc. Sin embargo, el nombre de la función rxDataStepXdf() sí resulta sumamente revelador.

La tercera, es que hay algo en los experimentos que describe el artículo que huele a chamusquina. Se trata de un análisis para comprobar el rendimiento del paquete a la hora de realizar una regresión sobre un conjunto de datos con 123M de filas y 29 columnas y que ocupa 13GB en disco. El estudio lo realizan con un portátil con 3GB de RAM (también con un servidor, pero eso no nos preocupa en esta entrada). Los tiempos que obtienen son:

¡Curioso! En la segunda y posteriores ejecuciones, el tiempo de proceso desciende a 4 segundos desde los casi 40 de la primera. ¿Motivo? Dizque las cachés. Y yo me pregunto, ¿cómo pueden cachear 13GB con 3GB de RAM? De ser por las cachés, la mejora en tiempos sólo podría explicarse si el fichero original ocupase menos de 3GB. ¿Será que los 13GB de fichero inicial realmente ocupan muchísimo menos (incluso menos de 3GB) en formato XDF? Porque tampoco es creíble que un portátil lea 13GB en 40 segundos. Ni mi portátil ni el de nadie. Según la Wikipedia, no cabe esperar velocidades de lectura superiores a 1000Mbits por segundo; es decir, nunca más de 125MB por segundo. Únicamente leer 13GB a esta velocidad requeriría algo más de 100 segundos.

Al autor de esta entrada se le escapa algo de lo que cuenta el artículo.

Una última salvedad: sólo R (con el paquete RevoScaleR) puede leer y generar ficheros de tipo XDF. Entonces, ¿cómo generarlos? Porque si, por ejemplo, alguien te hace llegar un fichero de texto enorme, antes de poder cargarlo con R tienes que pasarlo a formato XDF. Pero para pasarlo a XDF tienes que haberlo cargado antes en R. Etc. De nuevo, ¿me pierdo algo?

¡Quién sabe si Revolution Analytics estará usando mi paquete colbycol (a propósito, ¿lo conocéis? ¿lo habéis probado?) para realizar la primera lectura!

gplot2 es, sin duda, el paquete gráfico de moda en R. Hay quien lo ama, hay quien lo odia, pero cada vez son menos los que lo ignoran. Lo que igual no es tan sabido por los usuarios de R es el contexto en el que nació ggplot2, su relación con el motor gráfico de R y su relación con otros mecanismos de representación gráfica existentes en otros paquetes estadísticos.

Existen en R (cuando menos) dos motores gráficos distintos. Por un lado existe el original. Cuando se utilizan las funciones gráficas tradicionales de alto nivel, tales como como plot, lines, hist, etc.se está interactuando con él. El libro Gráficos Estadísticos con R de Juan Carlos Correa y Nelfi González es una referencia (aunque ha envejecido algo desde su publicación; ¡a ver si Juan Carlos nos regala una nueva edición!).

Pero Paul Murrel desarrolló grid, un motor gráfico alternativo y mucho más flexible que ya está integrado en el sistema base de R. El interesado puede encontrar información adicional sobre grid en la página y el libro de Murrel R Graphics. El usuario habitual de R no lo utiliza directamente (¿le suenan a alguien las funciones wiewport o grid.rect?); es principalmente utilizado por otros paquetes que proporcionan funciones gráficas de alto nivel, tales como lattice, grImport (véase este ejemplo) y finalmente, ggplot2.

Prácticamente todo lo que hay que saber sobre ggplot2 puede encontrarse en la página de Hadley Wickham, incluido su libro (nota: hay gente muy mala que lo ha distribuido como pdf pirata). Pero me gustaría hacer hincapié en ciertos aspectos que parecen injustamente olvidados de muchos.

En primer lugar, que ggplot2 es una implementación en R de ideas desarrolladas por Leland Wilkinson en una serie de artículos (como éste) y en su libro que hace una distinción entre los aspectos sintácticos (la forma en que se especifican) y semánticos (los mismos datos que se representan) de los gráficos. De acuerdo con este documento, Leland Wilkinson trabajó para Systat en los años ochenta. En los años noventa trabajó en técnicas orientada a objetos para gráficos, organizando éstos como árboles. El resultado fue, a finales de los años noventa, Graphics Production Library, GPL una biblioteca de funciones gráficas de Java que desarrolló junto a Dan Rope y Dan Carr. Alrededor de 2005 se unió a SPSS, pero regresó recientemente a Systat. Las ideas contenidas en su libro han dado lugar a implementaciones en diversos entornos.

Aparte de la implementación (más o menos libre) que de las ideas de Wilkinson hizo Wickman para R en ggplot2, existen otras. No conozco Systat, aunque imagino que no las habrá desaprovechado. Pero una pregunta que realicé en StackOverflow me permitió averiguar que existen implementaciones de algo parecido en SAS (véase esto y esto) y en SPSS (ChartBuilder).

Revolution Analytics ha disparado un torpedo apuntando bajo la línea de flotación de SAS. Se trata del SAS to R challenge, una muy inteligente campaña de publicidad por la que se compromete a reescribir en R gratuitamente código SAS de clientes potenciales si el primero es más eficaz que el segundo.

Más allá de lo que la campaña parece ser, se esconde lo que realmente es: la constatación de que el premio gordo en el mundo de análisis empresarial es la actual base instalada de SAS y de que Revolution va a por todas.

¿Cómo espera Revolution Analytics desbancar a SAS? Utilizando su nueva extensión propietaria RevoScaleR, un paquete de R diseñado para afrontar los retos que supone el análisis de los conjuntos de datos grandes que manejan típicamente las organizaciones. Los lectores de esta bitácora, con la ayuda de Google o Blekko serán capaces de encontrar por sí mismos la típica información comercial (vídeos, folletos, etc.) acerca del producto.

Sin embargo, destacaré aquí dos de los aspectos técnicos RevoScaleR que han transcendido:

• Utiliza un formato propietario de almacenamiento de datos, XDF (¿estará emparentado con éste?), diseñado para permitir un acceso rápido a filas y columnas de los datos (y sin necesidad de volcar su contenido en la memoria).
• Contiene reimplementaciones de diversos algoritmos habituales en estadística y minería de datos que no necesitan disponer de la totalidad de los datos en memoria (supongo que al estilo de biglm)

Puede encontrarse una discusión técnica (de uso, no de arquitectura) en este artículo. Además, los interesados en aprender más sobre nuevos paradigmas de almacenamiento de datos que combinan las ventajas de los sistemas de almacenamiento por filas (como casi todos los RDBMs) y columnas (como R), encontrarán, seguro, de interés este enlace.

Al autor le preocupa de viejo el problema de la representación gráfica de datos. Piensa que tiene más de arte que de ciencia. Tal vez lo dice porque no se le da bien: confunde tonos y colores y desgarbado es el adjetivo que mejor describe sus trazos.

Y como casi todo diletante maltratado de las musas, ejerce de crítico. Y voto a Dios que su crítica es acerba. Le irritan todos los gráficos de tarta (menos éste), desea toda clase de malaventura al cretino que lleva lo de Excel en Expansión y vive prisionero de otras manías semejantes.

Pero a su crecida colección de atentados contra el buen gusto y criterio (un ejemplo acatarrante) y no peor provista recopilación de otros que parecen concebidos para engañar a incautos (¡uno de tantos!) le faltaba éste:

El autor quiere proceder de impresión a sustancia y de sustancia a análisis. Observa primero cómo en el gráfico R ocupa la periferia de los proscritos (junto a un tal StatCrunch), excéntrico respecto al núcleo duro de los SAS, SPSS, Excel (¡Excel!) y Stata, lejos de la estrella verde (Best) y del circulillo (Perfect). Tal debe ser la impresión que impresiona a los impresionables hojeadores circunstanciales del artículo A comparative study of the reliability of nine statistical software packages de Kellie B. Keelinga y Robert J. Pavurb (que encontrará el interesado en la red).

Lo mostrado es un resumen gráfico que hacen los autores de unas tablas prolijas en las que se muestra la precisión (en términos de número decimales correctos) de ciertos indicadores construidos por varios paquetes estadísticos sobre una serie de conjuntos de datos recopilados por el NIST para calibrar y comparar algoritmos.

El impresionado impresionable puede entender que el gráfico es la precisión sin advertir que el efecto más importante que se aprecia en él es un artefacto del método de representación. Como los más sagaces de los lectores habrán adivinado, de las etiquetas Prin1 y Prin2 de los ejes se deduce que lo mostrado es una representación de las primeras dos componentes principales de la matriz de resultados tabulados, responsables (dice el artículo) del 60% y del 18% de la variación de los datos, respectivamente.

Pero, ¿qué miden Prin1 y Prin2 realmente? Dicen los autores que Prin1 es una general measure of overall accuracy. No especifican con qué pesos (¡ni si son todos positivos!) pero el lector podría darse medianamente por satisfecho.

¿Y Prin2? Es una measure of the contrast in performance between certain data sets, una medida de contraste entre la precisión alcanzada entre algunos (sin identificar) de los conjuntos de datos. O sea, una especie de varianza (pero que no es la varianza de toda la vida, sino otra más chachiguai). O sea, excipiente dimensional, graficaca.

Pero Prin2, de menor relevancia y con un tercio de carga factorial, se representa sobre el eje X, casi el doble de largo que el Y (¡que es el verdadearamente significativo!) desdibujando las relaciones de proximidad entre los puntos y creando asociaciones aparentes y espúreas.

¡Cuidado con las impresiones, cuidado con la graficaca!

Hace  unas semanas se liberó una nueva versión de Mathematica. Aunque lo he utilizado ocasionalmente y leído varios manuales de cómo usarlo eficazmente, suelo estar al tanto de las nuevas versiones que se liberan y de sobre qué funcionalidades se centran las mejoras. Me gusta ver cómo siguen creando cierta diferencia sobre el resto de competidores en este segmento del software “mathemático” y de un tiempo a esta parte con la aparición de Wolfram Alpha, su creador, el niño prodigio Stephen Wolfram, se prodiga un tanto más, que también anima el espíritu.

En esta nueva entrega, una de las mejoras introducidas ha sido la de ampliar la gama de distribuciones estadísticas que Mathematica es capaz de gestionar. Y para dar muestra del gran avance han creado un par de gráficos donde se muestran las diferencias con respecto a otros programas, uno de ellos R.

En este primer gráfico, la comparativa es directa, un gráfico al uso, claro y sencillo de entender. Un Pareto. Pero al tiempo, opaco porque no aparece (tampoco es el objetivo) la referencia a los “individuos” analizados, las distribuciones.

El Pareto de los de Mathematica. Sencillo de entender.

La carencia del gráfico anterior, queda completamente cubierta en este otro. Que aunque sin duda más complicado de entender, sí que lo calificaría de “honesto”. Refleja todo el conjunto de distribuciones y sobre ellas de una forma original, indica si las otras aplicaciones las contemplan o no.

Detallado y honesto... pero....

Cierto, es detallado y honesto, pero falta dar respuesta a otro atributo sin duda necesario, ¿es cierto?. Es aquí donde tengo mis dudas. Por varias discrepancias (Copula, Pareto) creo que el gráfico refleja de R tan sólo el conjunto de distribuciones que se contemplan en la librería “base”, pero poco más allá.

El que compre Mathematica por esta mejora, sin duda no habrá hecho una buena compra.

Previamente he hablado en este blog de las ventajas que ofrece PROC SQL en SAS sobre otros métodos más propiamente SAS de realizar ciertas manipulaciones de datos. Existen no obstante cierto tipo de manipulaciones que exigen pasos data: gran parte de las que hacen uso de la variable automática _n_.

No obstante, existe una función no documentada de SAS que permite implementar con SQL muchas operaciones de este tipo: monotonic.

He aquí un ejemplo:

proc sql;
  create table results as
    select
      monotonic() as sequence,
      *,
      case
        when (monotonic()=1) then 'First'
        else 'Not First'
      end as text
    from sashelp.class
  ;
quit;

He aquí otro de mi factura para muestrear la cuarta parte de las observaciones de una tabla:

proc sql;
  create table muestreo as
    select *
    from sashelp.class
    where mod( monotonic(), 4 ) = 0
  ;
quit;

Estoy seguro de que mis lectores encontrarán otras aplicaciones. ¿Será que alguno querrá compartirlas a través de estas páginas, quizás, para ilustración de todos?

Quien no esté interesdo en la literatura que viene después, puede acudir directamente a él. Encontrará subforos que discuten distintos aspectos y productos de SAS, podrá enviar preguntas, hacer gratis el trabajo que debería corresponder al soporte técnico de SAS si las responde, aprender cosas navegando, etc.

Claro que uno puede también obtener/aportar ayuda en StackOverflow o en la archifamosa lista de correo SAS-L.

De un tiempo a esta parte, observo que SAS se está volviendo una compañía más abierta a los aires del siglo XXI que la que conocí. Ha pasado de ser, primero, una compañía sumamente hermética, a tratar de crear lazos firmes con el ecosistema —así nos llamaban en tiempos sin que llegase nunca a saber si se trataba de una velada y subrepticia manera de llamarnos animalicos— de desarrolladores de SAS externos a la compañía. Y parece, en una tercera fase, que trata de crear una comunidad de usuarios al uso y explorar opciones que ofrecen las nuevas tecnologías tales como la creación de un portal para los usuarios de sus productos o el patrocinio de un canal específico en Twitter.

Sigo sin recomendar SAS prácticamente para ningún uso. Pero quien tenga la necesidad de trabajar con él cuenta arriba con una serie de medios a través de los cuales pueda obtener soporte más rápida y fehacientemente que por los canales habituales que la compañía pone a disposición de sus clientes.

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 a 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!