In some points, I’ve tried to fill in the most sketchy and un-articulated points with some simile of what I ended up actually saying.

Combinatorial species started out as a theory to deal with enumerative combinatorics, by providing a toolset & calculus for formal power series. (see Bergeron-Labelle-Leroux and Joyal)

As it turns out, not only is species useful for manipulating generating functions, btu it provides this with a categorical approach that may be transplanted into other areas.

For the benefit of the entire audience, I shall introduce some definitions.

Definition: A category C is a collection of objects and arrows with each arrow assigned a source and target object, such that

1. Each object has its own identity arrow 1.
2. Chains of arrows are associatively composable, with 1 the identity of this composition.

Examples: Sets, Finite sets, k-Vector spaces, left and right R-Modules, Graphs, Groups, Abelian groups.

: finite sets with only bijections as morphisms.

Examples:

• Category of a monoid.
• Category generated by a graph
• Category of a group (groupoid version of the category of a monoid)
• Category of a poset
• Category of Haskell types and functions.

Definition: A functor F is a map of categories, in other words, a pair of maps Fo on objects and Fa on arrows, such that the identity arrow maps to identity arrows and compositions of maps map to compositions of their images.

Examples:
Constant functor: sends every object to A, every map to 1.

Identity functor: sends objects and arrows to themselves.

Underlying set functor, free monoid/vector space/module/… functors.

We are now equipped to define Species:
Definition: A species of structures is a functor .

The idea is a set gets mapped to the set of all structures labelled by the elements in the original set. A bijection on labels maps to the transport of structures along the relabeling.

Examples:
: rooted trees, labels on vertices
: simple graphs, labels on vertices
: connected simple graphs, labels on vertices.
: trees, labels on vertices.
: directed graphs, labels on vertices
: subsets, .
: endofunctions
: involutions
: permutations
: cycles
: linear orders
: sets:
: elements:
: singletons: if and otherwise
: empty set: , otherwise
: empty species: .

In enumerative combinatorics, the power of species resides in the association to each species a number of generating functions:

The generating series of a species F is the exponential formal power series

where we use the convention , and .
Thus:

There are a number other in use for combinatorics, but for my purposes, this is the one I’ll focus on.

Operations on species

The real power, though, emerges when we start combining species, and carry over the combinations to actions on the corresponding power series.

Addition

The number of ways to form either, say, a graph or a linear order on a set of labels is the sum of the numbers of ways to form either in isolation.

This corresponds cleanly to the coproduct in Set, and we may write F+G for the species

(where the second + is the coproduct — i.e. disjoint union — of sets)

In the power series, we get .

Examples: We may define the species of all non-empty sets by

This kind of functional equations is where the theory of species starts to really shine.

Multiplication

A tricoloring of a set is a subdivision of the set into three disjoint subsets covering the original set. The number of tricolorings of size n is

A permutation fixes some set of points. The permutation restricted to the non-fixed points is a derangement. Total number of permutations on n elements is

In both of these cases, the total generating series is a product of the component series, and we end up defining

So .

Thus, tricolorings are and permutations are , where the set is that of fixed points, and the derangement captures the actual action of the permutation.

Composition

Endofunctions of sets decompose in their actions on the points as cycles or directed trees leading in to these cycles.

Since a collection of disjoint cycles corresponds to a permutation, we can consider such endofunctions to be permutations decorated with rooted trees attached to points of the permutations; or even permutations of rooted trees.

To form such a structure on a set U, we’d first partition U into subsets, put the structure of a rooted tree on each subset, and then the structure of a permutation on the set of these subsets.

Thus, the number of such structures on n elements is

This corresponds to the power series , and we write, in general, for the species of F-structures of G-structures on subsets.

Examples:
A = X·E(A)
L = 1 + X·L
B = 1 + X·B·B

Pointing

Picking out a single point in a structure on n points can be done in precisely n ways.

Thus the corresponding generating function will be

for f-structures with a single label distinguished.

Since we’re working with exponential power series, we may notice that

and thus that derivatives are shifts.
Furthermore,
so that the generating function for F-structures with a single distinguished are

In species, this process is called pointing.

In functional programming, Conor McBride related this construction to Huet’s Zipper datatypes.

As it turns out, many of the constructions for species make eminent sense outside the category . In fact, species in Hask are known to programming language researchers as container datatypes and the whole calculus translates relatively cleanly.

Functional equations translate to the standard new data type definitions in Haskell.

Examples:
L = 1 + X·L

data List a = Nil | Cons a (List a)


B = 1 + X·B·B

data BinaryTree a = Leaf | Node (BinaryTree a) a (BinaryTree a)


A = X·E(A)

data RootedTree a = Node a (Set (RootedTree a))

usually, we simulate the Set here by a List. If we need for our rooted trees to be planar, we can in fact impose a Linear Order structure instead, and get something like
Ap = X·L(Ap)

The species interpretation of corresponding to leaving a hole in the structure carries over cleanly, so that is the type of T-with-a-hole.

Two derivatives of lists

We can deal with in two different ways:

1.
DL = D(1+X·L) = D1 + D(X·L) = 0 + DX·L+X·DL
and thus
DL-X·DL = 1·L
so (1-X)·DL = L
and thus
DL = L·1/(1-X)

