Programación

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. R está pensado para facilitar ese tipo de trabajo, no para crear programas complejos. Está optimizado para el usuario, no para la máquina. De ahí se sigue una cascada de corolarios que no ha lugar plantear aquí.

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! This Scala tutorial is text-and image based, easy to search for quick answers, and super helpful for anyone: as a base for learning or as a reference guide.

El problema es sencillo: se cuentan y ya.

Pero hay quienes tienen cantidades ingentes de elementos que contar. Tantos que por razones de memoria, etc., es inviable hacer lo obvio, es decir, guardar una lista de claves (elementos distintos) y valores (el número de ocurrencias) sumando uno a los últimos cada vez que ocurra una de las primeras.

Por ese motivo, existen algoritmos que aproximan el número de elementos distintos de una lista. Existe, de hecho, toda una industria dedicada a crear tal tipo de algoritmos.

Los que estéis por allí o tengáis la posibilidad de acudir, sabed: la semana que viene (5, 6 y 7 de mayo de 2015) se celebra una nueva edición de APIdays Mediterránea en Barcelona.

Quienes tengáis pensado acudir, podéis beneficiaros de un 30% de descuento si os registráis desde este enlace.

Participé en la edición de 2013 en Madrid y me duele no poder asistir este año. Entre otras cosas, por esto. Y me displace perdérmelo porque mi nuevo stealth project tiene mucho que ver con APIs…

Tengo un fichero .bak. Un fichero .bak (el mío, al menos) es una copia de seguridad de SQL Server y no hay forma humana de acceder a sus contenidos sin otro SQL Server (que yo sepa). No me preguntéis de dónde lo he sacado. La cuestión es que contiene datos que tengo que leer.

Requisito imprescindible para tener un SQL Server es disponer de una máquina con Windows. Pero yo no tengo ninguna. Cuando tuve, instalé la versión de evaluación gratuita de SQL Server (¿Express?) y me ahorré parte de la pena que describo a continuación. Lo hago por referencia mía, por referencia de otros y por si alguien conoce algún atajo.

Telegram es un sistema de mensajería por internet similar a Whatsapp, aunque con algunas diferencias notables:

• No es de Facebook
• Una vez tienes una cuenta, puedes usarla desde distintos dispositivos (Linux incluido)
• Tiene menos usuarios
• Es programable

De lo último es ilustración esta “conversación” que tuve con la cuenta @TeleR:

Los detalles, aquí. Y el crédito, para Rubén Tobalina.

Abres una aplicación en tu móvil que diseñó un programador búlgaro. Ipso facto aparece un insidioso banner de, p.e., Jazztel. ¿Cuáles son los mecanismos que ponen en contacto al búlgaro con Jazztel? ¿De qué manera recibe aquel una compensación de esta?

Tradicionalmente, el desarrollador habría hablado con, p.e., Google. Le habría dicho: yo voy a generar “espacios” donde tú vas a poder colgar propaganda a cambio de una cantidad (fija o variable). El intermediario, por otra parte, capta anunciantes (Jazztel en nuestro ejemplo), almacena un inventario de ellos y decide cuál de ellos mostrar. Hay teoría aplicable en estos contextos, como la que describe Real-Time Bidding Algorithms for Performance-Based Display Ad Allocation.

Tengo por delante otro proyecto que tiene mucho de análisis exploratorio de datos. Sospecho que más de un árbol construiré. Los árboles son como la Wikipedia: prácticamente nunca el último pero casi siempre el primer recurso.

Esta vez, además, por entretenerme un poco, probaré el paquete [evtree](http://cran.r-project.org/web/packages/evtree/index.html). Aunque no porque espere sorprendentes mejoras con respecto a los tradicionales, ctree y rpart.

¿Qué tiene aquel que los diferencie de los otros dos? Que la optimización es global. Tanto ctree como rpart utilizan algoritmos recursivos: al definir un nuevo corte del espacio, el algoritmo solo tiene en cuenta la región definida por los cortes anteriores. La optimización es local. evtree utiliza un algoritmo global de la familia de los evolucionarios (¡qué tufillo a lentorro!). Los detalles están aquí.