MathJax support

[fgdorais]

Please enable MathJax everywhere it makes sense!

[cjlee112]

Yup, it's time to flip the switch. Presumably we should use the MathJax default delimiters, so as to be compatible with what people expect. And presumably we should convert arXiv titles and abstracts to use those delimiters (rather than just a single $) so they display MathJax equations too.

[fgdorais]

No! People expect $ for inline math. That is what is used everywhere. For display math $$ and [,] are both broadly used so this is more problematic. Since there is no preview mechanism, it is probably best to allow everything.

[cjlee112]

Are you saying the MathJax defaults don't fit mathematician's expectations? Maybe we should make the inline math display math delimiters a user configurable option. For people outside math, automatically treating any $ as inline math will make a big mess.

[mqlaql]

I don't think it's possible to use LaTeX in Google+. Deen Abiola created an extension to render MathJax in Google+, however, it doesn't produce flawless results.

I think your best bet is to use something supported natively by the browser. The only thing I can think of that social networks (and pretty much every international site) are going to be able to parse is Unicode. There are a couple of online websites that convert from LaTeX to Unicode. So basically the user writes a post taking advantage of a LaTeX -> Unicode conversor. That's the Google+ side. On the side of SelectedPapers, you take that and convert it back to LaTeX to parse it via MathJax as usual.

There are a couple of issues with this approach. Not every character in LaTeX has an equivalent Unicode character, so there you have a mild restriction. The other issue is that you have to provide a bookmark and/or extension to let users convert their posts into Unicode reliably.

As for delimiters recognized by MathJax, you don't want to use $ for inline math. That was a mistake according to the LaTeX people and they are trying to correct it by enforcing the use of [ ]. I think the main technical reason is that it's impossible to interpret correctly (via regex) a message using $ as delimiters for LaTeX and $ in other contexts.

[fgdorais]

MathJax defaults are built on sound design not on actual usage. All mathematicians expect $...$ to render math, most mathematicians don't even know (...) is a possibility even if its better design. So it depends on what you want to do: if you want to be more usable for mathematicians, you need to go with $...$; if you want to support better practice then go for (...). The MathJax Bookmarklet uses $...$ for inline math and [...] for display math and that seems to work well with practice.

[mqlaql]

Technical sound design must take precedence over convenience. Mathematicians will get used to using ( ) and [ ] in one minute.

[cjlee112]

I would be very hesitant about anything that messes with the user's content, e.g. changes LaTeX to some other encoding. We need to stick with standards (like LaTeX) and standard usages, because in a world of incompatibility that's all that can save us.

[sir-deenicus]

Per Google+ Chrome extension: Typically mathjax works once on all visible text. So (1) clicking 'read more', (2) writing a post or comment (3) editing a post or comment and (4) infinite scrolling / view new posts will all leave the latex unrendered. A simple solution to (1) also has a nice side effect in dealing with (2),(3) and (4).

I decided on adding a listen to clicks on spans which then triggers typesetting. This solves read more and also has the side effect that clicking the options menu to the top right of any post renders all accessible latex

It also listens for ctrl-shift keypresses which will then trigger a render of all visible latex, including those in a comment or posting box.

The problem of cut offs can't be avoided since G+ doesn't account for the possibility of texts with vastly differing heights. The only way round is line breaks and then a dot or whatever so the whitespace isn't trimmed. Also, editing a comment loses the latex and converts it to unicode so one must be wary of that (it does suggest a path from latex to unicode: write latex, ctrl+shift then ctrl+z). The upside of using unicode is every browser can easily read the math (as long as typesetting isn't overly complex) the downside is parsing unicode to latex is a non-trivial (for good coverage) nice to have, not key. Thus, I think it's better to leave the latex syntax as raw for those who are reading it on a social network without some sort of extension.

js is not my strong suit; the next thing I might try is to see if one can monitor ajax requests but that just makes too much sense to work easily =).

[cjlee112]

