«Phil Harvey wants us to partition {1,…,16} into two sets of equal size so each subset has the same sum, sum of squares and sum of cubes.» — posted by @MathsJam and retweeted @haggismaths.

Sounds implausible was my first though. My second thought was that there aren’t actually ALL that many of those: we can actually test this.

So, here’s a short collection of python lines to _do_ that testing.

import itertools
allIdx = range(1,17)
sets = itertools.combinations(allIdx,8)
setpairs = [(list(s), [i for i in allIdx if i not in s]) for s in sets]
def f((s1,s2)): return (sum(s1)-sum(s2), sum(map(lambda n: n**2, s1))-sum(map(lambda n: n**2, s2)), sum(map(lambda n: n**3, s1))-sum(map(lambda n: n**3, s2)))

goodsets = [ss for ss in setpairs if f(ss) == (0,0,0)]

And back comes one single response (actually, two, because the comparison is symmetric).

[([1, 4, 6, 7, 10, 11, 13, 16], [2, 3, 5, 8, 9, 12, 14, 15]),
([2, 3, 5, 8, 9, 12, 14, 15], [1, 4, 6, 7, 10, 11, 13, 16])]


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?

So, first I downloaded the zipcode database at Mapping Hacks, and unpacked the zipfile in my working directory.

Then, I loaded the data into R

So, now I have an R frame containing a lot of US cities, their geographical coordinates, and their zip codes. So we can start playing with the plot command! After rooting around a bit, I ended up settling on the smallest footprint plot dot I could make R produce, by setting the option pch=20 in the plot options. Hence, I ended up with a command basically like this:

where the +1 after the modulus is to make even 0-values plot, and the cex parameter sets the point size to something small and pretty.

We can continue this, tweaking the divisor to extract all the other digits of the zip code, and we end up getting:

and the result

and the result

and the result

and finally

and the result

And then, of course, we can zoom in on data too. So we can do things like extracting Californian zip codes

to get

or, we could extract New York zip codes:

or even extract, say, the zip codes starting with 10 or 11, covering New York City and surroundings and take a closer look

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)))

But, out of a whim, I downloaded J and started to play with it while reading this set of neat notes on Functional Programming and J.

And … well … my reaction so far is kinda “Buh!? What the *** just happened there?”

The first example I ran across, tried to read, and finally managed to is the following:

This snippet is supposed to tell us how many 0s are trailing 100!. To get at this, we first need to figure out what, exactly, is done here. First observation is that 100! is the product of all integers from 1 to 100. The second is that the number of 0s trailing this is the same as the lower of the orders of 2 and 5, respectively, dividing 100!. Which, in turn is the lower of the numbers of 2s and 5s occurring in the totality of all prime decompositions of all the integers from 1 to 100.

Now, if , then certainly , so the sum of orders of 2 is guaranteed to be larger than the sum of orders of 5, so it is enough to count the number of 5s dividing any of the numbers along the way. And THIS is what the program above computes.

Next thing to figure out is how it does this. It turns out, after some experimenting, that the best way of reading this is to go through from right to left and figure out what it all does. All the functions we're looking at end up being applied in a monadic fashion – which means something completely different in J than in Haskell – here it means that the function gets applied to a single argument. So, here goes:
i. n lists the first n integers, starting at 0. So i. 100 is the 1×100 matrix containing 0, 1, 2, …, 99.
>:, when applied monadically, increments each element it sees by one. So >: i. 100 is the 1×100 matrix containing 1, 2, 3, …, 100.
q: yields a prime factorization of the integers it sees. So from q: >: i. 100 we get a matrix where each row carries the primes dividing the row number, with 0 padding at the end.
Then we see the one dyadic (as opposed to monadic) application in this program. 5 = mtx yields a matrix of the same shape as mtx, but with a 1 whenever the corresponding entry is a 5, and 0 otherwise. So 5 = q: >: i. 100 picks out the entries in all the prime factorizations that are equal to 5.
Then ,. This is one of two complementary operators to reshape matrices. , gets us an 1xn matrix with the same entries, read row by row, from left to right, as we started with – whereas n m $ mtx takes the matrix in mtx and builds an nxm matrix out of it. Thus, , 5 = q: >: i. 100 flattens out the matrix with the 0 and 1 we got out above.
And finally, +/ is an example of a J adverb being used. + is a dyadic function corresponding to, as expected, usual addition. / is a monadic adverb that takes a dyadic function, and inserts it between all the elements in the following list. This is essentially identical to the Haskell call foldr. So +/ is more commonly known as “sum”. And thus, +/ , 5 = q: >: i. 100 sums up the 0s and 1s produced by picking out all the entries in the prime factorization matrix that are equal to 5, after flattening the matrix. Or, in other words, counts the 1 entries. Which is the same as counting the number of 5s in the prime factorizations of all the integers between 1 and 100.
Note that if we skipped the flattening step given by , then the application of +/ would have just summed each column in the matrix. So, we would have needed to apply it again to get the total tally.