Now, from L=1+X·L follows by a similar cavalier use of subtraction and division — which, by the way, in species theory is captured by the idea of a virtual species, and dealt with relatively cleanly — that
L = 1+X·L
so
L-X·L = 1
and thus
(1-X)·L = 1
so
L = 1/(1-X)

Thus, we can conclude that
DL = L·1/(1-X) = L·L
and thus, a list with a hole is a pair of lists: the stuff before the hole and the stuff after the hole.

2.
We could, instead of using implicit differentiation, as in 1, attack the derivation we had of
L = 1/(1-X) = 1+X+X·X+X·X·X+…

Indeed,
DL = D(1/(1-X)) = D(1+X+X·X+…) = 0+1+2X+3X·X+…
which we can observe factors as
= (1+X+X·X+X·X·X+…)·(1+X+X·X+X·X·X+…) = L·L

Or we can just use the division rule
DL = D(1/(1-X)) = D(1/u)·D(1-X) = -1/(u·u)·(-1) = 1/[(1-X)·(1-X)] = L·L

Gröbner bases for operads

All of this becomes relevant to the implementation of Buchberger’s algorithm on shuffle operads (see Dotsenko—Khoroshkin and Dotsenko—Vejdemo-Johansson) in the step where the S-polynomials (and thereby also the reductions) are defined. With a common multiple defined, we need some way to extend the modifications that take the initial term to the common multiple to the rest of that term.

For this, it turns out, that the derivative of the tree datatype used provides theoretical guarantees that only partially filled in trees of the right size, with holes the right size, can be introduced; and also provides an easy and relatively efficient algorithm for contructing the hole-y trees and later filling in the holes.

In this course, we will teach category theory from first principles with an eye towards its applications to and correspondences with Haskell and the theory of functional programming. We expect students to previously or currently be taking CS242 and to have some level of mathematical maturity. We also expect students to have had contact with linear algebra and discrete mathematics in order to follow the motivating examples behind the theory expounded.

Wednesdays at 4.15.

Online notes will appear successively on the Haskell wiki on http://haskell.org/haskellwiki/User:Michiexile/MATH198

come this fall, I shall be teaching. My first lecture course, ever.

The subject shall be on introducing Category Theory from the bottom up, in a manner digestible for Computer Science Undergraduates who have seen Haskell and been left wanting more from that contact.

And thus comes my question to you all: what would you like to see in such a course? Is there any advice you want to give me on how to make the course awesome?

The obvious bits are obvious. I shall have to discuss categories, functors, (co)products, (co)limits, monads, monoids, adjoints, natural transformations, the Curry-Howard isomorphism, the Hom-Tensor adjunction, categorical interpretation of data types. And all of it with explicit reference to how all these things influence Haskell, as well as plenty of mathematical examples.

But what ideas can you give me to make this greater than I’d make it on my own?

Recall how you would run the Gaussian algorithm on a matrix. You’d take the leftmost upmost non-zero entry, divide its row by its value, and then use that row to eliminate anything in the corresponding column.

Once we have the matrix on echelon form, we can then do lots of things with it. Importantly, we can use substitution using the leading terms to do equation system solving.

The starting point for the theory of Gr̦bner bases was that the same method could be used Рwith some modification Рto produce something from a bunch of polynomials that ends up being as useful as a row-reduced echelon form.

Basically, the central theorem-definition of Gröbner bases (by Buchberger, named for his thesis advisor Gröbner), says that a Gröbner basis for some ideal in some polynomial ring is a bunch of generators for that ideal such that if we do polynomial division of any element of the polynomial in the ring with the generators, one after the other, until no more divisions could be performed, then what we get out of it all is uniquely determined.

This need not necessarily be the case, even to begin with Рwe could get weird loops and various kinds of bad behaviour that screws up the concept of dividing, with remainder, by a whole bunch of polynomials. Having a Gr̦bner basis means this is no longer a problem.

The important bit of the theorem is that we can GET a Gröbner basis by just iteratively trying out combinations of the generators, trying to find overlaps of the leading terms, and generating “bad examples”. Any bad example that doesn’t get completely reduced to 0 by division by the generators is also needed to complete the Gröbner basis, and by adjoining it we grow our generating set, but not the things it generates. And the method works by growing the generating set until anything we can build out of two of the generators really will reduce completely to 0.

And, the central theorem says, if THIS works, then reduction works in general, and we have a tool as good for solving systems of polynomial equations as the echelon form is for linear equation systems.

Losing commutativity

The next interesting step is to look at non-commutative polynomial rings. Here, we suddenly have a deep theoretic issue popping up. We know that the word problem for monoids Рi.e. whether a specific string can be reduced with rewriting rules to an empty string Рis unsolvable in general. It hooks up to Turing machines and the limits of theoretical computer science, but in essence we can encode problems as Gr̦bner basis computations for non-commutative algebras that we know cannot possibly be solved in finite time.

So we cannot hope for the situation to be as good as for commutative algebras. However, there is a theorem floating around – the Diamond lemma by Bergman – that says that if we DO get a Gröbner basis computation that halts in finite time, then all the good things that we had in the commutative case – such as reductions modulo the generators being well defined – hold for the things we’ve computed. In other words, the only thing that could go wrong would be that the computation of the Gröbner basis doesn’t finish in finite time.

Operads

Now, what I really wanted to talk about was operads.

Here, an operad is a collection {O(n) : n?1} of vector spaces with permutations attached to them. Hence, for each n, there is a map S_n ← Hom(O(n),O(n)), or in other words, we can apply any permutation of n things to any element in the component O(n) and get something back out of it.

