Comments for Stacks Project Blog

Comment on Summer projects by Johan

Johan — Tue, 15 May 2012 11:05:38 +0000

In the stacks project there is no such thing as taking things on faith. Also when you say foo, people are next going to expect you to say bar…

Seriously though, we have “stackyfication” described in the chapter on stacks. Sure, it is somewhat rough and the exposition and proofs could be improved (this would be very helpful). Adding a remark on what it means to iocalize a 2-category and then adding a remark on how the process of stackyfication is one of these localizations would be very helpful too. Since in algebraic geometry we usually are interested in a finite list of particular algebraic stacks (such as M_g and A_g) and their interrelationships, this should be enough for now…

A similar discussion can be had about the relationship between the 2-category of “presentations” (i.e., smooth groupoids (U, R, s, t, c) in algebraic spaces with suitable notions of 1-morphisms and 2-morphisms) and the 2-category of algebraic stacks. I’ve always thought that it is enough to show that every stack of the form [U/R] is algebraic and conversely that every algebraic stack is of the form [U/R]. Others find it useful to compare the 2-categories. The problem with doing this is that this leads into 3-category land which we try to avoid at all cost.

Namely, my feeling is that in the stacks project we should avoid doing explicit 3-category things, until we decide it is really necessary, and then we go all the way and do infinity categories.

Comment on Summer projects by David Roberts

David Roberts — Tue, 15 May 2012 02:30:39 +0000

One thing which might be nice for the stacks project is the proof that the 2-category of foo-stacks is the localisation of the 2-category of blah-groupoids, for appropriate values of foo and blah. Dorette Pronk has a result in this direction, and I am aiming to expand her result to cover a wide range of definitions of algebraic stacks, and other sorts of stacks. The proof however relies on a theorem whose proof is heavy on 2-categorical (abstract nonsense) calculations. If you are willing to take that on faith, then I see it as a potentially useful addition.

Comment on Flat is enough by Flat is not enough | Stacks Project Blog

Flat is not enough | Stacks Project Blog — Fri, 11 May 2012 22:40:28 +0000

[...] title of this blog post is the opposite of this post. But don’t click through yet, because it may be more fun to read this one [...]

Comment on Non zero-divisors by Johan

Johan — Thu, 10 May 2012 18:40:40 +0000

OK, that makes sense. I’ve now decided to go with Jason’s suggestion because I like “nonsingular”, “nonnegative”, etc without the hyphen. But I’m sure I’ve been inconsistent with this. Thanks!!! (And sorry for doubting your google skills!)

Comment on Non zero-divisors by Johan

Johan — Thu, 10 May 2012 18:21:39 +0000

OK, so I think the real question to ask is whether it is “zerodivisor” or “zero-divisor” or “zero divisor”? Once we have answered this question we just put “non” in front. I think the problem comes from the fact that it seems more correct to write “zero divisor” but “nonzero divisor” is obviously wrong (because non should modify the whole thing and not just zero). Also, apparently in American English one should just add non without a hyphen. So it is starting to look like Jason’s suggestion is the best, because I don’t like the looks of “nonzero-divisor” (because it seems again as if non is only modifying zero).

Alternatively, Bhargav suggests using “regular element” everywhere…

Comment on Non zero-divisors by Graham

Graham — Thu, 10 May 2012 18:08:30 +0000

Yes, I’m sure. It didn’t say “showing results instead for…”, but “did you mean…”. I didn’t use quote marks, which I guess is the difference — when I add them in (and then click on ‘search instead for…’), I get the 3470 you get. Google’s treatment of quotes has gotten really confusing since they killed the ‘+’ operator.

In any case, here’s my reasoning: I like a hyphen after ‘non’ in all contexts: non-singular, non-free locus, non-maximal, etc. Double hyphens, as in ‘non-zero-divisor’, is ambiguous, in that it could be ‘non-zero divisor’. So I go with non-zerodivisor.

Comment on Non zero-divisors by Johan

Johan — Thu, 10 May 2012 17:30:14 +0000

I get only 3,470 results for "non-zerodivisor". Are you sure you did your search correctlY? When google recommends something you have to click on the link: non-zerodivisor to get the actual search results!

Comment on Non zero-divisors by Graham

Graham — Thu, 10 May 2012 14:06:10 +0000

I get 53,900 results on Google for “non-zerodivisor”, my preferred choice. Google recommends “Did you mean ‘non-zero divisor?’, which is just wrong.

Comment on Non zero-divisors by Jason Starr

Jason Starr — Thu, 10 May 2012 13:14:33 +0000

nonzerodivisor

Comment on Comments by Pieter Belmans

Pieter Belmans — Wed, 09 May 2012 10:49:02 +0000

Using both a wiki approach and git might be a bit redundant (wiki and git both provide their own implementation of versioning), it was only a possible deduction given some of the initial ideas. I certainly don’t feel like advocating it.

The proposed user management system isn’t really a user management system, without actual registration / identification this non-system will be simple to set up. The proposed CAPTCHA is a very appropriate idea too. The idea of signing tags off would have to be independent (but that’s probably a good thing).

The actual comments page should be dynamically generated: the content of the tags is available as plaintext in a Git repository anyway, and the comments could be managed as plaintext or in a simple database. No need for a wiki if you opt for a comment form, it would look very much like a blog post that way.

The editing of LaTeX code on a comments page is only possible if we integrate the code on the wiki page, the comment form approach wouldn’t make such a thing possible.

Conclusion: the comment form approach seems both implementation-wise and usage-wise the easiest:
* everything is under your control, no need to impose any rules on the wiki etc.
* allowing Markdown syntax or an HTML subset seems appropriate, and is easy to implement
* an RSS feed is possible too

Downsides:
* no editing or user registration a priori possible (but can be implemented)
* everything is under your control: no spontaneous ideas that sometimes sprout in wikis