Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nforum nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf sheaves simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
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 a for elements and morphisms, A for objects, \mathcal{A} for categories, and \mathfrak{A} 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 C for categories (or n-categories or \infty-categories) and F for functors (that is, the same) if the article is primarily about categories and functors. That leaves lowercase x and f for objects and morphisms. But I'm more likely to use \mathbf{C} (even though that doesn't presently render properly, at least in Firefox) or \mathcal{C} (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 S for sets or structured sets but a for elements and f for functions.

    Also, I tend to enforce \mathbf{B}G for the delooping of a group G into a one-object groupoid but \mathcal{B}G 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).