Tengo delante Los cerebros ‘hackeados’ votan de Harari, autor de cierta y reciente fama. Elabora sobre un argumento simple y manido: el cerebro funciona como un ordenador y los seres humanos somos no solo perfectamente predecibles sino también perfectamente manipulables. De lo que se derivan muchas funestas consecuencias en lo político y en lo social.
El artículo me ha sido recomendado por dos personas cuyo criterio tengo en muy alta estima.
De vez en cuando pruebo paquetes promisorios. No es infrecuente que cosas que he intentado hace años, algún ejemplo más o menos sencillo que he publicado aquí, acabe convirtiéndose en la piedra angular de algo facturable. Incluso de algo facturable por mí.
geozoning podía haber sido uno de esos. La promesa del paquete es que puede ayudarte a segmentar regiones del espacio de acuerdo con alguna variable, una especie de clústering para información de tipo espacial.
El otro tropezamos con el siguiente artefacto:
a <- list(aa = 12, bb = 14) is.null(a$a) #[1] FALSE a$a #[1] 12 No es un bug de R, por que la documentación reza:
x$name is equivalent to x[[“name”, exact = FALSE]]
Y se pueden constrastar:
a[["a", exact = FALSE]] a[["a", exact = TRUE]] Comentarios:
Odio muchísimo los bugs que no son bugs porque están documentados en el la nota ‡2.a.(c), párrafo §23.
Una función no debería cambiar nada de cuanto la rodea. Debería devolver algo y ya. Se acepta barco como animal acuático cuando hay funciones que escriben en logs, guardan datos en disco o crean gráficos.
R deja que los usuarios se disparen en el pie permitiendo hacer cosas tan peligrosas como:
a <- new.env() a$1 # error foo <- function(){ a$a <- 1 } foo() a$a # [1] 1 De la misma manera, si le enseñas un cuchillo a una vieja, es posible que te dé su bolso con todo lo que contiene.
Echadle un vistazo a Syberia (y me contáis qué tal os va). Tiene muy buena pinta y puede ser útil para produccionalizar código.
[Esto es casi todo; lo que sigue es omitible.]
Sin embargo y sin que necesariamente haga desmerecer a Syberia como tal, en la página arriba enlazada se lee:
In the viewpoint of the author, R is syntactic sugar around LISP, which enables arbitrary computation; Syberia is an attempt to support this conjecture by allowing the construction of arbitrary software projects within the R programming language, thereby finally outgrowing its long-overdue misconception as a statistical tool.
Tuve ocasión el pasado jueves, en Barcelona y gracias a la invitación de KSchool, de lo que llamo el stack analítico. Es decir, de aquellas herramientas tecnológicas necesarias para poder hacer ciencia de datos hoy en día.
Las diapositivas de la charla están aquí.
El tema es viejo pero no por ello menos urgente: existen herramientas (y, desgraciadamente, me he visto a incluir el saber leer documentación técnica en inglés) cuyo conocimiento es imperativo para poder trabajar de manera efectiva en ciencia de datos.
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.
Nunca me he visto en la tesitura de tener que usar callbacks porque no son mi guerra. Pero por lo que he oído de la gente que sabe mucho más que yo, son uno de esos infiernos de los que hay que huir con el mismo pavor que de los fors, los ifs, los elses (¡argggg! ¡he escrito else!) y los whiles.
Una pequeña maravilla teórica que me ha hecho replantearme la absoluta inutilidad de aquello que estudié en Álgebra III (funtores y demás) son las mónadas.
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).
Es:
Nivel 1: Realizan la mayor parte de su trabajo con herramientas ofimáticas (fundamentalmente Excel), aunque pueden utilizar puntualmente Eviews, Stata, R o Matlab. Nivel 2: Los que realizan la mayor parte de su trabajo con R, Python, SAS o SQL pero cuyo sistema de control de versiones es el de ficheros con determinadas convenciones de nombres. Nivel 3: Como el anterior, pero usando control de versiones, estilos de código, y revisión por pares (peer review).
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
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.