Furthermore, an operad O = {O(n)} has defined on it structure operations. These behave like the composition of multilinear functions – so we have a way of plugging one function into another:
f(a1,a2,…,g(ai,…,aj),…,an)
and this composition is associative, so the order we figure out some sequence of compositions doesn’t matter.

These gadgets show up in modern approaches to universal algebra like questions, and also all over the place in topology; some of the earliest instances were from homotopy theory.

Recently, Dotsenko and Khoroshkin released a paper on Gröbner bases for operads. In the paper, they figure out a way to find the kind of canonical and ordered basis that you need in order to mimic the whole workflow of Gröbner bases above; and specified how one should go about producing a Diamond Lemma for operads. It turns out that Gröbner bases would be useful to prove operads to be Koszul – something I won’t discuss here, but which is important in the operad theory context.

Basically, instead of working in a polynomial ring on some set of variables, we start out with out variables in one of these graded sets {V(n)}. Then we can build rooted trees, whose internal vertices of degree n+1 are labeled by elements from V(n).

The vector space spanned by all such trees forms an operad where the composition operation works by taking a tree and attaching the root to the leaf numbered by whatever position we need to compose at.

The resulting construction is the free operad on the generating set and takes the role that the polynomial ring had in the previous examples. And what Dotsenko and Khoroshkin pointed out was that if we restrict the kinds of actions we allow from permutations on these trees somewhat, we end up with something that has exactly one representative that fits in the restricted context for each tree that occurs as a basis element of the free operad.

So we can impose some sort of ordering on these trees, and use them to mimic the Diamond lemma.

Indeed, what we end up doing is forming the overlaps between leading terms by finding trees that parts of the trees from the leading terms from pairs of operad elements can embed into, and using the resulting procedure to build the same kind of bad cases we need to test for Buchberger’s algorithm.

And again, it turns out that while we may not always get an answer within finite time, if we’re lucky then the answer we DO get has all the properties we could dream of. And not only that – all the previous kinds of Gröbner bases embed as special cases of doing it this way.

I heard of this, and got my hands on the paper, when I first arrived in CIRM in Luminy, outside Marseille, for 2 weeks of operad theory with a master’s course and a conference on the subject. And I got so excited – once upon a time this was essentially my proposal for PhD thesis project – that I decided to sit down and code the whole thing up right away!

And code away I did. Once the two weeks were gone, with the valuable help from Vladimir Dotsenko and Eric Hoffbeck, I had ended up with a working implementation in Haskell of the whole paradigm. It’s now available from the HackageDB, and runs at least in GHC 6.8 and 6.10:

And we see here that with the particular set of generators given, namely using m2 as the variable, and for a generating set, we pick
m2(m2(x1,x2),x3) + m2(x1,m2(x2,x3))
and
m2(m2(x1,x3),x2) – m2(x1,m2(x2,x3))

we get a Gröbner basis almost instantly containing additionally the generator
m2(x1,m2(x2,m2(x3,x4)))

So, here it is.

import Data.List

cards = [(1,7),(0,5),(3,7),(2,7),(2,13)]

countpairs [] = 0
countpairs [a] = 0
countpairs (a:as) = length . filter (((snd a)==) . snd) $ as

pairingOff = sum . map countpairs . tails

And that’s that. Alas, the actual competition only takes Perl, VBScript and PowerShell, so I won’t be submitting this.

One subject I spent a lot of time thinking about this spring was taking tensor products of A_∞-algebras. This turns out to actually already being solved – having a very combinatorial and pretty neat solution.

Recall that we can describe ways to associate operations and homotopy of associators by a sequence of polyhedra K_n, n=2,3,.., called the associahedra. An A_∞-algebra can be defined as being a map from the cellular chains on the Associahedra to n-ary endomorphisms of a graded vector space.

If this was incomprehensible to you, no matter for this post. The essence is that by figuring out how to deal with these polyhedra, we can figure out how to deal with A_∞-algebras.

A tensor product of algebras is basically the direct product of the polyhedra, and we can get precisely the thing we want if only we find a map from the cellular chains on K_n to the cellular chains on K_nxK_n fulfilling a few neat properties.

This map is what is known in the literature as the Saneblidze-Umble diagonal from the people who presented it in a paper from the late 90s. They describe in that paper, and more clearly in a later paper, how to actually get hold of one map with the right properties. The road goes over basic matrices, derived matrices and connecting matrices to trees describing associations. I’d like to take this opportunity to work through the implementation I just wrote of an enumerator for these, displaying the code and discussing it a little bit.

This post will be written as literate Haskell, so copy the text into a file, and then just save it as SaneblidzeUmble.lhs and you’re ready to go.

So, we will build a module named SaneblidzeUmble that shall contain the code:

We’re going to juggle a lot with lists, and a little with potentially failing calculations, so we’re going to include a couple of standard utility function sets too.

Permutations and staircase matrices

The issue we’ll want to solve in the end is to enumerate all the terms entering into a diagonal on K_nxK_n for one fixed n. These terms are, using the later to be mentioned terms, in correspondence to derived matrices of staircase matrices with entries from [1,..,n-1]. A staircase matrix is one with one entry for each diagonal (parallel to the main diagonal), and such that along each row and column, all entries are adjacent and strictly increasing down and to the right.

As an example, we have the matrix

.14
25.
3..

