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 finite 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 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.
    • CommentAuthorEric
    • CommentTimeFeb 18th 2012

    Hi Andrew,

    I was writing something that quotes some source from the nLab expecting it to render properly on the nForum. I thought the itex was more compatible than it seems. For example, “\vec”, “\dot” and “\ddot” work on the nLab, but not the nForum.

    You probably explained why somewhere before. Can you refresh my memory?

    Thanks!

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeFeb 18th 2012

    For example, “\vec”, “\dot” and “\ddot” work on the nLab, but not the nForum.

    They do for me: typing

    $\vec v$, $\dot v$, $\ddot v$
    

    produces

    v\vec v, v˙\dot v, v¨\ddot v .

    You maybe have the wrong text filter selected. See below the comment box. You need “Markdown+Itex”-

    • CommentRowNumber3.
    • CommentAuthorEric
    • CommentTimeFeb 18th 2012

    They are working for me now too. Hmm. I do certainly have and had Markdown+Itex selected. Perhaps Andrew worked some magic sense I posted?

    • CommentRowNumber4.
    • CommentAuthorEric
    • CommentTimeFeb 18th 2012
    • (edited Feb 18th 2012)

    Now “F\in\Gamma” is not working. The culprit seems to be “\in”. I see. It seems like there needs to be a space after “\in” (after some trial and error).

    aba\in b

    FΓF\in \Gamma

    Edit: By putting a space after “\in”, I can get FΓF\in \Gamma to work, but “F\in \Gamma(T X)” doesn’t seem to work no matter what I try besides splitting into two pieces FΓF\in \Gamma (TX)(T X) (see Source).

    • CommentRowNumber5.
    • CommentAuthorUrs
    • CommentTimeFeb 18th 2012

    Ah, I see. Good to know.

    I would never have run into this problem, because I always include whitespace everwhere.

    If I weren’t wary of the ensuing discussion (which I don’t have the energy to get into), I would ask you all to also generally add more whitespace in LaTeX code for mathematics on the nnLab. Every now and then I go and fix somebody’s diagram or something on the Lab, only to find a single huge string of symbols in the code, that wraps around the display line several times without any space or line breaks.

    I can’t read such code without much effort. And I suspect nobody can. We are humans, not computer parsers. Let’s write human readable code!

    • CommentRowNumber6.
    • CommentAuthorzskoda
    • CommentTimeFeb 18th 2012
    • (edited Feb 18th 2012)

    I agree Urs, that we have to read human code, but I often have an opposite problem – when something is very sparse and takes a large space I have hard time visually capturing it, scrolling through it, and organizing myself in. Some people write big letters and big spaces and many pages, some like dense letters with only a couple of pages per lecture. The bias toward sparse and elaborate or, on the other hand, toward laconic code and writing is not universal, “human” is not universal.

    On the opposite spectrum of my own biases, in programming, LISP is very efficient and dense, but I could hardly read it quickly even when I was good at lisp. Most of lisp enthusiasts however consider LISP more readable than C++…

    • CommentRowNumber7.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 18th 2012

    If I were to get involved in the discussion that Urs has not initiated, I would express my agreement with Zoran. (-:O There’s a balance to be struck, and individual preferences may differ. Although I do think we should insert linebreaks tastefully in large displayed formulas.

    • CommentRowNumber8.
    • CommentAuthorAndrew Stacey
    • CommentTimeFeb 18th 2012

    Back on the original comment, the reason why inserting spaces here and there gets round problems on the nForum is because the nForum caches the maths snippets. If, for some reason, some maths doesn’t render properly the first time around then the blank gets stored in the cache and, unfortunately, gets served every time in the future. The link between the formula and the cache store is based on the md5sum of the formula so adding a space somewhere creates a new md5 and therefore a new request to the server.

    Every now and again - basically when someone complains - I clear out obviously mangled stuff from the cache (anything of zero size). I expect that if I did that now then the original formula that Eric complains about would then render correctly (I’m pretty certain since I tried the formula on the itex server and it worked just fine). iTeX on the nForum ought to be exactly the same as on the nLab because it is actually generated by exactly the same program.

    As for the vecs, dots, and ddots; Eric, were you on your iPhone when you first looked? I read this thread first on Mobile Safari and the formula didn’t render quite right. But that’s because they’re images and they got cropped a bit badly. Indeed, now that I have a device on which I can’t run Firefox - ie a device that doesn’t render MathML - it’s given me the extra push needed to clean up the rendering of maths for broken browsers. I know what to do .. just need some time to get it in place!

    • CommentRowNumber9.
    • CommentAuthorEric
    • CommentTimeFeb 19th 2012

    Hi Andrew #8: No, I was not on my iphone at the time. Windows 7, Firefox 10.0.2.

    • CommentRowNumber10.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 19th 2012

    It seems like “anything of zero size” could in theory be detected automatically and not cached at all in the first place. Right? Of course that would be extra work for whoever implemented the caching routine.

    • CommentRowNumber11.
    • CommentAuthorEric
    • CommentTimeFeb 20th 2012

    FΓ(TX)F\in\Gamma(T X)

    • CommentRowNumber12.
    • CommentAuthorEric
    • CommentTimeFeb 20th 2012

    That is weird. I meant to post that last expression to demonstrate a blank post and ask you to “See the Source”, but lo and behold! It renders properly when posted.

    The issue is with “Preview” it seems. It did not preview, but posted properly.

    • CommentRowNumber13.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 20th 2012

    It did not preview, but posted properly.

    I think that this has been reported before. Is a cache used for previews where a fresh rendering is used for posting?

    (Eric: Now that you’ve posted it, if you start a new post, does it preview correctly?)

    • CommentRowNumber14.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 20th 2012

    Right now, if I preview anything with math in it, then nothing renders in the preview. (But I’ve only had the patience to wait a few seconds.) I think that this is a known bug indicating a slow server somewhere.

    • CommentRowNumber15.
    • CommentAuthorTim_Porter
    • CommentTimeFeb 20th 2012

    (As a test) I tried and the first bit of maths took a few seconds to preview, but additional bits then were very fast.

    • CommentRowNumber16.
    • CommentAuthorAndrew Stacey
    • CommentTimeFeb 20th 2012

    Mike (10): Good suggestion. If I ever catch the no-good lowlife who programmed the caching routine, I’ll make him implement that. Actually, what worries me with a simple test like that is that if the nLab server is down then it is better to cache nothing than to try to keep reloading it from the server. So I’ll have a think about that. In the meantime, I’ve made it easier to take out the empties and have just done that.

    Toby (14): I’ve been mucking around with iTeX today so you might just have caught it at a bad time.