Extension talk:Math/Roadmap

Some comments from mathematics content contributors

User:Jdforrester (WMF)‎ seemed to think it signficant that no content contributors had commented on this page. Accordingly, I'm posting a personal summary of a discussion at en:Wikipedia_talk:WikiProject_Mathematics#A_challenge_from_Jimbo_Wales which addresses issues that might be considered relevant. There are links to several other discussions on related topics at that page for the interested reader. Deltahedron (talk) 17:24, 21 June 2014 (UTC)

@Deltahedron: OK, well done for copy-pasting, but where's the consensus between wikis? Jdforrester (WMF) (talk) 16:03, 23 June 2014 (UTC)

Since you ask, I invited participants at French and German language equivalents and you will see that there were contributions from participants at both. I made, and make, no claims that this is a cross-wiki consensus: it is the summary of a discussion. If it is important to obtain that, then WMF community advocate staff could help you. Deltahedron (talk) 17:30, 23 June 2014 (UTC)

Summary of discussion

Background

About 1% of Wikipedia's 4.5 million articles are assessed as being in "Mathematics and Logic". Probably a similar number are in theoretical physics and in computer science. So in about a hundred thousand articles, the ability to render mathematics is indispensible to the reader: the ability to write and edit mathematics is indispensible to the author and editor.

Currently the predominant mathematics markup system in all forms of document preparation is some flavour of LaTeX. It may be presumed that any serious mathematics content contributor will be thoroughly familiar with LaTeX. LaTeX is rendered on web pages in a variety of ways: currently Wikipedia uses two of the more popular methods, rendering formulae as PNG images and rendering dynamically using MathJax. There are deficiencies in the current implementation of each of these methods.

The stability and usefulness of current mathematics rendering is reduced by the following

• Incremental development of reader and editor interfaces is apt to degrade the reader or editor experience without warning.
• Major changes in editor interfaces, such as the introduction of Wikipedia:VisualEditor and Wikipedia:Flow, may be radically incompatible with existing LaTeX markup practices.
• Effort to support mathematics editing and rendering comes entirely from the volunteer community. Currently one volunteer is working on mathematics rendering, and support for mathematics editing in VE consisted of one GSoC summer volunteer.

WMF planning

We are reliably informed that WMF has no plans for development of mathematics rendering and editing. That is, there is no plan to coordinate volunteer effort; no plan to integrate volunteer effort into existing products; no plan to ensure the sustainability of mathematics rendering and editing through major changes to the software and user interface.

As a consequence of the lack of plans, there is no allocation of WMF developer effort to the maintenance, sustainability or enhancement of mathematics rendering and editing. It is assumed that volunteer developers will undertake any tasks that are necessary, even though there is no plan to coordinate those efforts.

It is reasonable to say that there is considerable expertise and experience in mathematics rendering and editing in the existing editor communities. There is no explicit mechanism to capture that experience and make use of it in planning, development or review. Such efforts as have been made to do so are limited in extent and driven by the user community rather than WMF. The role of Community Advocates in linking the editor community and WMF planning and developers in this context has not been effective.

Suggestions

• General

1. WMF planning address the issue of development of mathematics and other complex rendering markup and editing components.
2. WMF liaise actively and effectively with existing editor and reader communities in (1).
3. WMF draw up roadmap for development of complex rendering and editing.
4. WMF liaise actively and effectively with volunteer developer communities to determine required frameworks and work packages.
5. WMF allocate funds and resources to support work packages.

• Specific

1. Mathematics rendering to be based on MathJax as principal vehicle, with efficiency and resources issues resolved on a wide variety of platforms.
2. LaTeX markup retained as principal mode of editing mathematics text with concomitant option to directly edit at the wikitext markup level.
3. WMF establish a workflow for further development and deployment of the math extension, using the https://www.mediawiki.org/wiki/Extension:Math/Roadmap page to coordinate the development process.
4. WMF designate a fixed contact person at WMF that cares about math related questions and a brief to maintain regular and frequent contact with volunteer community.

• Short-term

1. Fix MathSource mode is currently disabled: see [1] which resolves this issue.
2. Fix issues with experimental mathoid (MathML + SVG) support on the Beta Cluster.

discussion about texvccheck and texvc

Log of a private IRC discussion between cscott and physikerwelt on 25th July 2014

