Si creo la función
foo <- function(a,b) a*a + b y la llamo mediante
foo(1 + 1,3) pueden ocurrir dos cosas: o bien que R precalcule 1+1 y la función ejecute 2 * 2 + 3 o bien que la función ejecute directamente (1+1)*(1+1)+3. Pero, ¿qué es lo que hace realmente? Si escribimos
f1 <- function(x){ print("Soy f1") x } f2 <- function(x){ print("Soy f2") x } foo(f1(2), f2(3)) obtenemos
Tengo la sensación de que un lenguaje funcional (como Scala) está particularmente bien adaptado al tipo de operaciones que exige MCMC.
Juzguen Vds.
Primero, genero datos en R:
datos <- rnorm(500, 0.7, 1) writeLines(as.character(datos), "/tmp/datos.txt") Son de una normal con media 0.7. En el modelo que vamos a crear, suponemos conocida (e igual a 1) la varianza de la normal y trataremos de estimar la media suponiéndole una distribución a priori normal estándar.
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.