Given a permutation of [1,..,n-1], we can write the images in the order they occur, and then just take this as a description of the entries from lower left to upper right of a staircase matrix.

It turns out that the basic matrices involved in this process are in bijection to permutations of [1,..,n-1] by placing the digits into the matrix, going up whenever the next entry is lower, and going to the right whenever it is larger.

Thus, the example above is given by the permutation (32514).

So, to handle this, we need to be able to list all permutations as well as pick out all rising and all falling part runs of a permutation

This is almost readable as it stands. The permutations of [1..n] are just the permutations of the list [1..n].
There are no permutations of an empty list, the list with one element has one permutation of itself, and for any larger list we pick out one element at the time, permute the rest and prepend this element. The collected results are compiled into a single long list and returned.

Solves, by recursion, neatly and with a lot of connection to the mathematical thought behind it our problems.

Now, for the chopping permutations into monotonic runs, I’ll solve it all in a manner slightly decreasing the amount of code repetition. We have a “factory function”

and two use cases of this

Using this, we can build the matrix out of a given permutation. The only really interesting thing for the diagonal about such a matrix is the contents of the rows and of the columns, so we shall just use that. This means we can represent a matrix as the list of rows and the list of columns. Since row and columns “look basically the same”, they’ll be represented by the same type. So we have

The reason we use map sort and reverse is to make the result fit with the conventions chosen by Saneblidze and Umble. Note: when actually reading the results, users should take care to read the Columns backwards.

Deriving staircase matrices

Deriving the matrices is done with so called moves. We have a downward move, and a rightward move – both consisting of picking a subset of elements in one row or one column, and pushing them over to the next – given the condition that all the moved elements have to be larger than the largest they move over to. They also have to move to empty positions, but the ordering conditions for the staircase matrices will guarantee that if they really are larger, then the corresponding position is already empty.

So, we can write a a function that gives us all the subsets of the first column/row that might possibly be moved to the second in a given column/row-list of a matrix

This function picks out all the subsets of elements that fulfill the requirement of being larger than the largest element of the next row. But hang on – this subset-function actually isn’t defined yet. No worries – it’s easily done:

Again, we define everything recursively, relying on a base case of “blinding” simplicity, and end up with a very mathematical looking description. Here, the subsets of the empty set is just the empty set itself, and the subsets of any set with one element existing in it consists of the subsets containing that element and those that do not contain it. We simply list first those with and then those without.

Now, for the actual deriving move, we might run into a host of trouble, so we’ll just let it be able to return an error condition. It first checks a few possible error cases, and then writes down the actual move by picking out the rows it needs, modifying those, and putting it all together again in the end.

Supposing we have some set m we want to move, and we have a list of the rows where it could be moved, then we’ll want to first check whether all of m is in a single row together. Thus, for each row, we pick out all elements that are in our set m. But we don’t really care for what the elements are – we only need the number in each. So we compile a list of the lengths of these filtered out pieces.

We shall require the number of rows that have all the pieces we want to move to be 1, and also for that single row to have a good position within the matrix.

That monstrous expression at the end is known as a guard expression. It works through the cases until something actually is true, and then returns whatever is after the equal sign as the value. The conditions I listed weed out all the pathologies, and lets the program pick out something sensible whenever possible.

So, we can list all possibilities of one row, and we can move them. This should be enough to simply generate all derived matrices, right? Let’s start simple. Let’s start with all we can do on one side of the pair – either all possible down moves or all possible right moves (they are essentially the same anyway…)

Guiding you through this piece of code – when encountered with a list of rows, we look at each starting point, list all the possibly movable sets at that point, and move the corresponding sets, placing all the results at the back of a queue that we work through. Once the queue is empty, we know we have worked through all the results from all the moves we could find, and that no others can be found.

So, if we have our pair of row-lists? We first move to the right, and then down. At each point, we keep the other half fixed, and simply add it on to all the results of moving in the first part.

This first works through one direction, taking all derived rows, and tacking on the constant second half, then when that’s done, changes to the same but for the other half of the pair.

Now, we’re almost able to state what a specific diagonal looks like. There is only one more thing to handle: we might not want the results of a particular computation. More specifically, we recognize something we do not want by it having a row that isn’t consecutive, not even when including previously occurring rows. So, we need to check that.

Now it’s just a matter of putting the pieces together

Previously, a student of Ron Umble has done an implementation of the same task in C++. This cannot, according to Umble, handle anything larger than n=5. This Haskell implementation, while being surprisingly short and readable, has on my (64 bit, modern, high memory) workstation been able to meet the following execution parameters:

Conway’s Look-and-say sequence

Now, his text is unreadable. I mean, it’s even unpronounceable. Why? Because he’s looking at bigram distributions of letter.

Great, I thought, I’ll do him one better. Random text using bigram distributions on words must surely be a LOT better than random text using bigram distributions on letters. At least the words come out readable, and they may even come out in a decent order.

So I sat down with his code, and hacked, tweaked, and monadized it to this

So, I have some corpus — I just pulled the King James Genesis to have some sort of body of text to work it, and saved it into the kjv.genesis file. Then, I can pop over to my beloved GHCi and execute

The first execution will take a while, since it has to, y’know, digest the actual text, calculate distributions, and set everything up.

Subsequent executions also take quite some time, and I’m not at all certain why. An explanation would be nice, if someone has it.

And for some sample poetry, I give you