(01:17:16 PM) physikerwelt: Hi, sorry but I have doubts to change texvc. Maybe you can convince someone else to merge your changes.
(01:17:16 PM) cscott <AUTO-REPLY> :  I'm not here right now
(04:39:04 PM) physikerwelt: I told the full story on github
(04:39:29 PM) physikerwelt: so if you find time to further work on that it might be helpful
(04:40:37 PM) cscott: did you mean 'gerrit' rather than 'github'?  i'm confused.
(04:41:38 PM) cscott: i think that gwicke does indeed want to use texvcjs for mathoid.  it should already be 'good enough', i've tested it against texvccheck pretty extensively.
(04:41:49 PM) physikerwelt: https://github.com/cscott/texvcjs/issues/1
(04:42:25 PM) physikerwelt: did you find this page?
(04:42:27 PM) physikerwelt: http://www.formulasearchengine.com/Verify%20texvc%20light
(04:47:46 PM) cscott: i think first I would like to import the test cases from [[mw:MathTest]]
(04:52:46 PM) cscott: wFormula-nocount.txt is very interesting, though!
(04:53:24 PM) physikerwelt: Maybe I heard to many talks about automated theorem proofing, but I think it's strange to modify texvc and whatever other syntax at the same time, if the goal is to reproduce the current behavior
(04:54:02 PM) physikerwelt: yes but that's definitly the second step. I think starting the the testpage makes more sense
(04:54:09 PM) cscott: i don't think the goal is to reproduce the current behavior.  i think the goal is to document and test *correct* behavior.
(04:55:00 PM) cscott: verifying that the algorithm is idempotent is an important part to ensuring that texvc isn't destroying/corrupting the input.
(04:55:27 PM) cscott: there are a number of bugs in texvc, i have no intention of duplicating those.
(04:56:25 PM) physikerwelt: that's the reason why I stopped with the php port
(04:57:34 PM) physikerwelt: if texvccheck is idempotent we can pass the output to texvc
(04:57:55 PM) cscott: right, but we need to patch texvc in order to do that. ;)
(04:58:00 PM) physikerwelt: the fact that it's currently not idempotent prevents us from ding that
(04:58:02 PM) cscott: since texvc (for example) won't accept 
(04:58:09 PM) cscott: \mbox{\coppa}
(04:58:13 PM) physikerwelt: I know that
(04:59:09 PM) physikerwelt: but once we did the input check with texvccheck we don't need most parts of texvc
(04:59:12 PM) cscott: i understand that changing the output of texvc, even in trivial ways, causes issues for production.  but i don't think the solution is to never change texvc's output.
(04:59:38 PM) physikerwelt: I think the solution is to get rid of texvc\
(04:59:50 PM) cscott: well, that's quite possible.
(05:00:27 PM) physikerwelt: even today there is no need for texvc
(05:00:48 PM) physikerwelt: mathoid could also generate png images for IE<9
(05:01:53 PM) physikerwelt: and texvcjs can be integrated to mathoid easily
(05:04:00 PM) physikerwelt: to speed up the process we could merge the changes to texvccheck verify that against texvcjs and change texvc only once in the end if we really want to
(05:05:10 PM) physikerwelt: changes in texvccheck have almost no influence on production. Only if texvccheck rejects input that was accepted by texvc this will cause a change
(05:05:50 PM) physikerwelt: but this won't produce significant server load since texvc would not be called
(05:06:46 PM) physikerwelt: for example the input <math>\color</math> that might exist somewhere would be a syntax error afterwards
(05:07:39 PM) cscott: i'd be surprised if i don't find a few such issues in en-wiki-formulae
(05:08:01 PM) physikerwelt: You'll find a few. But only a few
(05:14:43 PM) physikerwelt: I'd like to merge the changes for texvccheck i.e. https://gerrit.wikimedia.org/r/#/c/149097/5/texvccheck/texutil.ml  https://gerrit.wikimedia.org/r/#/c/148677/8/texvccheck/lexer.mll https://gerrit.wikimedia.org/r/#/c/148677/8/texvccheck/texutil.ml https://gerrit.wikimedia.org/r/#/c/148677/8/tests/MathInputCheckTexvcTest.php
(05:15:04 PM) physikerwelt: those changes are save to merge without ops interaction
(05:20:33 PM) physikerwelt: are you open to change them separate or would you prefere to keep that in sink with texvc
(05:21:04 PM) cscott: well, it's certainly harder to keep track of which changes i've only applied to one or the other if they are separate patches
(05:21:42 PM) cscott: but i can probably manage; there aren't that many changes after all.
(05:21:55 PM) physikerwelt: I can keep track of them;-)
(05:22:08 PM) cscott: it would help if we could start a separate branch for the 'fixed texvc', so that we could commit corresponding patches to texvc on that branch at the same time
(05:23:28 PM) physikerwelt: I've been spending a significant amount of time on reorganizing changes for the math extension in the last year so that is just a very minor issue
(05:23:44 PM) physikerwelt: yes I like the idea of a new branch
(05:24:26 PM) physikerwelt: however, I had the feeling that nobody wants to review changes to non master branches
(05:24:50 PM) cscott: so long as you're willing to review the changes, we won't have a problem ;)
(05:25:08 PM) physikerwelt: yes
(06:07:50 PM) physikerwelt: can we publish this irc log?
(06:08:09 PM) cscott: sure

MathJax (MW_MATH_MATHJAX) depreciated

When looking at the code I realised that MathJax is now a depreciated rendering method. On shared hosting this seems however to be the only way to get this extension working at all. Thus it will be cool to continue support for this mode for all the ("unfortunate") people out there who have no command line access to their server (shared hosting). --[[kgh]] (talk) 15:40, 4 September 2014 (UTC)

inline vs. blockstyle

