Hacker News Reader

Comment by xelxebar | Hacker News Reader

It has struck me for a while that associativity can be seen as a higher-order commutativity. Specifically, for the real numbers, it's associativity just says that you can commute the order in which you evaluate the multiplication map.

To make that more explicit, consider the space of left-multiplication maps Lr(x) = rx for real numbers r and x. Similarly, for right-multiplication maps Rr(x) = xr. Then the associative rule a(xc) = (ax)c can be re-written La∘Rc(x) = Rc∘La(x), which is precisely a commutativity relation.

The above obviously generalizes to arbitrary Abelian groups, but I'm curious if there's more depth to this idea of associativity as "higher-order commutativity" than just what I've said here.

View on HN

I don't know if there's more depth to it but fwiw I think that's a really cool insight regardless.

See also https://www.cs.utexas.edu/~EWD/ewd11xx/EWD1142.PDF (which ties in distributivity)

Cool. A Dijkstra note. Thanks for sharing.

The distributivity argument is a bit sketchy, though. It defines g.p := p▫q, meaning that g implicitly depends on q, but then writes f(y▫z) = f(g.y) and fy▫fz = g.f(y), where in the first instance g.x = x▫y and in the second g.x = x▫fz.

That said, I do see the point. The distributive rule let's us commute the order in which we compute addition and multiplication. Generally, I guess if we have some family of arrows A and B, where all commutative diagrams Bx∘Ay = Az∘Bw hold, then we can say "A and B commute". This can probably be expressed as some literal commutativity using natural transformations, but I'll need to think on it some more.

Thanks for the prod!

This is likely the same as a distributive law of monads... https://ncatlab.org/nlab/show/distributive+law on good days i might understand this stuff..

Another less high-brow connection: associativity of matrix multiplication relies on the usual distributivity law..

Yes: the requirement of commutativity in the "addition" for distributivity to work with a noncommutative "multiplication" is exactly why my current model for code* is based on an (anathema to practicing programmers) unordered choice.

* and also data; with suitable choices of definitions there are very few differences between the left and right hand arguments to application.

Reply on news.ycombinator.com