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 internal-categories k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure 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 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).

nJournal > nJournal Articles: Leinster2010

Bottom of Page

1 to 100 of 263

  1. <
  2. 1
  3. 2
  4. 3
  5. >
    • CommentRowNumber1.
    • CommentAuthorUrs
    • CommentTimeJan 4th 2011

    I have created a skeleton for Leinster2010.

    The plan is to convert the LaTeX source linked to there into an nnLab page, the way I have tried to indicate. I can’t continue working on this right now. Anyone who feels like adding a bit more should feel free.

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeJan 4th 2011
    • (edited Jan 4th 2011)

    while the conversion of the document is underway, we should start the refereeing process.

    Since the Annals-editors are not fully in place and instructed yet, it is still the steering committee (nlabmeta) that serves as the editorial board. So if you are interested in refereeing, you should tell any one of them.

  3. I’ll not be able to act as a referee, but I can (and will) help in converting the file into an nnLab page.

    • CommentRowNumber4.
    • CommentAuthorUrs
    • CommentTimeJan 4th 2011

    I can (and will) help in converting the file into an nLab page.

    That would be great! Thanks.

    • CommentRowNumber5.
    • CommentAuthorTom Leinster
    • CommentTimeJan 4th 2011
    Thanks very much, Domenico.

    As I said somewhere else, I'm not actually ready to submit this for refereeing yet: I want to make some improvements first.
    • CommentRowNumber6.
    • CommentAuthorUrs
    • CommentTimeJan 4th 2011
    • (edited Jan 4th 2011)

    I’m not actually ready to submit this for refereeing yet

    I understand now what’s going on, but feel like mentioning just for the record, so that people who feel inclination to help with formatting won’t be put off:

    Tom did say we should start with converting the article to an nnLab page here.

    • CommentRowNumber7.
    • CommentAuthorTom Leinster
    • CommentTimeJan 4th 2011
    @Urs 6: yes (well, what I said was a "could" rather than a "should", but it's good that the ball's rolling). Personally I plan to think about the substantial changes first, then turn my attention to the presentation of the web version and associated technological issues. But as people (e.g. you) have kindly said they'll help out with the web version, I don't want to impose any kind of restriction -- I'm grateful for the help. In particular, if you/anyone find it more convenient to work on this sooner rather than later, that's fine by me.
    • CommentRowNumber8.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 4th 2011

    As there isn’t a particular urgency in doing the conversion, may I recommend that people concentrate on converting the diagrams as a first priority? My reason is that if this works (as I hope it does), the problem of converting a LaTeX document to an iTeX+Maruku one is going to be something that would be nice to automate as much as possible. In a semi-automatic system, the most difficult will be diagrams (as they’re most visual) and the simplest will be common stuff such as simple command substitution (\newcommand{\fcat}[1]{\mathscr{#1}} springs to mind). So those who want to get stuck in and convert Tom’s article should start with the stuff that is most difficult with a semi-automatic, namely diagrams.

    • CommentRowNumber9.
    • CommentAuthorTom Leinster
    • CommentTimeJan 4th 2011
    Man, I'm glad I tidied up my Latex before I arXived it. Never imagined it would be the subject of public discussion.
    • CommentRowNumber10.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 5th 2011

    That’s tidy??? I’m glad I didn’t see it in an earlier incarnation …

    • CommentRowNumber11.
    • CommentAuthorDavidRoberts
    • CommentTimeJan 5th 2011

    @Tom - some rationale for Andrew’s reaction. :-)

    • CommentRowNumber12.
    • CommentAuthorTom Leinster
    • CommentTimeJan 5th 2011
    Thanks David. I guess you're telling me that Andrew is some kind of obsessive? His jibes will not ruffle me.
    • CommentRowNumber13.
    • CommentAuthorUrs
    • CommentTimeJan 5th 2011

    We should maybe alert people that if they use xypic for their diagrams, then chances are higher that their LaTeX is automatically converted to instiki (eventually): the xypic-code just has to be wrapped in a code-cogs call and whitespace has to be removed

    (for those who don’t know what this referes to, search HowTo for “codecogs”)

  14. I’ve now converted a couple of pages, but I see I messed things up with the numbering of Lemmas and Definitions and with creating the new theorem-like enviroment Fact. I tried to follow instructions at the instiki tutorial page, but something went wrong. apologize for that.

    • CommentRowNumber15.
    • CommentAuthorTom Leinster
    • CommentTimeJan 6th 2011
    No need to apologize, Domenico (at least, not to me)!
    • CommentRowNumber16.
    • CommentAuthorzskoda
    • CommentTimeJan 6th 2011
    • (edited Jan 6th 2011)

    An outsider comment: The cafe on Leinster’s survey has some tangencies about higher geometric theories as well as previous discussion about algebraic geometry with Dolan. Now my memory is that Lurie in Higher Topos Theory exhibits briefly a counterexample to (infinity,1)-version of Deligne’s theorem (coherent theory is classified by a grothendieck topos) hence that correspondence between higher coherent theories and Grothendieck higher topoi are not to be expected (what looks not in accordance to the conjectures raised in the above cafe discussions).

    Am I mixing something up ?

    • CommentRowNumber17.
    • CommentAuthorMike Shulman
    • CommentTimeJan 7th 2011

    Why not post that to the cafe discussion?

    If anyone remembers where in HTT such a thing is to be found, I’d love to know….

    • CommentRowNumber18.
    • CommentAuthorTom Leinster
    • CommentTimeJan 7th 2011
    I would now like to submit my article for peer review.

    The version I am submitting is here.

    Exactly the same version, but marked up with stars in the right-hand margin to show where changes have been made from the original version, is here. I did this for my own purposes, but maybe some other people will also find it useful.

    I'll now join in the conversion process. Thanks once again to those who are helping or have helped with that.
    • CommentRowNumber19.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 7th 2011

    Tom, can we have the LaTeX source, please? I’ve written a script to convert LaTeX to iTeX. It’s not perfect, but it should get the majority of the document in a suitable form without too much hassle. Then people’s efforts in converting it will be concentrated on the bits that need human intervention rather than the “grunt work”.

    • CommentRowNumber20.
    • CommentAuthorTom Leinster
    • CommentTimeJan 7th 2011
    • (edited Jan 7th 2011)
    Yes - but are you sure you want it? After all, work's already started on converting the previous version, and the difference between the original and submitted versions is pretty small. If more than 15 minutes' work has gone into the previous version, it's not worth starting again.
    • CommentRowNumber21.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 7th 2011

    Send it to me anyway, if you don’t mind. If this is going to take off, we’ll need to be able to convert stuff from LaTeX to something suitable for the nLab wiki. Although this article has received a fair bit of work, I suspect that enthusiasm for this will tail off fairly quickly.

    • CommentRowNumber22.
    • CommentAuthorTom Leinster
    • CommentTimeJan 7th 2011
    OK, it's here. I'm now available to work on the conversion. On the plus side, in some sense I have more motivation to do this than anyone else. On the minus side, it's the first time I've used the nLab.

  23. Human latex-to-instiki conversion has currently gone through just 20% of the file, so Andrew’s script will speed up things for sure. And it well be a good test for future submissions. Please, Andrew, process Tom’s file and replace what is currently in Leinster2010 with that.

    • CommentRowNumber24.
    • CommentAuthorTom Leinster
    • CommentTimeJan 7th 2011
    Thanks for that, Domenico...

  25. Andrew, how is the automatic LaTeX to iTeX conversion going?

  26. I’ve lost track of what’s happening here: should I wait for the automatic conversion and then come in for human fine tuning, or should I go on with the human conversion?

    • CommentRowNumber27.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 11th 2011

    Wait for the automatic conversion. It’s in the final polishing stages.

    (Our semester began this week and I was lecturing on Monday and today so that put me a bit behind.)

    If you do want something to do, you could do the diagrams. Any of the diagrams that use the diagrams.sty syntax won’t get converted properly. You could stick them in the Sandbox, or we could have a dedicated page (say, on doriath) for the time being: Leinster2010 diagrams (doriath).

  28. ok, I’ll work on the diagrams. I’ll not be able to do much before friday, though.

    • CommentRowNumber29.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 12th 2011

    I suspect that I’m getting to the point of diminishing returns on the automatic conversion. Ideally, it’ll get better but at the moment it’s a half-way house between the Right Idea and a hack that Does The Job, but the main bits to do on the script involve converting the hacky bits to proper bits and that won’t affect the outcome very much.

    Obvious stuff still to do:

    1. References and labels. I think that the references bits are in place, but I don’t quite understand the labelling system.
    2. Enumerations and lists. It doesn’t indent paragraphs that are parts of lists so it often looks as though a list keeps restarting when it should be part of one big list. (I think I know how to do this automatically, but it’ll take a bit of converting hacks to better code)

    For those interested, the script attempts to emulate TeX and do the expansions as TeX would, but leave alone anything that iTeX could interpret.

    Anyway, you can see what I’ve done so far at converting latex to itex (doriath). I’ll put it over to Leinster2010 sometime soon.

    • CommentRowNumber30.
    • CommentAuthorUrs
    • CommentTimeJan 12th 2011

    That’s already impressive, Andrew. Thanks for the effort!

    • CommentRowNumber31.
    • CommentAuthorTom Leinster
    • CommentTimeJan 12th 2011
    Yes, thanks very much, Andrew. As ever, please feel free to give instructions for grunt work.
    • CommentRowNumber32.
    • CommentAuthorTobyBartels
    • CommentTimeJan 12th 2011

    For those interested, the script attempts to emulate TeX and do the expansions as TeX would, but leave alone anything that iTeX could interpret.

    Cool! This is certainly the Right Way, but it’s hard, and I didn’t expect it.

  33. I’ve now fixed the diagrams up to equation (8) in converting latex to itex (doriath). I’d now like to fix (by hand for this time but we should find a way to automatize it) the \ref issue. According to the instiki how to, the grammar should be \ref{NameOfReference}, but converting latex to itex (doriath) seems not to recognize the \ref command. Which grammar should I use for this?

    • CommentRowNumber34.
    • CommentAuthorTobyBartels
    • CommentTimeJan 16th 2011

    That grammar is for references to numbered theorems or equations (although (eqref:NameOfReference) is better for equations).

    But you seem to want numbered sections; iTeX does not support these! (MediaWiki has support for displaying numbers of sections, but even it cannot put those numbers into the text.)

    So we’ll have to do those by hand (and using section names, or putting the numbers into the section headers by hand too), at least for now.

  35. iTeX does not support these!

    ok, thanks! now I’m going to do that by hands

    • CommentRowNumber36.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 16th 2011

    That was something I was meaning to raise as it’s an issue to consider. Should we number sections? One proposal was for sections to be on separate pages, in which case numbering them seems overkill. Also, mere numbers produce small links whereas the full name would provide a better target. So “Section Introduction” (with “Introduction” also being a hyperlink) might work. If we want sections numbered, we could introduce a new counter (similar to the theorem counter) to number them, then I think that the \ref command would work. If not, there’s always the fallback [link text](#anchor).

    The other issue with references is that colons aren’t great in label names. They’re technically okay in XHTML syntax, but I think that Maruku doesn’t like them. So the colons need to be replaced, say by dashes.

    Oh, and another thing that needs changing in the current version on doriath is the accented characters. Tom used things like \"{o} which needs replacing by the relevant character. Don’t forget my handy converter for that! (I’ll adapt my script to pass it through that anyway for next time around).

    Once we see what works, I can adapt my script to do (some of) this automatically.

    • CommentRowNumber37.
    • CommentAuthordomenico_fiorenza
    • CommentTimeJan 16th 2011
    • (edited Jan 16th 2011)

    I’ve used the [Section n](#Section_n) sintax. There’s some mysterious problem with the toc (sections 1 to 3 do not appear), but this can be managed later.

    • CommentRowNumber38.
    • CommentAuthorTobyBartels
    • CommentTimeJan 18th 2011

    I wrote:

    iTeX does not support these!

    Sorry, that has nothing to do with iTeX. It’s instiki that doesn’t support them.

    • CommentRowNumber39.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 18th 2011

    I’ve done a bit of cleaning up, fixing a few labels and lists and did the accents.

    The issue of numbering and references is still outstanding. I’m not sure that XHTML can support automatic link text (ie that bit that one clicks on), I’ll need to look. When theorems and equations and so forth are linked, the text is put in by the formatter (maruku). That makes sections and lists difficult as the numbers are put in by the browser. I know that we can predict what those numbers will be, but it does seem a little awkward.

    • CommentRowNumber40.
    • CommentAuthorTobyBartels
    • CommentTimeJan 18th 2011

    In ordered lists, yes, the numbers are put in by the browser. (In principle, besides predicting them, we can use CSS to override them, if we really want to be certain.)

    But in sections, the numbers are not put in by the browser. It would be nice if we could put them in automatically, as with theorems and equations, when requested by a certain markup. (MediaWiki does this with pure XHTML, when that option is chosen, although even that is only for display, not for internal links, and the choice is by the viewer, not by the writer. So it actually has little to do with what we want here.)

  41. minor edits. quite proud of this one:

    Sh(X)≃←→Et(X). \mathbf{Sh}(X) \underoverset{\leftarrow}{\rightarrow}{\quad\simeq\quad} \mathbf{Et}(X).

    :)

    • CommentRowNumber42.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 18th 2011

    The theorem etc numbering is done by CSS so I don’t see why, in principle, we can’t do the same with sections. Maybe it’s possible to do something similar with lists, but each list would have to have a separate counter.

    Also, it’s important to think about what is useful for the reader. I tend to find that I have less visible on the screen when reading online than when reading a PDF so the likelihood that the actual list is fully visible when I’m looking at the reference is small. But I may not actually need to flip back to the list to remember it, just be reminded which item it is referring to. So giving labels and references actual names is something to consider seriously. We should be always thinking how to make the online version have that little extra than the offline (PDF) version. We won’t get it all right straightaway, but hey - it’s a wiki!

    One thing to remember is that actually clicking on a link is more of a step than flicking over a page.

    Another thing: I think that the text on the Doriath page is now past the point of no return as far as my script is concerned. Although there are several things that should have been automated, it’s now easier to do them by hand than run it through an updated version of the script. So I propose that we copy it across to the page on the nLab. I’ll still work on making the script better so that next time there’s less to do by hand, but for this one I think we’re beyond that point.

    Lastly, Domenico: I think your pride is completely justified!

    • CommentRowNumber43.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 18th 2011

    Actually, maybe we shouldn’t move it. Some things that we might want to do will involve changing the CSS (such as putting in section counters). Those are best done on Doriath.

    • CommentRowNumber44.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 18th 2011

    Speaking of which, I’ve added the CSS to number the sections automatically.

    Also, it appears that putting lists inside examples environments messes up the header on the environment. A fix is to put a non-breaking space &nbsp; before the list.

    • CommentRowNumber45.
    • CommentAuthorTobyBartels
    • CommentTimeJan 18th 2011

    One thing to remember is that actually clicking on a link is more of a step than flicking over a page.

    Not to me! It’s more of a step than glancing down to a footnote, but less than looking at an endnote or bibliography (except on something so short that these are on the same page or on the back of a one-page print-out).

    • CommentRowNumber46.
    • CommentAuthorTobyBartels
    • CommentTimeJan 18th 2011

    Also, it appears that putting lists inside examples environments messes up the header on the environment. A fix is to put a non-breaking space &nbsp; before the list.

    I’d noticed that but hadn’t come up with a fix (other than putting in intoductory help). Thanks!

    Does this work for the end of proof environments too? … Sandbox says yes, but you need a blank line before the &nbsp;.

    Maybe instiki should put these in automatically?

    • CommentRowNumber47.
    • CommentAuthorTobyBartels
    • CommentTimeJan 18th 2011

    I’ve added the CSS to number the sections automatically.

    But they’re not numbered the way that the text does them; in Tom’s text, the Introduction doesn’t have a number.

    I think that we need some distinguishing markup; if ## is a numbered section, maybe == (borrowed from other wiki software) is an unnumbered section? (Or conversely, but ## looks like numbers to me.)

    • CommentRowNumber48.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 18th 2011

    It’s easy enough to do a numbered section and an unnumbered section. The distinguishing features are to do with the CSS style so we could have classes .num_section and .un_section for numbered and unnumbered. The only question is to decide which is the default. I suppose also there’s the question of depth: at the moment, I’ve numbered sections and subsections (though you can’t see the latter on Tom’s article).

    Note also that the references are labelled “A”. I guess that normally the references wouldn’t be labelled at all. It also appears that putting a header inside a div hides it from the table of contents, which is useful to know.

    (Note that I added the “Introduction” header, mainly in an attempt to figure out what was going wrong with the table of contents but also because I think that starting the text without a section heading looks plain wrong.)

    • CommentRowNumber49.
    • CommentAuthorTobyBartels
    • CommentTimeJan 19th 2011
    • (edited Jan 19th 2011)

    we could have classes .num_section and .un_section for numbered and unnumbered

    How does one indicate these in the header markup?

    • CommentRowNumber50.
    • CommentAuthorDavidRoberts
    • CommentTimeJan 19th 2011

    I’ve had a go at fixing up the two outstanding diagrams, and it seems that to get \begin{matrix} to work inside \begin{equation} a little bit of fiddling is necessary - it seems a blank line above and below the {equation} is necessary. And now it looks as if I’ve broken the definition just below the first diagram in section 3 (toposes and set theory).

    And for example 4 in the second examples section in section 4 (toposes and geometry), could we get a picture (what’s that awesome picture code thingy that we use again?) made up? For now it’s just an array, but in the paper it’s a bit of cartoon of a section map.

    • CommentRowNumber51.
    • CommentAuthorTom Leinster
    • CommentTimeJan 19th 2011

    David (50): I can make a graphics file of the section cartoon, if that's a good solution.

    • CommentRowNumber52.
    • CommentAuthorDavidRoberts
    • CommentTimeJan 19th 2011

    I was thinking of svg. The picture looks simple to me, so it may not be too complicated. However, I don’t know if that is ok for you, or too much to ask, Tom.

    • CommentRowNumber53.
    • CommentAuthorTom Leinster
    • CommentTimeJan 19th 2011

    I've never made an svg file before, but I see that xfig can export to svg. (Well, it qualifies it as "beta".) I just tried a random example. Does that work for you? It should show a rounded-off rectangle and a kind of L-shape both inside a circle. For comparison, here it is in jpg.

    When I view it on this old version of Firefox, it's wrong: the other two shapes aren't inside the circle. I don't know where the problem is. If it looks wrong for you too, then I guess I don't have an easy way of making svg files. If it looks right, I'll give it a try (though I'll need advice about doing the text labels).

    • CommentRowNumber54.
    • CommentAuthorDavidRoberts
    • CommentTimeJan 19th 2011

    Hmm. It looks wrong to me on Ff 3.5 (the version at work) too. SVG is not mandatory, I thought it might be good for future-proofing the article. An included graphic file would be ok, I suppose, but I’ll let others more knowledgeable than me make a more definitive answer. In any case a minor change in the layout will be necessary.

    • CommentRowNumber55.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011

    To quote Wham!:

    If you’re gonna do it, do it right, do it with SVG

    But I’ve had a little experience converting stuff to SVG and I know that I’m the most rabid SVG fanatic here so I’ll happily take care of any diagram that needs SVG. We certainly should not be including images if we can at all help it. You may as well put tippex on everyone’s screen.

    Toby: if we adopt the numbered/unnumbered styles for sections then the syntax would be one of:

    ## Main Section ## {: .num_section}

## Main Section ##
{: .num_section}

## Main Section ## {: .un_section}

## Main Section ##
{: .un_section}

    (The closing hashes are optional but recommended). So it’d be like the theorem environments.

  56. Yeah! :)

    Set Open(X) op⊥←→Hom(I,−)−⊗ITopSp/X. \mathbf{Set}^{\mathbf{Open}(X)^{op}} \, \underoverset{Hom(I,-)}{-\otimes I}{\underoverset{\leftarrow}{\rightarrow}{\quad\perp\quad}} \, \mathbf{TopSp}/X.
    • CommentRowNumber57.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011

    I’m late for a meeting and something that I’ve done has messed up the page. I need to track down exactly what it is so please don’t edit it until I do and please don’t worry at the state that it’s in!

  58. ok

    • CommentRowNumber59.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011

    Right, it’s back in a usable state. I don’t know why, but it’s complaining vociferously about \ref{egsheaves}!

    I’ve figured out how maruku handles references to counters and by flagrant abuse of the system, I’ve gotten it to do automatic labels to enumerated items. It’s straightforward enough that an automatic script can handle it on import, but the actual syntax is a little odd! Also, maruku doesn’t like punctuation in ids (don’t know about numbers, must test). So with the notable exception of egsheaves, the references should now be all in place. Oh, though I haven’t updated the section numbering so that isn’t sorted out yet.

    • CommentRowNumber60.
    • CommentAuthordomenico_fiorenza
    • CommentTimeJan 19th 2011
    • (edited Jan 19th 2011)

    I’ve now added the adjoint functors diagrams. now it seems there are only the two big diagrams left, and hyperlinks to be added.

    By the way, any idea on how to make f *f^* the same size as f *f_* and f !f_! in this diagram?

    ⟵f *−→f *⊥→⊥f ! \, \underoverset{\underoverset{f_*}{\perp}{\rightarrow}}{\underoverset{\perp}{f_!}{\rightarrow}}{\longleftarrow {f^*} -} \,
    • CommentRowNumber61.
    • CommentAuthorUrs
    • CommentTimeJan 19th 2011

    How about this:

    ⟵ f *−→f *⊥→⊥f ! \, \underoverset{\underoverset{f_*}{\perp}{\rightarrow}}{\underoverset{\perp}{f_!}{\rightarrow}}{\longleftarrow {}^{{}_{{}_{f^*}}} -} \,

  62. wow!

    • CommentRowNumber63.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011

    iTeX allows for changing style just as in LaTeX:

    $$
\underoverset{\underoverset{f_*}{\perp}{\rightarrow}}{\underoverset{\perp}{f_!}{\rightarrow}}{\longleftarrow {\scriptsize f^*} -}
$$
    ⟵f *−→f *⊥→⊥f ! \underoverset{\underoverset{f_*}{\perp}{\rightarrow}}{\underoverset{\perp}{f_!}{\rightarrow}}{\longleftarrow {\scriptsize f^*} -}
    • CommentRowNumber64.
    • CommentAuthorUrs
    • CommentTimeJan 19th 2011

    now it’s me to say wow. Why do I learn about this only now???? :-/

    • CommentRowNumber65.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011

    Because you spend your time doing maths rather than avidly reading the itex command page?

    • CommentRowNumber66.
    • CommentAuthorTom Leinster
    • CommentTimeJan 19th 2011

    Round of applause to all!

    • CommentRowNumber67.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011
    • (edited Jan 19th 2011)

    I’d like people’s opinions on SVGs for Leinster2010 (doriath)

    • CommentRowNumber68.
    • CommentAuthorUrs
    • CommentTimeJan 19th 2011

    I’d like people’s opinions on SVGs for Leinster2010 (doriath).

    I don’t see any arrow-heads. (?) Is it possible to have the arrows be thinner? And the hook less curved?

    Maybe it’s just a matter of being used to it, but I like the xypic-style rendering of such diagrams. Can we produce something that loks very similar to xypic output with SVG?

    • CommentRowNumber69.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 19th 2011

    How’s that?

    • CommentRowNumber70.
    • CommentAuthorUrs
    • CommentTimeJan 19th 2011

    Okay, on my system, the left arrow now has a good thickness (or rather thin-ness). All other lines are still thick.

    The “inclusion”-curves on an arrow in xypic are much less curved in the middle of the curve. I think that looks better. Do you know what I mean?

    (By the way, just to be sure: I am not intending to push you to go through the trouble of trying to make the SVG come out very similar to, I am just offering that opinion, since you asked.)

  71. on my system the diagram is extremely nice. maybe the curvature of the hook in the “inclusion” arrows could be milder, as Urs suggests. me too thinks that way would look better (maybe that’s just since I’m used to xy-pic). anyway, Andrew, change this only if it takes less than 1 minute.

    • CommentRowNumber72.
    • CommentAuthorTom Leinster
    • CommentTimeJan 19th 2011

    Andrew, I think it's very nice.

    • CommentRowNumber73.
    • CommentAuthorTobyBartels
    • CommentTimeJan 19th 2011

    what’s that awesome picture code thingy that we use again?

    Maybe you’re thinking of codecogs, but SVG is better if you can do it.

    • CommentRowNumber74.
    • CommentAuthorTobyBartels
    • CommentTimeJan 19th 2011
    • (edited Jan 19th 2011)

    SVGs for Leinster2010 (doriath) looks good to me. (Yeah, the hook could be a little less tight, but whatever.)

    Maybe the right-angle should be a bit smaller too; it goes almost halfway to the next symbol for me.

    • CommentRowNumber75.
    • CommentAuthorTobyBartels
    • CommentTimeJan 19th 2011

    (The closing hashes are optional but recommended).

    I usually leave these out, because I’ve found that sometimes people change the level of the heading and forget to change the ending hashes, and then it looks bad.

    So it’d be like the theorem environments.

    But it’s not like theorem environments, so I wasn’t sure of the syntax. Now I am, so thanks.

    • CommentRowNumber76.
    • CommentAuthorDavidRoberts
    • CommentTimeJan 19th 2011

    @Toby, it was SVG I was thinking of, and only for Tom’s little ’cartoon of a section’. As far as diagrams go, I don’t think I would like to set a precedent where all diagrams are done in SVG - it could cause a lot of work on some papers. But it remains to be seen if it is a solution that is better than redoing the diagrams in the matrix environment. If so, then I guess the path of least resistance is better.

    • CommentRowNumber77.
    • CommentAuthorTobyBartels
    • CommentTimeJan 20th 2011

    I would like all diagrams to be in SVG, since it seems to be the most flexible format, but I certainly wouldn’t want to require all diagrams to be done in SVG, since it’s also harder to do than many other ways. So on the one hand, authors should be allowed to put diagrams in any accessible format, but on the other hand, it should be welcomed for Andrew (or whoever) to convert them to SVG (if done correctly, since the automated tools are still far from perfect).

    • CommentRowNumber78.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 21st 2011

    Ah, I interpreted “less curved” incorrectly. Ooops.

    I’ve uploaded an image with the diagram done using AMS Array (but didn’t know how to do a downwards inclusion arrow), an XY matrix, and a TikZ picture, just for comparison. Of course, I’m definitely not advocating doing diagrams as pictures, but I thought it might help focus people’s thoughts on what they do and don’t like of each picture (so it’s as much to have three different versions to compare as to compare the different types) so that I can tweak the SVG accordingly.

    • CommentRowNumber79.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 21st 2011

    Regarding section numbering: I think that the default should be for unnumbered sections since the CSS is applied to every page and on some pages having sections numbered is a bit daft!

    • CommentRowNumber80.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 21st 2011

    I’ve also redone it in a slightly different form (all bar the pull-back symbol, not sure how best to place that) where only the arrows are SVGs.

    That is, the topmost diagram is an SVG with inset MathML. The lowermost diagram is a MathML with inset SVG. If you look at the source, you’ll probably prefer the lower one!

    • CommentRowNumber81.
    • CommentAuthorUrs
    • CommentTimeJan 21st 2011

    Thanks for working on this, Andrew!!

    That new SVG version looks good to me now, with the arrows being thin. I think that’s important for the diagram to look like nice math and not like a carbon cycle flow chart.

    In this vein I also like the thin non-filled arrow heads of the xymatrix example. But the filled arrow heads of the TikZ and SVG example don’t look too bad either, so maybe it’s okay the way it is now.

    • CommentRowNumber82.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 21st 2011

    Yay! I think I’ve finally found a real use for the iTeX \array command: to put the pull-back symbol in (roughly) the right place.

    On arrowheads, I think that this is going to be very much a matter of personal style. I really like the solid arrow heads because I feel that one doesn’t need to have such a large arrowhead to see it, so they’re more compact. Note that TikZ has support for both filled and unfilled so it’s not about XY versus TikZ but purely my choice in typesetting them. Perhaps Tom should cast the deciding vote (assuming that this is a good way to typeset the diagrams).

    (For those interested in automatically making SVGs, the arrows were generated by TikZ and then copied in to the nLab. The TikZ code is:

    \documentclass{minimal}
\makeatletter
\@ifpackageloaded{tex4ht}{
\def\pgfsysdriver{pgfsys-tex4ht.def}}{}
\makeatother

\usepackage{tikz}
\usetikzlibrary{arrows}

\begin{document}

\tikz \draw[right hook-triangle 45] (0,0) -- (4em,0);
\tikz \draw[left hook-triangle 45] (0,0) -- (-4em,0);
\tikz \draw[right hook-triangle 45] (0,0) -- (0,4em);
\tikz \draw[right hook-triangle 45] (0,0) -- (0,-4em);
\tikz \draw[-triangle 45] (0,0) -- (4em,0);
\tikz \draw[-triangle 45] (0,0) -- (-4em,0);
\tikz \draw (0,0) -- ++(1em,0) -- ++(0,1em);

\end{document}

    which I then ran htlatex on. The \@ifpackageloaded is so that it also works fine with pdflatex. The last symbol is the pull-back symbol. When copying the SVGs in to the nLab, I deleted the first two lines (starting <?xml) and if necessary adjusted the height attribute on the main svg element: the given height ignores the width of the arrowheads, I found 10pt to be just fine.)

    • CommentRowNumber83.
    • CommentAuthorTom Leinster
    • CommentTimeJan 21st 2011

    Thanks so much, Andrew.

    Regarding arrowheads: for most of my "career" I've used solid arrowheads, but for this document I used plain ones (i.e. ones looking like >). Why? Because it's topos theory. Huh? Well, in topos theory you often want to indicate monos and epis:

    >---> and --->>

    (OK, that's hideous, but you know what I mean.) And I think those look way better with plain arrowheads than solid ones. I reckon that using solid heads in this context would be pretty unusual.

    For that reason I suggest adopting non-solid arrowheads (">") as a general policy.

    • CommentRowNumber84.
    • CommentAuthorUrs
    • CommentTimeJan 21st 2011

    For that reason I suggest adopting non-solid arrowheads (“>”) as a general policy.

    I think that’s a good point.

    • CommentRowNumber85.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 21st 2011
    • (edited Jan 21st 2011)

    That’s a good enough point for me, though I would argue that this is something where perhaps we should not set a “general policy” but let authors have some say. I’ll change the arrows - fortunately that’s really easy to do just by changing the SVG pages!

    Incidentally, that reminds me: you use both ↪\hookrightarrow and ↣\rightarrowtail. Is this deliberate?

    • CommentRowNumber86.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 21st 2011

    Also:

    1. What about the “pull-back” symbol? How does that look, and is it placed correctly?
    2. With the double headed, and double tailed, arrows, should it be blank between the arrows (–>>) or should the line extend (–>->) (the spacing between the pieces of the head would be the same in both)?
    3. Should the arrowheads be straight (as xy does) or gently curved (as in, say, →\to)?
    • CommentRowNumber87.
    • CommentAuthorTom Leinster
    • CommentTimeJan 21st 2011
    • (edited Jan 21st 2011)

    Re 85: yes, I agree that there shouldn’t be a general policy that overrides the author’s preference. But there might be more situations like this where you (or someone else other than the author) is doing the conversion, and there it might be helpful to have a default setting. I don’t know.

    Edit: yes, using both ↪\hookrightarrow and ↣\rightarrowtail was deliberate. I was using the former to indicate the inclusion of an actual subset, and the latter for any old injection. Yup, that’s evil.

    Re 86:

    1. Assuming we’re talking about the very last diagram: I think the pullback symbol is a good size. Personally I’d place it closer to the corner, i.e. up and left a bit. Caveat: this old browser might not be displaying the diagram correctly.

    2. Interesting… I don’t know. I thought the command I’d used, \twoheadrightarrow, was blank between the arrowheads, but when I looked I saw that the line extended. I don’t think I have an opinion here, as long as it looks like a single symbol.

    3. I definitely have no opinion. I leave it to your aesthetic sense, and merely express admiration at your attention to detail.

    • CommentRowNumber88.
    • CommentAuthorTobyBartels
    • CommentTimeJan 22nd 2011
    • (edited Jan 22nd 2011)

    @ Andrew #79

    I accept your reasoning.

    Also, I like the current ‘diagram with only the arrows as SVG’, and I also like the look of the TikZ version (especially if I ignore the poor resolution). I don’t think that these feelings of mine have anything to do with the solid arrowheads.

    • CommentRowNumber89.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 24th 2011

    I leave it to your aesthetic sense, and merely express admiration at your attention to detail.

    Well, to be honest it’s just that there’s a choice to be made and there’s no default option so I may as well find out what everyone likes rather than imposing my own style.

    Okay, I’ve changed the arrowheads to the style of →\to, but slightly larger than one gets “naturally”: I found it hard to see them when they were their normal size. I’ve shifted the position of the pull-back symbol a little, but pushing it higher up really only pushes the arrow further down (at least, the way I’ve done it - there’s probably a better way but I don’t know it yet).

    I’ve also uploaded a whole slew of arrows to provide a starting point for these diagrams. (Any that are missing are simply not uploaded yet, I have the files. So bird-spotters needn’t get out their binoculars looking for the twoheadswarrowtail.) Also managed to discover that my old left-right confusion hasn’t completely left me!

    • CommentRowNumber90.
    • CommentAuthorTobyBartels
    • CommentTimeJan 24th 2011

    I’ve realised that there’s a problem with only the arrows as SVG: the arrows don’t stretch as they should. (This is also a problem with the old \array versions.)

    the twoheadswarrowtail

    That would be an interesting bird!

    • CommentRowNumber91.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 24th 2011

    Not sure that I understand what you mean by stretching. Do you mean that one has to use arrows of different lengths if the label text is especially long? If so, then that is true. But I’m not sure what you mean by “the old \array versions” in that context.

    • CommentRowNumber92.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 24th 2011

    I’ve converted a lot of the commutative diagrams at converting latex to itex (doriath) to diagrams with included SVGs. One diagram is causing me a few hassles, it’s the natural numbers diagram which is here. I’ve had to shift it out of the list environment to get it to render, otherwise I get all sorts of complaints.

    Also, the labels on the vertical and diagonal arrows are not optimally placed.

    (I’ve emailed Jacques to ask if he has any ideas on those, if anyone else has any ideas please do say so.)

    • CommentRowNumber93.
    • CommentAuthorTobyBartels
    • CommentTimeJan 24th 2011

    @ Andrew #91:

    Compare these three diagrams (shamelessly lifted from you):

    The horizontal arrows in the top diagram are the same size, which is too short; the horizontal arrows in the other diagrams stretch to fill the available space, which looks better.

    The all-SVG diagram also has properly stretched arrows, but the diagram in which only the arrows are SVG is like the top diagram above (although the arrows are at least a bit longer).

    • CommentRowNumber94.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 24th 2011

    Ah, now I understand. That’s to do with boxes. When typesetting diagrams as arrays (or matrices), each column is the width of its widest element, and the columns sit nicely next to each other. Since the arrows are in a column, they can’t encroach on the other columns so can’t stretch as you want. In the pure SVG diagram and the TikZ picture then the boxes aren’t placed into columns so this restriction doesn’t apply.

    However, whilst it looks nice to have the arrows stretch like that, it’s also a bit dangerous. The problem is that there’s not yet a way to say “Draw an arrow from the right-hand side of this box to the left-hand side of that box.”. That means that arrows have to be specified more precisely in terms of lengths. But until the picture is rendered, there’s no way to know exactly how big all the boxes are. So the more precise one tries to specify the arrow lengths, the more chance there is that it will render badly somewhere.

    One possibility would be to align the entries slightly differently. In Tom’s article, most of the diagrams are squares. So one could align the left-hand column a bit more to the right and the right-hand column a bit more to the left. That way, the defect in the arrows wouldn’t be so obvious.

    • CommentRowNumber95.
    • CommentAuthorTobyBartels
    • CommentTimeJan 25th 2011

    The problem is that there’s not yet a way to say “Draw an arrow from the right-hand side of this box to the left-hand side of that box.”.

    You mean that in SVG there’s no way to say that?

    • CommentRowNumber96.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 25th 2011

    I should be careful with what I say as I’m no expert. The problem comes in that one wants to mix SVG with MathML. Either one has to put the SVG in the MathML or the other way around. Either way, there are problems with what you would like.

    To embed SVG in MathML, we need to put the SVG in boxes, then stack those boxes in an array. This leads to the grid-like effect that I described above. To do it the other way around, we need to put the MathML in boxes and insert those boxes in the SVG. We can do that, and have much more flexibility about where they are placed, but we have to give explicit sizes to the boxes. Unfortunately, we can’t know the true size of those boxes until they are rendered so have to be careful about how closely we attach the arrows.

    • CommentRowNumber97.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 25th 2011

    I’ve fixed the diagram that wasn’t rendering. It seems that the included SVGs shouldn’t contain any newlines, which is a bit of a pain as it means I have to go back through the ones I’ve already uploaded and take out all those pesky newlines. However, it is now rendering.

    • CommentRowNumber98.
    • CommentAuthorTobyBartels
    • CommentTimeJan 25th 2011

    @ Andrew #46

    Ah, I see, thanks.

    • CommentRowNumber99.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 26th 2011

    Fixed a problem with the automatic numbering of theorem environments. Basically, starting a theorem-like environment with a list is a bit problematic so one needs to insert some garbage to separate the header from the list. I had been putting in <p></p>, but that messed things up even worse so I’ve reverted to putting in a &nbsp; instead.

    Still to do:

    1. The two non-commutative-diagram-like diagrams (the big colimit and the section)
    2. Centre labels on vertical and diagonal arrows
    3. Wiki-links!
    4. Anything else?

    What’s the consensus on the diagrams? As said in the discussion just above between Toby and myself, ideal diagrams (looking like the TikZ diagram) are not really possible yet unless done as inline images (which I hereby veto!), but if perfection is not possible, we can still produce something that is pretty close! I’ve converted all the “commutative diagram” type diagrams to the “matrix + SVG arrows” style. How’s that?

    • CommentRowNumber100.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 26th 2011

    I have a solution to the second of those, though it’s a little more complicated that I’d like (not a lot, though). You can see it at Leinster2010 Sandbox (doriath).

1 to 100 of 263

  1. <
  2. 1
  3. 2
  4. 3
  5. >