Wikipedia talk:Manual of Style/Mathematics

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are known to be subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Inequality signs edit

Do you have to put spaces on both sides of an inequality? Also, if there is only one value, should a space be added there as well? Purplemountainmantalk contribs 20:10, 3 September 2022 (UTC)Reply

Yes, write "1 < 2" not "1<2" (just as "x = 1" not "x=1"); LaTeX does it correctly automatically, of course. I don't understand the second question. --JBL (talk) 20:15, 3 September 2022 (UTC)Reply
@JayBeeEll: If I'm understanding correctly, the second question is whether e.g. ">2" or "> 2" is preferred, for example in an infobox. -- Beland (talk) 18:00, 17 October 2022 (UTC)Reply
I see. My instinct is that such constructions should almost always be avoided, but maybe I could be convinced otherwise in a discussion of particular examples. JBL (talk) 18:50, 17 October 2022 (UTC)Reply
@JayBeeEll: You can see examples of one-parameter greater-than or less-than in Unmanned aerial vehicle#Classification types (table), North West England#Cities and towns (section headings), Nine men's morris (infobox), and Anthrax (infobox). -- Beland (talk) 02:51, 18 April 2024 (UTC)Reply

Should we more strongly recommend the use of mvar/math templates in preference to italic sans serif? edit

For any article where LaTeX is also used, it is typically clearer to read variables that are in an serif font like x instead of sans-serif x, even if the particular italic font used in one skin or another is different than the LaTeX font (computer modern)  

Now that LaTeX in <math> tags is displayed as SVG instead of PNG images, just using TeX everywhere is often even better looking. But there are some contexts where it can’t be used (e.g. in image captions), and many technical articles are written to not use LaTeX in at least some of their formulas, and I wouldn’t recommend trying to forcibly switch them them all to LaTeX.

But I routinely switch mathematical symbols in wiki articles sans serif -> serif italics, and this seems uncontroversially better in nearly every case.

(To be even more ambitious, we might encourage whoever is in charge of editing Wikipedia skins to specify a closer font in the CSS they apply to mvar/math templates, even perhaps some OpenType version of Computer Modern.)

jacobolus (t) 19:50, 19 March 2023 (UTC)Reply