Given that Google+ does not currently support LaTeX (Google+ will not render $c^2=a^2+b^2$, no matter what delimiters you use), I would argue that we are starting from zero and get to choose an existing standard and stick with it. On the principle that people are going to learn how to use this just by copying what they see other people do (i.e. no one is going to "read the manual"), I think it would be a mistake to have different people using different, incompatible delimiters. So we have to choose between

• LaTeX default: $inlinemath$ [displaymath]. This obviously won't "play nice" in fields other than math.
• MathJax default: (inlinemath) [displaymath]
• other choices? What do other math-on-the-web sites use?

Clearly it would be nice if the standard we choose could also work (through some plugin?) within Google+ itself, and other social networks. (Bear in mind we need to be looking beyond just Google+...)

[fgdorais]

I pinged MathJax developers, I hope they will help out with the innards. In the mean time, I'll bring up the "devil's advocate" argument because someone has to do it eventually...

It's clear that redefining $ isn't nice to anyone who doesn't expect it but neither is using something other than $ for inline math, as far as mathematicians and others who use it regularly are concerned. How many $ actually do occur "in fields other than math"? Couldn't they learn to use \$ instead?

What do other math-on-the-web sites use?

MathOverflow uses $ and $$.

[cjlee112]

Great! Now if we set $ and $$ as the standard, I can tell everyone "the devil ('s advocate) made me do it!"

RE: MathJax, activating it on selectedpapers.net is trivial. The only thing holding this up is deciding what delimiters to set as our standard; MathJax will work with whatever delimiters we tell it.

[mqlaql]

@cjlee112 I would be equally hesitant but the issue here is that LaTeX, despite its popularity, is not a standard. Therefore we have to incur in some kind of conversion process.

As for Mathjax delimiters, as I said, there is a good reason the MathJax people chose (inlinemath) [displaymath] as default. Quoted from the documentation:

The default math delimiters are $$...$$ and [...] for displayed mathematics, and (...) for in-line mathematics. Note in particular that the $...$ in-line delimiters are not used by default. That is because dollar signs appear too often in non-mathematical settings, which could cause some text to be treated as mathematics unexpectedly. For example, with single-dollar delimiters, ”... the cost is $2.50 for the first one, and $2.00 for each additional one ...” would cause the phrase “2.50 for the first one, and” to be treated as mathematics since it falls between dollar signs. For this reason, if you want to use single-dollars for in-line math mode, you must enable that explicitly in your configuration`

So, unless you want to ban economics research, (inlinemath) [displaymath] is the best choice.

@sir-deenicus I think that the implementation of a good coverage is trivial because it's basically a list of tuples, however, as you said, the problem is getting a good coverage. An additional problem is that Unicode can be hard to read depending on the symbols used.

Leaving the raw LaTeX obviously is the simplest route but that defeats the whole purpose of a Google+ integration. Why would you bother to go to Google+ when it is not humanly possible to read slightly complex LaTeX without a proper rendering. If that's the best we can do, I suggest to do the whole process in reverse:

1. Users go to SelectedPapers.net
2. They write their reviews with the right tools (formatting, images, LaTeX)
3. We push the updates to their social network, but without the whole content, just a text snippet as a notification to let other people know that new activity exists in the site.
4. Further activity on social networks is fetched and displayed in the appropriate paper.

[pkra]

Hi, I'm part of the MathJax team (thanks to @fgdorais for the ping). First of all, how can we help?

Second, some personal thoughts on the discussion so far -- feel free to ignore them.

The support for regular text markup is pretty abysmal on social networks and mathematical markup (say via a web standard such as MathML) is unheard of -- which is why TeX syntax is used so often.

$ vs \( ...\) is, simply put, an impossible choice. LaTeX users (not just mathematicians) are very much used to $ despite the fact that $ is formally deprecated even in LaTeX. \(...\) has never gained traction.

As a MathJax delimiter, $ is used on most user-driven sites such as MathOverflow, physicsforum, math.stackexchange and other MathJax-enabled stackexchange sites (though some SE-sites use other delimiters). For a discussion on deprecating $ in iPython check out this thread. Another point in favor for $ is that the arXiv, of course, allows TeX in the abstracts, e.g. here.

Some ways around this problem. pandoc-markdown only considers $+space etc a math delimiter. This solves the major problem of $2.50. Another one would be to use different MathJax configurations, e.g., arXiv papers probably indicate that TeX behavior is expected.

[fgdorais]

Always good to see you @pkra! Not sure this is possible here but this Pandoc option is pretty reasonable:

Anything between two $ characters will be treated as TeX math. The opening $ must have a character immediately to its right, while the closing $ must have a character immediately to its left. Thus, $20,000 and $30,000 won’t parse as math. If for some reason you need to enclose text in literal $ characters, backslash-escape them and they won’t be treated as math delimiters.

@mqlaql: Many economists regularly use LaTeX and they don't have much of an issue with using $ as a math delimiter. (Of course, dollar signs simply don't occur that often in economics research.)

[pkra]

Yes, I had thought about mentioning this elegant rule in pandoc. I'm actually not sure how to do something similar in a MathJax configuration but a pre-processor extension for MathJax could do it. But arXiv abstracts won't follow this rule.

[cjlee112]

Thanks for the really helpful comments. A few thoughts:

• if all the main math websites are using $inlinemath$ I think it would be more painful to go against that tide than to go with it. Indeed, I see people typing LaTeX already in selectedpapers.net comments, and they're all using $.
• for the moment, I'm going to restrict myself to the question of how selectedpapers.net should display content. This is extremely flexible; that is, the server can convert individual pieces of content either in on the fly or as a separate batch job. The only real challenge for us is to know the "encoding" of each piece of content (i.e. do $ mean inline math?).
• it seems to me that users will divide in two groups: people who use $ for inline math; vs. people who never heard of latex. So we can assume the "encoding" will be the same for all posts from a given person. That makes it pretty manageable: worst case scenario, give the user a settable option to render $ as inlinemath, vs. not.
• arXiv abstracts again must be treated as $inlinemath$, but not other abstract sources (e.g. Pubmed). Again this seems perfectly manageable.

Note this doesn't at all address the question of whether it's feasible to render $inlinemath$ on Google+ itself. As far as I'm concerned, if not, that's just another reason why users are better off viewing this content on selectedpapers.net. The cultural reality is, people are merrily typing $inlinemath$ on G+ regardless, and we are hardly in a position to stop them!

[cjlee112]

@pkra here's another question: how do most MathJax driven sites deal with the possibility that users include < (less than), > (greater than) or & in their post? I'm wondering whether G+ already html-escapes those characters if a user types them in a post; seems like G+ would do that, to render the content safe to render in a web page. We'll have to check that.

[cjlee112]

Decision time: I propose activating MathJax now with support for the following delimiters

• [displaymath] and $$displaymath$$ (MathJax default)
• (inlinemath) and $inlinemath$

I guess you could call this the liberal option: should work for most people without them having to think about it. This would support the traditional usage, while also working with the "recommended usage".

• To begin with, this would just apply to all content on selectedpapers.net, except DOI and Pubmed content.
• Later we can improve the default handling (e.g. pandoc rule described above), and add a user option to NOT render $ as inlinemath in that user's posts.

[mqlaql]

@fgdorais Sure, they don't have problems with it since they are not in change of LaTeX, MathJax or maintaining systems.

@cjlee112

if all the main math websites are using $inlinemath$ I think it would be more painful to go against that tide than to go with it. Indeed, I see people typing LaTeX already in selectedpapers.net comments, and they're all using $.

Actually, the tide is going in a different direction. $ is deprecated. Why make the same mistake that others have done? For example, watch this.

[johncarlosbaez]

Chris writes:

I propose activating MathJax now with support for the following delimiters

[displaymath] and $$displaymath$$ (MathJax default) (inlinemath) and $inlinemath$

I guess you could call this the liberal option: should work for most people without them having to think about it. > This would support the traditional usage, while also working with the "recommended usage".

I like the idea of having things work for most people, so this sounds good to me if it's not too problematic. What will happen when someone says that a math book costs $5? How badly will the system behave?

If both work, we can slowly try to move mathematicians in the direction of ( ) and [ ].

For those not up on these issues:

Many mathematicians, especially old fogeys, use $ $ for inline equations and $$ $$ for displayed equations, even though this is bad for three reasons:

1. In each case the ending symbol is the same as the beginning symbol, so leaving out one $ or $$, or putting an extra in by mistake, means that a big bunch of text is interpreted as if it were math when it shouldn't be, or vice versa. It's as if mathematicians wrote 2)x + 3) instead of 2(x + 3), making it impossible to automatically match right and left parentheses!
2. The beginning and end symbol in $ $ is a substring of $$, which causes further problems.
3. People who aren't writing in TeX often use $ to mean 'dollars', so you have to know if something is TeX or not to interpret it correctly.

All these are fixed by using ( ) for inline equations and [ ] for displayed equations. And that's what MathJaX does. But we should make things easy for everyone, as long as it doesn't cause big problems.

[mqlaql]

@johncarlosbaez Well, it will cause problems. What kind of problem depends on your input. Common scenarios are the following:

1. It won't recognize the dollar sign as a currency so it will display regular text as equations.
2. It won't compile the equation.
3. It will remove one dollar sign.

But in general this is a bit unpredictable.

[sir-deenicus]

@mqlaql

Users go to SelectedPapers.net

The key point of the project is that it tries to make an end run round why most projects like it fail by minimizing friction of interaction. It goes where people already are. If instead, people go through it as a central location then a whole bunch of design decisions don't make sense and its unique selling point disappears

We push the updates to their social network, but without the whole content, just a text snippet as a notification to let other people know that new activity exists in the site.

The main social network used by technical people to talk about technical things does not allow writing/push. It has some totally not useful private moments concept.

[mqlaql]

@sir-deenicus You're right! I thought the Google+ API was mature enough to allow posting, updating, etc. However, I found something called App Activities:

After the user signs in using the Google+ Sign-In button, you can write app activities to Google on behalf of your user with the moments methods. App activities reflect a variety of user actions including check-ins, reviews, commenting on articles, and more. Users control the visibility of their app activities on Google using circles. Your app can use the type of activity that best reflects your content or the user's action.

However, I'm not sure what it looks like. The 'review' part sounds interesting, though.

Regarding your first point, yes, I know that is the original idea but it is already causing many problems. At the end, I don't think it's technically feasible to create a good integration with Google+, let alone Twitter, Wordpress, etc. In any case, minimizing friction shouldn't guide design decisions. The idea should be build something that provides value to researchers and then worry about friction. Otherwise, you end up with bad user experience such as lack of LaTeX support, an extremely minimalist text editor, no preview, synchronization issues, restrictions in the API, etc. I think the main selling point should be "Look, this is an amazing site where you can find reviews and commentary on scientific literature." No one is going to complain that they have to type another url.

[cjlee112]

@johncarlosbaez Over time I think we can protect against $ problems in several ways:

• note first that when displaying several posts / replies on one page, we do not have to apply a single policy to all of them. For the purposes of this discussion let's say the spnet server analyzes each post separately;
• even if the encoding of a post is supposed to be $inlinemath$, if it contains an odd number of unescaped $, it clearly contains a user error, so we'll handle it carefully. Worst case we display that one post without converting the $ expressions (we can still render the displaymath), and send the user a notification to fix their post. Note that even if we only allowed (inlinemath), we would STILL face this problem (i.e. people will forget or mistype their delimiters occasionally).
• Various rules can help, e.g. the pandoc rule for detecting inline math (described by @fgdorais above) requires that the closing $ be preceded by a non-whitespace character, so "it costs $5 for 5 minutes and $15 for the full half hour" won't get interpreted as inline math.
• as I mentioned in a previous comment, we can probably avoid most of these interpretation problems by distinguishing types of users and content. E.g. for abstracts, only arXiv content can contain latex. For users, either a user is a mathematician who uses $inlinemath$ in their posts, or they are from some other field and never use $inlinemath$. We can infer those defaults for a given user based on their activity or tags, or let them set it up front.

[cjlee112]

the unfortunate reality is that rendering LaTeX (even with just (...) ) makes our job harder, because we can no longer just let the browser deal with how to render users' content. (Because G+ only allows flat text, we can safely treat it that way, in the absence of LaTeX). Users can mistype or forget the close tags ) or ], potentially causing the entire rest of the page to get mis-rendered. Our server will therefore have to check each post for such errors. And when we detect them, we'll have to handle them gracefully. @pkra how does MathJax handle these cases? Am I right in thinking we can't just leave all these problems to MathJax to solve?

[pkra]

Oops, so many new comments -- that's what I get for being stuck in a different time zone...

• re >, < etc: the sites' chosen input method escape those. MathJax works either way (it's very tolerant in general).
• re the proposed delimiters: imho, they make sense, especially for papers from the arXiv.
• re unmatched delimiters: MathJax does a pretty good job on its own. First of all, MathJax will stop parsing at HTML elements and unmatched delimiters are simply ignored. Accordingly, HTML elements within math delimiters will stop the parser -- e.g. <span>$</span> will be ignored, as will \( f \circ <br> g\) . This can be a different problem when an input mechanism adds things like <br> to an array. Of course, if, for example, there are two inline math expressions within an HTML element, and the first expression is missing its closing $, then MathJax will use the opening $ of the second element and ignore the last $.
• a general comment: if spnet wants some independence from MathJax // javascript (e.g. in rss feeds), then you could consider converting TeX to MathML on the server. Not that this will help much right now, since only Firefox has a decent implementation and most sites sanitize it to oblivion, but philosophically, that's the right web standard to use. Most conversion tools leave the TeX as annotations (and the next MathJax version will expose those better).
• @mqlaql as much as I sympathize, in my experience the "$ is deprecated"-argument just doesn't work (as iPython shows -- they haven't deprecated it so far). The problem is probably that the LaTeX folks can't really enforce it. The question is: how do we get people to adopt something other than $? I think eventually a combined effort of iPython, R-studio, MO, math.SE, and spnet could change that for math on the web. (imho, we need a better delimiter -- \[...\] (on a US-keyboard) is smooth to enter, \(...\)is quite rough.)

[loopspace]

I'd like to pick up on Peter's fourth comment. There is a way to get the best of both worlds on this. The server converts the TeX-like syntax to MathML (and caches the result). Anything that can cope with MathML can then get the raw MathML, anything else gets served the MathML with MathJaX as an interpreter. This is how the nLab and nForum serve up mathematics. Those sites show, I think, that people do quickly get used to how things work.

Server-side conversion has a whole slew of benefits involving better error-checking and better speed. Moreover, by using MathML you make your site accessible which is no bad thing. MathML support in browsers is growing, and growing fast. But even browsers that can't cope with it natively can use MathJaX to convert MathML to HTML+CSS. That conversion is far more reliable than the TeX conversion and is far faster.

(If you do go down the pure MathJaX route, I'll add my vote against dollars. The LaTeX folks can't impose the parenthesis method simply because that's not how LaTeX works. But my guess is that the people who will tend to use the selected papers network will be those who are a little more technologically savvy and find it a little easier to do "new things" rather than just cut and paste stuff from one article to the next.)

[pkra]

This is getting a bit off-topic but two comments.

As much as I'd like it be different, native browser MathML development is not picking up (e.g., Chrome & Opera abandoning their limited support). All direct development in Firefox and WebKit so far has been done by unpaid volunteers and there's nobody actively working on native browser support -- except one of our developers, on a small scale. (On the bright side, we're working to make that a much larger scale.)

Also, MathML isn't really more accessible. There are only two actively maintained accessibility tools supporting MathML -- MathPlayer and ChromeVox -- both of which support MathJax output. (Whether MathML is actually enough for generating aural representations is another matter of debate among specialists.)

Of course, I'd still suggest to consider MathML conversion; if not now, at least keep it in mind in design decisions.

[loopspace]

The consistent message that I get from the blindmath mailing list is that MathML is the best technology for making mathematics as accessible as possible, whilst acknowledging that that might not be as good as it could be.

Nonetheless, do you see any disadvantage to server-side MathML with client-side MathJaX where needed?

[pkra]

From a MathJax-output point of view, there aren't many disadvantages; both MathML and TeX input has its disadvantages. For the spnet development, the question is probably if server-side conversion is realistic. It will add dependencies, require development time etc

(re:a11y yes, that's a statement I've heard as well but recently with more and more caveats.)

[loopspace]

I like that: "both MathML and TeX input has its disadvantages"! So what is the best input for MathJaX, then?

I suppose that for spnet the question is as to how much is going to be slurped from elsewhere and how much is going to be "home grown". If slurped, then I don't really see how this is solvable. If I can add my website to what spnet slurps (since that's where I record all my comments, and I have no intention of changing that) then it'll have to adapt to what my website produces and given the number of possibilities around the internet that seems an impossible task. On the other hand, if spnet's content is meant to be "home grown" then it can impose its own rules, and server-side conversion is now a solved problem so there shouldn't be any real difficulty in implementing it.

It is interesting to read the discussions on the blindmath mailing list. My rough impression is that the established mathematicians want raw TeX and the newcomers (students, school kids, etc) want MathML - or at least, they don't know what they want but MathML is what is generally recommended to them.

I will accept that MathML is not perfect. But it is the best thing going, particularly as it is an open standard (unlike TeX!). It's acceptance is chicken-and-egg. Until it is widely adopted, browser support will lag. But until browser support increases, it is hard to get it adopted. That's where I see the great strength of MathJaX: as a way around that roadblock.

[cjlee112]

@loopspace You've stated the core issue very clearly. The spnet philosophy is "slurpy", that is, we are trying to integrate what people are saying from many sources (e.g. on your weblog) by adding a bit of tagging to identify what they are talking about. Precisely as you said, you are happy writing your posts on your site, so why should you have to change that? Since Google+ restricts posts to flat text, which is highly portable, we can display Google+ posts easily on selectedpapers.net pages. The opposite end of the spectrum would be some kind of page format that we have no way (yet) to "sanitize". In that case our worst case scenario is to just index its tags and title (and possibly its first few sentences, stripped to flat text) and display that on selectedpapers.net with a link to the original page. Sorry to go a bit off-topic, but I wanted to answer your question.

[cjlee112]

@pkra Thanks for your very helpful comments! Sounds like we can just let MathJax handle the delimiter error cases, at least for the moment. Out of curiosity, is it likely MathJax might enforce the "pandoc rule" that the closing $ must be preceded by a non-whitespace character?

[pkra]

@cjlee112 no, we wouldn't enforce anything like that -- that would break a lot of content such as MathSciNet, Oxford Journals, MathOverflow, physicsforums, countless blogs and personal sites...

I don't think whitespaces can be used as MathJax delimiters out of the box. But it should be possible to write an extension that enforces this (MathJax is highly modular).

Then again, if "slurping" is the strategy (which, imho, is great), then a heuristic might be better. Or checking out the head of a page to look for a MathJax configuration.

Before I forget it: you probably want to enable the Safe extension when you're using MathJax with user-generated content.

[mqlaql]

@pkra I think Ipython will deprecate $ most likely in version 1.0. Responding to your question:

The question is: how do we get people to adopt something other than $

By letting them know they should use [ ] and ( ) instead of $.

I agree on the fact that MathML enjoys a dismal browser support right now. Just take at look at caniuse. Furthermore, even the MathJax rendering of MathML doesn't look as good as the HTML/CSS rendering.

@cjlee112 wrote:

even if the encoding of a post is supposed to be $inlinemath$, if it contains an odd number of unescaped $, it clearly contains a user error, so we'll handle it carefully. Worst case we display that one post without converting the $ expressions (we can still render the displaymath), and send the user a notification to fix their post. Note that even if we only allowed (inlinemath), we would STILL face this problem (i.e. people will forget or mistype their delimiters occasionally).

It's possible to know if there is an error using a stack. However, it doesn't mean you're going to be able to handle it. Certainly not with regex. In case of user error, you let it go. This is another situation in which creating reviews in SelectedPapers would be far better because you could offer a preview of the review to be posted.

Precisely as you said, you are happy writing your posts on your site, so why should you have to change that?

Maybe because most people are not happy writing long technical stuff in Google+.

[fgdorais]

@pkra I think a pandoc-style extension to MathJax would be highly desirable. It would be super handy for tools like the MathJax Bookmarklet and GmailTeX!

[cjlee112]

@mqlaql I think @loopspace writes posts on his own blog, not on Google+. RE: preview capability, I definitely agree this would be fantastic. I just noticed the G+ Web interactive post docs added a JS call for creating an interactive post button. I want to experiment to see if that will let us create posts dynamically (rather than the post content being fixed permanently at page load). If so we gain all sorts of flexibility, basically because we can offer our own interfaces for writing posts etc. and the G+ dialog just becomes a rubber-stamp "confirm and send" step. FYI here's the new call documentation: https://developers.google.com/+/web/share/interactive#gapi.interactivepost.render

Note that even without this we could in principle have our own post submission form, but it would require one extra page-reload-and-click step:

• write your post on our form, submit it;
• see a preview, if you're happy, click Post button; (this is the extra step that would become unnecessary if the JS call can create interactive post button dynamically).
• annoying Google+ dialog comes up, you enter Public as the recipient, and click Share.

RE: handling inlinemath delimiter problems, I was not thinking to handle this with regexp, more like a computationally cheap Hidden Markov Model (ie. sum integer log-odds score, for competing models)

[cjlee112]

@pkra thanks for pointing out the Safe configuration setting!

[cjlee112]

@sir-deenicus @mqlaql: I agree, App Activities seem like nonsense designed for advertisers to flog products by pushing stupid "events" ("I arrived at the wonderful hotel!") into G+ users' streams, rather than useful for G+ users themselves (i.e. us). In my brief attempt to figure out what in heck App Activities actually do, I couldn't find anything we could use.

[mqlaql]

@cjlee112 Right. Wordpress is far more suitable for long-form writings. However, fetching from blogs is more complicated. It also reduces the number of active users.

I don't think interactive posts allows to create interfaces for writing posts. Currently, it seems to add a "Call to action" button for different actions such as promoting something. App Activities seems to be in development but it doesn't look so promising-

The 3 step process you outlined seems fairly painless to me. It's basically the same procedure that is used to share on Twitter from external sites.

Never heard about a HMM's application on nested delimiters. It would be interesting although a parser is the common solution and it's not so cheap.

[loopspace]

Yes, I post on my own ... well, actually it's a wiki. I currently have 304 papers listed there. Most just have basic bibliographic data and a few categories (sort of like tags) but every now and then I'll make some more comments. A quick look at file sizes shows that the one I've made the most comments on is: http://ncatlab.org/lspace/show/A%20convenient%20setting%20for%20differential%20geometry%20and%20global%20analysis. I'd be quite happy to add some link to that page to the SPN and allow that content to appear on the SPN. But I'd rather not have to paste it into a G+ post, or really I'd rather not have to paste it anywhere else. If you could figure a way that I could add a link to that page whereupon I (or anyone else) could click it and post it to SPN then I'd add it in an instant.

[cjlee112]

@loopspace We want the indexing to be automatic, i.e. just give it an RSS URL and it will scan for paper IDs. In principle, for old posts this could be just looking for an arXiv ID of the form arXiv:1234.5678 (or old-style arXiv ID), so you would not have to retag posts "spnetwork". That is issue #17.

[cjlee112]

I implemented the proposal (default MathJax plus $inlinemath$ allowed, Safe mode) and was immediately disappointed:

• arXiv abstracts are totally inconsistent: some use $, others strip them out (so there is no delimiter marking the inlinemath at all)!
• the second arXiv paper I looked at (arXiv:1305.6100) had an error that made it look awful: the author left out the starting $ on one of his equations, then MathJax got out of sync and interpreted much of the remaining text as inline math (forcing it into a single line running right off the edge of the window, so you lose much of the abstract). The horror, the horror.

I thought user comments would be the main source of trouble but it turns out that arXiv content is worse!

I am tempted to deploy this with a big message on the homepage (linked to this example) saying this is why $inlinemath$ must die:

• people make mistakes;
• computers must be able to detect and handle those mistakes sanely. $inlinemath$ makes that impossible, for the same reason that you wouldn't replace all the parentheses (...) in your equations with $...$ (you wouldn't be able to tell whether $ means open or close; similarly, a computer can't tell whether $ means start-inlinemath or stop-inlinemath, because it can't tell the difference between math vs. text -- that's why it needed a delimiter in the first place!)

[cjlee112]

In the face of inconsistent usage of $inlinemath$, it seems to me we should give people fine-grained control:

• we would recommend the MathJax default, i.e. (inlinemath) [displaymath]. Those delimiters will work everywhere.
• for arXiv abstracts, give people a checkbox "show $inlinemath$". $ would only be treated as inlinemath if the box is checked. Furthermore, we can "crowdsource" the default by keeping a count (in the database) of how many times people clicked to turn this ON vs. OFF (then set the default based on which count is bigger).
• for user comments, give each user a checkbox "treat $ as inlinemath in my posts". Give them a "big red warning label" saying they really should use (...) and that if they screw up their $, their post will look like crap.

The way this would be actually implemented would be by using the default MathJax settings, and if requested convert an individual piece of content (e.g. an abstract or post) to replace $foo$ with (foo) so that MathJax will treat it as inlinemath. We can also try to follow the pandoc rule mentioned in previous comments. If the count of unescaped $ in that text is odd, don't do the conversion at all, and stick in a warning message.

[johncarlosbaez]

Chris wrote:

arXiv abstracts are totally inconsistent: some use $, others strip them out (so there is no delimiter marking the inlinemath at all)!

People should not be using TeX in arXiv abstracts, since the arXiv doesn't render the TeX when displaying the abstracts. However, people are lazy, stupid and optimistic, so many simply grab the TeX from the abstract in their paper and slap it onto the arXiv.

Given all this, if there's a way to avoid using MathJax on arXiv abstracts, that would be good.

[pkra]

I really, really like the proposal, @cjlee112 . I think opt-ins are a great way for people to vote with their feet.

I differ from @johncarlosbaez in that I would love to see mathematics in arXiv abstracts (but I know that the arXiv is a bit slow in development due to limited resources); as a comparison, MathSciNet is a great example for TeX+MathJax.

[mqlaql]

@cjlee112 It seems to me that is a reasonable solution. However, it's also a good amount of work and adds to the overall complexity of this project. I suggest to display Arxiv abstracts without LaTeX rendering for the time being. We can make an effort to correct malformed LaTeX later on.

[johncarlosbaez]

pkra wrote:

I differ from @johncarlosbaez in that I would love to see mathematics in arXiv abstracts [...]

I too would love to see mathematics in arXiv abstracts. My point is simply that currently, the only people who include TeX in arXiv abstracts are clueless newbies who haven't noticed that TeX doesn't get rendered in the abstracts as they appear on the arXiv. Clueless newbies are precisely the kind of people who fuck things up! This is why Chris Lee found the TeX on arXiv abstracts to be "totally inconsistent".

In a future world, TeX will be rendered on the arXiv abstracts, people will learn how to use that feature correctly, and Chris won't scream "the horror, the horror" when he see what they do.

But for now we are stuck in the present, in a world where the little TeX that appears on arXiv abstracts is a mess.

[pkra]

@johncarlosbaez agreed! (sorry for my clunky formulation -- not used to disagreeing with you ;) )

[cjlee112]

@pkra If we want to change page content dynamically (AJAX), is there a way to get MathJax to rescan the content on the page, to properly display the new content?