This is a post with ideas I’ve considered over time regarding a comment system for the stacks project. The most important thing is that I don’t know what will work. I think initially we want something where it is relatively easy to leave comments, where comments can be tracked (maybe by an rss feed), and where it isn’t too hard to work the comments back into the stacks project.

Structure that exists now:

• lots of tex files coded in a neurotic way so it is (relatively) easy to parse them
• the tags system (Cathy came up with this) which tracks mathematical results as they move around the tex files
• a query page for tags where looking up a tag 0123 returns the results page
• the results page contains links to the mathematical result in the corresponding pdf and moreover (a more recent feature) the latex code of the environment.

Cathy made some suggestions for what a comment system could look like: Besides the “results page” for each tag have a “comments page” where

• the address of the comments page is something like http://commentson0123 for direct access,
• on the query page you can choose to end up on the comments page or the results page for the tag,
• links between comments page and results page,
• Cathy’s ideas about the comments page are:
  • at the top of the page a link to the result in one of the pdfs
  • have the statement of the lemma/proposition/theorem/remark/exercise there
  • under this a small strip where if you click it expands to show you the proof
  • under this comments by visitors
  • to the right of the statement a small column with two lists:
    1. the results that rely on this tag and
    2. the results that are used in the proof of this tag.

I have the following thoughts on this:

• Go for functionality over looks,
• statements of theorems, etc are updated over time and the comments page should always have the current version.
• It may seem that we don’t really need both the results page and the comments page. But I think we do. I want the web addresses of the “results pages” to remain the same forever. These addresses are supposed to be used if you want to give a direct url to a result in the stacks project, and they should not be used for more than a link to the result in the pdf and the statement. I think that in the future all of the stacks project will be directly online (i.e., not in pdf form anymore) and then the “results page” may become a redirect (?) to the result in the project — so we will need another page with the comments.
• I would like there to be a way for the maintainer of the project to check (or be notified) if there is a comment.
• I want there to be a very low threshold for leaving comments, so have minimal protection to comment spam
• Math rendering issues: This is a real problem and I don’t think it has been solved by mathjax. But eventually some software package will take care of this. We can in any case generate png from latex code and put that up on the “comments page”.

Different ideas I have toyed and experimented with in the past

• Have a bug tracking system. What is good about this is that there is standard system that works. My feeling is that it won’t work because the average mathematician has never used or even looked at a bug tracking system.
• Sign off system: Try to get people like Brian Conrad to sign off on tags: “I, Brian Conrad, declare this theorem is correct”. Again I think that this won’t work, yet, but I think it would be a really cool thing to have in the future.
• Layers: Have different “layers” of comments, some historical, some references, some sign-off, some bug, etc. This could probably be managed simply by having different types of comments.
• Mailing list. I actually think this isn’t needed until I convince more people to be active on the stacks project
• Use blogging software with one page for each tag. I actually kind of like this idea, but I do not see how to make it work.
• Use wiki software with one page for each tag. I think this could actually work and be easier to implement then Cathy’s above suggestion provided somebody knows how to set-up wikis. My preference would be a wiki which is file based, or a wiki which uses git to keep track of files, etc.
• Online latex editor for the stacks project

Common feature of all of these ideas: Use already existing, open source, software and just write scripts to interface the stacks project with this. One of my problems with this is that most of the wiki and blog software I looked at will not allow automatic page generation/updating as far as I could tell.

If you have any ideas about this, please leave a comment or email me.

The spring semester has just ended here at Columbia. I assume for most of you similarly the summer will start soonish. Besides running an REU, supervising undergraduates, talking to graduate students, going to conferences, and doing research, I plan to write about Artin’s axioms for algebraic spaces and algebraic stacks this summer.

What are your summer plans? Maybe you intend to work through some commutative algebra or algebraic geometry topic over the summer. In that case take a look at the exposition of this material in the stacks project (if it is in there) and see if you can improve it. Or, if it isn’t there, write it up and send it over. If you want to coordinate with me, feel free to send me an email.

Another (more nerdy?) project is to devise an online comment system for the stacks project. It could be something simple (like a comment box on the lookup page) or something more serious such as a wiki, blog, or bug-tracker, etc. If you are interested in creating something (and you have the skills to do it), please contact me about it.

Finally, I’ve wondered about having mirrors of the stacks project in (very) different locations. If you know what this entails and you are interested in running one, please contact me.

Before I get into the actual topic of this post, a plea. Please reference results in the stacks project by their tags (which are stable over time) and not in any other way. The tags system is explained here and here and latex instructions can be found here.

Just today I changed the output of the result returned if you lookup tags. See this sample output. You’ll see that currently the result of looking up a tag gives you to corresponding latex code. Moreover, cross references in the proofs and statements are now hyperlinks to the corresponding lookup page. This means that you can quickly follow all the references in proofs of lemmas etc down to the simplest possible lemmas.

