Wikipedia talk:Manual of Style/Mathematics/Archive 3

middot vs. sdot (in the context of mathematical product operators)

There seems to be no uniformity in the use of a·b = · = · (Unicode MIDDLE DOT) and a⋅b = ⋅ = ⋅ (Unicode DOT OPERATOR (Mathematical operators)). Even the WP "Insert" edit toolbar seems to confuse them. There are some contexts where a centered dot has a well-defined mathematical meaning:

(i) Denoting normal multiplication between real numbers, complex numbers etc., also denoted by juxtaposition

(ii) Denoting a scalar product (dot product) of vectors, distinguishing it from several other products

…

I imagine that the Unicode symbols each are intended to have a preferred meaning, and that it makes sense to outline in WP:MOSMATH relating to which symbol is to be preferred in each context, or whether they are to be considered interchangeable, rather than having no guideline. Opinions? — Quondum 14:56, 19 November 2012 (UTC)

I've noticed that the mid dot kerns against one of the adjacent characters in my default fonts, which is inappropriate. The dot operator is properly spaced. In the edit window, the mid dot appears in the Wiki markup section, while the dot operator appears in the math & logic section. <math>\cdot</math> also produces the dot operator. Both give tacit approval of their proper use. I think a bullet point noting this would be appropriate. There is probably a lot for a bot to clean up, though. — kwami (talk) 16:08, 19 November 2012 (UTC)

U+00B7 is in the Latin 1 Supplement block, category General Punctuation, whereas U+22C5 is in the Mathematical Operators block, category Math Symbol.[1][2]. This strongly suggests that dots as mathematical operators (be it multiplication, inner product, etc) should use U+22C5, whereas U+00B7 is meant to serve as punctuation in natural languages (such as Catalan). The kerning you observe is consistent with this distinction.—Emil J. 16:28, 19 November 2012 (UTC)

Added the markup for the dot operator and a warning that it is not the same as the interpunct. — kwami (talk) 16:34, 19 November 2012 (UTC)

I don't think we need to pay too much attention to this unless there is some documented reason why using one would actually affect the font for more than a handful of people. We don't have any data about how many people use fonts that actually include the other code point, or how many users will see a box instead of the other code point. I view the Unicode map much like ISO standards: sometimes interesting, but not controlling about the way we type mathematics.

A better improvement will be once the site moves to MathJax, so that we can type $\cdot$ and have it work. — Carl (CBM · talk) 17:39, 19 November 2012 (UTC)

What about when the variation becomes visually substantial, such as in Dot product#Properties, where U+2022 gets used as well? In my experience, the WP guideline do try to draw a line somewhere; some level of uniformity of presentation (especially in mathematics) has some benefit. You are suggesting that nothing be said; I am suggesting that if the distinction is unimportant, that the guideline might suggest that either U+22C5 or U+00B7 may be used; alternatively it could put a slight preference on the first. — Quondum 18:59, 19 November 2012 (UTC)

Yeah, the dot product article is something else. Actually, looking at it again, since ⋅ is available, I wouldn't mind language here that recommends using that for dot product and multiplication. — Carl (CBM · talk) 19:23, 19 November 2012 (UTC)

⋅ has broad coverage. · displays incorrectly in many common fonts, so it's more than just a few people. — kwami (talk) 19:26, 19 November 2012 (UTC)

And the wording has recently been changed (by kwami) to make the recommendation CBM refers to. So if there's no dissent, I think no more needs doing here. — Quondum 19:35, 19 November 2012 (UTC)

“It is easy to see that...”

Coming from the page on Operator_(mathematics), the subject's difficulty, and the reader, indirectly, is frequently judged, I feel, perhaps without need, and possibly without substantiation. Certainly without giving helpful indications of why the author's claim (It's easy!) might be true, or on what scale. Do such didactic phrases belong in an encyclopedia at all?

When an author claims that something is easy to see, then he/she should be able to at least indicate in some helpful way why this is actually the case. Maybe by referring to some standards of wikipedia and/or to empirical evidence that have shown people see this with ease; or by referring to some accepted results of the theory of learning. I doubt, though, that this is generally the intent of writing these statements—imitation seems a more likely cause, or a confusion of self's felt ease/difficulty or peers' felt ease/difficulty with a reader's, the latter being unknown.

“It is trivial to show” is another phrase; it could indicate that there exists a well defined set of commonly known trivia, i.e. pieces of knowledge from the trivial arts, Trivia, so that by referring to this set, “It is trivial to show” can actually mean something to a reader of the article. When the phrase is used without thinking about the Trivia (and its methods), I'd still expect an encyclopedia to speak in defined terms. This means, it should be able to hint at a method of proof/seeing. I think that an article in wikipedia is not a homework assignment, testing a readers ingenuity, or mathematical knowledge.

There should be better—systematic—ways of classifying the difficulty of a subject than to sprinkle an article with “It is X to see that ...”.

I must emphasize that I am not at all complaining about the difficulty or ease I felt reading the particular article. This is intended to be a comment on style, the page on operators is just an example. GeorgBauhaus (talk) 17:40, 22 December 2012 (UTC)

Agree. Such expressions, while appropriate in many mathematical contexts (e.g text books), are not appropriate for an encyclopedia. Paul August ☎ 18:05, 22 December 2012 (UTC)

For corroboration that this sort of phrase should not be used, see MOS:NOTED. I have similarly been removing phrases like "It can be shown that" or "It can be proved that", except in mathematical logic contexts where the distinction between truth and provability is important. —David Eppstein (talk) 19:32, 22 December 2012 (UTC)

Yes. Though, since the expressions mentioned above often occur in mathematical exposition, it might be good to include a specific proscription here. Paul August ☎ 21:10, 22 December 2012 (UTC)

Detalic

See also Talk:Differential_of_a_function#Detalic. — Preceding unsigned comment added by Wikispaghetti (talk • contribs) 19:33, 17 January 2013 (UTC)

most well-known

'The most well-known functions—trigonometric functions, logarithms, etc.—are often written without parentheses.' Shouldn't that be 'best-known'? Sorry if this sounds WP:SOFIXITish, but copyediting the MoS is a weird thing... Kayau (talk · contribs) 12:10, 6 January 2013 (UTC)

Sounds good to me. — kwami (talk) 13:46, 6 January 2013 (UTC)

Or perhaps "Many standard functions..."? The semantics differ slightly, and I can think of everyday functions that are not even designated with a standard name in this context, such as the identity function, the zero function etc.). — Quondum 13:56, 6 January 2013 (UTC)

I agree. Should we change it, then? Kayau (talk · contribs) 04:06, 10 January 2013 (UTC)

"Best" means "most good". We don't mean "most good known" -- that would be grammatically incorrect. We mean "most goodly known", and "goodly" isn't a word but "best" is the adverbial form of "good", so "most well known" is the best option here. If not Quondum's alternative. 128.227.248.166 (talk) 21:24, 23 February 2013 (UTC)

"Well" is the adverbial form of "good", and "best" can equally well be used as an adverb, meaning "most well". —David Eppstein (talk) 22:01, 23 February 2013 (UTC)

Function names set upright

The MoS currently says

Names for standard functions, such as sin and cos, are not in italic font, but we use italic names such as f for functions in other cases; for example when we define the function as in f(x) = sin(x) cos(x).

I think this is incorrect. sin and cos are not set upright because they are common; instead they are done that way because they have multiple letters. If I defined a new function foo by foo(x) = sin(x) cos(x) then that should be upright too, otherwise it looks like f×o×o(x). A good example of this is the Hermite polynomials, which are commonly referred to as H_n (should be italics) or He_n (should be upright). For example the MathWorld page on Hermite polynomials displays H_n and He_n this way. You could argue that He_n are standard functions just as sin is, but then H_n would be too. Quietbritishjim (talk) 19:59, 9 January 2013 (UTC)

I've just noticed that this is actually said in the section Choice of type style. I had been reading the earlier section Using HTML → Functions, so this just needs to be updated to match it. Slightly different but very related: even in the Choice of type style section, the suggestion that such functions can be set without parentheses is only mentioned for standard functions. I think this just as valid whenever there's a multiletter function e.g. I wouldn't have a problem with foo x. Quietbritishjim (talk) 20:24, 9 January 2013 (UTC)

I have a problem with the underlying logic. I read the the current reasoning as variables in an term are written in italic and other text parts are not with the goal that it is easier to recognize variables with an expression. But what would be the motivation for single letters in italic and multiple letter straight. To help recognizing single letters as single letters and words as words? This makes little sense to me.--Kmhkmh (talk) 16:06, 20 January 2013 (UTC)

If you never multiplied things together then your point would be valid! The purpose is to distinguish myfunct from m×y×f×u×n×c×t. Usually if you read the individual letters you can see whether or not they constitute a single entity, but a good notation should allow you to subconsciously see the overall structure of the equation first and then look at the individual parts that interest you, not the other way round. In any case, this is the common typographical convention outside Wikipedia, so I think we should follow it to. For example, it's what LaTeX does (not that LaTeX is always right):

<math>myfunct(x)</math> gives $myfunct(x)$,

<math>\operatorname{myfunct}(x)</math> gives $\operatorname {myfunct} (x)$,

<math>\mathit{myfunct}(x)</math> gives ${\mathit {myfunct}}(x)$.

I included the last one to concede that you can force LaTeX to follow your suggestion, but you can force LaTeX to do anything! Any number of maths style guides agree with what I'm saying. Quietbritishjim (talk) 22:29, 18 February 2013 (UTC)

WP: «math»

Please, help to classify and compare all types of math typesetting known to be used in Wikipedia. It will make a foundation of this MoS more solid. Incnis Mrsi (talk) 15:36, 20 January 2013 (UTC)

Thin spaces

The section about so named "HTML" formatting does not mention the thin space ( ), which looks pretty good in situations like (x, y) and n × n. Instead, the MoS recommends such forms as “f(x) = sin(x) cos(x)” and “(−π, π]” with U+0020, resulting in over-extended spaces. Incnis Mrsi (talk) 16:03, 17 February 2013 (UTC)

Templates braket, vec and intmath

I recently created these templates for use with {{math}}, so faults are my responsibility. Are they discouraged by WP:MOSMATH? Thanks in advance for feedback. M∧Ŝc²ħεИ_τlk 17:25, 7 March 2013 (UTC)

The boring problem of formatting

Yet another round of flamewar is ongoing, but there is some appearance of WP:consensus about two partial questions. Those who are unwilling to read the entire thread can skip to proposed amendments. Incnis Mrsi (talk) 20:19, 29 July 2013 (UTC)

That thread isn't a flamewar. Please stop exaggerating these things. M∧Ŝc²ħεИ_τlk 20:22, 29 July 2013 (UTC)

Ring convention

Why is this a convention on wikipedia?

A ring is assumed to be associative and unital. There is an exception for rings of operators, such as * algebras, B* algebras, C* algebras, which we do not assume to be unital. Note, currently, ring (mathematics) does not require a ring to be unital.

This seems just to be designed to confuse those that haven't read the manual of style in-depth - ring should mean ring, not associative unital ring.

Most rings that people study are associative unital rings. These are the rings that turn up in practice. For example, algebraic number fields and their rings of integers, matrix algebras, coordinate rings of algebraic varieties, endomorphism rings of all sorts, these are all associative unital rings. Rings that are non-associative or non-unital are either curiosities (like the octonions) or of very special types which are studied by different techniques (mainly Lie algebras and rings of operators). Nobody clamors for a general theory of non-associative non-unital rings. I agree that there is an elegance to having a common definition which applies to all cases at once; but elegant or not, it's not what working mathematicians usually assume. Ozob (talk) 11:27, 13 March 2013 (UTC)

While the notability argument (i.e. the terms as used, mainly by secondary sources) seems to be the uppermost in this for Wikipedia, this pattern in mathematics as echoed on Wikipedia does create a large amount of initial confusion for untrained readers using Wikipedia for reference of concepts. And while I intuitively feel there is merit in giving consistency of terms in WP greater weight than mathematicians do (and there is a precedent in WP:MOSMATH prescribing particular conventions), I have generally dispaired of trying to advance this view. The adoption of "ring" to be implicitly unital is an interesting edge case, because it does not seem clear that this use is overwhelming worldwide, which would have given scope for a more "logical" convention here as a matter of improving readability and ease of understanding. But, before I get rebuked for this outburst, I'm not actually going to push any views. — Quondum 21:06, 29 July 2013 (UTC)

Referencing mathematicians and CITEREFs

I have found differences in styles used to reference (via links and mentions) mathematicians. Also I've seen many links within articles navigate to CITEREFs... Is this acceptable? Ex. Barnette's conjecture#Equivalent forms — Preceding unsigned comment added by 24.97.221.98 (talk) 18:22, 27 November 2013 (UTC)

You mean the use of Harvard-style parenthetical referencing instead of or as well as footnotes? Yes, it's a standard and acceptable variation of referencing style. See MOS:REF#Parenthetical referencing, Wikipedia:Parenthetical referencing, and Wikipedia:Harvard citation template examples. Different articles may have different referencing styles; it's a good idea to use a single consistent referencing style within an article but it's a bad idea to unilaterally change the referencing style without a good reason and without the consensus of the other article editors (see WP:RETAIN). —David Eppstein (talk) 18:31, 27 November 2013 (UTC)

Zero ring

I would like to add a line to Wikipedia:Manual of Style/Mathematics#Terminology conventions: "The ring with one element is called the zero ring." I believe that this is the most common name for it in the mathematical literature, so ideally Wikipedia should reflect this. Any objections? Ebony Jackson (talk) 01:32, 18 December 2013 (UTC)

No infoboxes for geometry pages?

I don't know if this is the right discussion page to address this, but I have been noticing the strange lack of infoboxes at the top of a lot of articles about distinct geometrical bodies. Especially I would like something with a headline to contain the first visual representation for the article, and then if possible the simplest form of the equation of the object and/or that which requires the least mathematical preknowledge (say slope-intercept or standard form for Line (geometry) and ax + by + cz = d for Plane (geometry)). Then maybe some historical data, if available. I see a lot of different infoboxes spread around in some part of series of articles (Category:Mathematics_templates), but nothing unified. And a lot of the most basic articles haven't got any. I think to get this kind of overview at the start would help the average math interested person immensely. Is this a thing that is already being worked on? Cheers --Anjoe (talk) 18:36, 31 December 2013 (UTC)

So far as I know, this is not already being worked on. I also have doubts about its utility. The first visual representation for the article probably ought to be larger than can comfortably fit in an infobox. There is often not a simplest or best equation for an object, and sometimes simpler equations require additional background or context. That aside, it may be that I'm on the wrong track here, and that good things can be done with infoboxes. If you're interested, give it a try! Ozob (talk) 04:33, 2 January 2014 (UTC)

Rng vs. pseudo-ring

I would like to add the convention that a non-unital ring is called a rng. Currently, the Wikipedia page for this concept is called pseudo-ring even though some of its text refers to "rng". After investigating a little, my feeling is that "pseudo-ring" was a terminological invention of Bourbaki that mathematicians rarely use (outside of Wikipedia). Worse, the term "pseudo-ring" has been used to mean at least three different concepts: see Patterson, "The Jacobson radical of a pseudo-ring", Math. Z. 89 (1965), 348–364 and Natarajan, "Rings with generalised distributive laws", J. Indian Math. Soc. (N.S.) 28 (1964), 1–6 for the other two. "Rng" is a little more common, and has only one mathematical meaning, as far as I know. If "pseudo-ring" had one meaning, then I would want to make it a redirect to rng, but perhaps it should be a disambiguation page instead? Suggestions would be welcome. Ebony Jackson (talk) 02:12, 24 December 2013 (UTC)

I endorse all of this, with the caveat that rings of operators should not be assumed to be unital. Ozob (talk) 05:37, 29 December 2013 (UTC)

