Roberto De Almeida

Hahaha, I love her reaction.

The pointfree module is about using function composition notation in conjunction with automatic partial application. Both of these features are achieved by wrapping functions in the pointfree class (which can also be applied as a decorator).

Several “pre-wrapped” helper functions are provided by the module. For instance, if you wanted to define a function that returns the sum of squares of the lengths of the strings in a list, you could do so by combining the helpers pfmap() and pfreduce():

>>> from pointfree import *
>>> from operator import add

>>> fn = pfmap(len) >> pfmap(lambda n: n**2) >> pfreduce(add, initial=0)
>>> fn(["foo", "barr", "bazzz"])
50

Interesting module. I've been looking for something like this in order to build a stream-like composition of functions to process huge datasets, and maybe I could use this.

Se há alguns anos a falta de dados limitava os avanços da ciência, hoje o problema se inverteu. O desenvolvimento de novas tecnologias de captação de dados, nas mais variadas áreas e escalas, tem gerado um volume tão imenso de informações que o excesso se tornou um gargalo para o avanço científico.

Never in modern history has it been so easy to create something from scratch, with little or no capital and a marketing model that is limited only by your imagination.

So the code for scanning a rectangle is like so:

R+>. 0R-!I R+v. 0R|!J R+<. 0R-!I R+^. 0R|!J X

Cool idea for scanning 2D arrays (text UIs or even graphics).

To get as close as possible to raw memory from JavaScript we have to use WebGL typed arrays. It’s easy for a JIT to befriend those guys and optimize the hell out of reads and writes, because they have a nice semantics for their backing stores: no nasty holes leading to prototype lookups, all elements have known primitive type and no boxing is required.

var blocks = [];

function Block(size) {
    this.size = size;
    this.buf = new ArrayBuffer(this.size);
    this.i32 = new Int32Array(this.buf);
    this.f64 = new Float64Array(this.buf);
}

function malloc(N) {
    if (blocks[N] && blocks[N].length) return blocks[N].pop();
    return new Block(N);
}

function free(addr) {
    (blocks[addr.size] || (blocks[addr.size] = [])).push(addr);
}

This is a very naïve implementation (I would even say parody) of the famous malloc&free duo. It does not try to optimize memory usage at all but it is perfect for our demonstration.

I need to rewrite my Javascript Opendap server using WebGL typed arrays.

You don’t need a 1,000-page computer model code to find out some pretty interesting things about extreme events. The few lines of matlab code below are enough to perform the Monte Carlo simulations leading to our main conclusion regarding the Moscow heat wave – plus allowing you to play with the idealised U-shaped climate discussed above. The code takes a climate curve of 129 data points – either half a sinusoidal curve or the smoothed July temperature in Moscow 1881-2009 as used in our paper – and adds random white noise. It then counts the number of records in the last ten points of the series (i.e. in the last decade of the Moscow data). It does that 100,000 times to get the average number of records (i.e the expected number). For the Moscow series, this code reproduces the calculations of our recent PNAS paper. In a hundred tries we find on average 41 heat records in the final decade, while in a stationary climate it would just be 8. Thus, the observed gradual climatic change has increased the expected number of records about 5-fold. This is just like using a loaded dice that rolls five times as many sixes as an unbiased dice. If you roll one six, there is then an 80% chance that it occurred because the dice is loaded, while there is a 20% chance that this six would have occurred anyway.

Nice article, this is the kind of science that I like -- simple models/analyses that look at data from the best angle. Science doesn't have to be complicated.

That's why I don't have kids, I would totally do this. The cute blond kid who smiles is awesome, and the last kid creeps me out.

90% of the time [:] could be replaced by list(). Of course it won’t work for everything since the two are not strictly equivalent, but it is worth trying. Next time you see a [:] try to replace it with list, your code should be more readable. Do it, the devil is in the details.

I would use b = [element for element in a] instead. Using b = list(a) is not explicit enough for me when a is already a list -- it's quite confusing. My options is more explicit in that we're creating a list from the elements of a, whatever a is.