house and it to circumcised all cool of these things daughters from ye go dreamed for stead and in unto god of for wives done to i give god shall bowed himself and shem tower of small and said lord he was called his the days these are thither therefore cainan and and he rachel and hear my sons born

when isaac dry land unto him isaac and have i children struggled lord hath had eaten goods which morning was ye shall by the all the me this naphtali and years old was her to see of the his brother out of names after they feed thy mothers of ephron god said he put him into after his the tent

unto us i will to him i will the presence hands to his right name was possession of days journey down in that thou perizzites and and he they for god made that is of the twentys sake jacob so itself after thou and of anah years and in isaac pillar of and the builded a of canaan noah and

It divides neatly into two different sections: the months as a commercial programmer and the months as PhD student and academic careerist.

The year began still working for Teleca Systems, and with security consulting for Stockholm-based firms and frequent trips back home.

Then as the year went on and my PhD applications grew more and more, I started getting results. I got invited to Bonn for an interview with the Homology and Homotopy graduate school program – which was in the end turned down because I was more of a homological algebraist than a topologist. And the week after that, I was invited to Jena for an interview for a position doing PhD work on computational homological algebra. The interview went well, the potential advisor was nice (and a once-roleplaying gamer to sweeten the deal more) and I got the position just a few days later.

While in Switzerland.

Skiing.

On a weeklong luxurious conference in operad theory at a skiing resort in the western part of the swiss alps. Lots of skiing, fantastic food, lots of REALLY COOL people (I’m looking at you, pozorvlak, among others) and lots of fascinating mathematics.

As I returned there, it was time to wrap up my position with Teleca, disengage from all my duties, document everything I had done, train everyone else in my stuff, and get out of there. Preferably before the summer term started. Oh, and get through the bureaucracy involved in getting hired at a German university. It’s a fascinating experience, I can tell you. Especially when you get asked whether you were involved with the Stasi during communist east Germany.

Freshly hired, I had a week to get my affairs in order, and then got thrown on my first bunch of students. Teaching and reading up on cooooool mathematics for several months, leaving a little bit for visits to Sweden, and then hitting the vacation hard with a long relaxing visit to Sweden, and a marriage proposal.

The summer also saw the Pirate Bay raid, my heightened interest in the politics of privacy, and membership in the Pirate Party, the election, and following the election results explicitly with attention to the Pirate Party results.

After the vacation came conference summer, stretching August through September, with between 2 and 4 conferences depending on how you count them, and a little bit of research. At the end of this, a new term started and with that a new direction for my PhD research. This was, at the same time, the period when I got enamoured with Haskell, read up on it, grew more and more interested, fascinated, captivated.

During the time in Jena, I got involved in a roleplaying troupe, in a mathematical magazine (with two articles published by now!), in a group organizing math camps (participating in one camp), and getting hold, slowly, of a decently sized social circle.

And then the end of the year hit before I knew what happened. It ends tomorrow – and I have things hanging in idle loops swarming my head like angry bees and waiting to be channeled through my consciousness out on paper and code, and get me running with my research.

That’s my year in review. How was your?

He, as I, is a mathematician, spending his time thinking, finding patterns, and trying to formulate (more or less) absolute proof that his patterns hold all the time, alternatively ways to demonstrate that they may not be universal.

In the post linked above, he starts by a neat little exercise, gets interested, and goes out to look at more examples. These show a very clear pattern, and after following this pattern quite some way out, he finally believes the pattern enough to start searching for a proof: which he also finds.

Now, this is one central heuristic pattern in mathematics. Calculate examples. Look at the examples. All of a sudden a pattern appears, and you think up a reason why such a pattern could be there. While proving the “correctness”, if you may, of the pattern, you’ll either end up formulating in enough detail what’s going on so that you may possibly expand the statement to cover even more — or you may realize that it does not hold and find a way to construct a counterexample. Either way, the mass of knowledge increases.

Now, what does this have to do with programming languages?

I started looking at Haskell due to a sequence of blogposts from sigfpe, who was describing Haskell programming from a highly algebraic point of view. And even after my involving myself in the subject, one thing that stands out is the relatively low distance between thought expressed in my ordinary day-to-day mathematical discourse, and thought expressed in Haskell code. For the ubiquitous example, let’s take the factorial function. Mathematically, I think about factorials as
“n! is the product of all integers from 1 to n”
or
“n!=Γ(n-1)” (though this not so often, I must admit)

Then again, “the product of all”, when I introduce it strictly for the first time tends to be expressed along the lines of
“Π_n=1^k f(n) is f(k)*Π_n=1^k-1” or something along those lines.

So, what happens if I want to start playing around a bit with factorials, and see whether I can say anything interesting about them?

In C or similar languages, I’ll fire up an editor, and a command shell, and start writing code that looks something like

and I will spend more time writing scaffolding and reworking the problem into something I can write in C than I will actually working with my mathematical intuition about it.

C++, Java, PHP, Perl — it won’t be much different in any of these. None of them have an interpreter I like, none of them differ all too much from the mindset of C. (Yes, I say this knowing full well the difference between imperative and object-oriented programming…)

In functional languages, the way I write the code is very much more reminiscent of the way I define it in my head. I could dig out enough Lisp or Scheme from the back of my mind to give you an example, but it’s getting late and I couldn’t be bothered. So instead I’ll go straight on to the thingie I want to praise.

