Wikipedia talk:Manual of Style/Mathematics
Historical note: The page Wikipedia:Manual of Style/Mathematics was originally obtained by moving content from Wikipedia:WikiProject Mathematics here, see the diff. As such, this page was not created from scratch on 18:39, 19 January 2005 as the page history may suggest, but is rather the product of collaborative discussion of Wikipedians since 2001 or 2002. |
This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
|
|||||
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III. |
Markup for Common sets of numbers?
[edit]The guidelines for § Common sets of numbers mention using \textbfin LaTeX. What about the LaTeX) commands
- \C ()
- \H ()
- \N ()
- \Q ()
- \R ()
- \Z ()
all of which render in blackboard? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:02, 25 July 2024 (UTC)
- These commands are completely fine to use (and indeed should be preferred, to keep source markup concise). If they ever become broken for whatever reason they could easily be fixed by a script. –jacobolus (t) 19:49, 3 October 2024 (UTC)
Hoping someone with template editor rights and more knowledge of Lua can fix {{Percent}}
, which is outputting hyphen-minus (---) and not minus-minus (−), e.g.: {{percent|-1}}
→ -1%
That should be producing: −1% —Joeyconnick (talk) 23:28, 29 July 2024 (UTC)
Integral not bracketing the integrand
[edit]Does:
warrant reformatting on the grounds of being confusing to those unfamiliar with the practice, or does MOS:STYLERET apply?
Thanks, catslash (talk) 23:51, 7 August 2024 (UTC)
- By the time you're seeing FTs, you should have started getting used to seeing several style conventions. At the very least, there is no alternative interpretation suggested by your title -- no bracketing -- that would make sense, since every factor depends on the variable of integration k. In other example integrands, where factors may not depend on k, whether or not those factors are included inside or outside the integrand does not matter. Anyone with competence in basic calculus will deduce that the integrals work either way, regardless of whether they get thrown off for a moment by unfamiliar conventions. SamuelRiv (talk) 19:43, 3 October 2024 (UTC)
- And yes there legibility and pedagogical reasons for putting the differential in one place or another, so MoS:StyleRet naturally applies. SamuelRiv (talk) 19:47, 3 October 2024 (UTC)
- This kind of thing is common in some disciplines, and is fine, but should perhaps be changed if it shows up in an article about introductory calculus. –jacobolus (t) 19:47, 3 October 2024 (UTC)
- Introductory calculus texts tend to put the or or whatever at the end of the expression, presumably to show where the integrand "stops". It's kind of like punctuation. In more advanced books, the or or whatever can sometimes come first. Sometimes this is helpful because it shows up front which of many variables is being integrated over. XOR'easter (talk) 20:54, 3 October 2024 (UTC)
Sign conventions and signatures
[edit]Are there any wiki guidelines on sign conventions and signatures, e.g., is a Lorentzian metric ( ,-,-,-), (-,-,-, ), (-, , , ) or ( , , ,-)? There are are multiple topics where the literature does not have a consistent choice of sign conventions. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:30, 25 September 2024 (UTC)
- The literature is so wildly inconsistent about metric signatures that the best we can do, I think, is to make each article internally consistent within itself. XOR'easter (talk) 18:48, 3 October 2024 (UTC)
- I would call any of those a "Lorentzian metric". The wikilink you pointed to seems to mention that, so that seems fine (though it might be better to send that redirect to a new subsection of Pseudo-Euclidean space instead of a subsection of Pseudo-Riemannian manifold). I agree with XOR'easter that articles should try for internal consistency (and optionally, unobtrusively mention alternatives). –jacobolus (t) 19:25, 3 October 2024 (UTC)
- Any are acceptable, but in my opinion the default should be - or - since then spacelike surfaces are Riemannian and not (for lack of a better name) negative-Riemannian. With --- or --- there are no Riemannian submanifolds except the very trivial (timelike) one-dimensional ones. Gumshoe2 (talk) 20:08, 3 October 2024 (UTC)
- From what I understand giving space-like vectors a negative square is common in some branches of physics. I don't really understand why, but I imagine they have some good reason. See Sign convention. –jacobolus (t) 22:37, 3 October 2024 (UTC)
- Yes, both conventions certainly appear in various textbooks: [1]. But I'm unaware of any particular reason; I think physicists often regard it as totally arbitrary, the same way mathematicians regard the sign convention for the Riemann curvature tensor. My impression is that those who work on mathematical aspects of relativity (including certain physicists) tend to use - , holding basically the same viewpoint I gave above. The difference between - and - is a less immediate, the difference only being visible in index notation.
- The books of Hawking–Ellis, Misner–Thorne–Wheeler, Wald, and O'Neill (which I take as the most standard references) all seem to use - (or -). Gumshoe2 (talk) 01:21, 4 October 2024 (UTC)
- From what I understand giving space-like vectors a negative square is common in some branches of physics. I don't really understand why, but I imagine they have some good reason. See Sign convention. –jacobolus (t) 22:37, 3 October 2024 (UTC)
Function notation and screen readers
[edit]Hello all, Per MOS:FNOF in this MOS article, we should use italic f rather than the U 0192 ƒ character for functions because screen readers don't support the latter, as of 2010. However, that was 14 years ago. Is there any new info on what characters are supported? Is this guidance irrelevant because of some other happenings in the WikiMath realm? I am not a mathematical editor and wouldn't know.
Thanks!
JuxtaposedJacob (talk) 08:04, 3 October 2024 (UTC)
- I would recommend against using the ƒ character for mathematics. Some people use it for f-stops, but f is probably a generally better choice for that too. –jacobolus (t) 19:29, 3 October 2024 (UTC)
- Hmm, aren't many of the recommendations on MOS:MATH kind of moot nowadays? Most of us who edit mathematics never have to directly deal with unicode encodings. If we want to render a mathematical formula, we can write something like <math>y=f(x)=g(x)</math> and it gives a perfectly formatted , without having to know anything about the font for the function or variable symbols. PatrickR2 (talk) 05:13, 4 October 2024 (UTC)
- That is an interesting point - I wonder if there would be consensus to do a broader adjustment of the article? JuxtaposedJacob (talk) 05:16, 4 October 2024 (UTC)
- The manual of style page seems fine. Whether this symbol is supported by screen readers is fairly irrelevant (and could be removed from this page). Either way the ƒ symbol should not be used for this purpose. –jacobolus (t) 15:54, 6 October 2024 (UTC)
- @JuxtaposedJacob I rewrote the section to better reflect discussion/consensus. Is that clearer? –jacobolus (t) 18:48, 6 October 2024 (UTC)
- Yeah, looks great, thanks!
- JuxtaposedJacob (talk) 18:51, 6 October 2024 (UTC)
- Can you give an example of a specific thing you think is moot? (Mathematical formulas are rendered in at least three different ways in Wikipedia, the LaTeX-based system is just one of them.) --JBL (talk) 00:49, 5 October 2024 (UTC)
- Specifically in this example, when using the letter "f" for a function name, we don't have to know anything about what unicode symbol we have to choose when using the <math> tags. And there are many guidelines of this kind that seem irrelevant if you let Latex do the rendering, which seem much easier than doing it "by hand". PatrickR2 (talk) 02:54, 6 October 2024 (UTC)
- That it seems easier to you personally to do it one way doesn't mean that guidelines about best practices when doing things other ways are moot! (To be clear: I broadly agree with you about what's easiest.) --JBL (talk) 17:34, 6 October 2024 (UTC)
- Specifically in this example, when using the letter "f" for a function name, we don't have to know anything about what unicode symbol we have to choose when using the <math> tags. And there are many guidelines of this kind that seem irrelevant if you let Latex do the rendering, which seem much easier than doing it "by hand". PatrickR2 (talk) 02:54, 6 October 2024 (UTC)
- That is an interesting point - I wonder if there would be consensus to do a broader adjustment of the article? JuxtaposedJacob (talk) 05:16, 4 October 2024 (UTC)
Truncating "insignificant" irrational numbers/really long decimals
[edit]I "fixed" an arithmetic error on the Euler method page but my result was an irrational number is there a prescription for truncating long decimal numbers on mathematics pages? The style guide said round except on mathematics pages, and for mathematics pages I couldn't find any guidance. And upon truncation should there be any notice to the reader? Fcondorn (talk) 03:19, 19 October 2024 (UTC)
- Other than ellipses, the standard indicator of truncation, e.g. π = 3.14159...? Remsense ‥ 论 04:41, 19 October 2024 (UTC)
- It is also common to write e.g. or to spell out approximately in words rather than symbols. —David Eppstein (talk) 07:08, 19 October 2024 (UTC)
Conventions for the groupings of constants' integers?
[edit]The Mathematical constants are uniformly presented integers in groups of five, Golden ratio is presented in groups of three, and the Copeland-Erdős constant infinitely without spaces. Is this an artifact of citation faithfulness, or is there a convention of conventions (so to speak)? kencf0618 (talk) 01:16, 24 November 2024 (UTC)
- Per MOS:DIGITS "digits are grouped both sides of the decimal point" ... "digits are generally grouped into threes". So if you find them grouped in other ways, I think they should be regrouped to this consistent style. —David Eppstein (talk) 01:21, 24 November 2024 (UTC)