Corría el año 2009 cuando comencé mi segunda aventura bloguera (nadie, yo incluido, quiere rememorar la segunda) cuando Raúl Vaquerizo tuvo la caridad de aceptarme como colaborador en Análisis y Decisión.
En diciembre de aquel año escribí cómo utilizar R en una cosa que entonces comenzaba a sonar: la nube y, en concreto, el servicio EC2 de Amazon.
El resultado, probablemente totalmente desfasado, fue este.
Material de hemeroteca, alimento de melancolías.
Mis clases de/con R suelen consistir en un guión que es un programa en R con muchos comentarios y ejercicios. Con el tiempo, estos últimos tienden a crecer hasta el punto de que se convierte casi en un fichero de texto comentado con aspersión —en su acepción no-DRAE de efecto— de líneas de código.
Mejor, me he dicho recientemente, usar Rmarkdown.
Pero Rmarkdown sirve para lo que sirve: como fuente para compilar ficheros pensados para ser leídos por seres humanos.
Acabo de ejecutar
set.seed(1234) x <- runif(1e6) x.shift <- 1e9 + x sd(x) sd(x.shift) sqrt(sum((x - mean(x))^2) / (length(x - 1))) sqrt(sum((x.shift - mean(x.shift))^2) / (length(x - 1))) sd.sum.squares <- function(x){ n <- length(x) suma <- sum(x) suma.cuadrados <- sum(x^2) sqrt((n * suma.cuadrados - suma^2) / (n * (n-1))) } sd.sum.squares(x) sd.sum.squares(x.shift) inspirado por esto y me pregunto: ¿tanto ha llovido en términos de precisión numérica desde 2008?
Sí, mi viejo ordenador había cumplido 6 años y comenzaba a quedarse corto. La puntilla fueron problemas de compatibilidad de la tarjeta gráfica con el nuevo Xubuntu (más precisamente, con los nuevos núcleos de Linux que trae). Así que lo que hace no tanto habría parecido ciencia ficción, es ahora realidad bajo mi mesa: 64GB de RAM para mí solo. Y eso que no me he querido gastar dinero; además que, como autónomo y siendo la nueva máquina herramienta de trabajo, viene a salirme como en la mitad que a un civil.
Trabajar con Spark usando Scala implica renunciar a ese paraíso que son las funciones melt y (d)cast de reshape2.
¿O no?
import org.apache.spark.sql.types.StructField; import org.apache.spark.sql.types.StructType; import org.apache.spark.sql.types.StringType; import org.apache.spark.sql.types.DoubleType; import org.apache.spark.sql.Row; /** Create some data **/ val nrows = 20 val origDF = sc.parallelize(1.to(nrows).map(x => (x, math.pow(x,2), math.pow(x,3)))).toDF("id", "cuadrado", "cubo") /** Melt **/ val ids = Map("id" -> 0) val cols = Map("cuadrado" -> 1, "cubo" -> 2) def melt(x:Row, ids:Map[String, Int] , cols:Map[String, Int]) = { var tmp = ids.
… rigen los siguientes términos de servicio (que traduzco, porque el original vienen en inglés):
Usuarios autorizados: usuarios afiliados a una institución educativa de investigación o sin ánimo de lucro.
Supongo que ese es el fin de la historia: estoy expulsado de ella, salvo que retuerza el hilo de la casuística, relaje el perímetro de las acepciones y me considere afiliado a alguna de las instituciones educativas donde imparto alguna clase; y justifique, claro está, que no tienen ánimo de lucro.
La solución que presenté el otro día para resolver el problema en cuestión, tal como indicó Iñaki Úcar, es demasiado aparatosa. La alternativa a mi propuesta
ssh -ND 2001 miusuario@datanalytics.com
y todo lo que sigue es crear un túnel ssh mediante
ssh -NL 2001:localhost:8787 miusuario@datanalytics.com
y conectarse a la sesión remota de RStudio apuntando en cualquier navegador a http://localhost:2001.
El comando anterior exige la debida exégesis, que nunca había tenido del todo clara.
Finalmente, instalé RStudio Server en la máquina que está sirviéndote esta página. Pero no dejo abierto el puerto 8787 al exterior ni jarto de vino.
(De hecho, veréis que desde hace un tiempo a este blog escucha en el puerto 443 y, aunque esa es otra historia, utiliza HTTP/2).
Así que lo he configurado para que solo se pueda acceder a él desde localhost, i.e., que no admita conexiones remotas, añadiendo la línea
Son lenguajes de programación diseñados para describir odelos probabilísticos y realizar inferencias sobre dichos modelos.
El resto de la entrada de la Wikipedia sobre este apasionante (y lo uso sin retintín) tema, aquí (y puede que también quieras visitar esto).
Me llegan noticias de PyData Madrid 2016, que tendrá lugar en abril de este año en Madrid:
Os pongo un poco en contexto. Las PyData empezaron como conferencias de desarrolladores y usuarios de herramientas Python para trabajar con datos. Las primeras se hicieron en Silicon Valley, Nueva York, Londres,… Actualmente hay conferencias en NY, SV, Dallas, Seattle, Boston, Londres, Berlín, Amsterdam, París, Colonia, Tokio, Singapur,…, y Madrid. Como he comentado, empezaron un poco enfocadas en Python pero ahora están mucho más abiertas y se habla de Julia, Python, R, Scala,…
Una de las cosas que menos me canso de repetir es que R no es (solo) un lenguaje de programación. R es un entorno para el análisis de datos. Los informáticos se horrorizan con él: no entienden por qué es como es. Pero, fundamentalmente, su problema es que no conciben que pueda haber sido diseñado para el REPL y no (solamente) para crear programas.
Casi todo el tiempo que paso con R abierto lo consumo trabajando interactivamente, no programando.
Existe una breve obrita, Unix for Poets, que utiliza el análisis cuantitativo de texto como excusa para aprender a manejar una serie de comandos inexcusables de Unix y sus derivados: wc, grep, etc.
Se la recomiendo particularmente a aquellos que se compraron una Mac y no saben que cuentan con una terminal decente oculta en alguna parte de su sistema (en serio, los hay: el otro día se la descubrí a una maquera).
Recibí recientemente este correo (con los enlaces que aparecen en él; solo he eliminado el apellido de la remitente):
Subject: Carlos - Scala resource
Hi Carlos,
I was doing some research for our students here at Udemy on people using Scala resources and when I came across your site, saw you were using the tutorial from Wikipedia.
We really like that resource, and actually created our own that we think is a perfect supplement!