In Haskell, I’ll fire up my interpreter, and write at the prompt something very much like

and then start firing off actual calculations into the box.

During my time so far, I’ve used Haskell quite a bit in my research to generate lists of testcases. Not necessarily because Haskell is the best possible language for it, but because I could very quickly write down my thoughts, get working code out of it, and just go ahead and do what I wanted. Most languages I’ve worked with have their uses – and I’m not out to bash anything right now. But with Haskell, I’ve had a much lower threshold thought-to-code, and much less distance between my coder head and my mathematician head, than with anything else I’ve seen so far.

The first lecture was mainly an introduction to the area, ending with a very naïve algorithm to generate a permutation group from a set of generators. Next week will bring less naïve algorithms with not quite as horrible complexity.

Before the algorithm can be brought, we’d want some undergrowth: we’d want to be able to work with permutations at all. So, we’ll start with the basic group theory and permutation implementations. A lot of this is stolen or rewritten from this permutation group code.

Our code will make use of two libraries, so if you collate code snippets while reading this, you’ll want to use

If you don’t want to bother with that, the code is available here.

One of the things I love the most with Haskell is the way that you just write down what you think it means, and end up with good code. So, what is a group? It is this type class:

with some conditions on the functions given. This is geared towards implementing permutation groups in the first line — so the idea is that you give your group as a subgroup of S_n, and you can retrieve the identity in S_n by using the identity function.

We tend to want to be able to conjugate elements and multiply a whole list of elements, so let’s add a few functions:

And now we can start looking at permutations. We will store a permutation as the list of images, in order. So for instance, the permutation given by (1 2)(1 3) will be stored as the list [2,3,1]. (note that in the good tradition of computational group theory, we act from the right – thus motivating this result and not [2,1,3])

The interesting bit about permutations, though, is that they form a group; so we instantiate our type class as well.

We are used to being able to write permutations in cycle notation, so we’d want to be able to convert to and from that, too.

We can use saturateCycles and desaturateCycles in order to convert to and from the normal way of writing permutations. The toCycles and fromCycles functions both expect fixpoints to be listed as well. We need, however, to tell the saturateCycles which symmetric group we want to live in.

Now, the most naïve algorithm to list all elements in a group starts with the one element we know will live in the group: the identity. And for each iteration, all generators are multiplied onto the first known candidate in a list of group element candidates, and all results that are not yet known are added to this list.

In Haskell code:

We keep on adding tested candidates to the first list, and anything not yet seen that we get from our multiplication with generators gets added to the middle list. Once the middle list is empty, we’re done.

Some modules

To deal with the first problem, let’s break apart our program a little bit, forming several more or less independent code files linked together to form a whole.

First off, HelloWorld.hs – containing a very generic program skeleton. We will use our module Bindings to setup everything else we might need, and tie them to the callbacks.

Then Bindings.hs – our switchboard

We’re going to be hacking around a LOT with the display function, so let’s isolate that one to a module of it’s own: Display.hs

And a first utility module, containing the gritty details of drawing the cube , called Cube.hs

Now, compiling this entire section with the command

compiles and links each module needed, and produces, in the end, an executable to be used. There we go! Much more modularized, much smaller and simpler bits and pieces. And – an added boon – we won’t normally need to recompile as much for each change we do.

This skeletal program will look like .

Local transformations

One of the core reasons I started to write this tutorial series was that I wanted to figure out why Panitz’ tutorial didn’t work for me. The core explanation is simple – the names of some of the functions used has changed since he wrote them. Thus, the matrixExcursion in his tutorial is nowadays named preservingMatrix. This may well change further – though I hope it won’t – in which case this tutorial will be painfully out of date as well.

The idea of preservingMatrix, however, is to take a small piece of drawing actions, and perform them independent of the transformations going on outside that small piece. For demonstration, let’s draw a bunch of cubes, shall we?

We’ll change the rather boring display subroutine in Display.hs into one using preservingMatrix to modify each cube drawn individually, giving a new Display.hs:

Say… Those points on the unit circle might be something we’ll want more of. Let’s abstract some again! We’ll break them out to a Points.hs. We’ll have to juggle a bit with the typesystem to get things to work out, and in the end we get

where we note that we need to renormalize our colours to get them within the interval [0,1] from the interval [-1,1] in order to get valid colour values. The program looks like

The point of this yoga doesn’t come apparent until you start adding some global transformations as well. So let’s! We add the line

just after the clear [ColorBuffer], in order to scale the entire picture. As a result, we get

We can do this with all sorts of transformations – we can rotate the picture, skew it, move the entire picture around. Using preservingMatrix, we make sure that the transformations “outside” apply in the way we’d expect them to.

Back to the callbacks

Animation

A lot of the OpenGL programming is centered around the program being prepared to launch some sequenc when some event occurs. Let’s use this to build a rotating version of our bunch of points up there. In order to do things over time, we’re going to be using the global callbacks idleCallback and timerCallback. So, we’ll modify the structure of our files a bit – starting from the top.

We’ll need a new callback. And we’ll also need a state variable of our own, which in turn needs to be fed to all functions that may need to use it. Incorporating these changes, we get a new HelloWorld.hs:

Note the addition of an angle, and an idle. We need to feed the value of angle both to idle and to display, in order for them to use it accordingly. Now, we need to define idle somewhere – and since we keep all the bits and pieces we modify a LOT in display, let’s put it in there.
Exporting it all the way requires us to change the first line of Bindings.hs to