So far, my impression is essentially that WHOA! That language is compact to the point of insanity. Once you master the vocabulary, it kinda gives the feeling that the system has insane amounts of power – but the vocabulary is kinda imposing, as is the shift in the way I think about programming. I foresee learning J giving me the same kinds of epiphanies and major brain twists as Haskell did – so it might well be an appropriate next challenge.

We’ll start by generating a dataset. Essentially, I’ll take the trefolium, sample points on the curve, and then perturb each point ever so slightly.

As a result, we get a dataset that looks like this:

So, let’s pick a sample from the dataset. What I’d really want to do now would be to do the witness complex construction, but I haven’t figured enough out about how R ticks to do quite that. So we’ll pick a sample and then build the 1-skeleton of the Rips-Vietoris complex using Euclidean distance between points. This means, we’ll draw a graph on the dataset with an edge between two sample points whenever they are within ε from each other.

So we pick a sample from this sample. Every 31 points might be good. (number arrived at by guessing wildly, and drawing the resulting images until they looked pretty enough)

We’d get, from this, the following result:

Now, we’ll want to build the corresponding skeleton. Let’s do it for a few different εs to demonstrate the difference.

The result is:

We notice that as the radius we observe grows, we connect all the loops, but by the time the loops are completely connected, there are also cross connections forming toward the middle. However, with any luck, these cross connections will be so short-lived, in terms of the radii we use, so that the homology classes we extract from the Rips-Vietoris complexes are noticably more persistent.

Doing the corresponding computation relies on me figuring enough out to use the Plex software suite, or writing my own, and thus will be subject of a much later blog post. This one was mainly “Look – I use R” and “Look – pretty pictures”. Enjoy.

To break the lull, I thought I’d try to pick up what I did last summer: parallel computing on clusters. It’s been a bit of blog chatter about SAGE and how SAGE suddenly has transformed from a Really Good Idea to something that starts to corner out most other systems in usability and flexibility.

Matlab? SciPy bundled with SAGE and the Python integration seems to be at least as good, if not better.
Maple? Mathematica? Maxima? Singular? GAP? SAGE interfaces with all those that it doesn’t emulate.

And also, it allows you to install and interface with almost anything that has a Python module written. Specifically, a SAGE installation comes complete with OpenMPI and MPI4Py, allowing for multi-processor parallelity – either on an SMP machine, or on a cluster that runs some sort of MPI system. So, using the Python and MPI4Py that arrives with SAGE, it should be possible to start experimenting with parallel programming; and the rest of the SAGE integration should make it easy to start playing with, say, parallel algorithms for commutative or homological algebra.

But as a first step, I thought I’d do a “Hello world” for mathematics. Computing the Mandelbrot fractal.

Now, a Mandelbrot fractal is reasonably easy to compute: we step through all pixels in our image, and we repeat the transformation for c the complex plane point corresponding to the pixel, and . We see whether this iteration diverges within a limited amount of steps.

I’m going to, for benchmarking reasons, fix some parameters. I’ll have a 600×600 picture, spanning the area [-2.5,1.5]x[-2.0,2.0] of . I’ll allow 80 iterations, and after that, I want to see whether the square of the magnitude is larger than 4.0.

At the core of the iteration lies the function

and for a specific point , we can compute the number of iterations needed with the function

Repeating this for each point in the span we look at, modified for the granularity our pixels force, and choosing a color for each iteration number, we’ll get the familiar Mandelbrot fractal. I choose to assign colors using the hue in the HSV color space. This gives us rich, nice colors with a continuous and neat progression through them. So, given the number of iterations at a point, and the maximal number of iterations allowed, we compute the corresponding color by

the function colnorm is in there to convert RGB triples with values in [0,1] to RGB triples with values in [0,255].

And from here it’s just a matter of interfacing with the right kind of image writing library – I chose the PIL library – and then go through all pixels, computing the color implied at each pixel, and placing it in the image.

Run like this, the benchmark fractal takes some 12 seconds on our workgroup’s workhorse, and 8 seconds on a single node of the Jena Beowulf cluster.

The resulting fractal is

As for parallelization, the Mandelbrot fractal is a typical example of what’s called an embarrassingly parallel problem: each pixel in an image is completely independent from all other pixels, and so we could just let one single processor loose on each pixel, and get things done a lot faster than if we’d work through the pixels one after the other.

So, to parallelize it, we’ll need some way of distributing the work among the processors, and some way of gathering the pieces up once we’re done. In MPI4Py, initialization and finalization of the MPI library is taken care of under the hood, in the import of the library and in the closing of the program.

My first idea was to use the builtin Scatter and Gather functions. The idea was something like the following:

