En serio, es así. ¿También if? Pues también. De hecho, `if`(1 == 3, print("a"), print("b")) Y eso permite, por ejemplo, que funcionen expresiones tales como a <- if (1 == 3) 4 else 5 tan útiles como poco empleadas en general. También son funciones (, { y otras que aparecen en la sección .Internal vs .Primitive del documento R Internals.
Estuve el otro día en una charla de José Luis Cañadas en el grupo de usuarios de R de Madrid sobre sparklyr. Hoy en otra de Juan Luis Rivero sobre, esencialmente, lo mismo, pero esta vez con Python. Y podría escribir “etc.”. Me centraré en la de José Luis, aunque podría decir lo mismo de cualquiera de las otras. No había trabajado con sparklyr. No soy siquiera fan de dplyr (aunque no es que no se lo recomiende a otros; es simplemente, como tantas cosas, que soluciona problemas que no tengo). Pero la seguí sin mayores problemas. Lo que tenía de nuevo era una fina, somera capa de sintaxis que enlazaba fundamentos con fundamentos. ...
Hoy comienzo a enseñar un curso de introducción a la programación para recién graduados que comenzarán un máster de matemáticas aplicadas con incursiones en la llamada ciencia de datos. Serán 4 sesiones con el siguiente contenido: Sesión 1, programación imperativa: variables, condicionales y bucles. Sesión 2, programación orientada a objetos. Sesión 3, colecciones: listas, tuplas, conjuntos, diccionarios, etc. Sesión 4, programación funcional: map, reduce, fold, foldLeft, scan, filter, etc. Los lenguajes a utilizar serán R y Python (via Jupyter). No me he atrevido a añadir Scala (como ejemplo de cómo deben hacerse las cosas, además de ser un lenguaje, para variar, tipado y no interpretado) por falta de tiempo. ...
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 > foo(f1(2), f2(3)) [1] "Soy f1" [1] "Soy f2" [1] 7 lo que significa que f1 ha sido llamada una única vez. Es decir, R resuelve sus argumentos antes de aplicar la función. Pero hay más: ...
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. Y con Scala, así: ...
Corría el año 2009 cuando comencé mi segunda aventura bloguera (nadie, yo incluido, quiere rememorar la primera) 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. Contiene demasiada información irrelevante —formato, etc.— para un guión. ...
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.mapValues(y => x(y)) for((k,v) <- cols) yield tmp + ("var" -> k, "value" -> x(v)) } val df = origDF.flatMap(x => melt(x, ids, cols)) val newStructure = StructType( ids.values.map(x => origDF.schema(x)).toList ::: List(StructField("var", StringType), StructField("value", DoubleType)) ) val meltDF = sqlContext.applySchema(df.map(x => Row.fromSeq(x.values.toList)), newStructure) /** cast **/ val castDF = meltDF.groupBy("id").pivot("var").sum("value")