Of course this isn’t perfect. In many cases the lemmas need more context and you’ll have to open the pdf to read more. Another complaint is that it is cumbersome to have to parse the latex. I think having the latex code available for quick inspection is good in that people can edit locally and send their changes here. In the future I expect to have a variant page where the latex code is parsed (ideally something like a png file with embedded links for cross references). A requirement is that lookup is fast! (Lookup is already not instantaneous, but I’m sure that is due to poor coding skills of yours truly. I’m not convinced mathjax or anything like it is the answer: I don’t like the way it looks and I don’t like how long it takes to load.)

Please let me know suggestions, bugs (things that don’t work), etc.

For a lark I compiled a version of the stacks project with the XITS font package. (No Max not the zits font package!) You can do this for any of your papers by following the instructions in the user guide that comes with the package. It kind of looks nice. For a sample take a look at the chapter stacks-introduction or the whole project.

Let me know what you think!

Let A —> B be a finitely presented ring map. Then we can write B = A[x_1, …, x_n]/I and we get a two term complex

NL_{B/A} : I/I^2 —> ⨁ B dx_i

given by differentiation. In the stacks project we call this the naive cotangent complex of B over A, see Definition 07BN and Lemma 00S1. We say a ring map A —> B is smooth if it is finitely presented and NL_{B/A} is quasi-isomorphic to a projective module placed in degree 0, see Definition 00T2.

A ring map A —> B is said to be formally smooth if given a surjection C —> C’ of A-algebras with square zero kernel, any A-algebra map from B to C’ can be lifted to an A-algebra map from B to C, see Definition 00TI. A first result on smooth ring maps is that given a finitely presented ring map A —> B we have

A —> B is formally smooth if and only if A —> B is smooth.

See Proposition 00TN. This equivalence means in particular that our definition of smooth ring maps agrees with everybody else’s definition.

A standard smooth ring map is one of the form A —> B = A[x_1, …, x_n]/(f_1, …, f_c) with the matrix of partial derivatives df_j / dx_i for i,j = 1, …, c invertible in B, seeDefinition 00T6. A second result is that

a smooth ring map A —> B is Zariski locally on B standard smooth,

see Lemma 00TA.

A relative global complete intersection is a ring map of the form A —> B = A[x_1, …, x_n]/(f_1, …, f_c) such that the fibre rings have dimension n – c, see Definition 00SP. A third result, see Lemma 00T7, is that

a standard smooth ring map is a relative global complete intersection

The proof of this requires a bit of dimension theory; it is essentially the “Jacobian criterion”.

Lemma 00SV states that

a relative global complete intersection is flat.

You prove this by reducing to the Noetherian case and using the local criterion of flatness.

So far, besides some basic commutative algebra there are only ingredients needed to proceed along the lines above are some dimension theory and the local criterion of flatness.

A final result is Lemma 00TF which states that

a flat finitely presented ring map with smooth fibre rings is smooth.

The current proof of this in the stacks project uses a large amount of technical material including limit techniques to reduce to the Noetherian case and Zariski’s main theorem to bound dimensions in nearby fibres.

Some data regarding the dependency graph of the stacks project (on April 18, 2012).

We think of the bottom of the graph (height 0) as the vertices whose tags correspond to results whose proofs do not refer to any other result. Height 1 is those which refer to a result of height 0. Etc. The maximum height is 78 which is attained by 06RD. The next few are
Height 77 : 06RA 06RF 07BE
Height 76 : 06QK 06R9 06RC 06UF 06UG 07BA
Height 75 : 06QI 06QJ 06UD 06UE 06UI 07B4 07B9
Height 74 : 06MF 06N3 06QH 07B3
Height 73 : 06G3 06QG 077A 0783 07AQ 07B8 07BC
Height 72 : 06MX 06PL 0771
Height 71 : 06MT 06PK 0765 0782 07AP
Height 70 : 06MR 06PJ 075Z 0770 0775
Height 69 : 050B 06FI 076Z 0785

The distribution (number of tags per height for height > 0) looks like this

Go over to read Akhil Mathew’s very nice blog post before reading this one. Then read my comment on his post (which was somehow a bit off topic). My comment was a comment of the type: “Even though in the stacks project we use ZMT to prove such and such, we really don’t need to do this.”

But is that really the case? Let’s take for example Lemma Tag 00U9 which says that any etale ring map is a standard smooth ring map. In other words, if A —> B is smooth, then you can write B = A[x_1, …, x_n]/(f_1, …, f_n) with the Jacobian matrix invertible in B. The current proof of this in the stacks project has the following dependency graph (with ZMT in red).

However, if you look at the proof you see that we use Lemma Tag 00U7 (whose proof for some reason depends on ZMT, but that is another matter). However, we really could replace this by Lemma Tag 07CF whose proof is essentially trivial (and in particular doesn’t use ZMT). If we take out the use of 00U7 the new dependency matrix looks like this
As you can see ZMT isn’t used anymore. Not only that, the graph has become significantly simpler.