I had a look at the VE formula tool (the current one, and the one on the beta-cluster). They offer the choice between "default", "inline" and "block" display. I guess most editors will be used to the latex syntax of $$ for inline math and \begin{equation}\end{equation} (or equivalent environments) for block display. Unfortunately this clear distinction did not exist in wikipedia. As a consequence <math></math> is used for inline equations and block equations use the same, just in a new row with additional indent : in front. As far as I can tell, this is quite consistent throughout various projects and languages. Now there is the display="inline" or "block" option, which is not bad itself, but it breaks with the current conventions of distinguishing the two. I am not sure, if it is even possible to get an equation with the indent in front or to remove it using the VE.

My suggestions are the following:

• There should be no such thing as a "default" display style to choose from. The formula is always either block or inline and the option default suggests that it could be undefined or both depending on some user settings. The default should be inline math.
• <math></math> and <math display="inline"></math> should both render as inline math with \textstyle as a default. Maybe some equations that have no indent but are still block equations (for example in a table) get the wrong, but still acceptable \textstyle formatting. For the majority of them \textstyle is correct and thus an improvement. For editors using wikitext, it is inconvenient to read or type such large html expressions and editors using the VE interface only have to change the display style for block equations.
• \n:<math></math> and <math display="block"></math> should be equivalent notations for block math, have the same appearance and use \displaystyle as a default. Whether block style means centred or indented can then depend on user settings, but I can not think of any advantage of having both options available to the editor.
• It should always remain possible to override the font style with \textstyle \displaystyle (or even \scriptstyle) where appropriate. I think there might be a bug in the instant display of the VE when doing this, but the final result is correct as it is now.

I am not sure, whether this is the best discussion page for my comment, feel free to move them somewhere else.--Debenben (talk) 18:07, 29 November 2015 (UTC)

I linked to this on Phab. Thanks, --Elitre (WMF) (talk) 19:39, 30 November 2015 (UTC)

I think this problem will become important, once people discover the "block" and "inline" option and it should be solved now. I am not sure, but I think my proposed solution above was implemented in the old MathJax rendering mode. The other solution would be, to introduce new shortcut notations for the two options. This would require replacing all <math> tags in the articles. The :<math> can probably be replaced automatically with the new block notation while all other occurrences should better be replaced manually...--Debenben (talk) 15:19, 5 December 2015 (UTC)

Some suggestions

Hello,

just a few suggestions for the new math mode that came to my mind:

• First of all, it would in my view be sensible to have inner brackets be displayed smaller; in my view, this increases the overview one quickly can get over a formula. Let me give a small example:

$\sin(\cos(x)+\cos(y))$ VS $\sin {\bigg (}\cos(x)+\cos(y){\bigg )}$.

• Further, the middle command is currently not supported:

Failed to parse (unknown function "\middle"): {\displaystyle \left\{ x \in X \middle| f(x) \in B \right\}} .

I'll follow up with more suggestions as they come to my mind. With best regards, --Mathmensch (talk) 19:06, 9 December 2015 (UTC)

• Let me also say that the mathjax of [2] seemingly supports almost all commands. Can we get a similar support? --Mathmensch (talk) 19:51, 9 December 2015 (UTC)

• Although this might be doable in Wikisyntax, it would certainly be great if instead of writing a symbol, for instance \mathbf V for a vector space, one types \v1 and obtains the first letter currently used for vector spaces. In this way, one would obtain consistent notation throughout all mathematics articles; something which I would consider beneficial (first, because the reader can more easily recognize the objects and feels 'at home' quicker, but also because it becomes easier for the authors, since they don't have to think about a symbol then). --Mathmensch (talk) 16:05, 10 December 2015 (UTC)

• One should have support for blind people; there should be comprehensive language descriptions of formulae. --Mathmensch (talk) 17:23, 24 December 2015 (UTC)

• Failed to parse (unknown function "\begin{align}"): {\displaystyle \begin{align} \big\setminus \end{align}} shows an unsupported command and a flawed error message. For comparison ${\begin{aligned}test\end{aligned}}$.--Mathmensch (talk) 17:30, 9 February 2016 (UTC)

• bold $not{\text{ }}bold$ $certainly~not{\text{ }}bold$--Mathmensch (talk) 13:33, 5 March 2016 (UTC)

Real LaTeX support non-Latin letters

As you can see:

$E_{\text{чд}}=\sin(\cos(x)+\cos(y))+m_{\text{чд}}c^{2}$.

and this is good. Tnx) 89.23.32.99 11:25, 29 December 2018 (UTC)

(SI) units package

Is there any chance that we could install siunitx while working on improvements of this extension?

— Danny B. 20:19, 4 February 2019 (UTC)

Deprecated information

Page contains deprecated information, even after replacing old operators pages stays in the Category:Pages that use a deprecated format of the math tags :

• \Complex, \mathbb{C} (workaround using spaces around : \mathbb{ C })
• \land (no workaround)
• ...

-- ◄ David L • discuter ► 13:57, 6 May 2022 (UTC)

And this page w:en:Calculus on Manifolds (book) is in the category but I don't see any deprecated tags that should land it there. Jason Quinn (talk) 06:37, 5 July 2022 (UTC)