OK, pseudo-ring has been moved to rng, or more precisely to rng (algebra) because there is a disambiguation page (that's the page that used to be a redirect to pseudo-ring). Ebony Jackson (talk) 06:19, 31 December 2013 (UTC)

There is an exception for rings of operators, such as * algebras

This appears in the same section about rings. A *-algebra is a complex vector space, not a (something) of operators anywhere. May I delete it? Incnis Mrsi (talk) 13:59, 9 January 2014 (UTC)

No, you may not. A *-algebra is an algebra with something that looks like complex conjugation. The most prominent examples of these are C*-algebras. Despite their abstract definition, every commutative C*-algebra is isomorphic to C₀(X), the space of complex valued continuous functions vanishing at infinity on some topological space X. This theorem would not hold if *-algebras were required to have units: The unit ought to be the function which is identically one, but that function doesn't vanish at infinity unless X is compact. Ozob (talk) 14:50, 9 January 2014 (UTC)

Manual of Style for Geometry pages

Could there be a seperate "Manual of style" for Geometry pages

Many geometry articles are much to much about analytic or higher dimensional Geometry, and would hope that having a seperate Manual of style for Geometry would help to get it right (or at least have a place to link to when the article doesn't follow the style) For many laypeople geometry is about geometrical construction, while (real? professional?) geometers are much more about algebraic, higher dimensional or differentional geometry

I would suggest that after the introduction there is a part

- explanation in plane geometry or 3 dimensional geometry where possible.

- an drawing on the subject (if possible)

- analytic geometrical parts (and all the other specialised geometry parts that look more algebra than geometry) should be in a seperate (last?) section. — Preceding unsigned comment added by 213.205.230.37 (talk) 14:38, 24 January 2014 (UTC)

Default vs. \textstyle: example shows no differences, \scriptstyle unexplained, outdated documentation referenced

With FireFox 26.0 and Wikipedia.Preferences.Appearance.Math=MathJax, I see the examples illustrating the value of \textstyle in Wikipedia:Manual_of_Style/Mathematics#Using_LaTeX_markup as identical, with limits after the sigma. I tried adding \scriptstyle to the example, but it did not change. In Help:Displaying_a_formula I found no explanation of these elements. I searched for them in Wikipedia: and MediaWiki:, but found no documentation (but a great deal of what in this situation was noise) in the first 100 hits, though I did find “\displaystyle” – which helps, but adds to the confusion – (and “:<math>”) in Wikipedia:WikiProject_Mathematics/Typography. I suspect that the introduction of MathJax has something to do with all this. In case the page changes, the examples of rendering – which I see as identical with the exception of \displaystyle — are:

• Code: “<math>\sum_{n=1}^\infty 1/n^2 = \pi^2/6</math>”
• Default (no \*style): $\sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$
• With \textstyle: $\textstyle \sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$
• With \scriptstyle: $\scriptstyle \sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$
• With \displaystyle: $\displaystyle \sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$
• With :<math>: :$\sum _{n=1}^{\infty }1/n^{2}=\pi ^{2}/6$

The lead of Wikipedia:Manual_of_Style/Mathematics refers to meta:Help:Formula, which says it is outdated and looks rather like Help:Displaying_a_formula, though it does not refer to that.

It would be helpful if someone (or ones) could:

• Document these markup elements (and the default) in Help:Displaying_a_formula, including the effect any settings may have.
  • Also document :<math>, if that is supported (but say it is redundant if it is default).
• Update Wikipedia:Manual_of_Style/Mathematics#Using_LaTeX_markup so that the examples render differently and/or warn that they depend on settings and refer to the added documentation section for details.
• If \scriptstyle is obsolete, then this should be explained in both places.
• If Help:Displaying_a_formula supersedes meta:Help:Formula, then:
  1. Refer to it from the outdated page,
  2. Merge the outdated page to the new page — this could be done in steps, replacing sections by references to the up to date version.

And if experts do not know, then state that honestly in the documentation! PJTraill (talk) 22:37, 9 February 2014 (UTC)

The current way to explain symbols in formulae needs motivation

The old motivation for why explanations of symbols in formulae (see article section Explanation of symbols in formulae) should be written as prose, was simply because the list "has no reason to be bulleted". This is simply incorrect — there are probably several reasons for why the list should be bulleted, although the only good reason I can come up with for the moment is that it makes it much easier to quickly find the variable you want to read about. I therefore rewrote the sentence so that it now only says that lists should be written in prose.

Now, however, the statement lacks motivation for why the list should be written in prose, and such should therefore be added. Otherwise, we should probably revise the statement altogether and make it generally acceptable to list explanations of symbols in formulae as bullet lists, as an alternative to as in prose. —Kri (talk) 21:24, 9 March 2014 (UTC)

Descriptions of variables should generally be in prose because Wikipedia articles are written in prose. A list of variables is an index, and an index is intended to be referenced, not to be read. Ozob (talk) 23:31, 9 March 2014 (UTC)

And why should Wikipedia be written in prose? The primary reason for any guideline is presumably to optimise the accessibility of the information for some target audience, but it is reasonable to ask if that guideline is suitable for a given field. I have a suspicion that a style of thinking favoured by those leaning to humanities is being imposed on those of a technical bent. The argument “an index is intended to be referenced, not to be read” does not convince me, especially in a reference work, which I think Wikipedia is; I think the reader should be able to choose to read or reference the explanations, and consider both slightly easier in list form because the visual structure better reinforces the logical structure. I am however not sure if the small increase in ease justifies the extra space required. It would be nice to have markup that left the choice with the reader, but that seems impracticable. PJTraill (talk) 11:04, 10 March 2014 (UTC)

Because we want the whole encyclopedia to have a consistent style? See WP:PROSE: "Prose is preferred in articles as prose allows the presentation of detail and clarification of context, in a way that a simple list may not. Prose flows, like one person speaking to another. It is best suited to articles, because their purpose is to explain." —David Eppstein (talk) 14:35, 10 March 2014 (UTC)

I think that when justified, exceptions from this principle are acceptable. No one would argue that the tables in Wikipedia rather should be written in prose, for example. —Kri (talk) 17:15, 15 March 2014 (UTC)

For what it's worth this section may be useful, at least it's recent and relevant, possibly one motivation behind this thread.

I agree that lists are good for easy and quick reference, and also that prose allows symbols to be explained in brief detail. Using both is too much explanation, so we just have to decide which one or the other is best for any particular situation. M∧Ŝc²ħεИ_τlk 17:54, 10 March 2014 (UTC)

Rewrite

Hey, Dave! What are your objections to my rewrite?

Duxwing (talk) 06:37, 10 April 2014 (UTC)

1. I prefer "David" to "Dave".
2. For the short version, read my edit summary.
3. Given the fact that discussion on Talk:Waring's problem did not seem to make much difference to your idiosyncratic views on what is grammatical or idiomatic or standardly phrased, I am not optimistic about the discussion here, nevertheless...
4. There are lots of little things I could quibble with (like, it's not true that the lead section is the same as an introduction), but the big one that caused me to immediately revert was your replacement of "The lead should as far as possible be accessible to a general reader, so specialized terminology and symbols should be avoided as much as possible." with "The lead should be accessible to general readers: avoid special terminology and symbols." It is simply not true that all mathematics articles can have a lead that is written to be accessible at the high school level (using that as an approximation to general readers). A good heuristic is that they should be written to be one level of education lower than the typical level at which the subject is studied. So, for subjects studied in elementary or secondary school, yes, the lead should be accessible to general readers. For subjects at a level that might be studied by mathematics majors in college (say Waring's problem), the lead should be accessible to interested high school students. For subjects typically left to graduate school (maybe meromorphic functions are an appropriate example) the lead should be accessible to college mathematics majors. And for subjects of current research the lead should be accessible to mathematics graduate students. Additionally, you omitted the "as much as possible" part of avoiding terminology and symbols: it is not always possible to avoid them completely, so hardening this rule is a bad idea.
5. In general, for big sets of changes to guidelines like this, it works better to break them into smaller changes that we can discuss individually, and build consensus on talk for each of them. It would be a mistake to read my previous point and think that you should just do all the same changes except the one I'm complaining about. I'm sure there are several other things in there that I would object to enough to revert, or at least argue about, but I didn't look for them because that one already gave me enough reason to revert just by itself. —David Eppstein (talk) 07:24, 10 April 2014 (UTC)

1. Ok. :)
2. I read your summary and want more
3. Coincidentally, this Manual of Style explicitly states my point about not using technical language in the lead.
4. The Math MoS states that leads should not require expertise or references to understand; I hope I said "leads" and not articles and am sorry if I did not. Caveats like "as far as possible" are redundant here because Manuals of Style are guidelines and therefore inherently not hard-and-fast. Obviously, my argument from MoS therefore is not necessarily true.
5. Sorry, long edits are bad habit of mine, and I will try to avoid them.

Do you want to collaboratively copy-edit with me? Duxwing (talk) 09:13, 10 April 2014 (UTC)

On point 3: this subpage, which reflects a 10-year-old consensus, explicitly states that it may replace the general style: "For matters of style not treated on this subpage, follow the main Manual of Style". The technical language point is treated on this page, and the consensus wording is "as far as possible". A change like this would make it impossible to write articles on any serious technical subject at all. Deltahedron (talk) 21:57, 10 April 2014 (UTC)

I would normally try avoiding saying this so bluntly Duxwing, but your styling yourself as a grammar hammer indicates to me that this needs to be stated forcefully. After reading your edit to this MOS I had a look at your user page and I have come to the conclusion that good copy-editing is not in your skill set - you don't have a good grasp of how to write idiomatic and easy to understand English. Your reading of 'as possible' as meaning for the general reader also indicates you are unable to read instructions properly. You should stop when others disagree with you rather than fighting them. I agree with all of David Eppstein's comments above and believe the heuristic there for the level to aim at is a good one. Dmcq (talk) 11:35, 11 April 2014 (UTC)

Use of mathematical notation in non-math articles

I have edited the first sentence to say that some aspects of this manual apply not only to articles on mathematics but also to the use of mathematical notation in articles on other subjects than mathematics. It would be absurd to say that because an article using mathematiacl notation is on chemistry, it should be exempt from standard conventions when it uses mathematical notation.

The article titled Duckworth–Lewis method begins by saying:

The Duckworth–Lewis method (often written as D/L method) is a mathematical formulation designed to calculate the target score for the team batting second in a limited overs cricket match interrupted by weather or other circumstances.

But someone is saying on its talk page that WP:MOS does not apply to it since it is not a mathematics article, so that one should write things like 3<5 instead of 3 < 5 or 3 x 5 instead of 3 × 5, etc. Michael Hardy (talk) 12:06, 5 May 2014 (UTC)

phi problems

There are two different ways to include the phi symbol:

a wrong φ  ampersant phi semicollumn

and

a right  $\phi$ math phi math

and in some articles they both appear for example in Angle of parallelism is it not possible to make a script that automaticly change the wrong form into the right form? (for beginners it can be unclear that they have the same meaning)

see also Phi the page about the symbol — Preceding unsigned comment added by 213.205.230.28 (talk) 10:49, 13 July 2014 (UTC)

Bad idea I think. I've seen both variants of epsilon used together for different things. They are just math symbols, we are not writing Greek. They are not right or wrong. Dmcq (talk) 12:28, 13 July 2014 (UTC)

You can also get the "open" phi with varphi in math mode, i.e. $\varphi$. I think it is the preferred choice for e.g. the golden ratio. I see no point in prohibiting it or the other one. —David Eppstein (talk) 14:16, 13 July 2014 (UTC)

Consistency within an article is good, but is there a way of ensuring that across all combinations of HTML rendering and LaTeX rendering? Deltahedron (talk) 16:38, 13 July 2014 (UTC)

Variable re-use

Do we need an admonishment to avoid using the same variable name for multiple unrelated meanings? This has come up in Closed subgroup theorem. (There doesn't seem to be any disagreement there that this is a bad idea, but it happened because one contributor was following the style of a reference that did this.) —David Eppstein (talk) 16:49, 18 July 2014 (UTC)

Recommending against variable reuse is a good idea. It should come up only rarely, but the advice is certainly in keeping with the general principle of providing maximum clarity in an article. Something like

• Avoid using the same variable or symbol for two different mathematical objects.

--Mark viking (talk) 17:48, 18 July 2014 (UTC)

I think some qualifier such as "where confusion is likely to arise" is needed. There are quite standard ways of writing which would be excluded by this if rigorously enforced. For example, if (X,T) is a topological space with underlying set X and topology T, it is quite usual to refer to it as X if there is only ever going to be one topology on it. Similarly we use +, ×, ⋅ etc to denote operations in different groups freely without confusion. The reuse of place-holders such as i,j for summation is also usual. Deltahedron (talk) 08:29, 19 July 2014 (UTC)

Blackboard Bold Unicode

"A particular concern for the use of blackboard bold on Wikipedia is that these symbols must be rendered as images because the Unicode symbols for blackboard bold characters are not supported by all systems."

Is this still true? --Unverbluemt (talk) 11:27, 31 August 2014 (UTC)

According to [3], in July, Wikimedia sites collectively got over a billion requests from IE 7 and below; plus hundreds of millions of requests from very old versions of Chrome and Firefox. I think that while Unicode blackboard bold is not as problematic as it once was, in the interest of maintaining wide compatibility it is still best to avoid it. Ozob (talk) 16:38, 31 August 2014 (UTC)

Wikilinking formulae

I just came across the following [[Green's relations#The H and D relations|''H''₁]], rendering as H₁ which somehow struck me as unsatisfactory. Would it be a good idea to suggest that as a matter of style one should not wikilink to formulae unless they happen to be the actual article title, such as E8 (mathematics) or Ζ(3)? Deltahedron (talk) 21:35, 31 August 2014 (UTC)

I agree. To me this sort of thing is similar to what WP:SUBMARINE warns against. If the H and D relations need to be glossed for readers who might not know what they are, better to do it in text rather than in easily-missed links within the notation. —David Eppstein (talk) 22:39, 31 August 2014 (UTC)

Revising the page

I am not a member of this group, and came here looking for specific advice that could be given at a Edit-a-thon so I am loathe to make any changes without starting a discussion first and listening to the opinions of the subject experts- but I do get the feeling that this page is very dated, inaccurate and wishy-washy. The formating is not consistent etc- it is heavily dated. If I can't stimulate anyone else to do the work- I give notice that I want to bring this advice upto date to reflect current good practice.-- Clem Rutter (talk) 11:41, 24 February 2015 (UTC)

As far as I'm aware, it's not dated, inaccurate, or wishy-washy; it represents the current consensus of WP:WPMATH. Can you provide examples? Ozob (talk) 01:49, 25 February 2015 (UTC)

Thanks for responding. Examples coming shortly.-- Clem Rutter (talk) 08:57, 25 February 2015 (UTC)

Specific Points

My first warning bell was the line

Lastly, a well-written and complete article should have a references section. This topic will be discussed in detail below. Which refered to

Including literature and references

It is quite important for an article to have a well-chosen list of references and pointers to the literature. Some reasons for this are the following:

Compare that with WP:REF. WP:CITEHOW- Where is the strong statement that

WP uses secondary sources and is not OR, so all statements should be supported by an inline reference.

This is a MOS not an essay on the history of maths publications- so where is the statement that various methods of citation are supported but WP:WPMATH advises to use Harvard or Vancouver- or sfns. See the comment in the FARs eg Wikipedia:Featured article review/Infinite monkey theorem/archive2.

Should we just add a sandbox page here and knock together a tougher version. I have gone from looking at MOS pages for advice- to using them to teach post-graduate newbies the ropes. I see from the history that this is basically a 2002 page that that has been cp'd in 2005- and then tweaked. It still feels like the musings of 2002 (Magna Carta- rather than Criminal Justice Act!).

Even changing this line to:

All Wikipedia articles must have references supporting each edit. This topic is discussed below.

Would be make the page factually accurate. Looking to include material from Wikipedia:Scientific citation guidelines might be be more beneficial.

The Wikipedia:cite sources article has more information on this and also several examples for how the cited literature should look.

It has examples- but choices and no firm advice about current practice. This is a major confusing area for academics- and the editors I am training want firm advice here- newbies are not encouraged by doing wild wikilink chases. They have a message, which they want to put on wiki- correctly reference it and format it (and they have two hours).

Sections and lead

What section headings are required, in what order and what sections always occur? So I look at Wikipedia:Manual_of_Style/Mathematics#Suggested_structure while bearing in mind Wikipedia:Manual_of_Style/Chemistry#Article_types and Wikipedia:WikiProject_Computer_science/Manual_of_style#Structuring_different_kinds_of_articles.

Briefly looking at Wikipedia:WikiProject_Mathematics#Good_articles we have four types of article.

1. Mathematicians
2. Mathematics
3. Mathematical problems
4. Mathematical physics

What are the sections that we would hope to see in a GA/FA for each of these, and how does the MOS help us to write one?

So what do we have at the moment

Suggested structure

Probably the hardest part of writing a mathematical article (actually, any article) is the difficulty of addressing the level of mathematical knowledge on the part of the reader. For example, when writing about a field, do we assume that the reader already knows group theory? A general approach is to start simple, then move toward more abstract and technical statements as the article proceeds.

That is not about structure but a POV on writing pitfalls- though of course very true. (This sentence was copied across to the CompSci MOS and tweaked suggesting how they wrote theirs).

A general approach is to start simple, then move toward more abstract and technical statements as the article proceeds.

This is advice on the writing process- not on the contents or structure or style of a WP:WPMATH approved article. A possible easy alternative is to take the table from Wikipedia:WikiProject_Mathematics/A-class_rating#Criteria To achieve a well structured article that fulfills the objects of Wikipedia and WP:WPMATH articles should attempt to follow a common structure. There are four principal types of article that have achieved FA status, and their advised structure is considered separately.

We then follow the method used at CompSci giving proformas for each of these article types. In my POV- study links to FAs and GAs for each type of article work.

Laying out the page.

Not Typesetting- please- there is no hot lead or Linotypes involved. For a maths article this is critical. My first question was- Do I centre a formula, right justify, left justify or put in inline in a sentence? That is what a newbie will ask me- that is what a MOS says. We don't. The essay on LATEX is complete and fun to read- but is addressing the wrong audience. To put it bluntly it reads as if a group of editors have finally understood the intricacies of the markup and demonstrating their mastery. It does not say:

The body text of a mathematics article will be written using standard wikitext markup,<sup> and <sub> will be used push the text up and down. Wikitext can use latin and greek letters. More complex text can be included inline and in separate paragraph using maths markup as explained in a separate section. All standalone maths markup and formulae should align usually using one indent ( :) from the left margin.

Summarise

To summarise- there is nothing wrong with the mathematical consensus on this page- but it is not an adequate MOS page as it is not written for the potential user- particularly the brilliant time-poor mathematician who wants to get an article up and running.

I propose we open a sandbox page here and knock together a tougher version. And we focus that version from the point of view of a wiki-newbie who comes with a strong Mathematical background and the tutor who is mentoring her/him -- Clem Rutter (talk) 11:49, 25 February 2015 (UTC)

In part, you seem to be asking for us to establish consensus about topics that have no consensus. There is no consensus on citation style. There is no consensus on how to format inline mathematics. There is no consensus on what article headings are required and in what order. Moreover, there are people with strong opinions on each of these. I'm not averse to improving the current MOS page, but my past experience has led me to believe that consensus is unachievable and issuing diktats accomplishes nothing.

That said, I would welcome an attempt to improve this page. I don't think it makes all its points in a compact fashion. Drafting a new version may be helpful. Ozob (talk) 13:12, 25 February 2015 (UTC)

This is a time consuming process- and I am plugging away in one of my sandboxes. I hope to have a report and a suggested alternative ready by Friday. The lack of consensus hasn't really caused any difficulties- it is handled by being open about it. It is really about focusing on what the page is about, and must include and what are interesting footnotes. I have just penned this note to let you know I am alive- and working on it, all be it slowly. -- Clem Rutter (talk) 21:51, 10 March 2015 (UTC)

I have just posted the page Wikipedia:Manual of Style/Mathematics/sandbox where I have presented my ideas- discovered a sheaf of inconsistencies. I send respect and greetings to past contributors having experienced some of the difficulties they must have encountered. Please do feel free to start a debate on the talk page. — Preceding unsigned comment added by ClemRutter (talk • contribs) 17:09, 14 March 2015 (UTC)

I have just posted the page Wikipedia:Manual of Style/Mathematics/sandbox

I have just posted the page Wikipedia:Manual of Style/Mathematics/sandbox. I made several pointed remarks above- so I felt it was appropriate to rejig the whole page, trying to address some of my criticisms. Yes it was a major job. I feel that this was important as we wont get articles to FAC- unless they are MOS/Mathematics compliant- so having a tightly constructed page is a service and a duty to all FA hopefuls.

I tried not to add a single word- and certainly not change any existing decisions- through out the document I have left notes on the task and problems. Discovering an advised structure for the articles is an incomplete task. I have added a few suggestions. Unfortunately, no FAs or GA seem to follow the previous pattern. Exceptions- yes- but 25 out of 25!

Which brings me to the question of the structure of this MOS. Following other subjects- I detected a vague order, and have re-ordered the sections here to come into line. If this new order is accepted I feel it opens up the article to further improvement. At the moment we have hit a brick wall.

The second brickwall is there were three ways of presenting good/bad text. Obviously a C&P of three peoples work. When combined it was irritating to see first an example of bad text, a criticism then good text. Then the next paragraph- the convention was reversed! There are templates to help so I used them cf {{xt|----}} and ((markup|---|xxx}}.

What make this page unique is that we try and talk about good/bad text at the same time as trying to demonstrate <text> and html markup. I see no need to demonstrate bad text or bad markup here. (But it is essential to do it elsewhere in a tutorial page- or as a {{efn| ---}}

Let the discussion commence--- Clem Rutter (talk) 17:36, 14 March 2015 (UTC)

Three weeks- no comment. Okay I will be bold. I will build up the new page in Wikipedia:Manual of Style/Mathematics/temp-I will strip out my comments, and alternatives for discussion from this page I will then do a single copy and paste over Wikipedia:Manual of Style/Mathematics I then intend to format up the HTML sections to match the LaTeX sections. Wish me luck.-- Clem Rutter (talk) 17:20, 5 April 2015 (UTC)

"d" in integration and differentiation

There seems to some dispute whether the "d" should be upright in integrals and derivatives:

1. $\int _{1}^{\infty }x^{-2}\,dx$
2. $\int _{1}^{\infty }x^{-2}\,\mathrm {d} x$

Any comments. I have no personal preference, except it should be consistent within articles. — Arthur Rubin (talk) 19:12, 19 September 2014 (UTC)

There is a standard ISO 31 described in this Tugboat article that claimed it should be a roman d. But this standard is widely ignored. The TeXBook has an italic d. It might be a math vs engineering culture issue. Integral#Terminology and notation seems to recommend an italic d, but mentions the roman d is used, too. I generally follow the TeX conventions established by Knuth. --Mark viking (talk) 19:50, 19 September 2014 (UTC)

This has been discussed many times at this project (see the archives back to perhaps 2011, maybe earlier...). (Admittedly I used to be one of those that would "straighten" out the "d"s, part of the problem and not the solution). We should just keep them consistent within articles and close to what most sources use, as WP:MOSMATH#Choice of type style says. M∧Ŝc²ħεИ_τlk 22:49, 19 September 2014 (UTC)

I knew I should have read MOSMATH more closely. As far as I'm concerned, this is resolved. — Arthur Rubin (talk) 01:26, 20 September 2014 (UTC)

When this topic comes up I frequently point people to WP:RETAIN, which, despite being stated in a different context, captures the right spirit. Also, usually this topic comes up because someone changes an article, and then I (gently, with a talk page note) revert them. Ozob (talk) 04:06, 20 September 2014 (UTC)

This issue came up today at Fourier transform. Italics should be reserved for variable symbols. Using them for operators is confusing IMO because dx looks like the product of d and x. In the International System of Quantities, it should be dx. Dondervogel 2 (talk) 16:46, 24 July 2015 (UTC)

This recommendation is almost universally ignored in the literature. There is no policy mandating that we must follow proprietary ISO standards in our mathematics articles, especially not when those recommendations contradict prevailing use (as well as other style recommendations such as Knuth). Besides, in one of the perennial discussions on this very issue, someone has already pointed out that dx is not an operator "d" applied to a variable x, but the unit dx is a separate variable denoting an infinitesimal increment. Sławomir Biały (talk) 16:57, 24 July 2015 (UTC)

I think that this is something that does not need to be covered by policy. I have no preference, except I think dx is easier to write than \mathrm{d}x. --Sammy1339 (talk) 17:09, 24 July 2015 (UTC)

The use of \text in <math> in certain circumstances

Recently I've seen a use of \text in <math> tags update< incorrectly >, like Planck units#Base units:

${\frac {F}{F_{\text{P}}}}={\frac {\left({\dfrac {m_{1}}{m_{\text{P}}}}\right)\left({\dfrac {m_{2}}{m_{\text{P}}}}\right)}{\left({\dfrac {r}{l_{\text{P}}}}\right)^{2}}}.$

If you are using MathJax renderer, it doesn't look harmonious at all, as MathJax renders \text as sans-serif like the surrounding text. I've been in the process of changing some articles to use \mathrm, so it looks like this (please switch to MathJax in order to see the difference):

${\frac {F}{F_{\mathrm {P} }}}={\frac {\left({\dfrac {m_{1}}{m_{\mathrm {P} }}}\right)\left({\dfrac {m_{2}}{m_{\mathrm {P} }}}\right)}{\left({\dfrac {r}{l_{\mathrm {P} }}}\right)^{2}}}.$

For me at least it looks a lot better, so I went ahead and changed some of them. However I just want to ask here the community's opinion before proceeding further. What do you think about the tag used?

Some other options that don't work in MathJax:

\textrm

${\frac {F}{F_{\textrm {P}}}}={\frac {\left({\dfrac {m_{1}}{m_{\textrm {P}}}}\right)\left({\dfrac {m_{2}}{m_{\textrm {P}}}}\right)}{\left({\dfrac {r}{l_{\textrm {P}}}}\right)^{2}}}.$

\mathsf (shows sans serif in PNG too)

${\frac {F}{F_{\mathsf {P}}}}={\frac {\left({\dfrac {m_{1}}{m_{\mathsf {P}}}}\right)\left({\dfrac {m_{2}}{m_{\mathsf {P}}}}\right)}{\left({\dfrac {r}{l_{\mathsf {P}}}}\right)^{2}}}.$

Timothy G. ^{from CA} (talk) 02:17, 3 March 2015 (UTC)

Also not working in MathJax but working in PNG:

\mbox

${\frac {F}{F_{\mbox{P}}}}={\frac {\left({\dfrac {m_{1}}{m_{\mbox{P}}}}\right)\left({\dfrac {m_{2}}{m_{\mbox{P}}}}\right)}{\left({\dfrac {r}{l_{\mbox{P}}}}\right)^{2}}}.$

So it seems that only \mathrm works in all setups, others just look plain weird.

Timothy G. ^{from CA} (talk) 02:21, 3 March 2015 (UTC)

Also works for all layout engines: \rm

${\frac {F}{F_{\rm {P}}}}={\frac {\left({\dfrac {m_{1}}{m_{\rm {P}}}}\right)\left({\dfrac {m_{2}}{m_{\rm {P}}}}\right)}{\left({\dfrac {r}{l_{\rm {P}}}}\right)^{2}}}.$

Timothy G. ^{from CA} (talk) 23:32, 4 March 2015 (UTC)

Note that I do not want to change every single \text to \mathrm, only ones appropriate should be changed. Some of the circumstances I can think of where \text is appropriate is prose labels or anything that does not strictly need mathematical notations, like some equations on Navier–Stokes equations#Incompressible flow. Timothy G. ^{from CA} (talk) 01:10, 5 March 2015 (UTC)

Descriptive subscripts ought to be \mathrm in LaTeX. If it looks better, and it's more correct in principle, then that sounds like a double win to me. Quietbritishjim (talk) 16:58, 4 March 2015 (UTC)

@Quietbritishjim: that's what I thought. Do you think this should be added to the MoS? Timothy G. ^{from CA} (talk) 17:48, 4 March 2015 (UTC)

@Quietbritishjim: "ought to be"? I'm not saying anything either way at this point, but your rationale would be appreciated.

@Timothy Gu: \mbox is deprecated/discouraged, as I understand it. I get a "[Math processing error]" with MathJax on the machine I'm on at the moment, so difficult to comment. If \text is producing a problematic (non-harmonious) display on some browsers, it may make more sense to get to the bottom of the problem with the rendering, rather than to fix it via avoidance in the MoS. \text has been a standard part of TeX on WP for a long time. —Quondum 19:34, 4 March 2015 (UTC)

@Timothy Gu: Well, that is just my opinion and understanding of convention. But I believe such labels should be should be in the math font if it differs from the text font (as it does on Wikipedia, and a Times text / CM math document) because although the label is descriptive it's still part of some math. I also believe they should be upright regardless of whether the surrounding text is italic, either because the whole document is ( D-: ) or because this math is in emphasised text (e.g. in a theorem). \text gets both of them wrong, while \mathrm gets them right and agrees with \operatorname. Looking into it more, I notice that there is a problem though: if the math font is sans-serif then \mathrm still produces serif characters, which is not what you want. Unfortunately it seems there is no built-in math equivalent of \textup. Quietbritishjim (talk) 22:02, 4 March 2015 (UTC)

My opinion: \text and \mathrm are for two different things, both useful. \text is for when you want to include English-language prose within an equation, for instance the word "otherwise" in a \cases. \mathrm is for when you want to have short sequences of Roman alphabet letters that are themselves mathematical notation (not free-form prose); the example of a roman letter subscript is one where \mathrm is the better choice. Another alternative coding to consider is \operatorname, for mathematics notation written out as short sequences of Roman letters used as a function or operator (e.g. sin or cos) but not already built into LaTeX. The letters themselves should be formatted the same as \mathrm but the spacing around the operator should be better with \operatorname. So we should not be telling editors to prefer \text over \mathrm or vice versa, we should be using both where appropriate. —David Eppstein (talk) 22:43, 4 March 2015 (UTC)

@Quietbritishjim: I'd agree with David Eppstein here. But as LaTeX uses serif and it is unlikely to change in the future I'd stick with \mathrm. Timothy G. ^{from CA} (talk) 23:32, 4 March 2015 (UTC)

@Quondum: seems like I didn't make myself clear enough. I do not intend to do a wholesale removal of \text in all articles. I most certainly have seen cases where it is appropriate (can't find the article right now). Timothy G. ^{from CA} (talk) 23:09, 4 March 2015 (UTC)

Also I found out about a similar discussion on TeX StackExchange. It suggests to use \textnormal which is not available in MathJax at least; \mathup, but it is with a custom definition; and then \mathrm. So, I guess mathrm it is. Timothy G. ^{from CA} (talk) 23:32, 4 March 2015 (UTC)

If we do put something into the MoS, something like what David Eppstein proposes seems to make sense. The distinction between a subscripted text label and a Roman symbol is potentially semantically significant, so it would seem to me to be that \text is still semantically appropriate for labels. For example, the electron magnetic moment might be denoted \text \mu_\text{e}, where the subscript is literally a text label ("e" for "of the electron"), not a mathematical symbol such as a specific element of a set, for which I would prefer \mathrm.

@Timothy Gu: You are proposing a workaround for a rendering bug, not an issue of style. Subscripted text can be text and not symbols, so this does not contradict what David Eppstein is saying. Perhaps you should raise this at the Village pump (for fixing it), and at a place like WikiProject Mathematics (with respect to a settling on an interim workaround)? —Quondum 00:10, 5 March 2015 (UTC)

@Quondum: I agree with David's point as well. However, as I already said in my last reply, I was only referring to some specific use, not general-purpose labels. Plus, I do not consider \text being rendered as the way it is a bug, therefore I don't want to go to village pump for this. It is by definition rendered to the styles of surrounding text, which it is. It is just that many usage of \text is inappropriate on a semantic level as well. An appropriate use of \text IMO can be found on Navier-Stokes equations#Incompressible flow, reproduced below:

$\overbrace {\underbrace {\frac {\partial {\mathbf {u} }}{\partial t}} _{\begin{smallmatrix}{\text{Variation}}\end{smallmatrix}}+\underbrace {{\mathbf {u} }\cdot \nabla {\mathbf {u} }} _{\begin{smallmatrix}{\text{Convection}}\end{smallmatrix}}} ^{\text{Inertia (per volume)}}\overbrace {-\underbrace {\nu \nabla ^{2}{\mathbf {u} }} _{\text{Diffusion}}=\underbrace {-\nabla w} _{\begin{smallmatrix}{\text{Internal}}\\{\text{source}}\end{smallmatrix}}} ^{\text{Divergence of stress}}+\underbrace {{\mathbf {g} }.} _{\begin{smallmatrix}{\text{External}}\\{\text{source}}\end{smallmatrix}}$

The sans-serif font of the labels fits perfectly with the surrounding text.

To reiterate my point, certain if not most usage of \text is not appropriate and should be changed to \mathrm, but \text is still useful in many cases where non-mathematical/prose text is required, and I am happy with the way it is rendered as-is. Timothy G. ^{from CA} (talk) 01:10, 5 March 2015 (UTC)

In the MathML+SVG rendering mode that the developers are (IMO foolishly) standardizing on, when viewed in Chrome (which uses the SVG fallback), the labels are not sans-serif. They are a serif font that is unrelated to the body text. —David Eppstein (talk) 17:58, 24 July 2015 (UTC)

@Timothy Gu: I hear you that you do not intend to change everything. But if it renders differently in a respect that is significant in different rendering environments (and it is obviously significant, because you're making a thing of it to the point of suggesting a MoS change), it is a bug, period. \text renders as a serif font in every context that I can test at the moment (MathML and PNG), and I'll check tonight (when I have a different computer) whether it is the same on MathJax for me; this is already makes your "I am happy with the way it is rendered as-is" inapplicable. It is sounding as though your entire argument is based around rendering on a single browser+configuration+installation+MathJax. —Quondum 01:50, 5 March 2015 (UTC)

@Quondum: TBH I am surprised that you did not check the output from MathJax until this moment, which makes your argument sounds moot. This "bug" applies to all browsers using MathJax, so you can easily reproduce this. It is not depended upon your "browser+configuration+installation". Timothy G. ^{from CA} (talk) 02:28, 5 March 2015 (UTC)

Surprised? I indicated earlier that 'I get a "[Math processing error]"' on the machine I was working on when selecting MathJax (in place of every expression that MathJax was supposed to be rendering), and thus could not check. I see now that I have had the opportunity that I get the same rendering error on my other machine, though this had worked in the past. I'll accept that it might be uniform for all MathJax (when it works at all), but it still depends on whether MathJax is being used. But I have no interest in this argument; I do not support a change to the MoS along these lines, but I'll leave it to others to contribute to any consensus on this. —Quondum 03:06, 5 March 2015 (UTC)

Inappropriate italicisation of mathematical constants

In the International System of Quantities, mathematical constants, like e, i and pi are always upright. The MOS advice is to italicise, which means they can be mistaken for variables. What is the benefit of departing from the international standard? Dondervogel 2 (talk) 17:08, 24 July 2015 (UTC)

Apparently, ISO tried to standardize mathematics without any coordination with the International Mathematical Union. Therefore, there is no hope that mathematicians will change their typographical conventions for adopting ISO choices. For mathematical articles I do not see any benefit to adopt a "standard" which is not the standard in mathematics. In mathematical texts, the mathematical constants are usually italicized, as is every symbol consisting of a single letter (such as a function name). On the other hand the names consisting of several letters are upright. D.Lazard (talk) 18:35, 24 July 2015 (UTC)

I see. Remember that mathematical equations are used in physics and engineering too. What does the IMU have to say on the matter? Dondervogel 2 (talk) 18:37, 24 July 2015 (UTC)

As far as I can tell, the most definitive mathematical-society-produced style guide is still the AMS's Mathematics into Type. It uses italic for e (section 2.4.2c, p.20). I didn't see any examples with π or the imaginary unit meaning of i, but since they generally follow TeX conventions I would expect them to support italic for those as well. —David Eppstein (talk) 20:12, 24 July 2015 (UTC)

The ISO standard is almost universally ignored by mathematical sources. In no way should we mandate a proprietary convention like the ISO, which purports to be "standard", when it is in fact very much non-standard. Sławomir Biały (talk) 20:44, 24 July 2015 (UTC)

Yes. For another example of this, see binary logarithm, where the ISO's recommended notation "lb" is used far less than even the fourth-most-used alternative notation (lg, log₂, log, and ld). —David Eppstein (talk) 20:59, 24 July 2015 (UTC)

Unlike what happens in chemistry, astronomy, and biology, mathematicians have no authorities who decree standards. Rather, standards evolve from conventions. And they are sophisticated and precise. Crowdsourcing vindicated yet again. Michael Hardy (talk) 20:14, 24 July 2015 (UTC)

The problem with ISO's attempt to impose a standard for this is that successful standards usually reflect existing practice (except in subjects that are completely new and have no existing practices). There are hundreds of years of mathematical typography in which d, e, and so on were italicized. Decreeing that all of it was wrong changes no one's mind, which is why people have continued writing italics just as they always did. Ozob (talk) 01:11, 25 July 2015 (UTC)

I don't see that ISO is trying to impose anything, nor decreeing anything as wrong. They are simply facilitating progress by providing a standard for people to follow should they choose to. A choice seems to have been not to and I do not yet see an answer to my question "What is the benefit in departing from the ISO standard?" Dondervogel 2 (talk) 21:43, 27 July 2015 (UTC)

The benefit is using the same notation all mathematicians elsewhere use, and thereby being more readable to people used to that notation. That is, we follow the de facto standard, not the false standard imposed by non-mathematicians and ignored by mathematicians. Other lesser but still significant benefits include much greater ease of formatting these symbols within <math> formulas (upright Roman characters are possible in <math> but not particularly easy, and I don't even know whether there is an upright π that works across all of the multiple options for rendering <math> in Wikipedia) and avoidance of edit wars with editors who prefer the usual format and have no inkling that the ISO might have suggested anything different (i.e. probably the majority of mathematics editors). —David Eppstein (talk) 23:25, 27 July 2015 (UTC)

I don't see ISO's efforts in this area as facilitating progress. There were de facto standard typographic conventions. They chose to flout them. Adoption of their notation has been limited; the upright d is seen occasionally, but it's been a variant usage for a long time; upright e and π are essentially unused. If anything, I think the appropriate questions to ask are, "Why adopt ISO notation contrary to standard usage?" and "Why does ISO persist in its non-conformity?" Ozob (talk) 00:55, 28 July 2015 (UTC)

So, in a nutshell: the familiarity of following existing (ambiguous) conventions is preferred over a standard that distinguishes between eccentricity and Euler's number? Dondervogel 2 (talk) 09:32, 28 July 2015 (UTC)

Or with the fundamental charge, or the elasticity, or the identity element of a group? I can't say that's ever been a problem. We deal all the time with possible conflicts between one variable and another. One solution is to use a different letter, or emphasize that this variable is not the same as the one that appears elsewhere if there is a real risk of confusion. A small change in typeface between $\mathrm {e}$ and $e$ does not seem like the best way, and it is certainly not the only way, to handle such a possible collision.

The purpose of a typesetting standard is (or should be) to enhance communication. It fails to do this if it does not already to a large extent agree with standard practices. One cannot enhance communication by insisting that the way people have been communicating for hundreds of years now needs to be changed. One still has to be able to read the papers that were published before the ISO standard went into effect. So, yes, "familiarity" is certainly a more important aspect in a standard than an illusion of unambiguity. Sławomir Biały (talk) 12:42, 28 July 2015 (UTC)

There are only 26 letters in the modern Roman alphabet; when you include capitalization and standard variations, like blackletter and calligraphic type or the Greek alphabet, you still only get a few hundred characters. The sophistication of modern mathematics and science makes it impossible to assign every concept its own symbol without using characters that nobody knows; even letters that people ought to be familiar with, like ξ, get muddled on blackboards all the time. So for purely practical reasons ambiguity is unavoidable.

Moreover, mathematics is not a collection of formulas; it's a rare math paper that has page after page of formulas (and those that do sometimes apologize to the reader). Written mathematics is done using written language, and it's both natural and expected that the writer will make statements like, "Let M be a manifold" or "Let M be a module" just so that the status of M does not have to be inferred from context. Ozob (talk) 13:56, 28 July 2015 (UTC)

@Slawekb. I agree it is not the only way. It might not be the best way either (how can one tell?), but it is better than not bothering to distinguish at all. If all changes were discarded because they lead to unfamiliarity we would still be counting with our fingers, we would not have computers, and we would certainly not be having this exchange on Wikipedia.

@Ozob. I agree that ambiguity in written language is unavoidable, if that's what you mean. I do not agree that ambiguity in mathematical equations is unavoidable, though it can require hard work. Distinguishing between variables and constants by means of italicization can only help.

Dondervogel 2 (talk) 15:14, 28 July 2015 (UTC)

"If all changes were discarded because they lead to unfamiliarity we would still be counting with our fingers, we would not have computers, and we would certainly not be having this exchange on Wikipedia." That's a strawman. I never said that all change from the familiar is bad. Instead, departing from existing standards of communication, instead of trying to codify best practices, actually leads to poorer communication rather than better communication. It's hopefully obvious why that is true. This very discussion is a living example of why. Sławomir
Biały 15:51, 28 July 2015 (UTC)

If I read you correctly, you're suggesting that we can assign each distinct mathematical constant or concept its own unique symbol. While I agree that such an assignment would eliminate ambiguity, it can't be done in practice. You are asking people to change good notation, in which M might stand for a manifold or a module or plenty of other things beginning with the letter "m", for an essentially arbitrary assignment where the symbols have no linguistic associations. Current mathematical practice may not be perfect, but it maintains some amount of order because people see the symbols as meaningful. Ozob (talk) 05:01, 29 July 2015 (UTC)

All I am saying is that I see an advantage in following the conventions of ISO 80000-2. There is nothing in ISO 80000-2 about assigning a unique symbol to each and every concept - that would be absurd. What I see there is a very sensible convention to italicise symbols that represent variables, while operators and mathematical constants are upright. Simple. I do not perceive a serious attempt to discuss the pros and cons of this convention, and therefore prefer to end this discussion. Good day. Dondervogel 2 (talk) 08:12, 29 July 2015 (UTC)

I am still concerned about the use of "π" rather than "π" in many articles (Pi not among the offenders). In the font that Wikipedia normally uses for mainspace text, π is quite ugly and does not look like π as displayed in any textbook whether it's math, physics, or engineering. Shouldn't π be replaced with π everywhere, unless the default font is somehow adjusted? 173.48.62.104 (talk) 00:02, 15 December 2015 (UTC)

I agree. π should almost always be preferred to the default sans π, and the same is true of all Greek letters when used in mathematics. I'm surprised that the MOS makes the recommendation of italic Greek sans lower case, and does not even point out the alternatives supplied by the template. Sławomir
Biały 00:41, 15 December 2015 (UTC)

Scriptstyle for 'math' symbols in running text

An anon editor of Simple linear regression is under the impression that using "scriptstyle" for <math>ematical symbols in normal running text, such as $\scriptstyle {\hat {\alpha }}$ or $\scriptstyle {\hat {\beta }}$, is some sort of convention in math articles. I don't see any evidence of this. Am I missing something? Interested parties may consider discussing this at Talk:Simple linear regression#Scriptstyle. - dcljr (talk) 05:50, 1 January 2016 (UTC)

Scriptstyle should ordinarily only be used to generate subscripts, superscripts, and other small type face. It should generally not be used to overcome the shortcomings in how Wikipedia renders mathematics into PNG. It is semantically incorrect for this purpose, meaning that what may look good for users with certain defaults (e.g., rendering to PNG) will not look good for others (e.g., MathML and SVG). I have seen mobile browsers where scriptstyle renders as an indecipherable blur. So it generally must be avoided in part for reasons of WP:ACCESS for the vision impaired. Sławomir
Biały 11:42, 1 January 2016 (UTC)

Are algorithms "invented" or "discovered"?

Are mathematical algorithms "inventions" or are they "discoveries"? --82.132.234.81 (talk) 18:09, 7 January 2016 (UTC)

Depends on who you ask. Paul August ☎ 21:54, 7 January 2016 (UTC)

where to find info on "equation box"?

I'm looking for some info on this equation box (for instance, parameters, etc.):

$M=E-e\sin E$

I have been perusing a lot of the WP:math type articles without much luck. All I know is that it exists, obviously. Tfr000 (talk) 16:57, 31 January 2016 (UTC)

Type "template:Equation box 1" in the search field. D.Lazard (talk) 18:54, 31 January 2016 (UTC)

Yup, that did it. Thanks! Tfr000 (talk) 19:00, 31 January 2016 (UTC)

Thank you both! I never would have thought to look under Template instead of Wikipedia. — Anita5192 (talk) 20:22, 31 January 2016 (UTC)

Opening a diff allows one to click on the template (in either diff window) as well, which takes one straight there without having to use the search widget. —Quondum 23:06, 31 January 2016 (UTC)

Use of "\colon" vs. ":"

I think it would make sense to have a style guideline for the use of ":" and "\colon" in the <math> tags. Namely, only "colon" should be used for expressions like $f\colon X\to Y$, while the use of ":" should be limited to the cases where the colon is to be treated by the math engine as a relation, like in set notation: $\{x\in \mathbb {R} :x>0\}$. The creators of LaTeX never intended ":" to be used in map notation, and hence "$f:X\to Y$," which is found in many articles, can be regarded as bad practice encouraged by Wikepedia.--Ørsted (talk) 14:02, 29 February 2016 (UTC)

In the preceding post, the difference between ":" and "\colon" needs to be clarified. I understand, maybe wrongly, that the difference lies in the space before the colon. If this is correct, this suggests that ":" is treated by the latex engine as an operator, and "\colon" as a punctuation mark. In your both examples, the colon is a separator (punctation mark), which has no meaning by itself, and is not an operator, nor a relation (in the mathematical sense). This would induces that the spacing should be the same as punctuation in plain text. However, the colon, in both examples is a separator between math. expressions of different nature. In this case, the rule that recommends to not have two formulas separated by a single punctuation mark (for clarifying the separation between formulas), should be adapted, and this leads to insert a space before the colon. In summary, IMO, the use of ":" instead of "\colon" is not a question of good or bad practice, but a question of personal esthetic preference. D.Lazard (talk) 15:14, 29 February 2016 (UTC)

In LaTeX, one distinguishes between seven different classes of symbols: ordinary, operator, binary, relation, opening bracket, closing bracket, and punctuation. By default, ":" is treated like a relation, while "\colon" is the same symbol treated as punctuation, but with some extra spacing added by the package "amsmath." As noted by the TeX.SE user egreg (who is one of the leading figures in the TeX community), it is in general considered wrong to use ":" in map expressions like $f:X\to Y$. On the other hand, the colon in set notation, while not strictly speaking a mathematical relation, should be treated as such with regards to spacing. In particular, there should be equal spacing on both sides of this colon. This is univeral consensus in the TeX community, and it is recommended in Donald Knuth's TeXbook itself, which is the original documentation of the TeX program.--Ørsted (talk) 14:19, 1 March 2016 (UTC)

Now that we are at it, the same goes for "|" vs. "\mid": Compare $\{x\in \mathbb {R} |x>0\}$ to $\{x\in \mathbb {R} \mid x>0\}$. Here "\mid" is the right choice.--Ørsted (talk) 16:42, 1 March 2016 (UTC)

I agree to all this. This is the sort of thing that should be included in this section of the MOS. —David Eppstein (talk) 18:43, 1 March 2016 (UTC)

Distinguishing notation for distinct concepts within an article

I would like opinion on the mixing of indistinguishable notations for, for example, dx in Leibniz's notation for infinitesimal and in the differential of the exterior derivative when both are used within the same article. I am aware that Wikipedia:Manual of Style/Mathematics § Typesetting of mathematical formulae §§ Font usage §§§ Roman_versus_italic is deliberately non-prescriptive. There are also instances where a distinction would be immaterial, such as to distinguish whether e^x refers to the exponential function or to use of the constant e in exponentiation in an article on real analysis (though we've seen people tie themselves into knots in complex analysis when conflating them). Is there value in recommending distinguishing notations for distinct concepts within an article through no less than a typeface difference? —Quondum 18:17, 5 March 2016 (UTC)

Using the same notation for several concepts is, in some contexts, a standard abuse. If the abuse is standard, we do our readers a service if we explain the abuse and a disservice if we diverge from standard usage.

Distinguishing concepts using solely a typeface difference is a terrible idea. It is far too easy for editors to make an inadvertent mistake, or for readers to fail to notice the different typefaces, or even for readers to fail to notice that the article uses different typefaces. Such an article would be illegible for those who use screen readers. Additionally, there's a very good chance that someone will misunderstand the intent of the article and will blithely replace all the type changes with a single style. Ozob (talk) 19:54, 5 March 2016 (UTC)

Okay, accepting that distinguishing symbols solely though typeface difference is a bad idea (though we do this routinely in examples such as v = |v|, I actually agree with you on this point), I feel that we need some way of reducing confusion through conflation. I also agree that we should not be diverging from standard notation, though there might be some wiggle room when the notation is not really standard (as with the 'd' of the exterior derivative).

Perhaps I should rephrase my query as: should we have a guideline that encourages editors to take care to clarify through notation or explanation which of several distinct and conflatable concepts is meant in any given usage? For example, I cringe when I see dx referred to as an infinitesimal in one paragraph, and without highlighting it meaning the exterior derivative in the next (thus allowing the reader to draw the inference that they are really the same thing, or at least that some of the editors think so). In these contexts I have been tempted to make it clear through words, but then because there is no clearly dominant standard, to use a typeface as a redundant indication. —Quondum 20:44, 5 March 2016 (UTC)

Perhaps I'm misunderstanding, but I don't see v = |v| as being related to your question. The vector v and its length v are such different types of objects that even an inattentive reader is unlikely to confuse them. Whereas the distinction between an infinitesimal dx and the exterior derivative dx of the function x ↦ x is more subtle because they serve similar purposes.

I believe that we should encourage editors to write well. Your example of dx being both an infinitesimal and an exterior derivative, with no hint to the reader that the notation has changed meaning, is an example of bad writing. Such articles should be fixed, and since dx is in both instances the standard notation, the fix should be to use words. If notational confusion is a widespread problem, then I agree that the MOS should warn editors about it. Ozob (talk) 21:02, 5 March 2016 (UTC)

I can interpret the equation v = |v| perfectly well as a sensible conclusion of a logical argument (where both occurrences of v refer to the magnitude of a vector v), so I still see this as which symbol is meant as being distinguished solely by typeface (and perhaps contextually inferred intent). More explicitly: many articles rely on typeface to make the distinction between the symbol for a vector and that for its magnitude to be salient, although you appear to have labelled this as a "terrible idea".

I'm coming to think that my rephrased question should be answered as: Which symbol is intended in any potentially confusing case should be made clear to the reader, but there is not necessarily a benefit in making an explicit guideline, since this is in general obvious and not likely to result in arguments between editors.

A (possibly perverse) side of me then wants to ask whether to consider the principle that you have enunciated, namely that determining which symbol is intended in any given use, if significant, should not rely solely (or even primarily) on the typeface, mainly for the reasons you have given. But I suspect that we'll find this principle violated so often in WP and elsewhere that it'll be problematic. —Quondum 22:00, 5 March 2016 (UTC)

I think this is an important issue to address and I agree with Ozob. In well-written textbooks, the authors define their terms to make clear their meanings, especially when potentially confusing. We editors should do the same. We should use unambiguous symbols when possible. But when we must use similar or identical symbols, we should explain in words what the symbols mean and how their meanings differ when they do. We should encourage editors to write well and this should be encouraged in the manual of style. — Anita5192 (talk) 23:21, 5 March 2016 (UTC)

Again, I don't understand why the point you are making is relevant. You began this discussion with the example of dx being used to mean both an infinitesimal and an exterior derivative. I believe we are agreed that this is poor style. If I understand you correctly, you are also asserting that writing v = |v| is also poor style, and that this is contrary to my stated position that we should not distinguish concepts based on typeface alone.

But in your initial comment you brought up the choice of Roman versus italic type style. I interpreted that to mean that you were considering the merits of letting (for example) dx be an infinitesimal and dx be an exterior derivative. When I said that using typeface to distinguish concepts was a terrible idea, that was the example that I had in mind. I maintain that it is a terrible idea because of the risk of confusion. But, as I tried to clarify above, a vector and its length are obviously different types of objects. The equation v = |v| does not use different typefaces to distinguish concepts; it uses them to distinguish objects (the object v has the type "non-negative real number" and the object v has the type "vector"). So while I don't think that v = |v| is especially good style, I don't think it's so horrible, either. Ozob (talk) 02:45, 6 March 2016 (UTC)

My initial comment used roman vs. italic typeface as an example; bold vs. non-bold is another instance of the same thing. It is also a matter of opinion as to whether an infinitesimal and the exterior derivative are "obviously different types of objects"; I'd say they are utterly so: the former may be regarded as a hyperreal number or similar, the latter as a mapping between functions on a manifold. We now seem to be getting ourselves tied up about a peripheral issues, since I'm in agreement with your larger perspective. I think we should rather refocus on Anita5192's very neat encapsulation above. —Quondum 03:58, 6 March 2016 (UTC)

Another example of the problem is the polynomial notation: in many textbooks, and some of our articles, P(X) denotes a polynomial P in the indeterminate X, while P(x) denotes the same polynomial with the indeterminate substituted for x. Moreover, the polynomial is denoted indifferently by P of by P(X). Although this may be confusing for the reader, this is mathematically perfectly correct: if the functional notation is clearly defined as representing the substitution/evaluation operation, the substitution of the indeterminate by itself results in the polynomial itself, and this allows writing P = P(X). IMO, the clarification of the notation for polynomials is important, and I have tried to make it explicit in Polynomial § Notation and terminology. This has been reverted as unhelpful by this edit. I have not reverted this edit, because I am unable to provide a reference, but I think that this deserves discussion. D.Lazard (talk) 10:12, 6 March 2016 (UTC)

HD formulas

Is there any way to see formulas with higher resolution? The PNG formula images are quite low res, and they look really ugly on a high resolution screen such as an iPad. Is there any way to use SVG or higher resolution PNG? --IngenieroLoco (talk) 17:26, 17 April 2016 (UTC)

Yes, in your preferences, in the "appearance" pane, set the "Math" preference to "MathML with SVG or PNG fallback". Then, if your browser can handle it, you should either get MathML or SVG. However I don't know whether that works in the specific case of the iPad. —David Eppstein (talk) 19:09, 17 April 2016 (UTC)

Thanks! They look great now! They do indeed work on iPad. --IngenieroLoco (talk) 19:25, 17 April 2016 (UTC)

Indentation

Hi, all. I'm finding issue with this MoS' recommendation that "when displaying formulae on their own line, one should indent the line with one or more colons (:)". While this is visually correct and sets the formula inside the body, semantically it is incorrect. In wikitext, the colon is supposed to be used as part of definition lists, like so:

;Wikipedia
:An online encyclopedia
;Britannica
:A print encyclopedia

which forms the HTML:

<dl>
  <dt>Wikipedia</dt>
  <dd>An online encyclopedia</dd>
  <dt>Britannica</dt>
  <dd>A print encyclopedia</dd>
</dl>

and the final result:

Wikipedia

An online encyclopedia

Britannica

A print encyclopedia

A problem arises when only the colon by itself is used for indentation:

Pi is the constant
:3.14

which form the html:

<p>Pi is the constant</p>
<dl>
  <dd>3.14</dd>
</dl>

and results in:

Pi is the constant

3.14

It's still forming a definition list when in reality we were merely trying to use the colon to indent formulae. This is a violation of semantics and creates incorrect HTML, since it creates a definition list without terms.

What we are actually attempting to do with using the colon is to inset the formulae. So instead, I propose that we use <blockquote> instead:

Pi is the constant
<blockquote>3.14</blockquote>

which form the html:

<p>Pi is the constant</p>
<blockquote>
<p>3.14</p>
</blockquote>

and results in:

Pi is the constant

3.14

While this results in a lot of whitespace, it is actually semantically correct. Thoughts? Opencooper (talk) 04:18, 17 August 2016 (UTC)

Changing the appearance now, in such a major way, is a bad idea. However, fortunately for you, the Wikimedia developers have the same preference for purity of semantics over actually, you know, looking to readers the way we want things to look — that's why we have math formulas rendered as images rather than the better-looking MathJax everyone else has. So, they have also noticed that the way we do it with a colon has problematic semantics. Rather than fixing the rendering engine to make : have a more useful semantics, they have given you an option for rendering math as an indented block. It is: the |display=block option for the math tag. So, e.g., the markup <math display=block>(L^-\oplus R^-)\Cup(L^+\oplus R^+)</math> shows up looking like this:

$$(L^{-}\oplus R^{-})\Cup (L^{+}\oplus R^{+})$$

I don't think there's any semantically clean way of making it indent more than one level, for situations such as this one where the surrounding text is already indented, but fortunately the need for that's rare in articles. —David Eppstein (talk) 04:25, 17 August 2016 (UTC)

Thanks for the response and agreed about the need for better semantics considering we're also indenting this conversation with colons, but sadly I don't think that will ever be addressed since previous talk page alternatives have failed. (LiquidThreads and Flow) Regarding the |display=block option, I just tested it and indeed it works. I'm glad to see there is a solution built in. So how about we change the wording of the MoS to recommend using that parameter instead of the colon? It won't fix past uses, but at least it could prevent the problem in the future. Opencooper (talk) 06:27, 17 August 2016 (UTC)

Like it or not, years of usage have made the colon the standard way of indenting on Wikipedia. I would accept making both the colon and |display=block valid ways of indenting equations, but only under the condition that both are seen as valid and that mass conversions from one to the other are not permitted. If necessary, we could reassess this decision later. Ozob (talk) 12:46, 20 August 2016 (UTC)

The correct way to indent in wikitext is with a colon. The fact that this colon may be rendered as a definition list is an implementation issue in the Mediawiki software. Tomorrow, or any time in the future, the developers could change the way that the colons are rendered. So the fact that colons are currently rendered as definition lists is not incompatible with the fact that colons are the correct way to do simple indentation in wikitext. The issue of indentation goes far wider than just mathematical formulas, and I think that it is better for us to continue to follow the general practice of wikitext (i.e. use colons) than to try some other system which will be different than other article or other types of indentation within the same article. — Carl (CBM · talk) 12:53, 20 August 2016 (UTC)

The problem is that it can't and won't be fixed. Alternatives to talk pages (which use indentation the most) have already been tried and failed. You could change the implementation, but you would either break definition lists, or you would break where indentation is actually needed. There's already a working alternative available for our use case (display=block), so we should start using that rather than continuing to misuse syntax which was never meant to be used like that. Lastly, it is not the correct way to indent. The proper way to indent text is to use CSS or to use other block-level elements like blockquotes (or display=block). The only reason the colon in wikitext indents is as a byproduct of being part of a definition list. This is harmful for both semantic and accessibility reasons. Note that I'm not saying we go back to every article and force the new way, but going forward we actually do things right. I know it can be hard to do things different than accustomed to, but continuing the old way will not fix the problem.

Just a note, that they look exactly the same (the first one is colon-indented and the second using display=block):

Formula:

$x+2$

Formula:

$$x+2$$

Opencooper (talk) 13:33, 20 August 2016 (UTC)

Curiously, on my system (Chrome, MathJax enabled) the second version is rendered without any indentation! As to the question, this semantic argument is way down the list of what is important to me as an editor. Indentation is important to me since I use it so frequently in math articles and I want to be able to accomplish it with the minimum amount of typing.--Bill Cherowitzo (talk) 16:44, 20 August 2016 (UTC)

I presume that's because MathJax directly parses the TeX source and isn't coded to read any attributes. It looks the same to me on OSX Chrome. Opencooper (talk) 21:11, 21 August 2016 (UTC)

A long time ago, someone on Wikipedia decided that the semantics of how the developers coded up the indentation produced by : are irrelevant. Since then, the Manual of Style recommendation has been to use colons for indentation. This is not something that will change short of an RfC with massive support, whatever the merits. Sławomir Biały (talk) 13:40, 20 August 2016 (UTC)

Manuals of Style aren't set in stone and this discussion is only within the scope of Math articles. If we as a WikiProject decide that semantic matter to us, it doesn't do any harm for us to use proper semantics while still allowing others to indent with colons. (Also, if you can find it, It'd be great to be able to read that discussion) Opencooper (talk) 13:46, 20 August 2016 (UTC)

We've been doing it this way since forever. Changing long-established conventions requires an RfC. Wikipedia has millions of articles, and probably several hundred thousand using : for indentation of equations. Having articles that have suitable visual appearance, and a single simple syntactic element for editors to indent equations, has a much higher priority than some trivial considerations about how the back-end software renders : semantically. I would suggest talking to developers about fixing their semantics, rather than proposing major changes to already thoroughly-established Wikipedia conventions. Sławomir Biały (talk) 15:11, 20 August 2016 (UTC)

As I said before, this Manual of Style is for mathematics articles, and for the very specific case of mathematical formula, nowhere else. And you're talking as if adding "display=block" to a tag is any more work than the way we use templates. I already explained why the semantics will be never fixed, instead the developers gave us the block display option. If one more editor insists on starting a RFC, I will, but I don't think it's necessary for a minor change in the math MoS which doesn't even affect the rendered output and is merely trying to correct things.

I really don't get this resistance to change here; I've clearly explained why the old way is wrong, offered a completely compatible and visually indiscernible alternative, and explained why the old way can't/won't change. Is it really such a huge loss if you have to learn something different for formulas? You already use specific syntax for quotes, for images, and for templates. It's funny how this is coming from a crowd that is willing to learn LaTeX which has its own crazy syntax too. Please don't let tradition and habit get in the way of correctness. Opencooper (talk) 15:22, 20 August 2016 (UTC)

Typing ":" is at least 7 times easier than typing "display=block", and any change affecting existing standards of possibly hundreds of thousands of articles definitely needs strong consensus before implementing. I notice that you have basically no meaningful edits to mathematics articles, yet you want to dictate that mathematics editors need to adjust because of some trivial consideration about html syntactic elements? This is meant to be an encyclopedia: above all, readers and editors come first. If you've never edited a mathematics article, I don't see how you can be in any position to say what makes editing easier, and it is already demonstrated that colons are at least indistinguishable from the reader's perspective, if not slightly more robust in terms of what is possible without delving into the intricacies of CSS syntax. Trivial issues like this are way down the list, and need strong consensus before implementing.

Finally, I do not see a problem with identifying an equation semantically with a definition list. Even in LaTeX, equations often carry labels or captions. In electronic theses, captions are often required for inline equation. This is a feature, not a bug, albeit one that has not been exploited in Mediawiki software. Sławomir Biały (talk) 16:10, 20 August 2016 (UTC)

What do my contributions to mathematics articles have to do with this discussion? I clearly have technical knowledge about the subject and you should look past the first few pages of my contribs before making accusations like that: I've edited math articles in the past that include formulas, as well as computer science articles, and have done work with formulas on Commons. The fact that you prefer to separate users into an "old guard" category to even consider their opinion only confirms the elitist and resistant-to-change stereotypes about Wikipedia. I'll think twice in the future about dictating a proposal on a talk page without having written ten math FAs first. And its not trivial because Wikipedia also aims to be accessible for everyone, and semantics are a necessary requirement for screen readers. Lastly, a definition list is not the same thing at all as a caption, refer to the w3c spec on the various tags to see how they are meant to be used. Opencooper (talk) 21:11, 21 August 2016 (UTC)

I'm astonished that you would think that editing mathematics articles is irrelevant to a discussion about best practices for editing mathematics articles. "Captioning" is the wrong word here (in the sense of a caption to a figure). "Labeling" is perhaps a better word, like equation numbers or names that can be cross-referenced. It seems like ":" has the proper semantics for a construction like this, no? And you have now asserted without a shred of evidence that readers are disenfranchised by what you allege are "improper semantics". Please find actual examples of screen readers that do not work with ":" but that do work with your proposed change. In any case, this is clearly a problem that is best addressed by contact the appropriate developer forum rather than try to change long established Wikipedia conventions. Sławomir Biały (talk) 00:25, 22 August 2016 (UTC)

What is the (intended, official) semantics of : in wikitext? Please notice that I am not asking about the semantics of definition lists in HTML. Mgnbar (talk) 16:15, 20 August 2016 (UTC)

The intended semantics is one half of an associative list of (key,value) pairs. (The keys are specified by the semicolon.) The closest I was able to find to "official" policy is MOS:INDENTGAP, but that was written as late as 2014, and earlier guidance in other parts of the WP and Help namespaces are not easy for me to find. The argument here seems to be that it is nonsensical to have (key,value) pairs with empty keys. Firstly, I'm not sure that's true. Secondly, I'm not convinced that it matters in any way that has practical significance, except to cause a pain for mathematics editors to have to perform additional CSS incantations just to get equations to indent properly. Sławomir
Biały 17:14, 20 August 2016 (UTC)

Thanks. Mgnbar (talk) 18:53, 20 August 2016 (UTC)

The original post in this talk page section claims that : is intended for definition lists, but I'm wondering whether this is an official policy, what the rationale is, etc. Because the general use, at least for my 11 years here, has been indentation, which is formatting not semantics. Mgnbar (talk) 16:24, 20 August 2016 (UTC)

I think the point is not so much what : is actually intended as, but rather that the Wikimedia software transforms it into html whose semantics (association lists) does not match that intention. Rather than changing the html markup in a way that would match actual usage (without changing its appearance) the developers seem to prefer that we go through cumbersome workarounds. —David Eppstein (talk) 17:20, 20 August 2016 (UTC)

The original poster seems more concerned about the semantics of the generated HTML than the semantics of the wiki markup. That's why I asked about the latter. The problem seems to be that a single wiki markup (:) must map to multiple HTML markups (dd, blockquote). But I'm not even sure that blockquote is semantically correct. Maybe what we need is a wiki tag for making displayed equations, like \[\] in LaTeX. Mgnbar (talk) 18:53, 20 August 2016 (UTC)

I would really like this, but I find it hard to imagine that the developers would agree to new wikitext markup, let alone markup which is intended for such a small audience of editors and readers.

I don't understand the resistance to display="block". I agree that typing ":" is a lot easier and I think that's a strong argument for continuing to permit it. And I know that mass style changes are usually a bad idea, so I think it's a fine compromise to permit both. But as far as my own contributions go, I don't really care if someone else changes them to display="block". It should be easy enough for someone to use AWB to change anything matching the regular expression ^: *<math> to <math display="block">, and I'd be happy so long as they don't presume to yell at me.

Also, I wouldn't object to an RFC. I think all the math editors involved in this discussion have been on Wikipedia for a decade or more; we might be too set in our ways. Ozob (talk) 19:43, 20 August 2016 (UTC)

I also have no strong objection to display=block, although I'm likely to continue using : myself due to ease of typing. —David Eppstein (talk) 20:10, 20 August 2016 (UTC)

Whatever you do, please don't go through with AWB trying to change numerous articles. I don't think this is a math-specific issue, so I don't see why we should worry about it here rather than on some more generally-focused page. Moreover, there are many kinds of indented material in math articles, only some of which are pure math. The math block indentation will not help with an indentation such as this:

$\Pi$ is a letter

Instead we get this:

$$\Pi$$ is a letter

which has an undesired new line after the formula. We should stick with the established convention and let the developers fix the semantics of the underlying HTML. — Carl (CBM · talk) 20:26, 20 August 2016 (UTC)

If want you text to stay on the same line as the block formula, you have to keep it in the math tags, just like you would for a blockquote:

$$\Pi \ {\text{is a letter}}$$

If you don't want the text to be formatted as well, you should just be using the formula inline. You'd have to do the same thing for LaTeX's "display" math mode.Opencooper (talk) 21:11, 21 August 2016 (UTC)

That has the same kind of semantic error you are worried about! Only math should be in math tags; other material, such as commentary, should not be. Replacing a well-established usage of colons for indentation with a non-established (actually, discouraged) practice of putting non-math into math tags is not an improvement. Moreover, if we did use inline math in that formula, instead of "block", we would need to use a colon to achieve the indentation! — Carl (CBM · talk) 21:19, 21 August 2016 (UTC)

I agree. While it's not common to want text next to a displayed formula, it does happen. As long as display="block" doesn't support this, it can't replace colons. Ozob (talk) 03:08, 22 August 2016 (UTC)

Regardless of the objections to Opencooper's specific proposals, his/her desire to make Wikipedia accessible (through proper use of web semantics) is admirable. I've inspected the HTML generated from display=block a bit, but I'm not familiar enough to tell whether it captures the semantics correctly. Does it? If not, then does anyone have a solution to the semantics problem? Mgnbar (talk) 21:31, 21 August 2016 (UTC)

A proper solution to semantics designed for math-only articles is to use a WP template for indented equations that would translate simple markup into display="block" or whatever HTML we might find more suitable in the future; we'd be able to fix any formatting bugs quickly. Template:Equation is a good candidate for adapting to this, or copy it to Template:Eq. Template:Math is already encouraged for inline formulae over both plaintext and <math/> anyway.

Regarding the argument that ":" has been standard for years, remember that while the best time to plant a tree was 20 years ago, the second-best time is now (particularly when we have the sapling, shovel, and soil already here next to us). SamuelRiv (talk) 16:13, 25 August 2016 (UTC)

This seems like the most reasonable suggestion thus far. However, there currently are (at least) three ways to typeset mathematics in Wikipedia, that were at one time recommended or supported by the Manual of Style, including {{math}}, <math> and html. Adding a fourth ("we mean it this time!") I think requires some further discussion. Although certainly an implementation as proof-of-concept might go a long way to convince the old guard. Still, I'd be most comfortable with a wider RfC on this. But I don't think we're quite to the point where an RfC can be stated clearly enough to get meaningful community input. Sławomir Biały (talk) 18:41, 25 August 2016 (UTC)

I'd be willing to consider a WP template. I think the first step towards that would be to make a template that imitated existing practice, namely the colon, and to see how we liked it: Is it easy to use, easy to type, etc.? I'm worried in particular about = and | since those have a special meaning inside templates; it's quite easy to get tripped up on those, and I wouldn't want to commit to a new template like this unless I believed that it was easy to use. Ozob (talk) 01:10, 26 August 2016 (UTC)

Good point. The golden rule is "Do no harm." So a fundamental question is, "What does it break?" Sławomir Biały (talk) 13:00, 26 August 2016 (UTC)

Template:math is not "encouraged" over anything; in fact it should not be used in existing articles without consensus, because it has unusual formatting such as using a serif font instead of the usual article font for inline math. The two methods that are encouraged are HTML/wikicode for simple inline math and the math tag for more complicated or displayed formulas. I still don't see how this is a math issue rather than a general Wikipedia issue. — Carl (CBM · talk) 02:19, 26 August 2016 (UTC)

Well indentation isn't used often on Wikipedia, and usually quotation templates are used there. (or specific templates like hatnotes) It's a math-specific problem because it's codified explicitly in the math manual of style to indent using colons. I think in the past I've seen it in another WikiProject too, but I decided to bring it up here now, and it's much easier to try to gain consensus on a single WikiProject rather than more instruction creep elsewhere. Though if we were to compromise and also include instructions for the dispay=block parameter here, I don't think it would be too many instructions since it's specifically for the single section "Using LaTeX markup". Opencooper (talk) 11:47, 26 August 2016 (UTC)

Here's another idea. Perhaps the developers can be persuaded to introduce a <dmath> tag that is simply a synonym for <math display="block">. This is as easy to type as :<math> but doesn't have problems with special characters the way a template would. And the string of characters <dmath> is so unlikely to appear anywhere that there shouldn't be compatibility problems. Ozob (talk) 15:09, 27 August 2016 (UTC)

Explanation of symbols in formulae

A {{why}} tag has been in Explanation of symbols in formulae since 2014. My impression is that the question was answered in this discussion, so I propose removing the tag and modifying the statement to read:

In Wikipedia, prose is preferred to lists. Therefore, a list such as ... should be written as prose:

RockMagnetist(talk) 17:07, 8 November 2016 (UTC)

Wikilinks inside formulas

I have occasionally seen articles in which some of the notation within a formula is wikinked, e.g. O(n) or log₂ n. This only works in html or {{math}}-formatted formulas, not in <math>. Should the MOS include guidance on such links?

My own preference would be to say not to do this. The color changes distract from reading the formula. If a piece of notation needs explanation for its expected audience to be able to understand it, then a link hidden inside a formula won't be visible enough to be adequate as an explanation; instead, the notation should be explained in the actual article text. And if a piece of notation doesn't need such explanations, what is the wikilink for?

I am not talking about wikilinks on an entire formula, to an article that is about the object described by that formula like SL₂(R). Nor am I talking about wikilinks or external links in references whose title contains a formula. Those are separate issues and I think they are non-problematic. This is only about links on proper subunits of a formula.

But this seems like the sort of thing that might be controversial, so maybe we can have a discussion to see whether the MOS should be changed in this way. —David Eppstein (talk) 22:30, 13 December 2016 (UTC)

Yes, wikilinks inside formulas should be discouraged. Perhaps not banned altogether, because there are exceptions (like SL2(R)), that seem like they could be reasonable, but definitely actively discouraged. Sławomir Biały (talk) 23:41, 13 December 2016 (UTC)

I agree. Articles should set up notation and conventions beforehand. I agree that SL₂(R) is an exception; I would say that the underlying principle of this exception is that SL₂(R), with the subscript and bold, is the correct name of this object, and that the name should be linked only when the object is being used in a sentence, not when it is being used in a formula. I mean to include inline formulas, even simple ones. For example, I would support, "SL₂(R) is the group of Möbius transformations," while I would object to linking SL₂(R) in, "A fundamental domain for SL₂(R) / SL₂(Z) is given by {|z| > 1, -1/2 ≤ Re(z) < 1/2} ∪ {|z| = 1, -1/2 ≤ Re(z) ≤ 0}." Ozob (talk) 02:11, 14 December 2016 (UTC)

I agree with everything that has been said about linking formulas. However, contrarily to what has been said at the beginning, it is possible to wikilink a whole <math> formula. For example, $\color {blue}{\operatorname {SL} _{2}({\mathbb {R}})}$, which is entered as [[SL2(R)|<math>\color{blue}{\operatorname{SL}_2(\Bbb{R})}</math>]]. It is even possible to color in blue only a part of the formula, but, in any case, the whole formula is linked. D.Lazard (talk) 10:16, 14 December 2016 (UTC)

I think this trick should not be used either, but also should not be discouraged per WP:BEANS. Sławomir Biały (talk) 11:12, 14 December 2016 (UTC)

Parentheses with Functions

I strongly prefer using parentheses with standard functions: $\ln(x),\;\sin(x),\;$ etc. It makes it absolutely clear what the argument to the function is. I have been burned by this before, when a writer was sloppy and didn't include them with a complicated argument. At the same time, I realize that $\ln x$ and $\sin x$ have a long tradition, and with just an $x$ in there for the argument, it's no big deal. Therefore, I propose adding the following text to the Functions section:

"If you are typing an argument more than one character long for a function, consider adding parentheses around the argument to make it clear what is inside the argument, and what is not."

Ackbeet (talk) 16:20, 30 January 2017 (UTC)

I have to say that I feel like this depends so much on the context that I'm not convinced there's anything useful for the Manual of Style to say. For instance, I would prefer $(\sin x^{2})(\cos x^{2})$ to $\sin(x^{2})\cos(x^{2})$ or $(\sin(x^{2}))(\cos(x^{2}))$. But I would also prefer $(\sin(x+\pi /4))(\cos(x+\pi /4))$ to $(\sin x+\pi /4)(\cos x+\pi /4)$ (the latter looks like a different function to me). Maybe my preferences are unusual; opinions? Ozob (talk) 02:58, 2 February 2017 (UTC)

When there is an explicit operator such as "+" or "–" in the argument, the parentheses are absolutely required, otherwise the meaning won't be what the author intended. When the only operations with in the argument are implicit, such as multiplication indicated by adjacent variables, or exponentiation indicated by superscript, the parentheses are optional. I don't think the MOS needs to state this, since it's a standard part of math notation, and I don't the MOS needs to state whether optional parentheses are preferred or discouraged. Personally I like to see them omitted when possible. Indefatigable (talk) 01:56, 3 February 2017 (UTC)

Missing amsmath support

I'm reposting the following comment here to hopefully get some feedback. I'm not sure where I should bring this up, so I'm trying here now:

I just "fixed" a formula that was using \operatorname* -- WP seems not to support the starred version, so the only thing I could really do was to remove the star. This improved the appearance, but it still falls short of the intended typesetting. Is there any way to add support for this feature? Where does one bring up this sort of request anyway? One other missing bit of support that seems crucial is for \genfrac. This is needed a lot, and the workaround(s) are usually less-than-desirable LaTeX. Deacon Vorbis (talk) 19:36, 12 February 2017 (UTC)

Just to show what happens: $\operatorname {*} {starred}_{x}f(x)$ and $\operatorname {unstarred} _{x}f(x)$

Deacon Vorbis (talk) 14:32, 13 February 2017 (UTC)

Punctuation inside formulae

The "punctuation inside the <math></math> tags" rule seems to put rendering before logic.

But the cited rendering fault (line wrapping from breaking between the formula and the comma) doesn't occur in modern browsers (Chrome version 58 and Firefox version 53) — with a few exceptional cases where breaking is actually saner than not breaking.

It messes up when you want to copy & paste just a formula, without inadvertently taking in any surrounding text. Which is exactly what I was trying to fix with edit 778770928, which was reverted citing this rule.

This seems similar to the rule about putting punctuation inside quote marks for purely aesthetic reasons, but in this case, without the benefit of "looking better"; indeed it looks quite a lot uglier to my eye, to have punctuation in a different font from the surrounding text.

Can we have this rule removed or even reversed, please? Martin Kealey (talk) 10:46, 8 May 2017 (UTC)

It's a technical requirement because otherwise the punctuation will appear on a new line depending on browser geometry. The guideline mentions an alternative using the nowrap template, but that should probably only be used on inline expressions, rather than in formulae on their own line, because of well-known issues with the baseline in PNG rendering on Wikipedia (especially a problem on mobile). Sławomir Biały (talk) 11:07, 8 May 2017 (UTC)

In the version of "Cubic function" that was linked, it is very easy for me to cause the comma to wrap on a different line from the displayed formula by changing the width of my browser window, using Chrome. The math rendering system on Wikipedia has many issues, and could be improved considerably, but for the foreseeable future we'll need to keep putting terminal punctuation inside the math tags rather than just after. — Carl (CBM · talk) 11:32, 8 May 2017 (UTC)

For what it's worth, I kinda do think punctuation inside math mode does look better, but the technical considerations are probably more important anyway. On a side note, please do feel free to remove LaTeX spacing, like \, before closing math tags. Also, naked punctuation inside math mode is generally fine; putting it inside a \text{ } command like in some places in that article isn't necessary. --Deacon Vorbis (talk) 12:23, 8 May 2017 (UTC)

Vector Notation

There doesn't seem to be a standard for styling the names of vectors across the whole of Wikipedia, and i'd love to see a group consensus on a standard for formatting them. For example, in the Linear algebra article, many scalar and vector variables have no visual distinction between them, which is confusing.

The many options available seem to be:

Markup	Result	Notes
<math>\vec{a}</math>	${\vec {a}}$
{{math|{{vec|''a''}}}}	a→	As described on Template:Vec there are additional options for this template.
{{math|'''a'''}}	a	The essay WP:Rendering math mentions this option.
<math>\mathbf{a}</math>	$\mathbf {a}$	Used on the page Vector notation.
'''a'''	a	Super simple, but not the best.

I think it is essential to modify any vector that is not bold or "arrowed" into one of the styles above. Of course, we can't be expected to change every existing variable to one single format -- if someone is using the math template, we shouldn't convert it to LaTeX -- but moving forwards it'd be great to choose one method and have that on this Manual of Style.

I personally prefer the bold italics serif version from the ISO Standard used in Vector notation by User:Adelphious but they couldn't use LaTeX to reproduce the standard, so they used CSS instead. -Boanus (talk) 17:56, 17 July 2017 (UTC)

I'm not really an expert on some of the minutiae here, but I suspect the lack of consistency is reflective of the lack of consistency of vector style throughout the literature (from research paper level through introductory textbook level). Different styles are more common in different regimes. Using no decoration to denote variables representing elements of a vector space (as in the linear algebra article that you mention) is really pretty common. There are some other techniques to help also by the way, like using Greek letters for scalars and Roman letters for vectors. My gut feeling says that if we can't even get people to agree to scrap roman d's for differentials (where there's only 2 options, and probably a significant majority leaning this way), then there's no hope here. But take all that with a grain of salt. --Deacon Vorbis (talk) 19:48, 17 July 2017 (UTC)

Note also that ${\overrightarrow {a}}$ (<math>\overrightarrow{a}</math>) is used in Affine space, and that, in this article the arrow is aimed to distinguish vectors from points. The advantage of this notation is allowing an easy notation for a vector defined by two points (such as ${\overrightarrow {AB}}$). Otherwise, I agree with Deacon Vorbis. I can add the remark that using a special notation for vectors make sense only when one works with a single vector space and a single field of scalars: which notation should be used when working with a vector space of matrices or functions? Also when working with a field extension, a vector space over the large field is also a vector space over the small field (with different dimensions), and the elements of the large field are scalars for such a vector space, and vectors over the small field. I think that nobody knows how managing special notation for vectors in such case. and that is probably the reason for which professional mathematicians use rarely a special notation for vectors. D.Lazard (talk) 21:06, 17 July 2017 (UTC)

I agree with some of the concerns raised. Vector spaces are ubiquitous in mathematics, and it's too much to ask, that a single notation be used for every element of every vector space. I doubt that it's even desirable.

On the other hand, maybe the proposal was intended more narrowly — just for vectors in R^n or something like that? That might be worth discussing.

By the way, your table above does not include the bold-italic notation, which I have never seen, but which is apparently preferred by the ISO standard. Mgnbar (talk) 21:45, 17 July 2017 (UTC)

On matters of typesetting mathematics, I prefer to think of it as the ISO nonstandard, since it is almost universally ignored. Sławomir Biały (talk) 22:02, 17 July 2017 (UTC)

Different fonts used for inline math and equations/formulae is seriously confusing

Symbols tend to look quite different, making it harder to relate the math to the text. A common example are column vectors denoted as $x$ and x vs. X and $X$ referring to matrices with the x^T as rows. The way most math articles on Wikipedia are written, it's already difficult enough to follow without having to do a double-take every time a variable comes up in inline text.

We should introduce a new guideline: Use uniform font styles to refer to the same variables.--2A01:E35:8B11:FA90:1E6F:65FF:FE3E:10A9 (talk) 11:43, 16 November 2017 (UTC)

Use of Greek Letter Delta for Triangle?

Is there any reason *not* to replace the Delta in ΔABC with something that actually is a mathematic symbol? And secondly, what should it be replaced with?Naraht (talk) 15:32, 3 October 2017 (UTC)

Well, not having a suitable replacement is probably a reason not to do so. I mean, there's (U+25B3 △ WHITE UP-POINTING TRIANGLE), but that's probably worse. Is this being used somewhere specifically that you think is causing a problem? --Deacon Vorbis (talk) 15:43, 3 October 2017 (UTC)

Deacon Vorbis Sorry, I didn't see the response. The reason that I ask is that I periodically go through Wikipedia looking for cases where greek letters and roman letters have been improperly put side by side. The type of issue that I first saw was Sigma Alpha Epsilon being written as a Sigma followed by an A and an E. While there are some quite reasonable cases where it should be left (physics and chemistry articles where Change in Time or temperature is Delta followed by a T) However a referring to a triangle with a Delta followed by three roman letters doesn't fall into that category, since the Delta is just a convenient thing that *looks* like a triangle. Naraht (talk) 20:23, 30 November 2017 (UTC)

Being a convenient thing that looks like a triangle is why it was originally used, I'm sure, but it has become the standard mathematical symbol for this usage. As such, it should not be replaced. —David Eppstein (talk) 21:08, 30 November 2017 (UTC)

Standard that should not be replaced, to me equals something that is part of the Manual of Style and as such, should be considered in that way. Please indicate any references that you have that it is a standard.Naraht (talk) 13:33, 1 December 2017 (UTC)

Transposition symbol

I saw that the unfortunate "^T" is adopted as transposition operator instead of the much better "^\top". Is there a reason? (Also, it's my first time using these talk pages, and I'm not sure I'm doing it right.) Atcold (talk) 19:55, 30 November 2017 (UTC)

(You're using the page just fine). You say the former is unfortunate, and the latter is much better, but you haven't given any reason for claiming so. I wasn't around when this was set down, so I can't be sure, but I would surmise that \top shouldn't be used for the simple fact that it's not a T, which denotes the "T"ranspose, while \top generally means other things. –Deacon Vorbis (carbon • videos) 20:09, 30 November 2017 (UTC)

That is exactly my point, sorry for not clarifying it before. "T" is a letter, whereas "\top" is a symbol. Just yesterday I saw some $\sum _{t}^{T}x_{t}^{T}$ which is just painful to look at. I'm aware this is a subjective matter. Nevertheless, many agree that "^T" is ugly (see https://tex.stackexchange.com/q/30619/33287), and "^\top" or "^\intercal" should be used instead. Atcold (talk) 21:19, 30 November 2017 (UTC)

But it symbolizes being a transpose (a word whose initial is the letter T), not being the top element of some kind of ordering (which is what \top generally means). Getting the meaning right is more important than an aesthetic preference. —David Eppstein (talk) 22:13, 30 November 2017 (UTC)

For the benefit of readers not familiar with TeX or LaTeX, "X^\top" = $X^{\top }$, "X^T" = $X^{T}$, and "X^\intercal" = $X^{\intercal }$. This MOS page also suggests "X^\mathrm{T}" = $X^{\mathrm {T} }$ and "X^\mathsf{T}" = $X^{\mathsf {T}}$. FWIW, almost all of my (relevant) university textbooks (from c. 20–30 years ago) that I consulted used the equivalent of "X^\prime" = $X^{\prime }$ for a transpose, but the first textbook I came across that used any kind of T-like symbol just used the simplest "X^T". I strongly object to using symbols with different (non-transpose) meanings just because the "T" they give "looks good". Personally, I would use "X^T", "X^\mathrm{T}", or "X^\mathsf{T}", with a slight preference to the last one, since they all use the English letter "T" and not some ad-hoc T-like symbol. - dcljr (talk) 05:32, 2 December 2017 (UTC)

LaTeX (like ${\binom {10}{5}}+e^{\pi }$) in section headings

According to the main page, LaTeX won't render in section headings, but this seems not to be the case anymore. Whether or not it's a good idea otherwise is another issue, but it seems like we should update this. Thoughts? --Deacon Vorbis (talk) 14:55, 5 July 2017 (UTC)

Latex renders in section headings (at least in some browsers), but, if a section heading contents some latex, links to this section do not work properly. As an example, you may try to reach to this section by clicking on the arrow in the entry of this page in your watchlist. Thus latex in headings must be strongly discouraged. D.Lazard (talk) 15:45, 5 July 2017 (UTC)

I don't have any problem following the TOC link to this section, however links to here in the page history do not work (e.g., see D.Lazard's revision of 5 July 2017‎ — this seems to merely be a problem with how the links are formed in the edit summary box). The associated "[edit]" link works fine to enable editing of this section. And while the anchor text is quite bizarre looking: #LaTeX_(like_%7F'"`UNIQ--postMath-00000001-QINU`"'%7F)_in_section_headings, wikilinks formed using it do actually seem to work. - dcljr (talk) 05:47, 2 December 2017 (UTC)

History of this page

I chased down the time when colons were adopted as the Wikipedia system for indenting displayed mathematical content. Although the WP:MOSMATH page appears to be created in 2005, the actual style for indented equations was documented as early as 2002 [4]. The fact that guidance on indentation was included so soon illustrates how indenting displayed equations is fundamental to the presentation of mathematics - it is not a side topic for this page. The page history also shows that this page was not "forked" from any other MOS pages. Indeed, any other MOS page which describes formatting of mathematics is likely to have been written after this page, and could be viewed as a fork of this page. — Carl (CBM · talk) 16:28, 12 December 2017 (UTC)

No one said this page forked from another one. Rather, it's PoV-forking of guidelines, and against WP:CONLEVEL policy, to filibuster again this MoS subpage being updated to conform with current main-MoS and MOS:ACCESS advice that recommends more accessible markup over less accessible. It's "how to indent content better" provisions, and it has nothing to do with maths in particular. There's nothing special about a block of math content versus a block of poetic or linguistic or comics content. It's content, and there's a crap way to indent it that happens to be easy but with poor results, versus several well-tested and long-deployed better ways to do it that cost nothing but a few extra characters. If maths editors couldn't handle using a template instead of a colon, they couldn't handle <math> markup, or wikimarkup in general, in the first place.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:47, 12 December 2017 (UTC)

"No one said this page forked from another one. Rather, it's PoV-forking of guidelines," - which page is the fork, in that case? The MOS has always allowed the use of colons, and WP:INDENTGAP even says they are "commonly used". There is no general MOS page on "indenting all kinds of content"; to the extent that WP:INDENTGAP has advice on indentation, it is purely advisory, not in any way mandatory nor controlling. — Carl (CBM · talk) 22:38, 12 December 2017 (UTC)

Re: "which page is is the fork...?" – Repeat: No one said a page forked from another one; rather, it's PoV-forking of guidance content (of what a maths-topical MoS subpage says about an accessibility matter about which is it not authoritative, from what the main MoS page and the accessibility MoS page say about it). There absolutely is general MoS material on indenting all kinds of content – lots of it, all consistent except at MOS:MATH: "Various templates are available for indentation, including {{block indent}}, and (for inline use) {{in5}}. (at MOS:INDENT, a new shortcut created just for you :-), and see the lengthy quote below from MOS:INDENTGAP, they key material from which is "Colons (:) at the start of a line .... produces broken HTML .... The result is ... confusion for any visitor unused to Wikipedia's broken markup. This is not ideal for accessibility or semantics." And at MOS:DLIST: "When wikimarkup colons are used just for visual indentation, they too are rendered in HTML as description lists, but without ;-delimited terms to which the :-indented material applies. Use indentation templates in articles, e.g. {{in5}} or one of its variants for one line, and {{block indent}} for more than one line (even if misuse of description list markup on talk pages is too ingrained to change at this point)." (recently updated to refer to the same templates instead of different, older ones, but substantively unchanged). "[I]t is purely advisory" – Um, everything in all guidelines is purely advisory, including this one you're so protective of/controlling over. Even policy material can be viewed as advisory, in light of WP:IAR and WP:COMMONSENSE, other than legal policies imposed on WP as hard requirements by WP:OFFICE. So, the "advisory" point you're making is not a real point. No one said anything at all about anything being "mandatory or controlling"; this has never been about anything other than MOS:MATHS recommending a practice deprecated in favor of more accessible practice specified by the main MoS page and the accessibility page and the list-markup page. The material in question has nothing at all to do with mathematics and <math>...</math> markup, only with good versus awful ways to shift content to the right. I think we've been over this at least 5 times now..  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:55, 13 December 2017 (UTC)

Until this edit (which was even reverted) WP:ACCESS said the following:

Colons (:) at the start of a line mark that line as part of an HTML definition list. The visual effect in most web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on Talk pages. This is not ideal for accessibility or semantics, but is currently in wide use. Blank lines should not be placed between indented lines of text, as they are interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance: : Text here. :: :: More text.

which is not in conflict with the MSM guideline. So pardon me if I disagree that an edit that is just a few days old has a higher CONLEVEL than a guideline that has existed since the early days of Wikipedia. As far as I am aware, the only place where this issue is being formally discussed (the pump) also does not reveal any consensus to change the existing guideline, contrary to the claim being advanced here that there is some larger consensus to change the established guideline for the indentation of mathematical equations. Sławomir Biały (talk) 22:43, 12 December 2017 (UTC)

To be fair, the new edit also only describes something as "a more accessible replacement" - there is no language saying that the replacement must be made, only that it is an option to consider. I do think that any change to the MOS which actually required (in order to conform with the MOS) that colons needed to be replaced with something else would require much more consensus than just an undiscussed edit. The edit is OK with me precisely because it only gives an option without adding any new requirements on editors. — Carl (CBM · talk) 22:58, 12 December 2017 (UTC)

Yes, but subsequent undiscussed edits have substantially changed the balance. Sławomir Biały (talk) 12:00, 13 December 2017 (UTC)

Nah. Same stuff was already at MOS:INDENT and MOS:DLIST.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:55, 13 December 2017 (UTC)

"Was already at" = Two hours ago? With a personal attack against a group of editors thrown in the edit summary for good measure. Seems pretty tendentious. In the closing of your RfC, it was mentioned that this behavior is not appropriate, and could result in sanctions. This change too was very recent, and especially the paragraph mandating the use of templates should be removed as in contradiction with longstanding guidelines per WP:CONLEVEL. Sławomir Biały (talk) 14:16, 13 December 2017 (UTC)

Not recently added, just updated to stop recommending an obsolete template in that particular case. I've reworded it less emphatically, though, if that will dissuade you and ... what, one? ... other math editor from rampaging against everyone who cares about accessibility. WP:STICK, at all 'at. You can rant for the next five years if you like, and it's not going to change the fact that abusing : by itself for visual indentation causes validation failure, problems for screen readers, WP:REUSE issues, and other headaches. Just give it a rest, man.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:58, 13 December 2017 (UTC)

I do not think it is appropriate to describe the actions of other editors with whom you disagree as "rampaging". I also object to the implicit subtext here, that when you make an edit to a guideline, you are simply upholding community consensus, but when others make an edit to a guideline, they are on a "rampage". That is completely unconstructive. "Give it a rest, man." I agree. I wish you would take your own advice. Sławomir Biały (talk) 22:15, 13 December 2017 (UTC)

Fair enough; I should not be hyperbolic.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:11, 13 December 2017 (UTC)

(edit conflict) Exactly, CBM. It is not really possible under policy for a guideline to "forbid" editors from doing anything. Under WP:EDITING policy, as long as you're doing something productive, within the core content policies, you just go right ahead. If the style or markup is crap; some WP:GNOME will clean it up later. No one's ever been banned or blocked for not following some MoS line-item, and it's not plausible anyone ever would be for something that's just recommended as less problematic. The issue here is that a handful editors want to effectively require the misuse of : markup for visual indentation and deny that MOS and MOS:ACCESS and MOS:DLIST have identified a more accessible way to get the same effect. That denialism's not okay; it's a PoV fork of the advice here against three other guidelines (which are actually relevant to indentation and list markup accessibility while MOS:MATHS is not). This is a WP:CONLEVEL failure (MOS's lead: "If any contradiction arises, this page has precedence over all detail pages of the guideline"). There is no defensible basis for the idea that it can be forbidden in MOS:MATHS to recommend and illustrate the less problematic markup, even if you and Sławomir Biały and whoever else prefer personally to use the more problematic : markup. That really is all there is to it. A couple of you have made a drama mountain out of a technical molehill that has been considered controversial by precisely zero other people on all of WP for years.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:55, 13 December 2017 (UTC)

I agree that CONLEVEL is important. This RfC closure establishes that the community consensus is to continue to allow colons for indentation of mathematics displays. Sławomir Biały (talk) 14:20, 13 December 2017 (UTC)

Nah. This blatant and falsely-worded canvassing establishes that the RfC was derailed by a bloc vote from one special interest group who did not understand the wording of the RfC. It's a WP:FALSECONSENSUS. But, it's a moot point. No one tried to "ban" using colons for indentation anyway! The RfC had literally nothing to do with that at all, only with whether two editors here can filibuster against MoS subpages agreeing with the main MoS page.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:58, 13 December 2017 (UTC)

Carl's summary of the issue seems reasonable to me. Sławomir Biały (talk) 22:11, 13 December 2017 (UTC)

Make that case, then. If you still think this is worth any more of our time.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:11, 13 December 2017 (UTC)

Indenting

@SMcCandlish: I object to using {{in5}}, which uses multiple nonbreaking spaces to indent what follows, for indenting displayed math content. Unfortunately, the "obvious" <math style="margin-left:2em"> doesn't seem to be supported (perhaps a Phabricator task should be opened about this?). A simple TeX-based solution would be to start the math content with an initial "\quad\ " (a quad followed by a space):

$\quad \ \int _{0}^{\pi }\sin x\,dx$

Colon-provided indent, for comparison.

There might be a better (if not more convenient) TeX-based solution if I thought about / researched it a bit. Opinions? Suggestions? - dcljr (talk) 06:19, 2 December 2017 (UTC)

Then do that. Just don't given wrong HTML advice. PS: There's nothing wrong or objectionable about what I wrote; MoS doesn't care at all about non-rendered whitespace in wikicode, and there's nothing invalid about it. We do not have a rule to compress away whitespace in wikicode, and shouldn't have one, since we often use it to good effect. For every person who would object to the version I use there are probably 1+ who prefer it because it makes it easier to find the math markup in the source. I don't really care either way as long as we stop mis-advising abuse of list markup for non-lists, which is an accessibility problem.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:24, 2 December 2017 (UTC)

(Ignoring your second sentence, which makes it sound like I'm the one who was giving editors the "wrong" advice…) There is actually something very wrong with the {{in5}} approach. Look at the HTML it actually outputs: "<p>&#160; &#160; &#160;" (alternating non-breaking and regular spaces). This means long math content can actually be bumped to the next line, resulting in no indenting at all. In any case, I'm glad you see my suggestion as a viable alternative. What say other users? (In the meantime, shall we revert your change, SMcCandlish, until a better approach is found?) - dcljr (talk) 06:46, 2 December 2017 (UTC)

Then fix the template or use a different one. No-wrapping the spaces that template uses is a trivial fix, and there's probably another one that more sensibly does this with CSS padding. The point is, do something other that abuse of list markup. No, we shouldn't revert it, because abuse of list markup like that is, well, abusive, while the consequence of a long math content wrapping to a new line without an indent is just a line without an indent which isn't invalid, just not perfect. I've asked the Lua handlers of {{in5}} to fix the wrapping issue.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:35, 2 December 2017 (UTC)

Oh, duh. I actually wrote the ideal template for this, and forgot: {{blockindent}}. Just tried that, and it works fine. No blank line needed, either. (I created this originally as a {{blockquote}} replacement for material that isn't a quotation).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:38, 2 December 2017 (UTC)

The standard way to indent in mathematics articles is to use colons, and this page should reflect that. I am not sure I know of any math article that uses templates for indenting displayed math formulas. The HTML generated is irrelevant to this point - "colon" in wikitext means "indent", not "dd", and at any point Mediawiki could switch from "dd" to anything else that achieves an indentation. It is not in any way an abuse of wikitext to use colons to indent content. — Carl (CBM · talk) 15:08, 2 December 2017 (UTC)

Using something other than a colon is probably semantically better, but it's hard to see justifying the change at this point. On a different but related topic, I was wondering about the practice of having blank lines before and after indented equations. Doing so seems to help readability while editing, but again, semantically it would seem to be wrong, because it indicates paragraph breaks where there shouldn't be any. I don't know of a good way around this, but maybe it's worth thinking about along with the above. –Deacon Vorbis (carbon • videos) 15:27, 2 December 2017 (UTC)

I would agree about the spacing issue if the blank lines had an effect on page spacing, but I don't think they do, looking at the source of this from my sandbox: [5]. In general displayed math should not start a new textual paragraph, of course.

Regarding the colons, I think the key issue is that semantically, colons mean "indent" in wikicode. So the concern is not with the semantics of the wikicode but with the current implementation of those semantics, which is not an issue I think we need to worry about as editors. But moreover the very well established standard is to use colons, not some other template, for indenting displayed math. — Carl (CBM · talk) 15:36, 2 December 2017 (UTC)

Er, well, actually colon means "here is the definition part of a definition list". It just happens to be the case that that meaning causes things to be indented. I think that "indent something" is far more frequent than "definition part of a definition list" as the intended meaning by the editors using it, and that it would be a good idea for the Wikimedia engine to use semantic coding that reflects that, but it doesn't. In the meantime, if you want semantic purity, there's always <math display="block">, e.g.

$$E=mc^{2}$$

(But there is no way that I know of to use that to get more than one indent, e.g. to match the indentation of this comment.) —David Eppstein (talk) 03:11, 3 December 2017 (UTC)

Yes. It definitely does not mean indent; we just abuse it for that on talk pages because we're lazy.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:50, 3 December 2017 (UTC)

Depends on what you're trying to do. For what we've been talking about:

{{block indent|1=Your math here.}}
{{block indent|{{block indent|1=Further-indented math here.}}}}
emits:

Your math here.

Further-indented math here.

For simple stuff (but requires either a blank line or a <br /> preceding it, and indents less by default):
{{in5}}Your math here.<br />
{{in5}}{{in5}}Further-indented math here.<br />
or
{{in5|10}}Further-indented math again.<br />
yields:
     Your math here.
          Further-indented math here.
or
          Further-indented math again.

Neither of these produce bogus list markup, but the {{in5}} stuff can wrap such that the math is non-indented, as someone noted above, if the math content is long (or the viewport is tiny). There are also other indentation templates, but they are also space-based like {{in5}}. The most robust is the {{block indent}} approach.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:50, 3 December 2017 (UTC)

PS: You can also use {{block indent|left=X}} where X is an value in em units, to change the indent spacing (e.g. to make it match regular list indentation instead of blockquote indentation, or to indent further instead of using a block indent nested in a block indent. Another approach to the first example would be to open a block indent, put the first math, then do another block indent, do the extra-indented math, then close both block indents. That would be "cleaner", unless you need some non-indented text between the indented and extra-indented material, e.g. to introduce the second example.

I'm not sure why you'd want to have math examples indented to different levels in the first place, though.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:54, 3 December 2017 (UTC)

I think David E. buried the lead a bit: it appears that <math display="block"> is exactly what we've been looking for. Getting it to be generally accepted by editors is, of course, a totally different matter. I agree (with the implication of SMcCandlish's last comment) that indenting displayed math beyond one level is probably a relatively rare requirement in articles, but I imagine there are probably several legit examples lying around. In those cases, {{block indent}} looks like an acceptable approach:

$f(x)=|x|$

(assuming, of course, that it's not more appropriate to handle the formatting inside the TeX content itself).

BTW, the template-inside-template approach shown above to get further indenting is not necessary, since {{block indent}} has an em parameter to control how far to go (in ems, of course):

{{block indent|em=4|<math>f(x)=|x|</math>}}

$f(x)=|x|$

Yay. - dcljr (talk) 08:16, 3 December 2017 (UTC)

• Comment. Please note that changes such as this, which mandate a different way than the norm for all mathematics articles out there, including all mathematics featured articles and good articles, requires very strong consensus. The last time this issue was raised at WT:WPM, there was no consensus for a change. Similarly to this discussion, the change was imperialistically imposed on high by editors who do not routinely need to edit mathematics articles. Templates and display blocks are simply not as convenient for editors as colons, which have been used for indentation in Wikipedia since the very early days. (See WP:INDENTATION, Help:Talk, as well as the history of this guideline.) Even the alleged "violation" of WP:ACCESS is spurious: "This is not ideal for accessibility or semantics, but is currently in wide use." That guideline then gives guidance on how to use colons for indentation purposes! Consensus should be established with a formal RfC, as I said the last timme this issue was raised. Sławomir Biały (talk) 12:39, 3 December 2017 (UTC)

A couple further quick observations: If you're manually setting the indentation size (like the 4em above), you're almost surely doing it wrong. If any change is made, it should probably produce something that's at least very close to what a colon produces. Otherwise, we'll have pages with mixed amount of indentation as new stuff is added. Alternatively, someone could come up with a very thoroughly tested solution for converting automatically. –Deacon Vorbis (carbon • videos) 13:02, 3 December 2017 (UTC)

It it also very easy to find featured articles, such as Californium, which use colons for indentation. That is the standard way of indenting displayed formulas, is the only way in Help:Wikitext, and is explicitly allowed by WP:ACCESS. The real solution to access issues is get the developers to stop Mediawiki emitting dd/dl lists when colons are used for indentation, rather than trying to avoid using indentation wikicode to indent things in wikicode. In general, though, if we are looking at the HTML being emitted, we are doing it wrong. Editors work with wikicode, and the the HTML is the problem of the developers. — Carl (CBM · talk) 13:33, 3 December 2017 (UTC)

WP:OTHERSTUFF and WP:NODEADLINE.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:37, 3 December 2017 (UTC)

@SMcCandlish: I think Carl's remarks are entirely relevant and do not raise the spectre of WP:OTHERSTUFF. OTOH, your repeated reverting of the project page back to your preferred version suggests you think there is a DEADLINE in getting these guidelines changed. Please try to gain some kind of consensus before making such a major change to the guidelines. (Yes, I see the VP discussion linked below.) @Deacon Vorbis: The specific "4em" example I used above was only to get the mathematics at the third level of indenting. I assume that "almost never" happens in articles. @CBM: Considering the HTML that actually gets generated can help to decide which wikicode approach is better than another, or whether an approach can be improved (as just happened with the {{in5}} template/module). As for developer-involved solutions, I think a more realistic approach (rather than deprecating or reimplementing colon-indenting) may be to work towards a <math>-only solution for indenting mathematical content in particular. I've opened a new subsection for this below. - dcljr (talk) 11:36, 4 December 2017 (UTC)

Accessibility versus convenience in indentation (RfC at VPPOL)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:37, 3 December 2017 (UTC)

Extending math element functionality

Like I said above (although not to this level of precision), just using display="block" seems to give exactly the same indenting as a single colon (does anyone see otherwise?):

$|x|$

$$|x|$$ These are, respectively, coded as:

• :<math>|x|</math>
• <math display="block">|x|</math>

This tells me that it is not unreasonable to consider implementing the indenting of math content with the display="block" approach. (Again, as I suggested above, having the option and requiring it are two different things. Here I'm discussing having the option to indent in the math element itself. Also remember that MediaWiki features are used in wikis other than those hosted by the Wikimedia Foundation. Mathematically oriented wikis may actually like the idea of colon-less indenting of math content.)

Unfortunately, the way display="block" is currently implemented appears to result in bad HTML: paragraph opened before a <div> element then closed after it. Given this, I'm not sure I understand what the thinking was when the feature was originally proposed/implemented (since "displayed" math [in the TeX sense] almost always occurs inside a paragraph, yet a <div> element cannot). Perhaps someone knows where this was discussed? The only thing I've been able to find is mw:Extension:Math/Displaystyle, which doesn't have any real discussion.

Another, more serious, problem is that the page I just linked to reveals that on the MediaWiki wiki, display="block" results in centered displayed math (just like in TeX), not displayed math indented to the level of one colon! (Waaah…)

Notwithstanding all of the above, indenting to the level of however-many colons could be implemented in the <math> element with new syntax. This very idea came up back in December 2008 (phab:T18829) and was quickly nixed (within 14 hours!) by a developer (Brion, the only other user to comment on the bug), but opinions can change in 9 years, so maybe the idea would not be dismissed out of hand if some kind of consensus were reached about what the syntax might look like.

The proposer in 2008 seemed to be suggesting:

• <math indent=number>

where number is the number of "colons" of indenting to apply (0 would mean no indenting, which the proposer said would be the default and mean inline display — I would lean toward having 0 mean non-indented but still "displayed" math [i.e., after a line break]).

Another possibility is to put it inside the display attribute:

• <math display="indent">

for displayed math with one-level indent;

• <math display="indent:number">

for displayed math with number-level indent (0 or more, 0 meaning aligned to left margin).

I could probably come up with other possibilities, but I've been typing this up for an insane amount of time already. I need to go to sleep. - dcljr (talk) 11:36, 4 December 2017 (UTC)

In principle I do not object to mentioning <math display="block">, but share your concern that if this is supposed to be the solution that leads to completely valid html, that it might fail at that. Sławomir Biały (talk) 11:41, 4 December 2017 (UTC)

Re "Perhaps someone knows where this was discussed?": https://phabricator.wikimedia.org/T111712, I think, and before that at Wikipedia:VisualEditor/Feedback/Archive 2015 3#Indentation for mathematical equations. —David Eppstein (talk) 11:44, 4 December 2017 (UTC)

Yep, there it is… lots of prior discussion. [grin] For the record, there is also phab:T6521 for discussion about changing the way MW handles colon-indenting and semicolon-bolding outside the context of a deflist.

Interestingly, phab:T111712 mentions the possibility of creating:

• <dmath>

as an abbreviation for <math display="block">, an approach I think is particularly promising. Someone else (in the task) objected to creating a new tag, but I think it's a pretty neat solution. The new tag could then be used along with sitewide style sheets to style displayed math as either indented or centered, as desired by the wiki (IOW, whichever alignment is chosen as the "default default", a wiki could change it to the other default alignment in their site's CSS).

And then

• <imath>

could be created for inline math (display="inline"), and no already existing uses of <math> would need to be changed to get the benefit of the kinds of "logical" changes people have wanted to make to the behavior of <math> (e.g., that inline math should use inline styling by default, and displayed math should use display styling — this change would bring wikicode math much closer to the way TeX/LaTeX does it, which many technical folks would likely welcome). All current math content would continue to work the same way it does now, and instances of <math> could be slowly changed to <imath> or <dmath>, as appropriate, in the normal course of editing. (The <math> tag would remain a viable option into the future.) Unfortunately, I have no idea whether having three different tags as "entry points" to the same underlying code would cause any kind of problem from the developers' side. I would hope not. (Note that the display="block" and display="inline" functionality already exists. The change would be the use of the new tags and having different defaults for the two situations.) - dcljr (talk) 23:25, 4 December 2017 (UTC)

Something like this sounds like a great idea. It would be better to do it with CSS indentation (demoed here with margin:left) rather than by changing the content type to a block element, since we can't guarantee the context; a block element wouldn't be valid inside an inline element like <span>...</span>.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:14, 11 December 2017 (UTC)

Probably it would be easier just for Math to nix the opening paragraph HTML when it's in display form. I submitted phab:T182041 for that issue. As for display math, I think it makes more sense to do something like phab:T182673 which I submitted today. I dislike the imath solution because it a) adds tags for the same semantic information and b) because the solution should work with chem as well as math without an even larger number of tags. --Izno (talk) 12:47, 12 December 2017 (UTC)

Good point.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:52, 12 December 2017 (UTC)

This is an idea, but it requires things to be in math tags, while of course many formulas are formatted in plain wikitext, because of article-by-article decisions. For example, the display in californium ("History"). We also have to be careful, technically, with displayed equations that have math tags and additional text outside of math tags, as in ROT13 ("Description"). I think that fixing the output for colons in Mediawiki seems like a more comprehensive solution, because that would fit many more use cases, compared to looking just at the math tag. — Carl (CBM · talk) 13:11, 12 December 2017 (UTC)

Surely true, but after a decade, it seems clear there's a great inertia with regard to the colon/dd markup, and it's probably easier to get <math> and <chem> adjusted.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:52, 12 December 2017 (UTC)

WP:NODEADLINE. There is no reason to rush an incomplete fix. But we can and should encourage the developers to fix the more general problem with the HTML that is being emitted. — Carl (CBM · talk) 16:09, 12 December 2017 (UTC)

Oh, I agree, but it's unlikely to happen quickly if it all, and it's no excuse to use bad markup in the interim. I am happy to see some traction on the : Phabricator ticket for the first time in years but they keep saying, basically, "it's hard" which generally translates to "WONTFIX", either formally or through perpetual inaction.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:47, 12 December 2017 (UTC)

It appears extremely unlikely that the Phab ticket is over going to be acted upon. "It's too hard", basically.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:57, 20 December 2017 (UTC)

I think <math display="block"> is the way to go. It gets centered by default, but this was changed on common.css (see Wikipedia talk:WikiProject Mathematics/Archive/2015/Sep#Styling of block mode display of math formula). Helder 12:59, 26 December 2017 (UTC)

Please add explicit guidance re markup vs. special characters

Hello.

I propose/request that the MOS be amended to include explicit guidance regarding the use of markup versus special characters when editing mathematical formulas.

The MOS currently gives guidance for specific cases of similar situations. For example, it prefers <sup>2</sup> instead of ². It does not, however, address the possibility that an editor might directly enter the "special" character itself: ². This markup-versus-special issue is the subject I request be addressed.

By providing the "Special characters" toolbar, which directly inserts hard-to-type characters into the wikitext, Wikipedia seems to favor that approach over markup. I find this problematic.

The "toolbar" method requires the editor to search for and identify the desired character by eye alone. This effort is difficult.

• There is often no easily-recognizable strict total order on the set of symbol characters. It is not even clear within which category to search. (Is the "sigma" I want in category "Greek," "Greek extended," or "Symbols?")
• Even worse, can my sigma appear under multiple categories, suggesting that the correct choice of category depends on the character's semantic function? For example, if I wrote an article about a mathematician from Athens, would I need to use sigma from one toolbar category when specifying his name, and sigma from a distinct toolbar category when typesetting the formula he produced? Likewise, the toolbar offers "↑". Is that supposed to mean Knuth's up-arrow notation, or is it just a dingbat? Is there even a difference? Can this situation even happen?
• Even if the editor knows where to look, some characters are difficult to distinguish visually. Consider Ö and Ő and Ố.
• The above problems do not easily abate as the editor gains experience. Even if I know I want Knuth's notation, there is no way for me to quickly specify it.

The consequence of this difficulty is editor fatigue, and therefore editor carelessness. Editors who want beta will just use ß (Eszett) if they find it first. In the long term, I am concerned that "emojification" of Wikipedia's mathematics content will create ambiguity and decrease the value of articles. (See Emoji#Emoji_communications_problems.)

The alternative to the "toolbar" method is markup using one of the supported languages such as HTML or <math>. This eliminates the ambiguity problem (ala β), but has the disadvantage of a steep learning curve. I suppose that my preference for the direction of guidance is clear, but my aim in writing today is to gain clarity for myself and other editors, not to promote my particular opinion.

To summarize, I request that the MOS

1. clarify whether or not (English) Wikipedia has a preference regarding markup versus special characters, and if so, specify what that preference is.
2. clarify whether editors should or should not observe a semantic difference between symbols/characters used in formulas and used elsewhere.
3. advise that this guidance concerns an advanced editing technicality, and that inexperienced editors should not allow it to dissuade their participation. (A WikiGnome will come along to fix any mistakes.)

Thank you,

Christopher Ursich (talk) 00:31, 19 February 2018 (UTC)

Um, Christopher, you don't have to use bold on every link. In fact, please don't make links bold unless there's some particular reason to emphasize them. - dcljr (talk) 04:11, 20 February 2018 (UTC)

The preference for explicit superscripts over the superscript-2 character has nothing to do with how it is marked up. It is because the character doesn't match other superscripts; e.g. ''x''⁵''y''² comes out as x⁵y² which (at least in my view) has the 2 tiny and squished into its variable compared to the 5. So you should not use this character regardless of whether you type it directly or use the html entity. For the same reason, for characters that are ok to use directly, it should not matter whether you type them or name them. I think we should not express a preference for one way or the other, and in fact more strongly I think we should discourage editors from changing one way to the other or vice versa, because it is a useless waste of time for them to do so and a useless waste of time for the rest of us to see those changes on our watchlist. Better to encourage those editors to do something else, like creating actual content. —David Eppstein (talk) 06:09, 20 February 2018 (UTC)

Logarithms?

A discussion on this topic from 2010 is in the archive, but no conclusion seems to have been reached, there's nothing in the article, and I'd think there ought to be a consistent guideline here. I would propose $\ln$, $\log _{10}$, and $\log _{2}$ always be used for their respective meanings, with the bare $\log$ being reserved for contexts such as asymptotic behavior. Mathematicians might object to the foremost, but this being Wikipedia, I'd imagine even quite advanced topics would be found by a fair share of readers likely to read "log" and infer "common log"; similarly, although I'd imagine most of those with the sort of background to assume the natural log would catch on from context in most circumstances, the lay usage of the bare symbol to mean the common log should probably also be avoided for the confusion it might cause, as should the niche $\lg$. Regardless, even if all of that is rebuked, I do strongly believe we need some community-wide standard. Thoughts? 50.252.247.245 (talk) 19:37, 30 May 2018 (UTC)

That is not the standard usage in pure mathematics, where "log" without adornment is much more common as the notation for the natural log. —David Eppstein (talk) 20:09, 30 May 2018 (UTC)

I'm aware of this. However, as I said, this seems likely to confuse anyone not a reader of pure math journals, likely to be the majority of readers even on extremely advanced topics. Even those familiar with mathematicians' convention might not expect it on Wikipedia. 50.252.247.245 (talk) 20:32, 30 May 2018 (UTC)

On first glance it seems like a reasonable request. But it's a problem for Wikipedia, where we need to stick to the sources, and the sources all use "log". Hmm. Mgnbar (talk) 20:53, 30 May 2018 (UTC)

The convention in lower-level mathematics (in the U.S., anyway) seems to be that $\log$ means $\log _{10}$ (that's what I learned), while the convention in higher-level mathematics and engineering seems to be that $\log$ means $\log _{e}=\ln$. I don't recall any specific case where $\log$ meant $\log _{2}$, but I would not be at all surprised to have such cases pointed out to me. Given the inherent ambiguity, I agree that bare $\log$ should be discouraged in articles, except (as pointed out by the OP) in cases where it doesn't matter which base is used. In all other cases, $\log$ should never be used without clarification as to which base is intended. As for sticking to the sources, we need not use the exact notation used in sources as long as the notation we use has the equivalent meaning. - dcljr (talk) 21:05, 30 May 2018 (UTC)

There are definitely textbooks in computer science, information theory, and engineering that use the log = log₂ convention. See footnotes 17–19 of binary logarithm. I would be surprised to see this variation in pure mathematics, though, and I wouldn't recommend it even for computer science articles in Wikipedia (except within O-notation, where the base of the log is largely irrelevant). —David Eppstein (talk) 21:19, 30 May 2018 (UTC)

It's more important from our perspective to maintain consistency with sources rather than between articles. In some articles it will be more natural to write $\log$ or $\log _{10}$ or $\log _{2}$ or $\ln$. To impose order on this would be for Wikipedia to decide that certain matters of notation are better than others. That is incompatible with our objectives. So we simply stick with what prevailing sources use in a given context, and if there are no dominant conventions, we follow MOS:RETAIN. Sławomir Biały (talk) 21:45, 30 May 2018 (UTC)

"Sticking with sources" should not come at the expense of readers' understanding. This is an encyclopedia, not a professional journal. We should make it clear in each article which base logarithm is meant, and not rely on unspecified "conventions", whether they are shared by our sources or not. Surely we can all agree that (when it matters) simply using $\log$ in an article without providing any additional context (as to what the base may be) should be discouraged. No? - dcljr (talk) 00:51, 31 May 2018 (UTC)

I would again say it depends on the article. In an article like calculus or exponent, absolutely. In an article like Poisson kernel, nor so much, as one would never see any other kind of logarithm in that context. Again, we can let the treatment of standard sources in the subject inform our stylistic preferences for a given article. Sławomir Biały (talk) 00:59, 31 May 2018 (UTC)

There are also contexts for which "log" is the only correct notation for a concept that generalizes the natural log to other domains; see e.g. closed subgroup theorem or logarithm of a matrix. It would be incorrect to substitute "ln" or to put a subscript on the log in those contexts. —David Eppstein (talk) 01:37, 31 May 2018 (UTC)

What I believe we should do is to mention clearly which logarithm is used the first time an unclear $\log$ is used in any article; we should not change the notation if that would be weird in the context. If an explicit $\ln$, $\log _{2}$, $\log _{10}$ etc. is used, though, there is no need to explain. While some might find it strange to mention the log used as it would be obvious to them, we have to remember this is an encyclopedia and that we are writing to laymen (although in some cases we do expect some education). --Jhertel (talk) 10:33, 31 May 2018 (UTC)

Obviously if something is unclear to readers, it should be pointed out, whether that is a logarithm, units, and other conventions. Conversely, if something is likely to be clear to readers, then it is not necessary to point it out. The MoS doesn't usually take a position on whether extremely specific conventions like those for logarithms must be pointed out in the text. Sławomir Biały (talk) 11:44, 31 May 2018 (UTC)

I would agree it depends on the context. I would apply the rule that whatever we can assume six months before a person would be properly prepared to read an article need not be gone over again in the article. Anything which would be dealt with in a mathematics degree need not assume log is anything but a natural logarithm. Anyway the days when people remembered from their 7 figure tables that log₁₀3 was 0.4771213 are long gone, one just uses a calculator to multiply. Dmcq (talk) 11:57, 31 May 2018 (UTC)

Don't we already clarify a lot? Are there specific examples where the logarithm is not already clarified? Mgnbar (talk) 12:25, 31 May 2018 (UTC)

Italic Greek capitals

Several authorities recommend italic be used for all variables, whether Greek or not, and whether uppercase or not: IUPAC, NIST & ISO (referenced by NIST). In practice this is not always followed, although those 'contraventions' are not necessarily because of an opposing view. Sometimes the use of roman for variables is founded on the type of application (e.g. to represent a tensor), and very often it is due to defaults built into the software — which may or may not be appropriate.

The current MOS page claims that Greek capitals should (always!) be set roman in order to follow TeX's default setting!

First off, I personally think that they should be set italic if they represent variables; roman would be fine by me if they represent a function. But that's just my opinion.
More importantly, it seems like a terrible justification to say that the default of some typesetter is to be followed with no other reason given. Although there is a lot of discussion of the MOS in the archived talk page, there was no evident discussion of or consensus on this particular matter.

I am not confident of a consensus being reached on this matter. If my own preferences aren't adopted, then I hope some flexibility will be allowed in the MOS to allow for different applications (scalar variable versus function, say) and different contexts (pure mathematics versus engineering, say). But at the least there should be be a better justification presented — if not in the MOS page itself, then here on its Talk page!.
—DIV (120.17.228.105 (talk) 12:47, 9 July 2018 (UTC))

I haven't seen any of the archived discussion, so I'll just give my views without looking first. First off, pulling out things like NIST standards tends to be a dead end; they're just not really followed in the wild. However, if it's really common in some particular area to use italic capital Greek letters for something, then it's probably okay to use here too. After all, the MoS is a series of guidelines, none of which are set in stone. But it really should be done to follow a standard practice and not just out of personal preference. Also, I don't think deferring to what (La)TeX does is all that bad of a reason. It's (sort of) what Wikipedia uses in <math>...</math> sections, and it's what people use in practice to write. –Deacon Vorbis (carbon • videos) 13:18, 9 July 2018 (UTC)

Looking a bit more closely at the section in question, it seems like the intent is just to warn against italicizing capital Greek letters that are being entered as wiki markup. For example, use Γ or {{math|Γ}} (Γ or Γ), not ''Γ'' or {{mvar|Γ}} (Γ or Γ). In this respect, I think this is a fine thing to keep. If there really is a rare exception needed for an italic capital Greek latter, it would be fine to do so, provided that it would be done correspondingly in a <math>...</math> block as well. –Deacon Vorbis (carbon • videos) 14:46, 9 July 2018 (UTC)

Italicization of variables is an independent reason for use of the style, versus italicization of something because it's not English. We don't italicize Greek script for the latter reason because being non-Latin is enough to set it apart. But we do italicize Greek book titles, another independent reason. If it's customary to italicize variable regardless of script, WP should do it, too, unless there's a good reason not to it. "TeX doesn't do it by default" seems like a pretty weak reason, but I don't write enough formulas to care. I think this is another case of conflicting consistencies, and the most important consistency (for the project and its readers, not for someone's preferences) should win.  — SMcCandlish ☏ ¢ 😼  20:29, 9 July 2018 (UTC)

What TeX does by default is also pretty much what working mathematicians do by default (for reasons going in both directions). So going against what TeX does by default because you have non-mathematical stylistic instincts that differ is a mistake, likely to produce idiosyncratic and incorrect formatting. Anyway, it is customary (as evidenced by the TeX defaults) to italicize Latin-script single variable names, regardless of case, but not to italicize uppercase-Greek single variable names. This custom is important to follow, not only so that we agree with our sources but also because this convention allows certain Greek and Latin variable names to look more different from each other than they otherwise would. —David Eppstein (talk) 21:06, 9 July 2018 (UTC)

Following typical mathematics usage in RS is the important consistency probably, so this seems good enough to me. I'm wary of specialize-style fallacy arguments, but I don't detect one here; it's not an attempt to impose a specialists' style convention against normal English typography, since there's not a particular way to write formulas in everyday English, with readers getting hit with a principle of least astonishment issue if we do it the maths journal way.  — SMcCandlish ☏ ¢ 😼  21:27, 9 July 2018 (UTC)

The reason that TeX does not do it by default is the most mathematical publishing does not do it - TeX was specifically designed to emulate the best quality hand-typeset mathematics. On the other hand, ISO and NIST are pretty much irrelevant to mathematics publishing. The idea that Greek variables are italicized but not Greek functions is challenging to reconcile with variables that range over functions. — Carl (CBM · talk) 20:47, 9 July 2018 (UTC)

I think it is also curious that we have a number of IP editors arriving on an MOS page. Perhaps it would be a better idea to establish oneself as an editor, get experience editing mathematical articles, and then discuss the manual of style later. It's not productive for inexperienced editors to make random MOS suggestions. — Carl (CBM · talk) 20:47, 9 July 2018 (UTC)

Many IP editors are experienced (you can tell when they make clueful rather than clueless arguments based on WP policy, and so on). If you think someone's socking, the place to provide evidence is WP:SSI.  — SMcCandlish ☏ ¢ 😼  21:27, 9 July 2018 (UTC)

See also WP:ADHOM and WP:ABP. —151.132.206.26 (talk) 22:13, 23 July 2018 (UTC)

Indenting, again

From § Indenting (permalink) as well as various other MOS pages, it seems like using colons solely for indentation within articles is Bad, and using LaTeX’s block display mode $$x=3$$ does exactly what we want. Is there a reason the article doesn’t advise that over misusing colons? —67.14.236.193 (talk) 05:12, 28 June 2018 (UTC)

I think the main reason is that the |display=block syntax is still pretty new. But also, it doesn't work properly for text that is already indented (for instance in bulleted lists, and yes, I have seen bulleted lists with displayed equations in them). And if your goal is semantic cleanliness, it's just as broken as indenting with colons; for instance, your comment above nests a div (actually two nested divs) inside a p, something that is forbidden in proper html. Finally, the idea of avoiding colons for indentation is based on what is arguably a bug in Wikimedia rather than an actual semantic problem; colons are widely used with the intended meaning of indenting something, so the semantics of the wiki-markup is clean enough. The actual problem is that the Wikimedia engine renders the "indent something" semantics as a piece of a definition list even when there is no surrounding definition list to be found. So avoiding : is just working around a bug rather than making your intent clearer. —David Eppstein (talk) 05:25, 28 June 2018 (UTC)

WP uses HTML5; the paragraph element automatically ends whenever another paragraph or div or similar is encountered. (Edit: it doesn’t start a new <p> after the math, so the text underneath isn’t even in a paragraph, so there is that bug.) And colons (and semicolons) still function exactly as originally intended, and wikimarkup still lacks a simple indent. That’s not a bug in the colon; that’s us misusing definition/description/glossary lists purely for aesthetics. —67.14.236.193 (talk) 06:11, 28 June 2018 (UTC)

Yes. The convenience-over-standards-compliance hissy fit that was thrown the last time we raised the issue of abuse of description-list markup (:) was, frankly, shameful and an embarrassment to the project.  — SMcCandlish ☏ ¢ 😼  06:21, 28 June 2018 (UTC)

Calling indentation "abuse of description-list markup" borders on Stockholm syndrome. It is widely used here as indentation. Therefore it should be thought of as indentation and marked-up as indentation. The bug is that it is instead marked up as a description list, not our usage of it. —David Eppstein (talk) 06:36, 28 June 2018 (UTC)

“My computer won’t turn on when I press the space bar!” “That only wakes it if it’s already on. Have you tried the power button?” “No, couldn’t you just remap it to the space bar?”

We use colons for indenting because indentation is a side effect of what they actualy do. That’s not a technical problem. It’s an institutional problem of not knowing how to use it. —67.14.236.193 (talk) 07:06, 28 June 2018 (UTC)

Exactly. It's unprofessional and ignorant. In debates about it on this page it's faux-ignorant; the participants all actually know better. I call it shameful and embarrassing because none of the same people would tolerate abuse of mathematical markup for cutesy font and layout effects. It's simply not their personal technical specialty, so they're giving the finger to a different variety of geeky standards – discipline and specs snobbery, laced with excessive demand for "expediency" (i.e., laziness).  — SMcCandlish ☏ ¢ 😼  17:49, 28 June 2018 (UTC)

@SMcCandlish: Bit harsh and a bit ad hominem, but I agree that, as a group building a complex project on top of a number of technical standards (including our own!), we should at least pretend to care about technical standards in any formal discussion. And yes, using wiki-colons solely for the visual effect of indentation is no different from using math markup for visual effects in standard text. —151.132.206.26 (talk) 20:40, 28 June 2018 (UTC)

If we use <math display="block"> in its own paragraph (with a blank line above and below), and if we just use list markup instead of block in lists, wouldn’t that avoid these issues? Is there any reason not to use display="block" on its own between two blank lines? —67.14.236.193 (talk) 06:32, 28 June 2018 (UTC)

Let’s see.

$$x=3$$

Well, there’s an empty paragraph (<p></p>) above and below the math, so that’s weird, but otherwise no reason not to use it in typical cases. —67.14.236.193 (talk) 06:32, 28 June 2018 (UTC)

I'm not entirely sure how you are seeing an empty p element above/below; the source I have access to is <p><div>latex{x=3}</div></p>. mw:Remex (via use of the parser migration edit tool) will add apparently empty p elements at some point in the near-future rather than allowing that bad behavior, but that still doesn't explain how you are getting the source you are. Maybe because you are unregistered? The math source I get is because I have the option set for the MathML. Do you receive a PNG? --Izno (talk) 12:49, 28 June 2018 (UTC)

Same IP user as above, not on home computer. @Izno: I was actually looking at the DOM tree (right-click, Inspect Element or equivalent), not the page source, so I didn't see the div inside the paragraph because that’s not a thing that’s possible under HTML5. And yeah, if there’s nothing in the paragraph before the div, that would give you an empty paragraph. —151.132.206.26 (talk) 16:01, 28 June 2018 (UTC)

There was a formal RFC in December, which concluded with an outcome keeping the current guideline [6]. — Carl (CBM · talk) 12:56, 28 June 2018 (UTC)

Yes, we know. Consensus can change, and often does when a former conclusion was based on bloc voting and ignorant or territorial arguments.  — SMcCandlish ☏ ¢ 😼  20:55, 28 June 2018 (UTC)

Hmm... Consensus is great, except for all the ignorant fuckwits who disagree with you. Not exactly a winning argument. Sławomir Biały (talk) 22:40, 28 June 2018 (UTC)

Yeah, consensus can change… if you try every six months forever.</snark> - dcljr (talk) 21:45, 28 June 2018 (UTC)

I didn't bring this up, an anon did. And I've opened no new RfC or other proposal about it. I'm simply expressing my displeasure with the hypocritical bullshittiness of it. I'm confident that it will change eventually, even if I drop dead an hour from now, because everything about this site and "WMF stuff" in general is moving increasingly toward standards compliance, metadata, and automation.  — SMcCandlish ☏ ¢ 😼  23:04, 28 June 2018 (UTC)

For "you try" in my comment, read: "one tries". I wasn't necessarily talking about you, personally. - dcljr (talk) 23:22, 30 June 2018 (UTC)

To add something slightly more relevant (ever so): In my experience, style guidelines can be problematic, because they tend to be developed by people who like to develop guidelines rather than people with direct experience in the area the guidelines purport to cover. - dcljr (talk) 21:51, 28 June 2018 (UTC)

Imaginary dichotomies. a) Mathematics has no professionally codified or ingrained standard for what wikimarkup to use for a visual indentation; maths editors are on the exact same footing as every other editor using the same markup language. B) MoS editors likewise have the same broad and continual article-editing experience as the set of editors who never edit the MoS; same footing again. You're also missing that one doesn't have to like to develop guidelines in order to work on them and try to see them consistently implemented; it is entirely sufficient to simply keep readers, re-use, tools, the editorship as a whole, accessibility, and futureproofing in mind, and to be more averse to unresolved style disputes (which are often quite disruptive) than to writing guidelines that resolve them and forestall recurrence. It takes very little time, comparatively.  — SMcCandlish ☏ ¢ 😼  23:17, 28 June 2018 (UTC)

So you (SMcCandlish) know enough about my personal experience with guidelines to dismiss my statement as being based on "imaginary dichotomies"? Are you trying to make people ignore your point of view, or is that unintentional? (You can treat that as a rhetorical question.) - dcljr (talk) 23:33, 30 June 2018 (UTC)

Re "Mathematics has no professionally codified or ingrained standard for what wikimarkup to use for a visual indentation": actually it is pretty ingrained (because of LaTeX) to use centering rather than indentation for displayed mathematics, to the point where I've seen complaints from authors who thought it was a bug when some specific LaTeX style chose to use indentation instead. One actual advantage of |display=block would be to decouple that sort of stylistic decision from the semantic content. As for codification of the markup to use: LaTeX is codified and is the defacto standard. Based on it, most mathematicians would expect \[ ... \] or $$ ... $$ for displayed equations (and \( ... \) or $ ... $ for inline ones), so anything else (like our math tags) will take some getting used to. —David Eppstein (talk) 01:09, 29 June 2018 (UTC)

I don't disagree that enabling block display (and doing other things, like using a template to apply a close, to permit people to re-style with CSS) might be nice. Has nothing to do with abuse of description list markup to get a visual indentation. Of course maths people use LaTeX, and it is codified and its use is ingrained. I said "codified and ingrained standard for what wikimarkup to use" (emphasis added) because that is the actual topic.  — SMcCandlish ☏ ¢ 😼  02:37, 29 June 2018 (UTC)

"MoS editors likewise have the same broad and continual article-editing experience as the set of editors who never edit the MoS; same footing again." If we're on the same footing, then the expectation is that you should accept the overwhelming consensus of the RfC, based on discussion with your equals, and retract the dismissive personal attack that the outcome was based on "ignorant bloc voting". Everyone in that discussion is exactly as entitled as you are to determine what the manual of style should mandate. Sławomir Biały (talk) 13:49, 29 June 2018 (UTC)

So… are the various pages that explicitly advise against using : for simple indentation outdated? Because this contradicts them. —67.14.236.193 (talk) 15:00, 29 June 2018 (UTC)

Obviously not, and this is a WP:CONLEVEL and WP:POLICYFORK problem, where a wikiproject is trying to declare itself immune to site-wide guidelines. We've been through this many times and it never goes well (I mean, that's why we have CONLEVEL policy; it was written specifically to curtail this sort of thing, because it's disruptive to the encyclopedic output, and internally in the form of protracted dispute about a matter resolved a long time ago more broadly). Given the stonewalling this MoS sub-page, the proper course of action would be to open a new RfC at WT:MOS, neutrally and accurately advertise it at WP:VPPOL, and here, and at the maths project talk page (to prevent a repeat of the distorted canvassing that happened last time). I don't have the "drama" patience to do it now, but the outcome is pretty obvious. If the rest of the advice says not to abuse d-list markup, this page doesn't get a free pass to do so, especially since there is no maths-specific reason to (there is no WP:IAR rationale). See also MoS's lead: "If any contradiction arises [between the main MoS and other MoS pages], this page always has precedence." The MOS:MATH policy-fork is invalid on its face both by MoS's wording and by CONLEVEL policy.  — SMcCandlish ☏ ¢ 😼  15:20, 29 June 2018 (UTC)

(edit conflict) Sławomir, that's all off-kilter. It's not a "personal attack" to observe that the RfC was flooded by WP:WPMATH editors – after shameless canvassing that grossly misstated the nature of the proposal in a way that was sure to alarm wikiproject members into a negative mass over-reaction. It's an observation of stacked turnout, well-poisoning, and poor breadth of discussion; see WP:FALSECONSENSUS. That many of the arguments presented were ignorant of the HTML specs and even of what our wikimarkup resolves to in HTML, and of why it matters, was well demonstrated at that discussion (and in other ones); many were also not responsive to the actual proposal but reacting to the canvassed straw man of it.

Moving on: MoS, like other guidelines, doesn't "mandate" anything. But that rules/winning/control approach to the matter sure explains a lot, as does the implication that because you "won" last year no one's allowed to question the matter ever again. You also more directly suggset that the result of the RfC hasn't been "accepted"; yet no one is editwarring to change the wording, going around editing in contravention of what it says, or even opening a new RfC on it (I generally wait at least a year before I seek a broader consensus re-discussion of something, and I may never get around to this one; someone else is likely to do it before I do). You're not in a position to try to forbid people from saying at a guideline talk page that one of the guideline's line-items is wrongheaded, why, and why the process at which was got to it was faulty. Such discussions are what a guideline's talk page exists for.

Speaking of straw men, I've nowhere suggested that your or anyone else's input into process (RfC, etc.) is less legitimate, only that some of the facts and assumptions are demonstrably wrong; that too many of the arguments are off-topic, subjective preference, dismissiveness of standards that aren't maths standards, and/or grounded only in editorial convenience; and dominated by a particular bloc of (canvassing-confused) editors from one wikiproject.
 — SMcCandlish ☏ ¢ 😼  15:07, 29 June 2018 (UTC)

Frankly, I find your assertion that the people who actually edit mathematics articles should have been kept away so that the style-junkies could have this little playground to themselves to be bizarre and counterproductive. —David Eppstein (talk) 16:40, 29 June 2018 (UTC)

Silly straw man. I said nothing remotely like any of that. Objecting to a blatantly misleading canvassing of a wikiproject bears no resemblance to suggesting that people in the wikiproject be kept away from a discussion. The matter under discussion has nothing to do with mathematics anyway. There is no magically special "mathindents". Misusing description list markup for indentation is a topic-unrelated issue. It's a few people from WP:WPMATH who are treating this page (a WP guideline, not a wikiproject's WP:PROJPAGE essay) as an owned playground.  — SMcCandlish ☏ ¢ 😼  18:11, 29 June 2018 (UTC)

You of course had the option of notifying the affected WikiProject yourself. I'd be interested in knowing the reason for your failure to do so, from someone who so forcefully proclaims that he is entitled to a say in such matters. It's frankly weird for you to say that MoS editors are entitled to opine about style matters despite their lack of experience, yet your apparent attitude that others are too "ignorant" to have an opinion worth noting. But you're entitled to whatever delusions of grandieur you may suffer from. However: Don't you dare try to change mathematics markup recommendations again, without notifying the WikiProject, or I suspect you will soon see what "ignorant bloc voting" can achieve in an ANI report on your deplorable bullying behavior. Sławomir Biały (talk) 22:41, 29 June 2018 (UTC)

More ad hominem nonsense; I have never suggested I have more entitlement to a say in anything. You can falsifying my statements and views all day (well, in theory), and I'll keep correcting you until you stop it and say something substantive.

What this is going to continue boiling down to is what it boiled down to in the previous discussion. I'll just quote (with minor contextual revision) what I said then (and moving those discussions into /Archive 1 isn't going to sweep the issue under the rug): What's happened here is PoV policy-forking – of what a maths-topical MoS subpage says about an accessibility matter about which the maths page is not authoritative, from what the main MoS page and the accessibility MoS page (among others) say about the exact same matter. Contrary to reality-denying claims in these discussions, there absolutely is general MoS material on indenting all kinds of content (regardless of topic) – lots of it, and all consistent except at MOS:MATH. All emphasis is as in the original; these are direct copy-pastes from the pages in question:

• From the main WP:MOS page, at MOS:INDENT: Various templates are available for indentation, including {{block indent}}, and (for inline use) {{in5}}. For more information on the accessibility problems of using : (description list markup) for visual indentation, see [the next page quoted below].
• From MOS:ACCESS, at MOS:INDENTGAPS: An accessible approach to indentation is the template {{block indent}} for multi-line content; it uses CSS to indent the material. For single lines, a variety of templates exist, including {{in5}} (a universal template, with the same name on all Wikimedia sites); these indent with various whitespace characters. ... A colon (:) at the start of a line marks that line in the MediaWiki parser as the <dd>...</dd> part of an HTML description list (<dl>...</dl>). The visual effect in most Web browsers is to indent the line. ... However, this markup alone is missing the required <dt> (term) element of a description list ... this results in broken HTML ... which is confusing for any [screen-reader-using] visitor unused to Wikipedia's broken markup. This is not ideal for accessibility, semantics, or reuse....
• From MOS:LISTS, at MOS:DLIST: When wikimarkup colons are used just for visual indentation, they too are rendered in HTML as description lists, but without ;-delimited terms to which the :-indented material applies, nor with the list start and end tags, which produces broken markup (see WP:Manual of Style/Accessibility § Indentation for details). More accessible indentation templates can be used, e.g. {{in5}} or one of its variants for one line, and {{block indent}} for more than one line (even if misuse of description list markup on talk pages is too ingrained to change at this point).
• From Help:List § Extra indentation of lists): [Need for indentation] is fixed by increasing the default indentation ... and it can be done in multiple ways: ... use an explicit CSS margin spacing of [tech details elided]. Though not the simplest, this is the cleanest and most versatile method, as it does not rely on any peculiarities of the parser, nor on abusing any semantic markup for purely visual purposes. ... A list of one or more lines starting with a colon creates an HTML5 description list (formerly definition list in HTML4 and association list in draft HTML5), without terms to be defined/described/associated, but with the items as descriptions/definitions/associations, hence indented. ... Deprecated method: [this] technique ... produces poorly formed ... markup and abuses the semantic HTML purpose of description lists for a purely visual effect, and is thus a usability and accessibility problem. It will work in a hurry, but should be replaced with cleaner code....

This has never been about anything other than MOS:MATHS recommending a practice deprecated in favor of more accessible practice specified by the main MoS page and the accessibility page and the list-markup page and the list-coding instructions. That's four against one, so we know where WP:CONLEVEL policy goes on this, especially since the main MoS trumps MoS subpages, and it explicitly defers to MOS:ACCESS on this matter. The indentation-related material at MOS:MATHS has nothing at all to do with mathematics and <math>...</math> markup, only with good versus awful ways to shift content – of any kind – to the right.
 — SMcCandlish ☏ ¢ 😼  23:42, 30 June 2018 (UTC)

MOS:INDENT does not say "don't use colons". It says, "This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers.". Which is to say, "colons are still commonly used even though we know they have issues.". There is no conflict between this page and that page. — Carl (CBM · talk) 13:18, 2 July 2018 (UTC)

Of course there is. If the main MOS page (and the others) discourage an accessibility-problematic approach in favor of one that is not, and this MoS subpage pretends the only possible approach is the problematic one, that's obviously a conflict. See also WP:WIKILAWYERING and WP:GAMING on misinterpreting policy and guideline wording by the technicalities of its exact wording instead of absorbing its clear intent.  — SMcCandlish ☏ ¢ 😼  19:20, 2 July 2018 (UTC)

This bullshit CONLEVEL argument was definitively demolished at the aforementioned RfC, by an overwhelming consensus. I've no interest in repeating arguments there, which are available for your own perusal. You seriously need to drop the stick, mate. Sławomir Biały (talk) 22:04, 2 July 2018 (UTC)

Back to the technical matters

[7] —67.14.236.193 (talk) 23:34, 30 June 2018 (UTC)

So what exactly is the problem with using <math display="block"> when on its own line? The only technical issue that’s been mentioned is the empty paragraph before the div, which really seems like a non-issue (though it seemed to cause some confusion: under HTML5, which we use, <p> is self-closing; it’s functionally identical to <p></p><div>...</div>, so there is no nesting). —67.14.236.193 (talk) 15:50, 29 June 2018 (UTC)

Probably worth setting up a sandbox page with a test code in it with different approaches, both to see the visual effect in various browsers and to examine the post-parser source that is sent to the user agent.  — SMcCandlish ☏ ¢ 😼  18:14, 29 June 2018 (UTC)

Once we have mw:RemexHtml online in the next month or so we can look into what happens with the HTML. --Izno (talk) 18:31, 29 June 2018 (UTC)

Why not just use "View source" in browsers in the interim? This can be useful; see, e.g.: Wikipedia:Manual of Style/Accessibility/anchor tests, and sandbox we ended up saving for future tests with new browsers.  — SMcCandlish ☏ ¢ 😼  19:31, 29 June 2018 (UTC)

Mostly that it is a waste of time because RemexHtml changes the output in different ways than HTML Tidy does. You can access the Remex source by turning on the parser migration option in your (editing?) preferences and then by going to edit a page if you really want to, but in a couple month's that parser cleaner will be the default. --Izno (talk) 21:15, 29 June 2018 (UTC)

I don’t understand the problem—is RemexHtml expected to render <math> significantly differently? Do we not know? —67.14.236.193 (talk) 00:35, 30 June 2018 (UTC)

It may, or may not, change where that deviant p element ends up, or whether the div ends up inside the p--and while I trust the parser migration gadget to find issues with future rendering, I don't really trust it to output the exact rendering. If it ends up outputting as empty and closed paragraphs (well-formed but meaningless), then the use of display=block shouldn't be blocked on that issue. (There may be other technical or non-technical issues which block moving to display=block--the solution which I think is clearly the superior one.)

What one could do is go to a wiki where Remex is already enabled and test how display=block outputs. I'm a bit lazy on the point ;), so feel free to report back, IP67. --Izno (talk) 01:26, 30 June 2018 (UTC)

or whether the div ends up inside the p—You can’t have a div inside a p. I don’t mean it’s invalid; you literally can’t, it just doesn’t work that way. If you try, the p ends right there, and all you get is the div interrupting the p.

Otherwise, agreed. But I’m not at all familiar with Remex, and have no idea what wikis may or may not use it. —67.14.236.193 (talk) 15:31, 30 June 2018 (UTC)

FYI: The sysadmins have been gradually switching Wikimedia wikis from Tidy to RemexHTML for a while now. The "final switch" to RemexHTML everywhere is scheduled to happen on July 5th. See phab:T175706. - dcljr (talk) 23:19, 30 June 2018 (UTC)

IP67, I see nothing in that section to indicate that a div cannot be found inside a closed block p, which is invalid HTML (but that wouldn't stop authors from writing it that way). Does the closing </p> become stripped? Is it parsed instead as an opening <p>? It's a somewhat backward inference you're making. But as I said, if you want to test the problem, you can see after Thursday how the MediaWiki outputs the markup in question. --Izno (talk) 14:21, 1 July 2018 (UTC)

@Izno: The relevant bit is: A p element's end tag may be omitted if thep element is immediately followed by [a] […] div […] element, or if there is no more content in the parent element […]. In other words, if there’s a <p>, and then there’s a <div>...</div>, the div follows the entirety of the p with no need to explicitly close it. This is also why <p>...<p>...<p>...</p> results in one paragraph after another rather than nonsensically nested paragraphs. That’s how HTML5 works, and Wikipedia uses HTML5. The language provides no mechanism to alter this behavior.

I think you’re focusing too much on the orphaned </p>. That tag is nonsensical; there’s nothing left to close. It’s like if a recipe said to put the pan in the oven, bake, let cool, serve, and then take it out of the oven—it’s already out! —67.14.236.193 (talk) 02:13, 3 July 2018 (UTC)

Testing on a site already using Remex would be a good idea. A test page of coded examples, as I suggested, would work well for this, since it would test various conditions of what's happening now versus what'll happen under Remex, and they'll be directly comparable (though porting some templates to do the test might also be needed, and there could possibly be user or site-wide CSS doing something at affected the output, but that should be easy enough to figure out as the cause should there be discrepancies in the rendering between the two parsers).  — SMcCandlish ☏ ¢ 😼  23:48, 30 June 2018 (UTC)

I mean, Remex will be here on Thursday, so we can also wait. :) --Izno (talk) 14:21, 1 July 2018 (UTC)

No, NOW DAMMIT NOW! heh.  — SMcCandlish ☏ ¢ 😼  19:20, 2 July 2018 (UTC)

"So what exactly is the problem with using <math display="block"> when on its own line? " - several issues have been mentioned, not all of which I can remember, but one is that this is not sensitive to existing indentation, such as:

• List item 1

  $\int _{0}^{3}x\,dx$

• List item 2

• List item 1: math display=block on its own lind

$$\int _{0}^{3}x\,dx$$

• List item 2

It is quite common to have displayed math inside a bulleted list. — Carl (CBM · talk) 13:21, 2 July 2018 (UTC)

Because you placed it at a different level would seem to be the reason why there. The below is the correct analog:

• List item 1: math display=block on its own lind
• $$\int _{0}^{3}x\,dx$$
• List item 2

Now, this one has its own (probable, according to you, issue), which is the bullet next to the display block. The correct way to probably provide either of these cases is to break on the first list item, because only rarely (or perhaps never) is the display block meant to be a distinct paragraph rather than part of the first list item semantically. Or would you dispute that? :)

• List item 1: math display=block on its own lind
  $$\int _{0}^{3}x\,dx$$
• List item 2

--Izno (talk) 14:59, 2 July 2018 (UTC)

The spare bullet would indeed be a problem. It doesn't seem to me that explicit <br> tags are superior to the current system of using *:. If we want to have more commentary after the displayed equation, it seems we would need to put even more <br> tags.

• List item (with br tags)
  $$\int _{0}^{2}x\,dx$$
  is an integral. For some reason there seems to be extra vertical space above this line.
• List item (currently recommended practice)

  $\int _{0}^{2}x\,dx$

is an integral

• List item

I still think that it would be better to fix the problem by fixing Mediawiki to parse Wikitext better. — Carl (CBM · talk) 15:14, 2 July 2018 (UTC)

I don't think you need the ending break for further eliding, which is why you are seeing hte issue (math display=block is a block, which outputs a div, which by default forces everything below it):

• List item (with br tags)
  $$\int _{0}^{2}x\,dx$$ is an integral. The extra unnecessary break you added is the reason why there is extra space.
• 2nd list item.

As has been elided in many, many places, ":" has a specific meaning, and there are a number of reasons why it should not be changed. It is not a question of "parsing wikitext better". --Izno (talk) 15:32, 2 July 2018 (UTC)

A colon without a definition list does have a specific meaning, which is to indent. This has been standard usage for over a decade and is described in places such as this page, Help:Indent, etc. The specific way that the indentation is handled is not optimal - there's no reason Mediawiki should still create a definition list when no semicolon is used. But there is no way to argue that a colon in wikitext is not intended to denote indentation (it's a little like arguing that "cool" only means "low temperature" and does not mean "interesting"). The issue is that Mediawiki needs to recognize that, when there is no semicolon, a colon should be rendered via increased indentation. — Carl (CBM · talk) 15:47, 2 July 2018 (UTC)

Yeah, see, I didn't want to get into this--the fact you slipped right back to it in a section talking about the technical matter is a bit telling about your general motivation. Do you have anything further on talking about using display math (esp. issues you have observed)? --Izno (talk) 15:52, 2 July 2018 (UTC)

@CBM: A colon without a definition list does have a specific meaning, which is to indent. Not according to what the markup actually does, and has done since its inception: it creates a description list. See MDN’s page about the Description Details element. We’re arguing semantics here, but semantics matter (and if you don’t believe so, I’d ask what you’re doing in the MOS part of Wikipedia). If you want pure indentation markup, the colon is not what you’re looking for. On talk pages, for instance, discussions have long been threaded by means of nested description lists, which are actually better suited for the task than pure indentation. Doesn’t work so well when they’re broken up by things like blockquotes as above, but that’s getting off topic. —67.14.236.193 (talk) 01:45, 3 July 2018 (UTC)

I am not sure why you are singling me out for "slipping back into this". Anyway, if display=block inserts a following line break, then the other usage doesn't work, which is to put extra text after the displayed equation so that the text will not be rendered in math mode. This is used for explanatory text, comments, etc.

• List item with text after a displayed equation

  $\int _{0}^{2}x\,dx$ is an integral

• List item (with display=block inserting a spurious line break)
  $$\int _{0}^{2}x\,dx$$ is an integral
• List item

The same thing would happen without the list, of course:

$$\int _{0}^{3}x\,dx$$ these comments should be on the same line as the integral.

This is a worse issue, actually. — Carl (CBM · talk) 15:58, 2 July 2018 (UTC)

What you describe just strikes me as bad style. If you want the equation inline with text, don’t try to put it on its own line, and vice versa. Enforcing good style is not a drawback. —67.14.236.193 (talk) 03:25, 3 July 2018 (UTC)

Testing display=block with inline references (based on the featured article Pi):

$\int _{0}^{2}x\,dx.$

$$\int _{0}^{2}x\,dx.$$

References

— Carl (CBM · talk) 16:35, 2 July 2018 (UTC)

What I was actually trying to ask at the top of this subsection was whether there were any issues with using block-display independently of list markup—under circumstances where it would make stylistic sense to have the math alone on its own line with no other markup on the same line as it.

Regarding indentation, it works just fine in blockquotes:

Markup	Renders as
Quote: <blockquote> blah blah <math>x=3</math> blah: <math display="block">\int_0^3x\,dx</math> blah </blockquote>	Quote: blah blah $x=3$ blah: $$\int _{0}^{3}x\,dx$$ blah

(Note: I use {{blockindent}} above since I’m not actually quoting anything, but the result is the same.)

It also seems to work inline, with no line breaks of any sort, even in lists. Like so:

Markup	Renders as
* … * Another example of an integral is <math display="block">\int_0^3x\,dx</math> which resolves to <math>\frac x4</math>. * …	[List items about different kinds of integrals or something.] Another example of an integral is $$\int _{0}^{3}x\,dx$$ which resolves to ${\frac {x}{4}}$. [More list]

—67.14.236.193 (talk) 03:10, 3 July 2018 (UTC)

With the block’s use of div, though, it’s still not technically correct to use it in the middle of a paragraph of running text (it actually terminates that paragraph). But that seems to be the only real issue, and it’s a fairly minor one. The issues illustrated above in lists all seem like user error, adding unnecessary line breaks and the like. —67.14.236.193 (talk) 03:57, 3 July 2018 (UTC)

One remaining key issue is that the display=block adds a line break, so it is impossible to put anything after it on the same line.

$$\int _{0}^{2}x\,dx$$ this should be on the same line as the formula.

Even if this "strikes you as bad style", it's a requirement for a functionally complete replacement for the current system. Similarly, inline references placed after display=block are moved to the next line. A replacement for the current system needs to be able to do the things the current system does. — Carl (CBM · talk) 12:29, 3 July 2018 (UTC)

It strikes me as bad style too (do you want your math to be block or not? pick one.). I don't think it would be unreasonable to raise a task on Phabricator about that though. As for references, we can handle them like we handle blockquotes today (references before the quotation, generally). That aside, we do not need a "functionally complete replacement" to start using or even recommending block display rather than ": <math>". (I might suggest something like: "For a block of math content, use <math display=block>. You may use this other, deprecated form in these x, y specific cases that do not have a functional equivalent, but we advise a rewrite such that this way is unnecessary. (Those cases may be supported by math at some point in the future. [Link to Phabricator]) Your article should be internally consistent." and go from there. --Izno (talk) 13:04, 3 July 2018 (UTC)

@CBM: Can you give an example from an article in which this is necessary? —151.132.206.26 (talk) 18:11, 3 July 2018 (UTC)

Very little is necessary with enough edits to rewrite the articles. But if you want examples where displayed math is used in non-standalone ways, in the current versions of the article: Reference after equation in 115 (number); displayed math in bulleted list (with incorrect indentation) in 251 (number); text used at the end of one displayed equation to link it to the next one in 3SUM. —David Eppstein (talk) 18:22, 3 July 2018 (UTC)

Just to note, the example at 3SUM is an “or” toward the end of 3SUM#Reduction from 3SUM to Conv3SUM. The best alternative that comes to mind isn’t good, which is using ... \text{ or} ... which would render in a different font than plain text. —67.14.236.193 (talk) 01:43, 4 July 2018 (UTC)

And now, predictably, the proponents of the modified formatting have started editing those articles and destroying their value as examples. I'm switching to permalinks, because the point is not the usage in those specific articles, it's that these are standard usages on Wikipedia more generally that any modified formatting must also be able to support. —David Eppstein (talk) 19:09, 3 July 2018 (UTC)

I’ve only edited the one at “251” (that was me, away from home), and it rather seemed like an example of what not to do: improperly simulating an unnecessary line break before an equation that would wrap to the next line anyway, in a list of otherwise single-line items. Apologies if the break actually served some purpose, and sorry about invalidating your example without thinking—I’ve been pretty tired all day. But the others don’t seem to have been touched at all. —67.14.236.193 (talk) 01:34, 4 July 2018 (UTC)

Indenting: arbitrary break

With RemexHtml having now been in play for weeks, where do we stand on this? —67.14.236.193 (talk) 01:59, 26 July 2018 (UTC)

What does this do?

$$\int _{0}^{3}x\,dx$$

^ I see in my source:

<p><div class="mwe-math-element"><div class="mwe-math-mathml-display mwe-math-mathml-a11y" style="display: none;"><math display="block" xmlns="http://www.w3.org/1998/Math/MathML"  alttext="{\displaystyle \int _{0}^{3}x\,dx}">
  <semantics>
    <mrow class="MJX-TeXAtom-ORD">
      <mstyle displaystyle="true" scriptlevel="0">
        <msubsup>
          <mo>&#x222B;<!-- ∫ --></mo>
          <mrow class="MJX-TeXAtom-ORD">
            <mn>0</mn>
          </mrow>
          <mrow class="MJX-TeXAtom-ORD">
            <mn>3</mn>
          </mrow>
        </msubsup>
        <mi>x</mi>
        <mspace width="thinmathspace" />
        <mi>d</mi>
        <mi>x</mi>
      </mstyle>
    </mrow>
    <annotation encoding="application/x-tex">{\displaystyle \int _{0}^{3}x\,dx}</annotation>
  </semantics>
</math></div><img src="https://wikimedia.riteme.site/api/rest_v1/media/math/render/svg/4f6ee37704c67835d227c5b66f046f1ba9142be3" class="mwe-math-fallback-image-display" aria-hidden="true" style="vertical-align: -2.338ex; width:8.168ex; height:6.176ex;" alt="{\displaystyle \int _{0}^{3}x\,dx}"/></div>
</p>

And Firefox even highlights the last </p> in orange fore-color as if it is errant (because it is). --Izno (talk) 02:24, 26 July 2018 (UTC)

So we still have the empty paragraph element. Is there anything that can be done about that? Even if not, it still seems a good sight better than creating spurious description lists in article space. As I recall, the only other substantive complaint was the inability to treat block-style as inline (and we shouldn’t condone mixing the styles anyway). (Edit: Also the inability to use <ref>s with block display, which admittedly can be a problem.) —67.14.236.193 (talk) 03:50, 26 July 2018 (UTC)

Proposal: Recommend using <math display="block">…</math> when a block-level effect (with indentation) is desired. Recommend putting any explanatory text and citations in a paragraph before or after the math, because you can't use block display inline with other text. Stop recommending the use of description lists where no list is called for. —151.132.206.26 (talk) 00:28, 31 July 2018 (UTC)

Counter-proposal: don't make markup recommendations that invalidate existing content. The content we produce should dictate the kinds of markup we use to format it, not vice versa. —David Eppstein (talk) 02:03, 31 July 2018 (UTC)

@David Eppstein: You are exactly right, and I’m not sure how that conflicts with my proposal. If the content we produce calls for a math formula within a paragraph of text, use inline math markup; if it calls for a standalone math formula with paragraph(s) above or below, use block math markup. If you want both at once, pick one, because that’s just good style. —67.14.236.193 (talk) 02:33, 31 July 2018 (UTC)

Your proposal invalidates block-level display that has non-mathematical text on the same line. If we want to change current markup, we need to find a way of doing so that accommodates that sort of thing, not that forbids it. —David Eppstein (talk) 04:07, 31 July 2018 (UTC)

The purpose of a manual of style is to encourage good style, not to accomodate bad style. —67.14.236.193 (talk) 01:57, 2 August 2018 (UTC)

If only more people understood that. In particular, our MoS doesn't exist to enshrine bad ideas just because some people in a particular wikiproject have a lazy habit or don't care. If it comes down to it, get a bot to fix the bad markup. Just get it fixed one way or another. The ideal way is for recalcitrant editors to stop being recalcitrant and to instead write better code; this produces less bad code for others to have to repair.  — SMcCandlish ☏ ¢ 😼  04:22, 2 August 2018 (UTC)

@David Eppstein: Just so there’s no confusion, I’m asying that block-level display math should not have non-mathematical text on the same line, no matter what markup is used. It’s sloppy. You said yourself that it’s unnecessary and can be rewritten (with minimal effort, in the examples given here earlier). If adopting a better practice with markup “forces” us to stop using sloppy style, I’m afraid I’m not seeing the down side. —67.14.236.193 (talk) 05:29, 2 August 2018 (UTC)

How much mathematics article editing have you done? It's sometimes not just not sloppy, but necessary. For instance, when using {{NumBlk}}. —David Eppstein (talk) 06:06, 2 August 2018 (UTC)

I’m surprised <math> doesn’t have that formula-numbering capability itself, but display="block" appears to work perfectly well with {{NumBlk}}. (Edited 23:14, 2 August 2018 (UTC) to display the table borders. We really shouldn’t be using code [or templates] that use tables this way.)

Markup	Renders as
{{numBlk||<math display="block">x=3</math>|eq. 1|Border=y}}	Sample text. $$x=3$$ (eq. 1)

Equation number’s on the same line, math’s properly indented with no colon lists. Actually we could probably edit NumBlk to use block display and ignore the first param. The template doesn’t seem to play well with lists, though. Wonder if that’s fixable… —67.14.236.193 (talk) 07:34, 2 August 2018 (UTC)

Would it be possible to enable the equation environment in <math>? Then we’d be able to use \tag in the math markup itself rather than a template kludge that fakes it with tables (which is notoriously bad web-design style, by the way). —67.14.236.193 (talk) 22:49, 2 August 2018 (UTC)

Jc86035 I saw you resolve something similar quite recently (shortcut template breaking lists). Maybe you have some input? I could probably beat on this myself, but am running out of time for the day, maybe the rest of the week, for anything "involved".  — SMcCandlish ☏ ¢ 😼  04:09, 3 August 2018 (UTC)

@SMcCandlish: I don't think I can help, since the other issue was caused by Module:Shortcut emitting extra line breaks and breaking the list formatting. I also would rather leave the solution to this to someone else. Jc86035 (talk) 04:38, 3 August 2018 (UTC)

If it can’t be rewritten to use CSS rather than empty tables for layout, I say we’d be better off deprecating NumBlk and looking for alternatives. It just compounds bad style on top of bad style. —67.14.236.193 (talk) 12:27, 3 August 2018 (UTC)

Proposed substantive changes

Looking over what is currently Wikipedia:Manual of Style/Mathematics, I see numerous ways that the way the page can be rewritten, as well as content changes, that would substantially improve it. Starting with the "Suggested structure" section, I have set up my first sandbox so that a version of my proposed changes can be seen. A link to the difference between the current version of the section and my proposed changes can be found here. Some of the meaningful content changes that I am proposing include:

1. Changing the section name from "Suggested structure" to "Structure".
2. Removing "establish[ing] why [the subject] is interesting or useful" as part of the purpose of a lead.
3. Changing the list of subjects that it is safe to assume a reader knows, adding an alternate case regarding assuming knowledge on articles with subjects simpler than those a reader is normally assumed to know.
4. Changing example sentences to make what the sentences referenced appear as match what they currently (as of typing) do on their corresponding pages.
5. Fleshed out, and possibly reinterpreted, what "A person editing a mathematics article should not fall into the temptation that "this formula says it all"." means.

Since the differences between the current section and what I am proposing are significant, I am looking for feedback from other users regarding what they think of my proposed changes and how they could be better and more accurately reflect consensus. If agreement can be reached on what changes should be made to the section currently titled "Suggested structure", I will likely propose future substantial changes to Wikipedia:Manual of Style/Mathematics under this section. —The Editor's Apprentice (talk) 04:40, 2 December 2019 (UTC)

I have gone ahead and made the changes that I previously proposed, though with slight last minute modifications, since no one has responded to my feedback request on the changes during the 5 days in which I have proposed them. They are now live if you would like to review them. —The Editor's Apprentice (talk) 17:50, 7 December 2019 (UTC)

Style edit

A manual of style should be written cleanly and sparely. I have tried to cut useless words without changing the content. (In trying to clarify vague phrases, I might have introduced some of my own meaning.) — Preceding unsigned comment added by Magyar25 (talk • contribs) 19:00, 19 May 2020 (UTC)

I know it's not a change you made in this copyedit, but I am unhappy with this guideline's statement that we should not use imperative, for instance in the given example "Suppose that G is a group. G can be decomposed into cosets, as follows." => "A group G may be decomposed into cosets as follows.". In this example, the replacement text is better, and in general I would prefer the phrasing "Let G be a group" to "Suppose that G is a group". But in many instances, combining the definition of a mathematical object with its use will lead to long convoluted sentences, too long for casual readers to follow the line of reasoning, and likely violating WP:TECHNICAL because this sort of grammar makes the text unnecessarily difficult to read. An example from reversible cellular automaton, simplified a little for purposes of quoting here: "Suppose that the cells form a one-dimensional array, but that each state is an ordered pair (l,r) consisting of a left part l and a right part r, each drawn from a finite set of possible values. Define a transition function that sets the left part of a cell to be the left part of its left neighbor and the right part of a cell to be the right part of its right neighbor. Then this automaton is reversible." It is not actually an address to the reader, a first-person dialogue of a type that we are trying to avoid; it is merely a grammatical form that allows us to break thoughts into smaller logical units. —David Eppstein (talk) 19:09, 19 May 2020 (UTC)

Regarding: "I am unhappy with this guideline's statement that we should not use imperative." I think the point there was just to avoid starting the sentence with a symbol. The replacement avoids repetition and reads better. As for avoiding conversational style, I don't think anyone takes that so seriously to be hampered by it. — Preceding unsigned comment added by Magyar25 (talk • contribs) 19:25, 19 May 2020 (UTC)

If the point were merely to avoid starting the second sentence with a symbol, it could have been made by adding the word "Then". —David Eppstein (talk) 19:27, 19 May 2020 (UTC)

That would make 15 words vs 10. Brevity is key! — Preceding unsigned comment added by Magyar25 (talk • contribs) 19:30, 19 May 2020 (UTC)

If and only if

How about "whenever" as a standard phrase in definitions?

A number n is even whenever n = 2k for some integer k.

Just writing "if" seems logically incomplete, leaving open the possibility that some numbers might also be even, though they don't satisfy the condition. — Preceding unsigned comment added by Magyar25 (talk • contribs) 19:04, 19 May 2020 (UTC)

There is nothing wrong with using "if and only if". "Whenever" can sometimes be used as a substitute but is too ambiguous to make a good replacement everywhere. The only thing this style guideline should prohibit is jargony abbreviations like "iff". —David Eppstein (talk) 19:12, 19 May 2020 (UTC)

I agree, but someone over the last 20 years seems to dislike "if and only if". I can see that a non-mathematical reader would find it fussy or technical. Can you give an example of "whenever" being ambiguous? — Preceding unsigned comment added by Magyar25 (talk • contribs) 19:27, 19 May 2020 (UTC)

In general, I would interpret "whenever X, Y" as meaning "if X then Y", not "X if and only if Y". In that sense, it is not clear which connective is being used. The same problem plagues other attempts at using more colloquial English to replace precise mathematical English; for instance, "any" is often used colloquially as a quantifier, but it is never clear whether it means the same as "for all" or whether it means "an arbitrarily chosen one", two quite different mathematical interpretations. Such ambiguities should be avoided. Since you asked for an example, here's a particularly ironic one: in if and only if we find the sentence "research papers and articles (including English Wikipedia articles) follow the special convention to interpret "if" as "if and only if" whenever a mathematical definition is involved". Does this mean (as I think it does) merely that in this context, "if" can be short for "if and only if"? Or does it imply (as you seem to think) that there is no other circumstance in which someone would say "if" but mean "if and only if"? —David Eppstein (talk) 19:48, 19 May 2020 (UTC)

Typesetting of mathematical formulae and serif vs sans-serif

In Wikipedia:Manual of Style/Mathematics#Font formatting, it is written: "As TeX uses a serif font to display a formula (both as PNG and HTML), you may use the {{math}} template to display your HTML formula in serif as well." But as I can see, LaTeX markup with the <math> tag actually uses a sans-serif font. This makes pages that use a mix of LaTeX markup and {{math}} templates rather ugly. So there's something wrong with this guideline. Vincent Lefèvre (talk) 20:47, 1 June 2020 (UTC)

@Vincent Lefèvre: You say that LaTeX markup with the <math> tag actually uses a sans-serif font. Can you give a specific example? The PNG rendering that I see has a serif font (except where suppressed using \mathsf), and as I am under the impression that the PNG is generated by the Wikipedia servers, I expect this to be be independent of the browser. Maybe there are personal preference settings involved? —Quondum 19:34, 15 August 2020 (UTC)

If you're using a browser that renders MathML, the browser may be rendering formulas with a sans-serif font, but that would be very unusual. The svg/png that MediaWiki produces use the standard Computer Modern font that LaTeX uses. There are sans-serif fonts that you can use with a normal LaTeX installation (I think the default beamer package has is set up to use one), but that's not really applicable here. It would probably help if you could throw a screenshot up somewhere of what you're seeinng. –Deacon Vorbis (carbon • videos) 19:38, 15 August 2020 (UTC)

Sorry, what I actually should have said is that LaTeX markup with the <math> tag uses italic (as usual in LaTeX math mode), while {{math}} templates use slanted serif (I think I got confused by the fact that italic $m$ looks more like sans-serif than like serif):

$mx$ vs mx. — Vincent Lefèvre (talk) 21:54, 15 August 2020 (UTC)

{{math}} doesn't use italic by default (although {{mvar}} does), so you have to specify that (as you've done here). What you've got here isn't identical of course, but it's reasonably similar. So what's the problem? –Deacon Vorbis (carbon • videos) 22:00, 15 August 2020 (UTC)

I think we have here the problem of font matching that plagues mathematics and physics articles. So far, there is no good solution, though perhaps we can hope that MathML or a similar initiative will deal with this issue eventually. —Quondum 22:14, 15 August 2020 (UTC)

This looks rather different to me, and disturbing, in particular when used in the same sentence, like on Zero to the power of zero currently (which also uses plain HTML in some places, BTW). MathML would probably solve the issue. — Vincent Lefèvre (talk) 22:17, 15 August 2020 (UTC)

Well again, it's hard to say much more without a screenshot. –Deacon Vorbis (carbon • videos) 22:27, 15 August 2020 (UTC)

Below is a screenshot of: $mx$ – mx – mx

using respectively a <math> tag, a {{math}} template, and plain text. — Vincent Lefèvre (talk) 23:26, 15 August 2020 (UTC)

Ah. Your middle case is serif, but not with a flowing shape. This is presumably due to the serif font selection on your browser. While the left two examples do not match for me, they are not as jarringly different. BTW, I have edited Zero to the power of zero for inline font consistency. —Quondum 23:48, 15 August 2020 (UTC)

(edit conflict) Yeah, that's definitely not what it should be doing. The appropriate styling for stuff in in {{math}} should be:

.times-serif,
span.texhtml {
	font-family: "Nimbus Roman No9 L", "Times New Roman", Times, serif;
	font-size: 118%;
	line-height: 1;
}

Either of the first two should produce more reasonable results, and Times New Roman is pretty standard. Even a default Times should be fine as far as I can tell. If it's falling back to a default "serif", then that might be what's getting you. What OS, browser, and skin are you using? (Disclaimer: this is really getting to the point where I'm not that comfortable diagnosing this stuff; it might be better to take this to WP:VPT). –Deacon Vorbis (carbon • videos) 23:50, 15 August 2020 (UTC)

I'm using Firefox under Linux. But it appears this is because the option "Allow pages to choose their own fonts, instead of my selections above" is disabled (which is useful in general for readability). Now, with this option enabled, the renderings for the first two cases are more similar, but still noticeably different. So a unified solution should be found. Note that if one accepts this issue, a better workaround would probably be to generate italic characters (𝑚𝑥) with "Asana Math". This works better with Firefox. — Vincent Lefèvre (talk) 00:58, 16 August 2020 (UTC)

Font choice for PNG/SVG generation is a thorny issue, and not to be lightly embarked upon. The difference between Asana-Math (judging by the sample in the linked article) and the existing font is huge, and does not fit well on several systems. Your local font selection might be unusual. On pretty much every browser I've used (on Windows and on macOS) I think I have not seen a font being used for the {{math}} template that remotely matches what you're seeing. I would like to see a font that is less rounded in the PNG/SVG to more closely match typical rendering in mathematical texts, but beyond that any workarounds should be in the font selection in the generated HTML to match that. These could be by specifying a font in {{math}}, but I think currently it leaves it to the browser to choose a serif font, and I expect that a default can be specified for Firefox. —Quondum 12:14, 16 August 2020 (UTC)

Note that the Asana-Math Wikipedia page does not use italic (I'm wondering why, BTW), while we're discussing about italic rendering. See https://tex.stackexchange.com/a/145173/58921 for a font comparison, including italic (math mode) and the use of Asana Math. A problem with Firefox is that one cannot choose an italic font, just a serif font, a sans-serif font, and a monospace font. Italic just seems to be "fake italics" (i.e. slanted) as described on Oblique type. This should actually not be a real issue since for normal text, this can be fine (and one may actually prefer slanted fonts), and for math, one should normally use the Unicode italic characters: they have been introduced for this purpose, in particular for their semantic meaning vs styling (I remember a talk by Murray Sargent at ACA'99 – that's more than 20 years ago). Firefox currently does not apply the math font on these italic characters, but that's still much better than the slanted variant of a serif font. — Vincent Lefèvre (talk) 13:02, 16 August 2020 (UTC)

You are seeing a slanted roman font (your middle PNG example above), whereas in the line above it, I see in the middle case something very close to the italic Asana Math font that you linked to ... and I am using Firefox on macOS and on Windows. My default serif font is set to Times. I think italic fonts are used when installed, with slanted fonts as a fall-back. I'm no expert on this, but I have the feeling what you are seeing might be due to a slightly unusual configuration of your browser or lack of the full font set being installed.

On the use of Unicode Mathematical Alphanumeric Symbols for italic characters in mathematics on WP, I'm pretty sure this is a non-starter. —Quondum 15:16, 16 August 2020 (UTC)

Do you have the "Allow pages to choose their own fonts, instead of my selections above" option enabled in your Firefox? If you do, could you disable it and see what happens?

Why would the Mathematical Alphanumeric Symbols be a non-starter, while such characters have precisely been designed for this purpose? — Vincent Lefèvre (talk) 16:33, 16 August 2020 (UTC)

It's a non-starter because they're not as widely supported. For example, it worked fine on my Windows/Chrome setup, but on my Android tablet (also using Chrome), they rendered as boxes (default when it doesn't know what to do). If you're overriding a web page's font choice, you may have to just live with the visually unappealing consequences sometimes. I'm not sure there's anything else to do here. –Deacon Vorbis (carbon • videos) 16:51, 16 August 2020 (UTC)

On my Android phone, the characters from the Mathematical Alphanumeric Symbols block are rendered without any issue, both with Firefox and with Samsung's Internet browser. You should report a bug to Google.

A possible workaround could be a Javascript script to transform the characters, and leave the choice to the user (remembered thanks to a cookie).

Note that being able to override a web page's font choice is important, in particular on Wikipedia, whose default font is horrible. — Vincent Lefèvre (talk) 17:13, 16 August 2020 (UTC)

I concur with Deacon Vorbis that there is nothing in terms of the MoS that we can do. To answer the question, when I disable the "Allow pages to choose their own fonts, instead of your selections above" option, {{math}} still renders the mx as I saw it before: no change. With reference to your last comment, despite being terrible, working for essentially everyone with default selections is an overriding consideration. —Quondum 17:25, 16 August 2020 (UTC)

Note that being able to override a web page's font choice is important, in particular on Wikipedia, whose default font is horrible. You can do so with with some custom CSS. I'm not sure exactly what you'd have to change or what font(s) you're going for, but it would have the advantage of your browser not clobbering every font on every site you visit. As for dynamically changing variables in {{math}} to equivalent unicode symbols with JS...well, I'm really not too knowledgeable with this stuff, but I suspect it's possible, but difficult due to a lot of edge cases and variations in how you expect to find stuff marked up in the source. It's also a pretty heavy-handed, esoteric solution for this situation. In either case, if you want more info, I'd suggest WP:VPT. –Deacon Vorbis (carbon • videos) 17:41, 16 August 2020 (UTC)

I've found the cause concerning the poor italic rendering: Since I'm mostly interested in sans-serif fonts (which most pages use, often exclusively), I had configured that in the past, leaving the choice of the serif font to the system. I think that this was fine in the past, but since May, Debian was no longer overriding the fontconfig defaults, where the preferred font family is Bitstream Vera (thus "Bitstream Vera Serif" for serif), which is probably the poorest possible choice: this font supports very few characters and does not have proper italic, contrary to most fonts. After 11 years, this fontconfig bug was eventually fixed 2 months ago, but the fix is not in Debian yet.

Concerning overriding web pages' font choice, custom CSS can be difficult, because the purpose is really to affect every site I visit (I think I tried in the past without success, but I still use custom CSS to control the font sizes, the goal being to attempt to have the same size on all sites for the main text). IIRC, the latest major issue I could see was in January 2015, with the use of text figures in Wikipedia's section titles, which was disturbing, but it seems that this no longer occurs. — Vincent Lefèvre (talk) 20:17, 16 August 2020 (UTC)

Markup for math variables

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia_talk:Manual of Style/Text formatting/Archive 6#Mathematics variables section is wrong and needs updating

By my reading the MOS text has since been updated to resolve this complaint. -- Beland (talk) 06:08, 24 September 2020 (UTC)

Rendering of √

FYI, there's an RFC open at Wikipedia talk:WikiProject Mathematics#Improving rendering of radical symbol which asks:

Should inline √ expressions be rendered with <math>...</math> like ${\sqrt[{3}]{4}}$ where technically possible instead of with {{radic}} like ⁴√3 (which uses √+{{overline}})?

...and related questions. If there is consensus, text would be added to Manual of Style/Mathematics. Please respond there if interested. Thanks! -- Beland (talk) 05:46, 24 September 2020 (UTC)

@Beland: Thanks for implementing the RfC closure at Wikipedia talk:WikiProject Mathematics § Radical RFC comments. Could you also make a note that it is permissible to use the "bare Unicode character + no overline" option, per the closure? Best, Kevin (aka L235 · t · c) 21:28, 1 November 2020 (UTC)

@Beland: Hi, following up here – is this something you'll do or should I put it on my to-do list? Best, Kevin (aka L235 · t · c) 03:06, 3 November 2020 (UTC)

@L235: I added "The use of √ with no overline is acceptable for simple expressions, as long as the operand is unambiguous." Does that sound right? -- Beland (talk) 05:44, 3 November 2020 (UTC)

I also clarified "√ with no overline" can also still be used in image captions just like anywhere else, which I accidentally omitted from my previous edit. -- Beland (talk) 03:02, 7 November 2020 (UTC)

Looks good to me – I've also added a link to the RfC. Best, KevinL (aka L235 · t · c) 02:01, 8 November 2020 (UTC)

Latex-type ${\sqrt[{3}]{4}}$ should be used, the other method with \overline looks ugly, is unacceptable in almost all professional math-environments, and is hopelessly outdated. LMSchmitt 05:46, 9 November 2020 (UTC)

Tall inline parenthetical expressions

Hello, please excuse me if this is addressed somewhere in guidelines elsewhere but I haven't been able to locate it. For math that is parenthetical to text but contains tall formatting elements (i.e., a fraction), what is the preferred way to wrap it? Normally in tex I prefer to use "\left(" and "\right)" parens to ensure that they are the same size as the expression in question, but this does not look great when the rest of the text is not in tex, as in wiki articles. Specifically I'm encountering this issue with Squid giant axon, which has some tall exponents and fractions inline in paragraph 2. Currently they look like this:

This increases the space constant ($\lambda ={\sqrt {\frac {r\times \rho _{m}}{2\times \rho _{i}}}}$), leading to faster local depolarization and a faster action potential ($E=E_{o}e^{-x/\lambda }$).

But I wonder if it looks better for the parentheses to match the expressions more like this:

This increases the space constant $\left(\lambda ={\sqrt {\frac {r\times \rho _{m}}{2\times \rho _{i}}}}\right)$, leading to faster local depolarization and a faster action potential $\left(E=E_{o}e^{-x/\lambda }\right)$.

Or is there a better third option? (just occurring to me: would it be preferable to move large expressions like this onto their own lines/perhaps their own section devoted to the math?) I really dislike how bold the tall parentheses look w/r/t to the text, but I also feel like the math expressions far taller than their parenthetical is suboptimal. Thank you! Mehmuffin (talk) 12:53, 30 August 2020 (UTC)

@Mehmuffin: I think the parentheses look slightly better when they match the height of the math expression. I agree inline math like this looks oversized, but this can be minimized using the \textstyle syntax. Using your example:

This increases the space constant $\textstyle \left(\lambda ={\sqrt {\frac {r\times \rho _{m}}{2\times \rho _{i}}}}\right)$, leading to faster local depolarization and a faster action potential $\textstyle \left(E=E_{o}e^{-x/\lambda }\right)$.

Perhaps this syntax needs to be better publicized? -- Beland (talk) 05:51, 24 September 2020 (UTC)

There is a non-technical solution to this: parentheticals are avoidable in nearly all cases by thoughtful rewriting of the text. --JBL (talk) 16:12, 22 November 2020 (UTC)

Rendering of IR etc

The real numbers should be rendered as $\mathbb {R}$. This is today's standard in typesetting math books from major publishers and journals which are using LaTeX. The standard using ${\bf {R}}$ was popular in 1960's and 1970's books. But now it's hopelessly outdated. The section about rendering $\mathbb {R}$ should be rewritten. LMSchmitt 05:57, 9 November 2020 (UTC)

We've already been discussing this elsewhere; see the "MOS:MATH#Blackboard bold" thread on WT:WPM. Some of the participants there disagree with replacing boldface with blackboard bold, but I think there is at least consensus that, when using blackboard bold, it should be the math version and not the unicode version. —David Eppstein (talk) 06:34, 9 November 2020 (UTC)

[A] Who is "we".? Why is "we" authorized.? Why is this not discussed under this page.? Bizarre. [B] This is a style page many people look at. This is definitely outdated. It should be changed, because it doesn't reflect reality anymore. ---- [C] That this was discussed elsewhere is irrelevant. Agreements and arguments should appear here. People look and refer to here. ---- [D] It appears absurd to the highest degree that because 1750, some people agreed about the modern way of printing, that this should stay this way, because 1755 some people objected to change.LMSchmitt 10:22, 9 November 2020 (UTC)

Does this mean ℝ should be replaced with $\mathbb {R}$ along with all other similar Unicode characters (except when discussing the character itself)? If so, shouldn't MOS:BBB be saying that explicitly? It looks like the article real numbers is currently mixing R, ℝ, and $\mathbf {R}$, which is a bit disorienting and definitely not what MOS:BBB says to do. -- Beland (talk) 07:17, 21 November 2020 (UTC)

I think MOS:BBB should say to replace unicode-ℝ by math-$\mathbb {R}$ but perhaps we (the editors of Wikipedia as a collective whole) need an explicit discussion of that here first rather than relying on the discussion we (the participants at WT:WPM) just had there. The unicode-ℝ actually looks ok to me but the bigger problem is inconsistency between how unicode renders different bbb characters. To me the unicode-ℝ closely resembles the $\mathbb {R}$ except for being visibly smaller. (Neither matches the body text: the unicode one is too small and the math one is too big.) The same is true for unicode ℕ and ℤ, which look like small versions of the math ones. But unicode ℂ, ℍ, ℙ, ℚ are instead in a different bigger and bold sans-serif font that looks nothing like ℕ, ℝ, and ℤ, nor anything like the math $\mathbb {C,H,P,Q}$. As for mixing all three styles, I agree, not a good idea. —David Eppstein (talk) 07:27, 21 November 2020 (UTC)

OK. Does anyone object to replacing ℝ with $\mathbb {R}$? -- Beland (talk) 02:41, 22 November 2020 (UTC)

David's report of the Unicode symbols does not match this device's experience. For me, they all match in size, sans-serif, and lack for font weight. They also basically match the MathML renderings later in his paragraph (though those are indeed slightly larger). --Izno (talk) 03:47, 22 November 2020 (UTC)

Yes, the unicode appearance is likely to be highly variable depending on what fonts you have installed. I imagine for some readers it is even worse than mine with them appearing as boxes instead of legible letters. It's that variability, rather than the precise experience I reported, that makes them problematic. —David Eppstein (talk) 05:15, 22 November 2020 (UTC)

I agree to replace ℝ with $\mathbb {R} .$ However, replacing ℝ by ℝ (that is enclosing ℝ into {{math}}) improves already the rendering and is less time consuming. There are other Unicode symbols that are rendered differently with and without {{math}}, and, generally, the result is much better with {{math}}. So, in my opinion, the use of Unicode symbols must be reserved to those for which {{math}} provides a correct rendering, and must be discouraged for all other Unicode symbols. D.Lazard (talk) 17:04, 22 December 2020 (UTC)

There are plenty of books and journal articles written in 2020, even in top journals such as Annals of Mathematics, that use boldface instead of blackboard bold for the field of real numbers. So it is strange to argue that blackboard bold is the standard now. On the other hand, I don't see a problem with Wikipedia deciding that its style will be to use blackboard bold for its pages, as long as it acknowledges that boldface is a convention that is used by many other authors. Ebony Jackson (talk) 00:56, 23 December 2020 (UTC)

Functions are written to the left of their arguments

Should we specify that the convention is for functions to be written to the left of their arguments, as in f(x), not (x)f or xf, even in geometry? I wouldn't have thought this was necessary, but I seem to be arguing this point with Rgdboer at Talk:Real projective line. Ebony Jackson (talk) 06:52, 31 December 2020 (UTC)

This page cannot take into account all fringe considerations. So, there is no need to modify it on this aspect. It seems that the origin of the dispute is due partly to a confusion between $[x:y]$ (homogeneous coordinates) and $[x\;y]$ (row matrix), and partly to the promotion of a fringe convention. See the linked talk page. D.Lazard (talk) 11:34, 31 December 2020 (UTC)

OK, that makes sense. Thank you, Ebony Jackson (talk) 17:17, 31 December 2020 (UTC)

Pre-fix notation = Polish notation, right action = reverse Polish notation, and infix notation are all recognized already. — Rgdboer (talk) 05:18, 1 January 2021 (UTC)