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.
In our displayed-math environments various “operators” (such as “\prod” “\coprod” and “\int”) are typeset in a fontsize that seems too large.
For instance “\coprod_i X_i” gives (in display-math style)
or “\int_x f(x)” gives
which in general seems excessive in vertical size.
Now for “\coprod” there is the alternative “\amalg”
which is more often the size one really wants. Of course there is also “\sqcup”
but it’s look is not so great for a general coproduct and also this is now getting too small.
My question really is: Do we have (in Instiki) an analogous alternative for “\prod” (as “\amalg” is for “\coprod”)?
I am aware of “\sqcap”
but I’d rather have the upside-down version of “\amalg”, instead. If it exists?
(I have stared at the list of Instiki symbols, but it’s hard to penetrate.)
I’ve always thought “\Pi_X”
was the pair of “\amalg”, but on here appears to be slanted…
Just out of historical curiosity, I’d be interested in knowing the ancient history of the symbol “” (\prod): Was it ever meant to be a nerdy shorthand for “roduct”, or did in not rather evolve out of cap/cup-notation?
I expect the latter is the case and that “-” and “-” types owe their existence to the typographical carelessness of early type theorist, who missed the opportunity to have beautifully dual - and -types (and avoiding the upcoming clash with actual linear sum types that become relevant in dependent linear type theory). But that’s just my guess.
One can use \textstyle to force the size to be appropriate, but this could be a little annoying to type each time. I agree that the default displaymode quantifiers are comically enormous; in my own papers, I usually use macros that I have defined to force the smaller ones, but I guess this isn’t immediately applicable to instiki.
One can use
\textstyleto force the size to be appropriate
Ah, thanks!! I didn’t know this.
this could be a little annoying to type each time.
True, but that’s worth it: a small one-time annoyance for one person compared to a perpetual visual annoyance for all readers passing by.
(Of course, best would be to adjust the default in the software setup. Hisham and myself are still looking for a software company to throw available funds at. Once we make progress on that front, such issues might eventually have a proper solution.)
I just typeset the formulas in #1 in TeX, and both signs are slightly smaller. MathJax’s output on MathOverflow looks exactly the same as TeX’s.
Therefore, these are mere artifacts of Instiki’s iTeX and will all be eliminated automatically once the nLab switches to a modern math renderer. Not sure if it is worth to adjust manually to a system that will eventually be gone anyway.
On the other hand, \amalg is very confusing when used instead of \coprod, since it looks like a binary coproduct (pushout) sign, and it takes time to see that it is not actually binary.
PS @Urs what kind of work are you trying to have done? Maintaining and improving the infrastructure of the nlab?
what kind of work are you trying to have done? Maintaining and improving the infrastructure of the nlab?
The technical team has been telling me that further maintaining and improving the nLab installation is practically out of the question, that we are essentially just keeping a leaking ship afloat, and that the only way forward, sustainably, is to start from scratch, either transferring the code base to another existing stable & maintained wiki platform, or to have dedicated software being rewritten from scratch.
For the longest time it seemed out of the question that we would have resources to do anything like this, but now through our CQTS research center here, we do happen to have substantial funds that should at least be in the ballpark of what is needed.
But now with those financial means in hand, we were so far unable to figure out how to actually proceed with spending them. The small software company that had helped us with the nLab installation in the past said that rewriting the system is too big a task for them. now we somehow need to find another company, but we are not sure how to go about this. (Where “we” is Hisham and me, while the nLab technical team seems to have no further input for us at this point.)
Gotcha, it sounds like a tricky situation but I’m glad to hear that you have some financial resources to move forward. I have been making a lot of progress on my own project for hypertext mathematics this month, but it remains a bit unclear to me whether such an architecture could meet the needs of the nlab. Happy to chat any time though.
Re #8: Presumably, the conversion could go as follows:
1) Switch from the nLab version of Instiki to MediaWiki, while retaining the custom nLab parsers for Maruku and iTeX, as well as the hooks for tikzpicture/xymatrix. The source code of all article remains completely intact, no conversion is required.
2) Replace Maruku with one of the standard parsers: either MediaWiki’s own parser for its syntax, or, alternatively, one of the standard Markdown parsers.
3) Replace iTeX with MathJax or KaTeX.
Part 1) is somewhat different from 2) and 3): it requires less programming, since the existing code can be reused, and does not require any changes to the source code of individual nLab articles.
Part 2) and 3) will require some programming and semi-automatic conversion of nLab’s syntax, altering the source code of articles.
On the other hand, parts 2) and 3) are much less urgent than part 1), since it is much easier to use the existing parsers in isolation, without the rest of Instiki.
We have seen that trying to do all of 1), 2), 3) at once did not go well. So perhaps it is better to do part 1) first, and then decide on 2) and 3)? The nice thing is that 1), 2), and 3) can all be done independently from each other, and not necessarily simultaneously.
I would go as far as to say that Part 1) can be done most effectively by a single person, or a very small company. It is quite easy to hire a freelancer in Eastern Europe for a very reasonable price, and looking at the various freelancer websites, I see lots of job offers that look similar to what we need: set up a MediaWiki system and customize it to the particular needs of a customer.
For what it’s worth, I would be happy to assist with finding a freelancer and/or communicating with him, acting as a liaison.
@jonsterling:
I have been making a lot of progress on my own project for hypertext mathematics this month, but it remains a bit unclear to me whether such an architecture could meet the needs of the nlab. Happy to chat any time though.
I don’t know (or maybe I forgot) of this project of yours. I’ll try to check it out and keep it in mind, but I guess transporting the nLab to any other existing platform is a task comparable to rewriting it from scratch and we will need to hire somebody for that.
@Dmitri:
For what it’s worth, I would be happy to assist with finding a freelancer and/or communicating with him, acting as a liaison.
Let’s talk about this jointly with Hisham!, if you don’t mind I’ll send an email cc-ed to both of you.
(Not before end of this month, though, as we are completely occupied with preparing and running another conference here.)
Re #11: Yes, of course.
re #4:
By trial-and-error I discovered that there are more such “style”-commands, which are useful:
(For example \displaystyle can be used to typeset “”, which otherwise comes out weirdly as “”.)
I never knew of these style-commands. Is there a list of them available online?
There are four commands listed on this page that I’m aware of.
Thanks. LaTeX is one thing, but here I am asking about the “Instiki” dialect that our poor nLab wiki is running with. This does not seem to support the further items in the list you point to.
This does not seem to support the further items in the list you point to.
It should have occurred to me my suggestion was slightly over-optimistic…
1 to 16 of 16