Procrastination

I really should be working on this obscure distributed RDF/FRP thing, but for various reasons my head isn't working properly write now. So I did this other stupid thing instead.

Zippy

Once upon a time, M-x yow in emacs would deliver a nice random quote from Zippy the Pinhead. Nowadays, you just get

Yow!  Legally-imposed CULTURE-reduction is CABBAGE-BRAINED!

which has something to do with copyright law. More specifically, the file yow.lines in emacs' data-directory now contains only the opinion expressed above, rather than the original seven-hundred or so precious epigrams, delimited by \000. I have heard dark …

TL;DR

• There was this perplexing article in Ars Technica about replacing Fortran for scientific computation.
• The main performance advantage of Fortran is that its restrictive data structures facilitate vector optimization.
• There are many ways to match and even outperform Fortran, while using other languages.
• But it's OK to use Fortran if you want to.
• Ars Technica notwithstanding, Clojure, Haskell and Julia are not locked in competition to replace Fortran.
• Ars Technica notwithstanding, Fibonacci sequences may be something we learned about once, but it is difficult to disguise their irrelevance to scientific computing.

Preamble

Ten or fifteen pages into a …

Time is confusing. Sometimes, it's so confusing that our thinking about it changes... over time. Which makes it triply confusing, or something. In this post, I want to talk about two aspects of temporal data, both common, useful and often misunderstood:

• Homogeneous vs Inhomogeneous
• Temporal vs Bitemporal

Homogeneous Temporal Data

The first thing to stress is that we're talking about homogeneous data, because "homogenous" means something completely different.

In a homogeneous, temporal data set, one column will contain a known sequence of discrete time values, and the other columns will contain whatever information is associated with those times.

You would …

In my last post, I talked a bit about how FRP might look if state were maintained explicitly in persistent data structures, rather than in hidden mutable structures. The accompanying code was in Scala, but my first implementation was actually in Clojure. I was originally going to use the Clojure code in the post, but, having taken motivating example code from a Scala paper, it felt lazy to switch to Clojure just because I felt like it.

That said, it really was more fun to write in Clojure, and in some ways I think it is clearer. Additionally, it seems …

Like any red-blooded American, I find regex golf fascinating. The idea, to paraphrase the comic strip, is to find a regular expression that matches all members of a group of related terms, but not any members of a different group. The hover text on the strip suggests a regex that matches all winning presidents.

Peter Norvig went to town on this, first clarifying the problem and then building an algorithm to search for the shortest solution that matches all mainstream presidential candidates who eventually won, but not such candidates who never won. (So Perot, Nader, Anderson et al don't figure …

Some time after my recent fiddles with IMDB, I read an interesting article about using a perceptron to classify words as parts of speech based on features that precede them in text. It's all done in python or some such sh*t, but whatever. Still very cool. Since I had all of this IMDB data accumulated in Mongo, I thought I would try to play with it, and the idea I had was to predict metacritic scores from the actors that appeared in each film. In retrospect, it's far from clear that such a prediction can be made and especialy …

This is about a month old.

Actually, scrap that. This kind of thing never gets old.

To wit, a presentation on implementing and "using" Fractran, via clojure of course.

The least silly aspects of the show are (1) that we can implement the language very concisely and functionaly, and (2) to interpret the results, there's a nifty sieve of Eratosthenes - the real one.

The code is on github.

I am broadly sympathetic to view that scalable systems must be built with statically typed langages, for reasons outlined in this wonderful screed, and, until recently, that has made it difficult for me to recommend clojure for institutional use.

With the introduction of core.typed, that has changed. The author has says that core.typed is now production-ready, and I agree. It's not perfect, but it will find bugs in your code without breaking it or causing performance problems. It's also pretty cool, and in many ways more expressive than type declarations in "normal" statically typed languages.

That said, the …

At some point, everyone wakes up in the middle of the night, in a cold sweat of panic that they don't truly understand how to derive the Y-combinator. Well maybe not everyone, but at least me. (Note that I'm talking about the higher order function, not the startup incubator.) I ended up reading through quite a few web pages, all of which presupposed a slightly different background, before I finally understood. This post distills my understanding, expressed in clojure, which happens to be what I'm into now. It can now be one of the pages that someone else finds not …

This is very cool.

(Thanks to David Nolen, who pointed out errors in the original.)

I hadn't realized that the standard higher order sequence functions compose in a manner that requires quite a bit of run-time machinery. For example nested map calls will cause a separate lazy sequence to be instantiated at each level of nesting, with each level "pulling" results from the next innermost as needed. The function calls are thus temporally interleaved, but the functions are not actually composed. We can see this happening by adding some printlns to some unary functions and then running a nested …