but this fails already at the Scatter line. The thing is that you can’t just hand Scatter a list of things you want distributed, you’ll need to feed comm.Scatter with a list of lists, one for each recipient. This particular property of comm.Scatter is not actually described anywhere I could find on the web – the documentation for MPI4Py is minuscule at best, and this is specific to the Python interface setup, so the MPI standard documentation doesn’t give it away either.

The next problem that appears is that if we just divide the rows of the picture evenly – first processor gets rows 1,2,3,…,n; second gets n+1,…,2n and so on – then some processor will get the bulk of the actual Mandelbrot set – which is by definition the pixels that take the most iterations to compute – so the speedup by pouring more processing power on the problem won’t be as impressive as it could be. The processors that take care of regions outside the set will finish quickly and then just idle, and the processors that take care of most of the set will churn through as if they had computed the set alone.

There are very many ways to deal with this issue. The approach I’m taking is to use an interlacing pattern to distribute the rows. With n processors, each processor computes every n rows of the picture, thus getting easy and difficult rows reasonably evenly distributed. Also, with this easy a distribution scheme, there’s no reason to compute the rows centrally and distributing them with the MPI communication scheme.

Hence, the complete program ends up with the following source code:

We can run this program on a single-processor machine by issuing

and on a multiprocessor machine by replacing -np 1 with the number of processors we’d want to utilize.

On the quad kernel workhorse my workgroup uses, which currently has two processors fully utilized by group cohomology computations, I get the following results (approximates):

So – once I used up the free processors, the wall time shoots up, and the spread shoots up. So working on a utilized SMP machine might not be the way to go.

But I do have access to the Jena Beowulf cluster, since the lecture course I audited on cluster computing. And I’m getting much better results there. Over there, I run jobs by writing a job script

and submit it to the job scheduler, to work on – say – 3 processors with

I added commands to time the computation part – stripping out the book-keeping and image writing once the fractal is computed, and thus can get timings for the parallel computation.

As a result, I get the following:

Walltimes

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.

However, as such, this is not enough to solve the issue. For one thing, we can set Q’=P and P’=Q, and things are the way he asks for.

Now, I wonder whether we can solve this by using PROPs (or possibly di-operads or something like that). Let’s represent a document as a list of some sort of tokens. We’ll set the set of all lists of length , and we’ll set to denote operations that take a list of length n and returns a list of length m.

One operation here is obvious – the identity operation. So we’ll take that into the mix. And we’ll also want to have some manner of composing operations. So, set to be the operation that applies the second argument to the elements i,i+1,…,i+m of the list outputted by the first argument.

This way, we can make patch trees – using the identities to fill out when a patch doesn’t influence everything; and have composition of operations represent composition of patches.

Now, the commutativity that Brent asks for would manifest as an additional relation – on top of those inherent in the definition of a PROP – to rebuild trees. One obvious one pops out immediately – as long as the trees don’t overlap, in other words, as long as the subtree we want to reorganize is contractible (in the topological sense), we can commute patches freely.

When trees -do- overlap, however, the undo operation Brent asks for is much more tricky. Consider the following sequence of edits:

[] -> [a] -> [b] -> [cbd]

Now, undo the insertion of [a].

Sure, taken this way, we cheat a little. Maybe we want to restrict edit descriptions to explicit deletions and additions. So we would have

[] -> [a] -> [] -> [b] -> [cb] -> [cbd]

and here we could probably move things around a bit easier. I don’t quite see how to do it, right now, though.

Inspired by this, and inspired by my early playing around with Ruby on Rails, I decided to whack together a Rails plugin that takes care of building the Google Charts IMG tag using what I hope is reasonably easy to use syntax.

I have a test-site using random data up for playing around with it.

The test-site as such runs on Ruby on Rails. The controller does some parsing and setting up of relevant arrays, and primarily generates random data for plotting.

The view has the following source code:

where the @options array is populated with the options tag from the input pretty straight off.

The whole plugin resides at a project of its own at rubyforge. So far, I have not yet implemented color handling, grid lines or marker setting. I’m happy to share code responsibility or getting suggestions for how to handle the outstanding issues or improve on the code. Just get in touch with me if you feel like contributing.

And one of the things that makes Rails so Damn Neat is that if you only set things up the right way around, it guesses almost everything you need it to guess for you.

One of the ways it does this is by pluralization. Basically, the model Foo has a model defined in app/model/foo.rb and it accesses the database table foos.

So, when talking a good friend through the basics, we created the table persons and generated the model Person. And promptly got an error from the framework.

It turns out that the pluralization of person is people. I wonder what else irregularities they built into the system. If I have a model called Index, does Rails expect it to read from the database table indexes or from indices?

Edited to add:

So, I found out that in the Rails console, I can fiddle around with pluralization myself.

Which lead to this experiment

And at this point, the chosen pluralization engine simply Does Not Work. The pluralization of complex, at least as used in mathematics, is under no circumstances complices. We’d say complexes. Matrices, on the other hand, pluralizes correctly. And simplices pluralize correctly or incorrectly depending on which mathematician you ask.

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: