We are having a reading seminar on the book Representation theory of Artin algebras, by Auslander, Reiten and Smalø, and this afternoon it’s my turn to discuss chapter VI, on finite representation type. An important interest of most of the participants (excluding myself) is modular representation theory, and I should be able to tell something interesting about it in the context of finite representation type. Because of my appalling lack of knowledge on the structure of finite groups I had half an hour of fun with GAP to come up with some (trivial) facts.

Recall that by the recognition theorem for modular group algebras of finite type (see Theorem VI.3.3 in the book) it suffices to check whether the $p$-Sylow subgroups are cyclic or not, where $p$ is the characteristic of the ground field, which necessarily is a divisor of the order of the group (otherwise things are semisimple). Hence the following oneliner suffices to check being of finite representation type:

IsFiniteRepresentationType := function(G, p)
return IsCyclic(SylowSubgroup(G, p));
end;

The question now becomes: which groups are of finite representation type? Is it an easy condition to satisfy, or not? Of course, it would be best to sit down and think first. In case you are not like this, you write the following code

CountFiniteRepresentationType := function(n, p)
local finite;
finite := 0;

for G in AllSmallGroups(n) do
if IsFiniteRepresentationType(G, p) then
finite := finite + 1;
Print("  ", StructureDescription(G));
fi;
od;
Print("\n");

Print("  Of finite representation type:   ", finite, "\n");
Print("  Of infinite representation type: ", NumberSmallGroups(n) - finite, "\n");
end;

You feed it with an order and a prime (which should be a divisor of the order) and it checks how many groups are of finite representation type, for a field of this characteristic. An easy observation one can make, to reduce the number of cases to check, is:

The prime has to be factor of the order with multiplicity at least two.

Otherwise it is of course impossible for the Sylow subgroup to be non-cyclic. Hence using the following code one reduces the output a little

for n in [2 .. 128] do
Print("Counting the groups of finite representation type of order ", n, " = ", FactorsInt(n), "\n");

for p in Set(FactorsInt(n)) do
if Number(FactorsInt(n), m -> m = p) = 1 then
# Print("Not worth checking at ", p, "\n");
else
Print("Checking it in characteristic ", p, "\n");
CountFiniteRepresentationType(n, p);
fi;
od;
Print("\n");
od;

One obtains this output, and we conclude that being of finite representation type is indeed a strict condition: as the multiplicity of a factor grows, the groups of finite representation type become scarce. The smallest case is just $\mathbb{F}_2\mathrm{Cyc}_2\times\mathrm{Cyc}_2$, a rather small algebra if you’d ask me.

Another question to ask is: what about certain families? Symmetric and alternating groups have non-cyclic Sylow subgroups (if a prime factor has multiplicity greater than 1). Dihedral groups on the other hand have modular group algebras of finite representation type over each field of odd characteristic.

Every conclusion could’ve been made without resorting to a computer algebra system. Unfortunately my computer science background sometimes induces a “code first, think later” way of life.

Two days ago Matilde Marcolli and Goncalo Tabuada uploaded a survey article to the arXiv titled Noncommutative motives and their applications. It is a nice introduction to the notion of noncommutative motives, and taking dg categories as the main player in noncommutative geometry.

But one particular paragraph in this article intrigued me, paragraph 5.2 if you can’t wait to read it. Recall that the theory of motives is tightly related to Grothendieck’s standard conjectures on algebraic cycles. These conjectures are so far unproven, although lots of work have gone into them, mostly in trying to connect these conjectures to possibly easier to tackle problems. But there is hope to prove one of them using noncommutative algebraic geometry.

In their article Marcolli and Tabuada survey the “noncommutative standard conjectures”. And they summarize what is known about them: the commutative conjecture implies the noncommutative conjecture, but not vice versa. But there is an equivalence in one case! Namely for the smash-nilpotence conjecture as proposed by Voevodsky.

Conjecture D of the standard conjectures (they all have a letter, there’s also A, B and C) says that two types of equivalence relations on algebraic cycles, namely homological equivalence (depending on your choice of a Weil cohomology) and numerical equivalence, are the same. It is easy to prove (if I remember correctly) that numerical equivalence is weaker than homological equivalence (numerical equivalence being the weakest equivalence relation that satisfies some nice properties). Hence this conjecture says that it doesn’t matter which Weil cohomology you choose, you will get the same equivalence relation.

So far, parts of this conjecture have been proven apparently, in cases like divisors with coefficients in a field of characteristic zero (Matsusaka’s theorem, which even predates the standard conjectures!).

Another approach to these conjectures is proposed by Vladimir Voevodsky. He introduced the smash-nilpotence equivalence (again, see the Wikipedia page on equivalence relations), and proved that it is stronger than homological equivalence. Then he conjectured that it is actually equal to numerical equivalence too, so if one can prove this you get conjecture D for free.

And the coolest thing is that the noncommutative smash-nilpotence conjecture is equivalent to the commutative smash-nilpotence conjecture! The proof of this can be found in Unconditional motivic Galois groups and Voevodsky’s nilpotence conjecture in the noncommutative world by Marcolli and Tabuada, in theorem 4.1. The proof seems almost trivial, but dependent on some of the constructions and I’m not familiar with these, so I can’t say more on the result (for now). If I ever have more to say about it I will. Possibly when they have made the progress they are hoping for, as indicated in the article.

For instance in Loday’s Cyclic homology, paragraph 1.5.5 it is mentioned that Hochschild cohomology is not functorial. Compare this to the statement in paragraph 1.1.4 op. cit. that Hochschild homology is functorial. Why this (at first sight) strange dichotomy? And why does not a single reference (of the ones I have read) addresses this issue explicitly?

Remark that this non-functoriality makes computing Hochschild cohomology of algebras a difficult task: it is not possible in general to relate it to the Hochschild cohomology of related but easier algebras.

There are two ways of showing why Hochschild cohomology is not functorial: the conceptual explanation, and a counterexample. I’ll discuss both. Especially the last shows why the issue is not addressed in text books, and why this blog post perhaps should not be written, and left as an exercise. So if you are interested in the answer, try coming up with the explanation yourself first, it really is an easy exercise.

All notations are as in Loday’s Cyclic homology, and familiarity with Hochschild (co)homology is assumed. Although for the counterexample it suffices to know what finite groups and their centers are.

### Conceptual

In trying to mimick the functoriality of Hochschild homology is one led to considering an algebra map $f\colon A\to B$, and $\phi\in\mathrm{Hom}_{A^{\mathrm{e}}}(\mathrm{C}^{\text{bar}}_\bullet(B),B)$. One would like to define the pullback $f^*(\phi)$ by

$f^*(\phi)(a,a_1,\dotsc,a_n)=\phi(f(a),f(a_1),\dotsc,f(a_n))$

but the map $\phi$ has the wrong codomain: it should land in $A$ but it lands in $B$. The similar situation for Hochschild homology works fine though.

### Counterexample

We have the interpretation of the zeroth Hochschild cohomology as the center of the algebra. But taking the center is in general not functorial, as even the example of the maps $\mathrm{Cyc}_3\hookrightarrow\mathrm{Sym}_3\twoheadrightarrow\mathrm{Cyc}_3$ composing to the identity shows. The center in $\mathrm{Sym}_3$ is trivial, hence the composition of the centers of the morphisms is trivial too, but the center of the composition is the whole (abelian) group $\mathrm{Cyc}_3$.

To turn this into an example for Hochschild cohomology it suffices to take the group algebras on these groups, and we’re done.

A similar game can by the way be played with the inclusion of the complex numbers in the quaternions.

I would like to thank Theo Raedschelders for his ideas on this (in hindsight) trivial question. The conceptual explanation is his, the mistakes in its exposition are mine.

If you think it has been awfully quiet on my weblog, you are correct. Three reasons: graduating, and sheer laziness. The third? Our new baby!

Little over a year ago I wrote a post with a remarkably similar title: A new website for the Stacks project. The last couple of months Johan and I have been working on a new version of the Stacks project website, and this morning we have finally released it!

### What have we done?

#### New layout

I haven’t turned into a designer in the past year, but we have updated the layout to a two-column version to accomodate all the new information we have incorporated in the new website (see next). And in general we have made improvements to the layout: better spacing, using the Stacks logo, using icons, …

#### Tag lookup

We have updated the tag lookup page to incorporate more navigation options. Because that is what makes the Stacks project different from a usual book: it is online, and everything is linked.

#### Bibliography

The bibliography page is now easier to navigate. And each bibliography item now tells you where it is used, and it gives you the necessary BibTeX code to cite this result yourself.

#### Better search

The functionality of the search hasn’t changed significantly, but the options now reflect they way we think the search functionality should work. And the previewing of tags has improved. And the chapters are now visible in the search results, which I think is a small but important improvement.

#### Statistics

Everywhere it makes sense we have added statistics. Some of them are for showing off (e.g. on the main page), some of them provide new insights in the information contained in the Stacks project (e.g. if you want to know where Nakayama’s lemma is used in the Stacks project). Together with the next point, these provide truly new ways of understanding the structure which is hidden in the Stacks project, and they provide new means of navigating the Stacks project.

#### Graphs

This is the true highlight of the new version of the website. Dependency graphs. It is now possible to visualise how a result is built using earlier results.

Ever wanted to see how you can prove Hilberts Nullstellensatz? Now you can! Use your mouse to see the statements, change the colouring depending on whether you want to see the structure of the graph more clearly, or whether you want to see where the theorems, lemmas and definitions are hidden.

Ever wanted to see whether the proofs for Zariski’s main theorem and Chow’s lemma use results from the same chapters? Now you can! Answer: they don’t, Zariski’s main theorem uses virtually only results from the chapter on commutative algebra, while Chow’s lemma is a truly geometric result, using results from both the algebra chapter (you need some algebra of course) but also purely geometric chapters.

And if the graphs for some of the results become too big (either for your browser, or for the human mind to interpret) you can use the clustered view, e.g. for the existence of residual gerbes. This way you can still see the main lines of the argument by the number of descendant tags (given in the mouseovers). For instance, a quick tour through this graph (click on nodes!) one learns that this result (down a few levels) could be considered as one of the key points, because it combines several arguments: it has significantly more descendant tags than each of its children.

These are just a few of the ways one can use these graphs. At some point we will write something about how we envision these being used. Feel free to find your own uses!

There are still bugs in the website. Some I am aware of, probably plenty I have no idea about. If you see something: send a mail to stacks.project@gmail.com, or even better: create an issue at stacks/stacks-website. This way the rest of the world immediately sees which bugs have been found.

### Acknowledgments

I would like to thank everyone who participated in this process:

• Johan, for his ideas, coding support and motivation
• Cathy O’Neil, for her insistence on visualising the Stacks project, and her excellent comments on the first drafts of the graphs
• Peter Woit, for being the perfect server admin
• all the people at Columbia University, who made my breaks from coding so pleasant
• everyone who contributed to all the open-source projects we are using

Little over a year ago Markus Reineke published a note on the arXiv titled Every projective variety is a quiver Grassmannian about how quiver Grassmannians can be used to describe every possible projective variety. Based on this note Lieven Le Bruyn wrote a blogpost Quiver Grassmannians can be anything, which explains the result using an easy to grasp example. An interesting discussion in the comments section ensued, which was lost in the move to Drupal but apparently restored yesterday (unrelated to my interest in this).

Yesterday I attended a talk by Sarah Scherotzke in which this result was mentioned, and this renewed my interest for it. To entertain myself tonight I implemented some code that determines the information as described in Lieven’s example for a general projective variety. The implementation is based on Reineke’s original proof, not on Michel Van den Bergh’s alternative proof. It is nothing extraordinary, it is really just a programming exercise.

The code is written in SAGE, and can be found in the gist pbelmans/5645902. Its output can be found at Pastebin. If you have any comments, feel free to post them. The output for the original example would be

Considering the projective variety of dimension 1 in PG(2, Q) defined by
x^3 - y^2*z + z^3
The same equations, all of the same degree (d = 3)
x^3 - y^2*z + z^3
The dimension vector is (1, 10, 6)
The 1 morphism(s) defining the variety (i.e. the maps 2->1) are
x0 - x7 + x9
The 3 morphisms defining the d-uple embedding (i.e. the maps 2->3) are described by
(x0, x1, x2, x3, x4, x5)
(x1, x3, x4, x6, x7, x8)
(x2, x4, x5, x7, x8, x9)

Time for a little commercial break. A seminar in which I’ve been participating now has its own webpage, containing the set of notes people have written for this seminar. After April 26 there will be a short break, May 17 it will restart. That day I might or might not give a lecture on derived moduli stacks. Feel free to come if you are interested.

All remarks on the layout of the webpage (which I realize is rather bare, but I wasn’t feeling inspired and I’m a lousy webdesigner anyway) and the notes are appreciated.

I don’t know whether it’s common in other parts of the world, but in France one often (or rather: always) denotes an open or closed immersion by drawing a circle or a slash on the hooked arrow. A bad impression hacked together in plain LaTeX would be $\hookrightarrow\!\!\!\!\!\!\!\circ$ and $\hookrightarrow\!\!\!\!\!\!\!/$.

Now to define the six functors formalism we have a scheme $X$, a closed subscheme $Z$ and an open subscheme $U$ such that on the level of the underlying sets our big scheme is the disjoint union. In order to write this using tikz-cd, which is an excellent package to write commutative diagrams, a bit of effort is needed. We define the appropriate arrow styles by

\usetikzlibrary{decorations.markings}
\tikzset{
closed/.style = {decoration = {markings, mark = at position 0.5 with { \node[transform shape, xscale = .8, yscale=.4] {/}; } }, postaction = {decorate} },
open/.style = {decoration = {markings, mark = at position 0.5 with { \node[transform shape, scale = .7] {$\circ$}; } }, postaction = {decorate} }
}

and then we can produce the diagram by

\begin{tikzcd}
Z \arrow[hook, closed]{r}{i} & X \arrow[hookleftarrow, open]{r}{j} & U
\end{tikzcd}

This results in

Remark that we have to write the arrow from $U$ to $X$ in the opposite direction, because otherwise the hook is upside down. I haven’t found a better solution for this. And it seems that in the font I’m using (the Bera family with Charter from mathdesign for mathematics) the circle is slightly above the center of the line. If one goes this far in writing a silly diagram this should be fixed too, but unfortunately I haven’t found a (clean) solution for this yet. In the default font it looks better by the way.

It should be possible to do this in plain math mode too, but you’ll have to create long hooked arrows etc. This is easier and more consistent I think.