nForum
Not signed in
Want to take part in these discussions? Sign in if you have an account, or apply for one below
Site Tag Cloud
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
-
- CommentRowNumber1.
- CommentAuthorAndrew Stacey
- CommentTimeJul 23rd 2009
- (edited Jul 23rd 2009)
Leading on a bit from Eric's discussion on matters of style, here's a style question. Should we have a lab convention on fonts for categories, functors, and the like? I realise that it may not be possible to always adhere to such a convention, so more of a guideline than a strict rule.
My point is that good notation should aid the reader. Having preferred fonts for categories, functors, and so forth can make the relationships between different pages a little easier.
In one recent paper, I (and my coauthor) used
for elements and morphisms, 
for objects, 
for categories, and 
for functors. Of course I'm not suggesting that this be the convention, just raising the question as to whether or not there should be one, then if that is agreed upon here's my initial suggestion.(By the way, maths on this forum is contained in double dollars, even inline maths)
-
- CommentRowNumber2.
- CommentAuthorTobyBartels
- CommentTimeJul 23rd 2009
I tend to use
for categories (or 
-categories or 
-categories) and 
for functors (that is, the same) if the article is primarily about categories and functors. That leaves lowercase 
and 
for objects and morphisms. But I'm more likely to use 
(even though that doesn't presently render properly, at least in Firefox) or 
(although that can cause font trouble for some people) if the article is primarily about other stuff and the categories come in later. In that case, I'm liable to use 
for sets or structured sets but for elements and for functions.Also, I tend to enforce
for the delooping of a group 
into a one-object groupoid but 
for the classifying space of that groupoid. -
- CommentRowNumber3.
- CommentAuthorTobyBartels
- CommentTimeJul 23rd 2009
I forgot to mention that I pretty much never change a standard for a given page that is already established on that page.
-
- CommentRowNumber4.
- CommentAuthorMike Shulman
- CommentTimeAug 29th 2009
This is an interesting idea. I always use conventions of this sort when writing math papers; I find it especially helpful to keep things straight in my head because I tend to write papers that involve a bunch of different types of categorical thing (e.g. category, 2-category, 3-category ,double category, indexed category can often all occur in the same paper, not to speak of functors). But I think at this point I'd rather not try to impose a style convention on the nLab, since it would raise the barrier to entry just a little bit higher. (Plus the odds of getting multiple people to agree on a single convention for the entire nLab seem to me rather slim!)
-
- CommentRowNumber5.
- CommentAuthorAndrew Stacey
- CommentTimeSep 1st 2009
- (edited Sep 1st 2009)
Here's one for the Lab Elves (typesetting division): now that I can have the error logs scrolling past my screen without worrying about it blocking anyone else's access, I can see all the complaints that the markdown (maruku) filter has about everyone's syntax. The most common offenders are square brackets. Since these are part of markdown's syntax, it tries to make them such. So when someone types
[43, p. 153]then I see
___________________________________________________________________________ | Maruku tells you: +--------------------------------------------------------------------------- | Could not find ref_id = "43_p_153" for md_link(["43, p. 153"],"43_p_153") | Available refs are [] +--------------------------------------------------------------------------- \___________________________________________________________________________ Not creating a link for ref_id = "43_p_153".So presumably these should be changed to
\[and\]by some enterprising soul. -
- CommentRowNumber6.
- CommentAuthorTobyBartels
- CommentTimeSep 1st 2009
The good thing about that is that it simply renders this as if there were no brackets (albeit inside a
<span>or something that affects the CSS very slightly), which in most cases looks just fine. -
- CommentRowNumber7.
- CommentAuthorAndrew Stacey
- CommentTimeSep 1st 2009
I'm a little confused about what you are calling a 'good thing'. Either the brackets should be visible, in which case they should be escaped properly, or they shouldn't be there, in which case they shouldn't be there in the source code.
Maybe you mean that at least it doesn't break anything! In which case, I agree fully.
Oh, it's fun reading the error logs. It's amazing what people type ...
-
- CommentRowNumber8.
- CommentAuthorTobyBartels
- CommentTimeSep 1st 2009
Maybe you mean that at least it doesn't break anything!
Yes. Even at the level of the casual reader, it usually doesn't break anything significantly.
-
- CommentRowNumber9.
- CommentAuthorAndrew Stacey
- CommentTimeSep 2nd 2009
Yeah, but the error messages are sufficiently irritating that I'm going to fix 'em when I get a minute.
More seriously, I'm monitoring the errors to see when we get a spike and it's hard to keep up when all these minor stuff goes by (there's an asterisk in the Sandbox that it doesn't like either).
1 to 9 of 9