Display.hs:

Now, running this program makes a couple of different things painfully obvious. One is that things flicker. Another is that our ring is shrinking violently. The shrinking is due to our forgetting to reset all our transformations before we apply the next, and the flicker is because we’re redrawing an entire picture step by step. Much smoother animation’ll be had if we use a double buffering technique. Now, this isn’t at all hard. We need to modify a few places – tell HOpenGL that we want to do doublebuffering and also when we want to swap the ready drawn canvas for the one on the screen. So, we modify, again, HelloWorld.hs:

and we also need to modify Display.hs to implement the bufferswapping. While we’re at it, we add the command loadIdentity, which resets the modification matrix.

There we are! That looks pretty, doesn’t it? Now, we could start adding control to the user, couldn’t we? Let’s add some keyboard interfaces. We’ll start by letting the rotation direction change when we press spacebar, and let the arrows displace the whole figure and + and – increase/decrease the rotation speed.

Again, we’re adding states, so we need to modify HelloWorld.hs

Note that position is sent along to the keyboard as well as the display callbacks. And in Bindings.hs, we give the keyboard callback actual function

finally, in Display.hs we use the new information to accordingly redraw the scene, specifically the now changing amount to change the current angle with. Note that in order to avoid the placement of the circle to be pulled in with all the other modifications we’re doing, we do the translation outside a preservingMatrix call.

Summary

We now know how to modify only parts of a picture, and we also know how to use the idle and the keyboardMouse callback to support animations and keyboard input.

In order to somewhat limit the amount of typing I need to do, I’ll give links that give details on some of the themes we’ve touched upon.

First of all, the callbacks are described in more detail and with call signatures at
http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Callbacks-Global.html for the global callbacks (menu systems, and timing/idle callbacks)
http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Callbacks-Window.html for the window-specific callbacks (display, reshape, keyboard&mouse, visibility changes, window closing, mouse movement, spaceballs, drawing tablets, joysticks and dial&button)

Furthermore, the various primitives for drawing are listed at http://haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-BeginEnd.html.
There are 3-dimensional primitives ready as well. These can be found at http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Objects.html

The flag I set to trigger double buffering is described among the GLUT initialization methods, see http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Initialization.html for everything you can do there.

Next time, I figure I’ll get around to do Mouse callbacks and 3d graphics. We’ll see.

Hello World

First of all, we’ll want to load the OpenGL libraries, throw up a window, and generally get to grips with what needs to be done to get a program running at all.

This code throws up a window, with a given title. Nothing more happens, though. This is the skeleton that we’ll be building on to. Save it to HelloWorld.hs and compile it by running

ghc -package GLUT HelloWorld.hs -o HelloWorld


However, as a skeleton, it is profoundly worthless. It doesn’t even redraw the window, so we should definitely make sure to have a function that takes care of that in there somewhere. Telling the OpenGL-system what to do is done by using state variables, and these, in turn are handled by the datatype Data.IORef. So we modify our code to the following

This sets the global state variable carrying the callback function responsible for drawing the window to be the function that clears the color state. Save this to the HelloWorld.hs, recompile, and rerun. This program no longer carries the original pixels along, but rather clears everything out.

The displayCallback is a globally defined IORef, which can be accessed through a host of functions defined in Data.IORef. However, deep within the OpenGL code, there are a couple of definition providing the interface functions $= and get to fascilitate interactions with these. Thus we can do things like

Using the drawing canvas

So, we have a window, we have a display callback that clears the canvas. Don’t we want more out of it? Sure we do. So let’s draw some things.

Now, the important thing to notice in this codeextract is that last line. It starts a rendering definition, gives the type to be rendered, and then a sequence of function calls, each of which adds a vertex to the rendering canvas. The statement is basically equivalent to something along the lines of

for appropriate triples of coordinate values at the appropriate places. This results in the rendition here:

We can replace Points with other primitives, leading to the rendering of:

Triangles

Each three coordinates following each other define a triangle. The last n mod 3 coordinates are ignored.
Keyword Triangles

Triangle strips

Triangles are drawn according to a “moving window” of size three, so the two last coordinates in the previous triangle become the two first in the next triangle.
Keyword TriangleStrip

Triangle fans

Triangle fans have the first given coordinate as a basepoint, and takes each pair of subsequent coordinates to define a triangle together with the first coordinate.
Keyword TriangleFan

Lines

Each pair of coordinates define a line.
Keyword Lines

Line loops

With line loops, each further coordinate defines a line together with the last coordinate used. Once all coordinates are used up, an additional line is drawn back to the beginning.
Keyword LineLoop

Line strips

Line strips are like line loops, only without the last link added.
Keyword LineStrip

Quadrangles

For the Quads keyword, each four coordinates given define a quadrangle.
Keyword Quads

Quadrangle strips

And a Quadstrip works as the trianglestrip, only the window is 4 coordinates wide and steps 2 steps each time, so each new pair of coordinates attaches a new quadrangle to the last edge of the last quadrangle.
Keyword QuadStrip

Polygon

A Polygon is a filled line loop. Simple as that!
Keyword Polygon

There are more things we can do on our canvas than just spreading out coordinates. Within the command list constructed after a renderPrimitive, we can give several different commands that control what things are supposed to look like, so for instance we could use the following

in order to produce these four coloured squares

where each color command sets the color for the next item drawn, and the vertex commands give vertices for the four squares.

