Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
I have incorporated Jonas’ comment into the text at pretopos, changing the definition to “a category that is both exact and extensive”, as this is sufficient to imply that it is both regular and coherent.
Just a terminological comment for the benefit of future readers:
in the Elephant, (pretopos)$=$(coherent,effective,positive). In pretopos, (pretopos)$=$(exact,extensive)$\Leftrightarrow$(ditto, with “coherent” added).
The discrepancy between “effective” and “exact” is terminological: “effective” is just Johnstone’s synonym for “exact” (cf. Elephant p.24)
This leaves the question whether (coherent,exact,positive)$\Leftrightarrow$(coherent,exact,extensive); this is true for the maximally-strong, terminological reason that (positive)$=$definitionally$=$(extensive). (cf e.g. here for more)
[ I shied away from making a footnote on this in pretopos, since to achieve a maximally-clear comment like “This is sometimes synonymously stated as “effective and positive” one has to know whether it is true in general that (effective,positive)$\Rightarrow$(coherent), as is true when “effective,positive” is replaced with “exact,extensive”; the latter I did not stop to to try to ascertain, in particular since “positive” seems to usually only be discussed for categories which are assumed to be coherent in the first place ]
It’s a bug we know about, see here. Hopefully Richard Williamson will be able to fix it.
Thank you very much for reporting this, Kevin. I have now fixed $\Pi W$-pretopos and hopefully $\Pi$-pretopos (if there were any occurrences of ’$\infty$-pretopos’ which genuinely referred to $\infty$-categories, these will now wrongly be $\Pi$-pretoposes as well, but I could not find any such occurrences). Please report any other occurrences of question marks and seemingly erroneous $\infty$-symbols that you come across!
Thanks for doing these fixes Richard!
The term “$\infty$-pretopos” is also used in the literature (at least, in the Elephant) for what we on the nLab call an infinitary (1-)pretopos. Apparently we didn’t mention that anywhere though! I’ve now added a note to pretopos.
Added conceptual completeness to Related concepts.
At infinitary coherent category we have remarked on the $\kappa$-ary version. Maybe we should use our terminology, and move the remark about the Elephant’s terminology to that page?
Sure, that’s fine. I feel that $\sigma$-topos is still a better name, though, than $\aleph_1$-ary pretopos (or $\aleph_1$-ary regular pretopos), even though it’s not systematic. It’s a special enough case that a special name (with echoes of $\sigma$-algebras) for it is useful.
We might have to agree to disagree on that one. (-: Are there interesting examples of $\sigma$-pretoposes that are not infinitary pretoposes?
The category of countable sets (in the presence of AC)? Probably something like countably-presented sets without AC
Is that category interesting for a reason other than being a $\sigma$-pretopos?
Not sure (-: I was wondering if there was some kind of computability-related category, or one that a particular type of quasi-finitist might be interested in. Or an arithmetic universe?
I note that Simpson and Streicher, Constructive toposes with countable sums as models of constructive set theory, https://doi.org/10.1016/j.apal.2012.01.013 prove a nontrivial result about $\sigma$-$\Pi$-pretoposes, relating them closely to a variant of CZF.
In particular they give the example of the ex/reg completion of the category of modest sets over the second Kleene algebra $K_2$ as having countable but not small sums (and in fact, is essentially small).
Hi Dmitri,
I have replaced the non-supported bibitem code with code that works here.
I get the impression that you add non-supported code not only by accident, but also intentionally?
(Maybe with the idea that it ought to be supported, and that one day it will be supported, and maybe with the idea of nudging its implementation by intentionally producing pages that remain broken otherwise? )
While I can see that this may make sense for internal development purposes, it seems wrong to do this on live pages, no?
Re #19: I only use the new syntax when I need to reference bibliography items within the page.
This is the only syntax I know, and I distinctly remember reading here on the nForum that it will be implemented. Indeed, \ref/\cite have been implemented for a long time, and \cite/\bibitem were mentioned in the same thread. \cite already appears to be partially implemented.
Is it so difficult to add a similar line of code for \bibitem?
Is it so difficult to add a similar line of code for \bibitem?
I don’t know. But it seems wrong to take innocent readers of our pages as hostages in this debate. All they see is a broken page.
This is the only syntax I know
The working syntax is explained at HowTo. I guess most people pick it up by a glance at source code examples.
To provide a reference with an anchor name do
* {#AuthorYear} Author, _Title_, Journal, Year (Links)
and then to cite it type
See [Author Year](#AuthorYear)
If you insist on proceeding this way, maybe you could add a note to the pages of the following content:
This page is broken intentionally, using syntax in its source code that seems desireable but is not currently supported by our software. We are desperately looking for more volunteers to help work on our code base. If you are bothered by this page not rendering properly, yet persuaded that it ought to and knowledgeable about programming and willing to lend a hand, then please contact our admin Richard Williamson, who will direct you on how to proceed.
If we could add these two lines (* {#…} and […](#…).) at least to the “Markdown+itex2MML formatting tips”, which show up on the right side when one is editing a page, this would go a long way in helping users remember them.
I am talking about this file: https://github.com/ncatlab/nlab/blob/master/app/views/markdown_table.html.erb
This does not require any programming.
Just a quick note (in haste!) that I worked on this yesterday, intending to complete the work on citations/referencing that I began some time ago. Something intervened which prevented me from finishing yesterday, but I should be able to do so over the next few days. The coming functionality is more comprehensive than just the bibitem aspect :-).
Re #19 etc: as announced here, this is now implemented.
1 to 26 of 26