

a+0=a, a+b=b+a, a+(b+c)=(a+b)+c



a1=1, a(bc) = (ab)c



a(b+c) = ab+ac and (a+b)c = ac+bc.







T -> [[T]] (by trivial inclusion of generators)



[[ [[T]] ]] -> [[T]] (by above argument)





[[ [[T]] ]] -> [[T]]



> import Control.Monad.List



> flatten x = concatMap (map concat . sequence) x





> x = [[ [['a']],[['b']] ], [ [['c']],[['e','f'],['g','h']] ]]

> test1 = flatten x





> x' = ListT [[ ListT [['a']],ListT [['b']] ],

> [ ListT [['c']],ListT [['e','f'],['g','h']] ]]

> test2 = runListT $ join x'



ListT

join

ListT []

flatten

ListT []

ListT []

ListT []



(a+b+a+b)*(a+b+a+b)



= a*a+a*b+a*a+a*b+…





(a+b)*(a+b)+(a+b)*(a+b)+(a+b)*(a+b)+(a+b)*(a+b)



= a*a+a*b+b*a+b*b+…



ListT []



> u = ListT [["a"],["b"]]





> v = ListT [[u],[u]]





> w = ListT [[v,v]]



join



> expanded1 = join $ join w

> go1 = runListT expanded1





> expanded2 = join $ fmap join w

> go2 = runListT expanded2



fmap

go1

go2

expanded1

expanded2

join . join = join . fmap join

ListT []

ListT []

[]

ListT []

Well I'm back from my vacation . But this isn't my personal blog so I think it's time to dive right in. Anything to take my mind off these mosquito bites...So consider the free semiring R generated by some set S. In other words, S consists of finite sums and products of 0, 1 and elements of S and where the only simplification rules allowed areFor example, consider a term like ab+c(ef+gh). We can use distributivity to multiply this out to ab+cef+cgh. There's not much else we can do to simplify this. Now notice that if you multiply out all of the brackets wherever you can, ie. use distributivity until you can no longer, you end up with an expression that is a sum of terms and each term is a product of generators from S. (The sum of terms may be empty, in which case it's zero, and each of the terms may be a product of zero generators, in which case it is 1). This allows us to write elements of R in a canonical form: as a set of terms where each term is an ordered list of generators. For example, we could write ab+cef+cgh as {[a,b],[c,e,f],[c,g,h]}. Notice how the commutativity of addition is represented by the fact that we're using a set of terms, but each term is a list of generators because we're making no assumption about the commutativity of multiplication.In Haskell it's more convenient to work with lists. Se we'll represent our running example as [['a','b'],['c','e','f'],['c','g','h']]. So if S is the Haskell type corresponding to our set of generators, then [[S]] can be thought of as the free semiring generated by elements of S, with the proviso that we consider two elements equal if one can be reordered to the other. Note that []=0 and [[]] = 1.Now suppose that S is itself a free semiring generated by T. Then R = [[ [[T]] ]], modulo ordering. If you think about it, there's a nice way to use the algebraic structure to 'flatten' an element of [[ [[T]] ]] down to an element of [[T]]. R is freely generated by elements of S, in other words it consists of sums of products of elements of S. But the elements of S are themselves sums and products. So we have sums of products of sums of products. I emphasised two words in that sentence. This is because R contains subparts that are products of sums. If we multiply these out in the usual way, we get sums of sums of products of products. Group the sums and products together, and we get back to sums of products. Here's an example: any element of T trivially gives an element of S. So if a,b,c,e,f,g and h are all in T, then a,b,c and ef+gh are all in S and hence are generators of R, so ab+c(ef+gh) is in R. Multiply out and we obviously have the element ab+cef+cgh of S. It's not hard to see how this generalises to map any element of S back down to T. So we have mapsLook to you like a monad? Of course it does! :-) But what monad is it?First, let's implement the map. After tinkering I came up withWe can test it outIt multiplies out exactly the way we want.Now compare with running this:In other words, apart from thefluff,foris. So if we consider lists as a mechanism to represent sets,is revealed as the monad of semirings. I'm not sure, but I think that historically this is where monads originally came from. Certainly there are many papers on the relationship between monads and algebraic structures like semirings.And now I can answer my original question. In a semiring, addition is commutative, so the order of terms doesn't matter. But in, we're using lists, and order does matter in a list. So if we do take order into account, then reallyis the monad of semirings where both addition and multiplication is non-commutative. And here's the problem: in general, there is no such thing as a freely generated semiring with non-commutative addition.Here's why: consider the expression ((a+b)+(a+b))*((a+b)+(a+b)). Multiply out the inner parentheses first and we getNow multiply out the outer parentheses first and we getThe terms are coming out in a different order. Essentially distributivity doesn't work in a semiring with non-commutative addition.This translates directly into failure of one of the monad laws. First write our expression as an object of typeu = a+bv = (a+b)+(a+b)w = ((a+b)+(a+b))*((a+b)*(a+b))multiplies out parentheses. So working from the outer parentheses inwards we can use:Working outwards from the inner parentheses we get:(Note how I useto 'duck down' through the outer layer of parentheses so as to multiply out each of the subexpressions first.)Evaluateandand you'll see that they corresponds to the two ways of multiplying out that I gave above. And more importantly, the values ofandaren't equal, meaning thatisn't satisfied. You may recognise this: it's one of the monad laws. (At least it's one of the monad laws written the way category theorists write them.) So we ain't got no monad.I think this is now a fairly complete analysis of whatis all about. So one obvious remaining question is: where do games come into all this? The answer is that games form a semiring in a way that I haven't seen documented anywhere (though is surely common knowledge). I'd explain but I've run out of time...Note that the reasonisn't a monad is thatisn't commutative, in some sense. This has been observed many times in the past. Two papers mentioning this are this and this I actually figured out all of this stuff before this . I realised that the trees I was scribbling on the backs of my envelopes to represent elements of semirings could actually be generalised to just about any kind of tree, so I wrote about the general case first.I prefer my example offailing to be a monad to the examples given here . The latter make use of the IO monad so they aren't quite as 'pure'.

Labels: haskell, mathematics