It is fun how you can test this kind of shortening of arguments before actually implementing them. I’ll add an update to this post when I’ve actually made the changes to the stacks project.

Update. OK, I’ve changed the proof and in fact it is now much simpler. Here is the the final dependency graph So yeah, the original proof was just ridiculously bad!

In this post I want to outline an argument that proves “most” algebraic stacks are generically “global” quotient stacks. I don’t have the time to add this to the stacks project now, but I hope to return to it in the not too distant future.

To fix ideas suppose that X is a Noetherian, reduced, irreducible algebraic stack whose geometric generic stabilizer is affine. Then I would like to show there exists a dense open substack U ⊂ X such that U ≅ [W/GL_n] for some Noetherian scheme W endowed with action of GL_n. The proof consists in repeatedly replacing X by dense open substacks each of which has some additional property:

1. We may assume that X is a gerbe, i.e., that there exists an algebraic space Y and a morphism X —> Y such that X is a gerbe over Y. This follows from Proposition Tag 06RC.
2. We may assume Y is an affine Noetherian integral scheme. This holds because X —> Y is surjective, flat, and locally of finite presentation, so Y is reduced, irreducible, and locally Noetherian by descent. Thus we get what we want by replacing Y be a nonempty affine open.
3. We may assume there exists a surjective finite locally free morphism Z —> Y such that there exists a morphism s : Z —> X over Y. Namely, pick a finite type point of the generic fibre of X —> Y and do a limit argument.
4. We may assume the projections R = Z ×_X Z —> Z are affine. Namely, the geometric generic fibres of R —> Z ×_Y Z are torsors under the geometric generic stabilizer which we assumed to be affine. A limit argument does the rest (note that we may shrink Z and Z ×_Y Z by shrinking Y).
5. We may assume the projections s, t : R —> Z are free, i.e., s_*O_R and t_*O_R are free O_Z-modules. This follows from generic freeness.
6. General principle. Suppose that (U, R, s, t, c) is a groupoid scheme with U, R affine and s, t free and of finite presentation. Consider the morphism p : U —> [U/R]. Then p_*O_U is a filtered colimit of finite free modules V_i on the algebraic stack [U/R]. This follows from a well known trick with basis elements.
7. General principle, continued. For sufficiently large i the stabilizer groups of [U/R] act faithfully on the fibres of the vector bundle V_i.
8. General principle, continued. [U/R] ≅ [W/GL_n] for some algebraic space W and integer n. Namely W is the quotient by R of the frame bundle of the vector bundle V_i.
9. We conclude that X = [W/GL_n] for some Noetherian, reduced irreducible algebraic space W.
10. The set of points where W is not a scheme is GL_n-invariant and not dense, hence we may assume W is a scheme by shrinking. (I think this works — there should be something easier you can do here, but I don’t see it right now.)

Note that we can’t assume that W is affine (a counter example is X = [Spec(k)/B] where B is the Borel subgroup of SL_{2, k} and k is a field). But with a bit more work it should be possible to get W quasi-affine as in the paper by Totaro (which talks about the harder question of when the entire stack X is of the form [W/GL_n] and relates it to the resolution property).

Let R be a ring. Let D(R) be the derived category of R-modules. An object K of D(R) is perfect if it is quasi-isomorphic to a finite complex of finite projective R-modules. An object K of D(R) is called compact if and only of the functor Hom_{D(R)}(K, – ) commutes with arbitrary direct sums. In the previous post I mentioned two results on perfect complexes which I added to the stacks project today. Both are currently in the second chapter on algebra of the stacks project. Here are the statements with corresponding tags:

1. An object K of D(R) is perfect if and only if it is compact. This is Proposition Tag 07LT.
2. If I ⊂ R is an ideal of square zero and K ⊗^L R/I is a perfect object of D(R/I), then K is a perfect object of D(R). This is Lemma Tag 07LU.

Enjoy! If anybody knows a reference for the first result which predates the paper “Morita theory for derived categories” by Rickard I’d love to hear about it. Thanks.

So I’ve now updated the list of contributors to include literally everybody who I know has ever contributed a typo, error, made a suggestion, etc. In particular, please let me know if your name should be there and it isn’t.

The reason for doing this is that this is the only maintainable choice. Up till now I tried to make some choice as to when to put somebody on the list based on number and importance of contributions. However, looking at the list of people I added today I now see this was completely arbitrary and not at all objective! I hope I didn’t offend anybody!

You can look for what people have contributed by searching in the logs (except as with everything in life it isn’t perfect). To do this, first clone the project using

git clone git://github.com/stacks/stacks-project.git

then cd stacks-project and finally use something like

git log --grep=Lastname
git log --grep=lastname
git log --grep=Lastname --color -p
git log --grep=lastname --color -p


Future contributors who send new material in the form of latex will show up as authors as I described in this post a while back and those who point out typos, errors, suggestions, etc without sending latex will show up in the commit messages.

Please let me know if you have an idea for a more efficient way to keep track of contributors.