Population Algorithms

Hi Peter! Do you have any high res screenshots of Nitti Pear? I'm wondering how readable it is at different sizes. Any chance of a copy?

Mon, 18 Mar 2013 12:08:47 -0400

Refer to Blue Monday. They are making a new coding version of Nitti.

I have been browsing for the Nitti font for coding. I was wondering if you could send me your variation, Nitti Pear? Thank you very much.

Mon, 18 Mar 2013 12:07:25 -0400

Bold Monday is in the process of making a professional coding Nitti font. You should contact them.

jonklassen: A spread from ‘The Dark’, written by Lemony...

Fri, 08 Mar 2013 05:26:17 -0500

jonklassen:

A spread from ‘The Dark’, written by Lemony Snicket. Comes out April 2nd!

straightsixes: DP Custom’s Ironhead Bobber The Gulf rules

Sat, 10 Nov 2012 19:58:39 -0500

straightsixes:

DP Custom’s Ironhead Bobber

The Gulf rules

kiss

Sat, 10 Nov 2012 19:55:54 -0500

kiss

Photo

Tue, 17 Jul 2012 16:46:34 -0400

Go's gob encoding and nil values

Mon, 11 Jun 2012 19:35:11 -0400

In Go1 (to be specific, revision 7021c8a8a25a) the gob package returns an error if one tries to encode a nil value loosely speaking.

Excluding channels and functions (which cannot be serialized), nil values can be assumed by slices, maps, pointers and interfaces. Nil values, in the case of slices and maps, linguistically behave like empty slices and empty maps, respectively, which is perhaps why the gob package can, in fact, encode and decode those correctly.

On the other hand, it returns an error if one tries to encode a nil pointer or a nil interface. (Here, a nil interface is either an interface which has no type and no value, or an interface that has a type and a nil value.)

Oddly, there are some other quirks. Gob refuses to encode a slice of pointers, if any element in the slice is nil. However, it does not refuse to encode a struct that has pointer fields that are nil.

Jon Klassen from the book Coraline. I wonder if his process is...

Fri, 23 Mar 2012 15:28:15 -0400

Jon Klassen from the book Coraline. I wonder if his process is all digital, all manual, in between?

Awesomeness.

Wed, 21 Mar 2012 05:02:00 -0400

Awesomeness.

libflame and Elements

Fri, 02 Mar 2012 17:46:00 -0500

I listened to a talk by Robert van de Geijn today at MIT. I learned a few handy things regarding linear algebraic computation. The FLAME project contains a few sub-projects, which are of independent interest:

The Elements project is all about ‘programmability’ of linear-algebraic and other numeric algorithms. This means that it includes a language for expressing numeric algorithm while avoiding the cumbersome, error-prone and often-encountered multiple nested loops. This language consequently compiles down to machine code and optimizes the code intelligently for different targets: cluster, multi-core, GPU processors, even Texas Instruments’ DSP card (which purportedly can now SVD systems with nearly 100,000 variables).
The Elements project comes with re-implementations of BLAS and LAPACK and since it can compile for a cluster target, it is marketed as an improvement of ScaLAPACK. Apparently is beats ScaLAPACK in speed but also in having a more human-friendly language for implementing algorithms.
It seems that the bare-bones FLAME framework redefines the interface of BLAS and LAPACK and is actually easy to compile and use. It is thus probably preferred over the latter two.

The current research trajectory of the team is to figure out how to abstract away (and isolate from the algorithm logic) the expert’s knowledge of how to optimize code for a specific target hardware; thereby making it possible to plug in different optimization drivers into Elements for new hardware or cluster targets.

Design by Transformation (DxT)

Thu, 01 Mar 2012 17:39:00 -0500

There is an interesting talk advertisement at MIT by Robert van de Geijn. The advertisement stirred some thoughts with me regarding (systems for implementing) distributed numerical algorithms (like recommender systems, community detection, etc.). But first, the talk abstract:

The FLAME project has yielded modern alternatives to LAPACK and related effort. An attractive feature of this work is the complete vertical integration of the entire software stack, starting with low level kernels that support the BLAS and finishing with a new distributed memory library, Elemental. In between are layers that target a single core, multicore, and multiGPU architectures. What this now enables is a new approach where libraries are viewed not as instantiations in code but instead as a repository of algorithms, knowledge about those algorithm, and knowledge about target architectures. Representations in code are then mechanically generated by a tool that performs optimizations for a given architecture by applying high-level transformations much like a human expert would. We discuss how this has been used to mechanically generate tens of thousands of different distributed memory implementations given a single sequential algorithm. By attaching cost functions to the component operations, a highly optimized implementation is chosen by the tool. The chosen optimization invariably matches or exceeds the performance of implementations by human experts. We call the underlying approach Design by Transformation (DxT).

There are at least a couple of interesting things to be said here, from the point of view of massive-scale computation (as the one that happens in Facebook, Twitter, Google, Tumblr, Amazon, e.g.) engineering:

First, the majority of large-scale massively-distributed computation (like recommender systems or community detection) is numerical and no one is taking advantage of this handy bit of information. Paradigms for massive computation (like MapReduce) specify information flow scheduling, but assume entirely arbitrary information processing by user applications, thereby foregoing the ability to (statically or dynamically) optimize the resulting distributed code (in general and with respect to the available hardware). A direction worth exploring!
My current favorite paradigm for massive data processing is GraphLab, or to be more specific, the abstraction proposed by the GraphLab team. It is worth exploring how this compares with the paradigm in FLAME and whether a marriage is possible.
FLAME claims to have converged on a programming paradigm that shields the novice programmer from the tricky pitfalls of numerical algorithms. If this is indeed achieved, it worth keeping their design ideas when developing runtime platforms for massive-scale computation.

The possibilities hinted at are quite attractive:

Can one design an optimizing compiler (and respective runtime) for massive-scale distributed numerical computation by fusing ideas from FLAME and GraphLab?

The Nitti Pear programming font

Tue, 28 Feb 2012 18:00:00 -0500

I’ve designed a programming font, which has stood the test of time (with me) for about a couple of months now. My starting point was Nitti (Light and Medium), a very elegant and little known monospace font. I went on to make a myriad of changes to ensure the font meets certain stylistic requirements for programming purposes. For example, the signs ‘<’ and ‘-’ need to be vertically centered (with respect to each other) so that pointer dereferences ‘->’ (say in C/C++) and channel sends ‘<-’ (say in Go) appear pleasing and non-disturbing.

I’ve attached a screenshot from my machine, which features the font in use in a Go program inside Vim at 19px size. If you are lusting after my creation, do let me know. My codename for this font is Nitti Pear.

MapReduce < GraphLab < Pregel

Tue, 28 Feb 2012 15:34:07 -0500

MapReduce < GraphLab < Pregel:

GraphLab is a programming abstraction which is more general than MapReduce (Google) and less general then Pregel (Google). It is easier to parallelize than Pregel and allows for much natural and flexible implementation of modern machine learning and graph manipulation algorithms. In addition to that, it beats both frameworks in allowing vertex-level asynchrony.

Testing global graph properties via few parallelizable samples

Tue, 28 Feb 2012 11:15:00 -0500

Testing global graph properties via few parallelizable samples:

This paper demonstrates how one can compute non-trivial global graph properties by a small number of vertex samples. While it does not directly meet a specific need in the social graph business, it is exemplary of a class of similar algorithms which are efficient to parallelize in the GraphLab computational model and are likely very practical for huge social networks.

This paper’s introduction is, perhaps, more informative than its results in that it contains references to good reads in this field (of testing/exploring graph properties using this highly-parallelizable sampling paradigm), e.g.

Hassidim, Kelner, Nguyen, Onak, Local graph partitions for approximation and testing, FOCS 2009
Nguyen, Onak, Constant-time approximation algorithms via local improvements, FOCS 2008