I would strongly DIScourage the use of anything but LaTeX in an article where LaTeX is also used. The math/mvar templates try to achieve a similar appearance but they don't really succeed. Mathematics commonly uses the same letter in different fonts to mean different things, which can be confusing to newcomers; we shouldn't add to the confusion by using different fonts of the same letter to mean the same thing. In articles where the formatting is simple enough to be all-templates (e.g. no square roots or displayed equations) and in some special contexts where LaTeX-math can be problematic (e.g. formulas in titles of references with linked titles) I think template-math can be ok. —David Eppstein (talk) 20:37, 19 March 2023 (UTC)Reply
That's also fine with me, and switching other variables -> LaTeX seems fine to do case by case while also making other substantial changes, but we have many articles that currently mix LaTeX with plain text, and it would probably be disruptive to try to forcibly update them all.
But this page currently recommends plain sans-serif italics as one way of denoting variables, etc. I wonder if we should at least start by encouraging those to use math/mvar templates instead.
Personally I use LaTeX when writing new substantive parts of articles, except for things like writing "nth" in the prose, putting symbols into headings, or writing simple formulas in image captions (where some technical bug causes LaTeX to disappear from the caption when the reader clicks to view the image at full-window size). –jacobolus (t) 22:50, 19 March 2023 (UTC)Reply
Sure, I think we should avoid plain html/wikimarkup formatted mathematics for anything that involves variables and goes beyond just having numerical values and basic arithmetic on them. —David Eppstein (talk) 23:19, 19 March 2023 (UTC)Reply
Just saw an edit based on this discussion. In my opinion, mixing serif and sans, inline, looks atrocious. The right answer is to go back to a global default preference for serif (that is, for text as well as for math), but I doubt we can sell that. For inline non-LaTeX, I think we should not insist on serif. --Trovatore (talk) 03:37, 17 April 2024 (UTC)Reply
@Trovatore I don't think we should insist, but we might nudge: using serif fonts is generally more consistent if there is also LaTeX on the same page, which uses serif fonts. (Aside: Let me recommend changing your personal Wikipedia stylesheet to use whatever font you prefer – I have Wikipedia text all render in Charter, which I think is significantly better looking than any of the fonts used in common skins, and not too stylistically far from Computer Modern while being quite a lot nicer in my opinion. YMMV.) –jacobolus (t) 04:02, 17 April 2024 (UTC)Reply
I do in fact set my preferences to use serif. I think serif is just all-around better. In sans, it's hard to tell "Iago" from "lago" (see talk:Iago#Shouldn't the name be Jago rather than lago).
However, I have a strong negative reaction to using serif math inline in sans prose. I think e (mathematical constant) looks hideous for this precise reason (for those who don't set their preferences to use serif), and I think it reflects negatively on Wikipedia when people see it. --Trovatore (talk) 05:12, 17 April 2024 (UTC)Reply
I would add that displayed serif formulas look fine, even when the prose is in sans. It's the mixture of typefaces within a line that makes it look like a ransom note. I think it's fine to have the inline math in a different typeface from the displayed math; it's more important to keep the inline typeface the same than it is to keep the math typeface the same. --Trovatore (talk) 05:13, 17 April 2024 (UTC)Reply
The mixing of typefaces is ubiquitous, and it is quite common to mix serif math symbols with sans-serif prose. To me this mainly seems like your own hangup based on niche personal preferences (and "hideous" etc. is incredible hyperbole).
Using a serif symbol in block math formulas and a sans-serif symbol (which often looks dramatically different) for the same thing in the immediately adjacent prose is distracting, confusing, and ugly. –jacobolus (t) 05:17, 17 April 2024 (UTC)Reply
I don't think it's incredible hyperbole. I really do think it looks hideous. --Trovatore (talk) 05:24, 17 April 2024 (UTC)Reply
In any event, you should take this up at the Village Pump or similar. You can try to petition for whatever comes after Wikipedia:V22RFC to use a serif font by default. Maybe they can fix the variety of other more obviously typographically terrible choices/compromises while they're at it. –jacobolus (t) 05:38, 17 April 2024 (UTC)Reply
Having the same symbols appear in both serif and sans serif versions on the same web site — or worse, in the same article — is quite confusing to people who are trying to learn the math in question for the first time. Font effects, like bold, blackletter, and italics, are used to differentiate completely different mathematical entities; novice readers have every reason to expect that an intentional serif vs. sans serif difference conveys an important distinction. That includes everyone from high school students learning vector math to PhDs learning quantum mechanics or advanced set theory for the first time. Conveying information easily and accurately seems a lot more important to the core mission of an encyclopedia than cosmetics, if it's a binary choice.
If someday we start rendering LaTeX in sans serif, or for some reason decide to render inline math as sans serif, I think it still makes sense to advise editors to use {{mvar}} and {{math}}, before and after such a change. The fonts used for those templates can be switched in one place if consensus changes. Using those templates also means that spell checkers and screen readers can process math expressions correctly, which is often done differently than for English prose. In the event of a font change, we could simply delete the "because it makes a sans serif font" rationale from this guideline, but not have to make changes to massive numbers of articles. -- Beland (talk) 16:42, 17 April 2024 (UTC)Reply
Oh, and {{math}} prevents line breaking without using interstitial nbsp's, which maximizes clarity for both readers and editors. -- Beland (talk) 16:51, 17 April 2024 (UTC)Reply
This "if someday" hypothetical seems unlikely and not worth putting much weight behind. I agree with you that the template is a bit more explicit about author intention, and has some other benefits like suppressing line breaks. Can you explain concretely what the benefit is for screen readers and spell checkers? Have you explicitly tried running screen readers on the two variants? –jacobolus (t) 17:17, 17 April 2024 (UTC)Reply
Yes, I agree the "someday" scenario is not at all likely, but my point was that wanting that to happen is not a good reason not to use {{math}} etc.
The benefit for spell checkers should be obvious. In something like "The area of a disc can be found with A = πr2.", "πr" is not a valid word in any language, so that would get flagged as a possible misspelling. Equal signs and superscripts should not appear in prose, so those would generate complaints from my style checker. A grammar checker would need to know to treat this string as a mathematical expression in order to parse it properly into the surrounding sentence like a quotation or a noun. My grammar checker does dictionary lookups to determine part of speech, and it would be a bad idea to try to put every single possible mathematical expression into a dictionary or database.
The screen reader I use currently misreads both <math>...</math> and {{math}} expressions. I think it's getting images for LaTeX, which it completely ignores even if there is alt text. For math expressions displayed as text, it treats them as English prose. So "A = {x : x > 0}" is read as "ay equals ex ex greater than zero" rather than something like "The set ay equals the set of ex where ex is greater than zero". However, I could reconfigure my screenreader to look for the CSS added by the {{math}} tag and change how the contents are handled. It would be pretty feasible to have it produce something rudimentary like "ay equals open curly brace ex colon ex greater than zero close curly brace" that at least prevents important punctuation from being silently omitted. For untagged mathematical expressions, there wouldn't really be a solution other than building some AI that knows math when it sees it (which would not be cheap or easy). -- Beland (talk) 21:53, 17 April 2024 (UTC)Reply
Do you have a spell checker which understands {{math}} templates? Seems entirely hypothetical. –jacobolus (t) 01:38, 18 April 2024 (UTC)Reply
Yes, volunteers working on Wikipedia:Typo Team/moss have changed hundreds if not thousands of mathematical expressions to use {{math}} so they don't show up in the potential typo reports there. -- Beland (talk) 02:42, 18 April 2024 (UTC)Reply

On inline formulae edit

I've looked at this page recently trying to figure out when to use <math inline>, and I found the advice at Wikipedia:Manual of Style/Mathematics#Using LaTeX markup quite disorganized. I tried to improve it, but my edit was reverted by @JayBeeEll: [1]. I invite your ideas on how to improve my attempt, or on what you find valuable about the original version, rather than just saying it's worse/better. Matma Rex talk 10:50, 11 December 2023 (UTC)Reply

Hi Matma Rex, I'm on vacation but I wanted to quickly acknowledge having seen this. Briefly: prose is better than ugly bulleted lists, and your rearrangement separated pairs of examples that should be directly contrasted -- e.g.   and   should obviously be part of the same sentence. You have not articulated in what way you think your edit was an improvement beyond a vague handwave: the section you edited doesn't look "disorganized" at all to me. --JBL (talk) 17:05, 12 December 2023 (UTC)Reply
Some improvement have already been made since then, and your additional syntax highlighting probably wouldn't hurt.  — SMcCandlish ¢ 😼  20:01, 12 December 2023 (UTC)Reply
Thanks for responding. Enjoy your vacation, I'm not in a hurry :)
I really like bulleted lists, but I guess you could say I overuse them. Let's chalk that one up as a subjective preference, it's not that important.
I actually moved the inline and non-inline examples to separate paragraphs intentionally, to demonstrate that the latter increase the line spacing, while the former do not. I think that would actually clarify things. I also considered making it a table, or putting the examples in two columns. Would that look better?
The other improvement I wanted to make in my edit was to separate the advice or rationale for it, and the examples. The previous version doesn't really make it clear that <math inline> basically solves all problems and should be used in all cases, but I'm pretty sure that's what it really meant, and I think simple advice that always works is best, when that's actually possible. Unless that's not actually correct? Matma Rex talk 21:19, 12 December 2023 (UTC)Reply
It does not solve all problems. There are many formulas that are too big for inline regardless of whether the inline option is used. —David Eppstein (talk) 21:33, 12 December 2023 (UTC)Reply
Even the example given,  , while it fits inline when written with horizontal fractions and an inline-size summation symbol, is substantially more legible per se when written on its own as a block formula,
 
However, there's a trade-off: often the whole section becomes clearer when formulas are inline in the text instead of breaking up the visual flow so much as separate blocks. Authors need to make a subjective choice about which version is better in context.
@Matma Rex the purpose of that section of the page is just to show how to use display=inline as a tool, not necessarily to give complete advice about when to use it. –jacobolus (t) 21:41, 12 December 2023 (UTC)Reply

Subsection numbering edit

Subsections are strangely numbered in this article; for example, there is a section 7.6 but no sections 7.1, ..., 7.5. Apparently, this seems the case for other pages of the Manual of Style, and also in the name space "Wikipedia". Is this intentional or the result of a (new?) bug? D.Lazard (talk) 12:19, 1 April 2024 (UTC)Reply

I don't see it. Someone having fun on April Fools? —David Eppstein (talk) 18:12, 1 April 2024 (UTC)Reply

Not-greater-than rendering problems edit

On Talk:Inequality (mathematics)#Renderization of "not greater than" symbol, Fgnievinski reports problems rendering U+226F NOT GREATER-THAN, with Chrome version 123.0.6312.106 on Windows 10 version 22H2:

 

(The first three are all just the Unicode character not displaying properly.)

I assume this be added to the list of characters that should only be expressed with <math>...</math>? Are there any related characters for which anyone is also experiencing rendering problems? -- Beland (talk) 02:37, 18 April 2024 (UTC)Reply

Imo, the most problematic issue is with the symbol for function composition (∘ or ○). On some devices such as Safari on my laptop, the first one is so small that it is easily confused with an interpunct, and the second one has the same size as \circ ( ). On other devices, such as Safari on my iPhone, the first has the same size as \circ, and the second one is much larger. I am thus in favor of using only latex for function composition, but this implies to edit a lot of articles. D.Lazard (talk) 16:36, 18 April 2024 (UTC)Reply
The nice thing about a latex   is that it can stretch to fit whatever size you need. EEng 16:44, 18 April 2024 (UTC)Reply
@D.Lazard: I only see 231 articles with "∘". There are 597 articles with "○". It would be very easy for me to change all the instances of "∘" to "○". Would that solve the problem of visual confusion? -- Beland (talk) 21:41, 18 April 2024 (UTC)Reply
This would deserve more discussion, since, on my smartphone, "○" is much too large. My opinion is that only latex should be used when the symbol for function composition is used. D.Lazard (talk) 09:16, 19 April 2024 (UTC)Reply
@D.Lazard: OK, I've added all three characters to the list, recommending LaTeX markup instead. -- Beland (talk) 23:18, 19 April 2024 (UTC)Reply
No, the big circle is inappropriately large. –jacobolus (t) 14:40, 19 April 2024 (UTC)Reply

One thing that would help a lot in my opinion is (English) Wikipedia directly hosting a "math" font indicated first in the font stack in the CSS for {{math}} templates which explicitly included a wide range of supported glyphs. This could be e.g. something constructed from Computer Modern glyphs, or STIX 2.0 (or something else?). The appearance of STIX 2 is not an exact stylistic match for Computer Modern, but it's also not inordinately far away. I don't really know what would be technically required for MediaWiki/Wikipedia to host something like that though. –jacobolus (t) 14:54, 19 April 2024 (UTC)Reply

@Jacobolus: If you'd like to discuss that with the responsible parties, see [2] (where one developer said the server side generally doesn't host fonts) or [3] (where one person recommending asking Microsoft to fix their fonts). Beland (talk) 23:22, 19 April 2024 (UTC)Reply
Yes, please voice your concerns at the bug tracker, because the report was dismissed as not a technical issue. fgnievinski (talk) 18:19, 20 April 2024 (UTC)Reply