Callbacks – how we react to changes

We have already seen one callback in action: displayCallBack. The Callbacks are state variables of the HOpenGL system, and are called in order to handle various things that may happen to the place the drawing canvas lives. For a first exercise, go resize the latest window you’ve used. Go on, do it now.

I bet it looked ugly, didn’t it?

This is because we have no code handling what to do if the window should suddenly change. Handling this is done in a callback, residing in the IORef reshapeCallback. Similarily, repainting is done in displayCallback, keyboard and mouse input is in keyboardMouseCallback, and so on. We can refer to the HOpenGL documentation for window callbacks and for global callbacks. Window callbacks are things like display, keyboard and mouse, and reshape. Global callbacks deal with timing issues (for those snazzy animations) and the menu interface systems.

In order for a callback to possibly not be defined, most are typed within the Maybe monad, so by setting the state variable to Nothing, a callback can be disabled. Thus, setting callbacks is done using the keyword Just. We’ll add a callback for reshaping the window to our neat code, changing the main function to

Here, the code for the reshape function resizes the viewport so that our drawing area contains the entire new window. After setting the new viewport, it also tells the windowing system that something has happened to the window, and that therefore, the display function should be called.

Summary

So, in conclusion, so far we can display a window, post basic callbacks to get the windowhandling to run smoothly, and draw in our window. Next installment of the tutorial will bring you 3d drawing, keyboard and mouse interactions, the incredible power of matrices and the ability to rotate 3d objects for your leisure. Possibly, we’ll even look into animations.

Hardware woes

The old computer running this website had some problem all of a sudden about 3 weeks ago. These problems appeared as a complete lockdown of the system – no response to anything. So my brother – with me on the other side of a telephone, tried to reboot the box; but couldn’t get it back up online again. He was headed out to a LARP anyway within hours – and so couldn’t really do much more about it.

Right.

End result? I joined forces with a good friend of mine; we split hardware costs for a slick new box – an Asus barebone box with a 64bit processor and a gig of RAM. It received the harddrive and network interface from the old box, and was with that good to go – only .. processor architecture changed; and so for optimal performance, it’d be a nice idea to actually use a new system install that took advantage of the extra available bitwidth.

A completely failed OpenBSD installation later, we settled for Gentoo – which now is humming along nicely. It even turned out to be surprisingly easy to restore the old data on the new box.

There. I won’t blather more about my hardware woes – but instead poke about other themes for a while.

Party party party

My students here for the course rock. The REALLY rock. We had the course evaluations a couple of weeks ago – and apparently my exercise sessions has been gooooood. At least the students thought so. I average in the upper fifth of possible ratings in every single evaluation area. All of them. I kick ass, yo!

Compared – both to the faculty mean, and to the workgroup results – I outperform in all evaluated areas.

And, in addition to this cause for celebration, the end of the school term (last week) comes with all manners of parties, celebrations, meets, and activities. I think I had my first non-planned evening in about 2-3 weeks yesterday.

Summer in the city

The Jena climate, though, leaves a bit to wish for. I sincerely long to get back to Sweden during the hottest summer weeks we have up there, in order for me to cool down a bit. We have had 25°+ since beginning of June (i.e. about 2 months of active time with weekly lectures, seminars and exercise classes – in tropical bloody heat); and the last about 2 weeks or so, the temperatures have been in the upper 30°ies.

Horrible. Horrible, I tell you.

And of course, this heatwave has coincided with the World Cup, the Thüringertage and several other huge parties that cover the town in DJ booths on the streets and drunk germans shouting on the streets at 3am.

This wouldn’t have had to be a problem, if it wasn’t for the fact that the main bar street begins at my front door. And the heat forces me to keep as many windows open as ever possible, lest I boil away in the night.

The wild swinging of the PhD topic

As I begun here, I was told that since the people here don’t know much about A_∞-algebras, operads, props and similar topics, so it’d be best if I shelf it and keep it a hobby. My advisor hesitated on suggesting one possible and highly computational theme since he couldn’t see any applications of it later on; no directions for further research. And so I studied group cohomology in order to at least try and understand what’s going on. (I’m getting there – by and by…) Then my advisor went to Oberwolfach for a week. Upon returning, A_∞-stuff is hot, operads seem related, the computational theme is worthy of serious consideration and I should consider whether I really want to commit that deeply to the original ring-theoretic ideas.

So … right now I know even less of what I’m going to do for my PhD than a month ago. On the other hand, one of the leads would amount to my programming for about half a year, and then publishing a paper about that and start using that program to gain intuition for results to put into the PhD. This might be a good direction to go.

The constant distractions

I’ve started looking at Haskell. I -like- it. It’s a language where I’m capable of hacking together an efficient algorithm for enumerating subsets just by thinking through what a subset is. How did you do it, you may ask, whereupon I answer: Recursion.

Consider a total ordering of your finite set. Pick the first element. For each subset, either this element is there, or it’s not. So if we take all subsets of the rest, and throw in once with and once without this particular element, we get what we want.

Now, just translate this to actual code – and the result is

Useful for parsing this is to know that : is the cons operator, and ++ concatenates lists. map applies the given function to all elements of the following list; and where lets you define local variables postfixedly.

A shoutout to sigfpe for piqueing my interest in these things enough to try and make sense of the language. Without his category theory heavy posts on Haskell, I wouldn’t have looked into it.