Wikipedia talk:Manual of Style/Mathematics/Archive 1

From Wikipedia, the free encyclopedia
Jump to: navigation, search



Sometimes people say that this is an encyclopedia as a reason for excluding certain information that is considered too specialised/difficult. I don't see their point. I have seen some mathematics articles that suffer from too narrow a perspective, like laplace operator, which completely ignored generalization to forms and still ignores a discription in terms of covariant derivatives so it would apply to all tensors. Also I have seen some mathematics articles which are now physicist territory, like Noether's theorem and Lagrangian. I think that a good article should start at it's highest level and then explain how lower levels are special cases of it. These lower levels may then also have their own page if necessary. And if something has application to physics or anything else, these should then be treated. BTW The laplace article is still very far from decent since it does not say anything usefull about the (general) Laplace operator etc etc. Any comments?MarSch 18:47, 25 Mar 2005 (UTC)

You mean an article titled derivative should start with a general definition that encompasses the derivatives of first-year calculus, the derivatives of Schwartz's theory of distributions, and Radon-Nikodym derivative, and all the others, and only after that mention special cases? That seems incredibly silly to me. Michael Hardy 02:15, 3 Jun 2005 (UTC)
Hi MarSch. You need to put this on Wikipedia talk:WikiProject Mathematics if you want poeple to notice this. I would also suggest splitting it into several paragraphs, to make your point more clear. Oleg Alexandrov 19:06, 25 Mar 2005 (UTC)
I agree with MarSch. I would ask more specifically: what is the difference between a Wikipedia and a Wikibook? It seems to me that a sufficiently well-structured collection of articles on wikipedia would be just as useful to learn from as a wikibook, no matter what level of knowledge the reader currently has. In fact, I would go further: I think the division into "encyclopedia" and "textbook" is a by-product of historical technical limitations in publishing, which are now being broken down. I welcome the development of wikipedia into a source of material at a textbook level of detail. (However, I will try to restrain myself from writing such content if the consensus falls against it.) Dmharvey Talk 14:46, 2 Jun 2005 (UTC)
Violently agree with Dmharvey. In fact, WP is arguably better than a book, since its more conducive to research. One can dig more widely more quickly than one would ever hope to with a book. One neat idea is of a "wiki neo-book" which would be nothing more than a curious list of article titles that should be read in a certain order.
Note, however, that a number of structural problems need to be addressed in order to accomodate this kind of expansion. I've already belabored on one such issue on Wikipedia:WikiProject Mathematics/Proofs, but similar issues loom. The structure of an article becomes extremely important if it is to be readable. I also have uneasy feelings about subtle vandalisms, intentional or accidental, and my personal ability to manage my watchlist. I'd like to have some permanent way of stating "I've examined this formula, and agree that its correct". But I think this talk would best be for Wikipedia talk:WikiProject Mathematics and not here. linas 00:40, 3 Jun 2005 (UTC)
I am, unlike others, for peaceful resolutions! :)
The current wikipedia policy is to keep encyclopedia articles separate from books. This is not the place to argue against it; the consensus so far seems to be that this separation is good.
The advantage of a collection of loosely integrated articles (such as Wikipedia), over books (such as WikiBooks) is that you don't need to worry about global consistency, you don't need tight integration, and each article can be read rather independently of others. You also don't need to worry about mistakes in proofs. So, encyclopedia format removes a layer of complexity present in books, and as such, gives more flexibility and makes it harder to make mistakes.
By the way, MarSch's main point was not about books. It was about writing a math article top-down starting with the most abstract and going toward particulars. I would say everybody else disagreed with MarSch, see Wikipedia talk:WikiProject Mathematics/Archive7#Structure of math articles. Oleg Alexandrov 01:56, 3 Jun 2005 (UTC)
OK. Clarification of my point of view: I agree with the outcome of Wikipedia talk:WikiProject Mathematics/Archive7#Structure of math articles, that is, I think an article (particularly its introduction) should be accessible to as wide a variety of people as is possible, and then people should be able to meander to material that matches their level of knowledge/experience.
However, I tentatively stand by my position that in principle there need be no difference between a book and an encyclopaedia. I could be persuaded to change my mind. I am, after all, a complete newbie, and, I like to believe, open-minded. Perhaps someone can suggest a place where this has been discussed, so I can educate myself. Thanks. Dmharvey Talk 02:26, 3 Jun 2005 (UTC)
Try Wikipedia:Village pump (policy) if you would like a community-wide discussion. Oleg Alexandrov 04:43, 3 Jun 2005 (UTC)
Hi Oleg, I did have a look there, but it seems they only have archives going back two weeks at the most, and I couldn't find anything to answer my question.
In the meantime however, I did think of at least one reason why a textbook is different from an encyclopedia: textbooks often have "homework problems". (This thought was prompted by the Polygon Sum Conjecture discussion.) So far I haven't seen a set of exercises at the end of any WP article, and I concede that they probably don't belong there. (Well maybe, I need to think about that some more.) Someone once said that there is no substitute for doing a Hartshorne exercise every day (referring to the book Algebraic Geometry by Robin Hartshorne). Dmharvey Talk 11:47, 3 Jun 2005 (UTC)

I would like to mention that even I don't agree with myself anymore about the top-down approach. Bottom-up is the way to go, but now it is mostly bottom. I would like the encyclopedia to be more comprehensive. --MarSch 13:02, 3 Jun 2005 (UTC)

The difference between textbooks and encyclopaedias is that an encyclopaedia consists of loose articles. For instance, an textbook on (elementary real) analysis may have a chapter on univariate functions with sections on continuity, limits, derivatives, etc. However, an encyclopaedic article on continuity talks about continuity of univariate functions, multivariate functions, functions between metric spaces, functions between topological spaces (cf. continuous function). This is why it is easier to learn from a textbook than from an encyclopaedia. All IMHO, of course. -- Jitse Niesen 20:35, 7 Jun 2005 (UTC)

History section

Would like to see the Guideline recommend the inclusion of a History section - many mathematical fields and concepts have a rich and interesting background - see fractal, chaos theory or group theory for examples. Would be good if we could reach a concensus on the position of the History section - my preference is near the beginning of the article, straight after the intro, but in some articles (such as complex number) it appears near the end. Gandalf61 09:15, Jun 2, 2005 (UTC)

I second that. --MarSch 13:48, 2 Jun 2005 (UTC)
I also agree; although I have no preference about the location of the history section. Dmharvey Talk 14:34, 2 Jun 2005 (UTC)
Agree w/ Dmharvey. linas 00:40, 3 Jun 2005 (UTC)

the "informal introduction"

Perhaps we could add a section giving an example of an informal introduction for continuous functions, e.g.: "In the case of the real numbers, a continuous function corresponds to a graph that you can draw without lifting your pen from the paper." (This was a working definition at the beginning of a calculus class I once taught.) Dmharvey Talk 14:48, 2 Jun 2005 (UTC)

Agreee, all math articles should have an informal intro. Again, potential structural problems abound: if all articles have intros, invormal overviews, formal defnitions, a set of theorems, possibly a diagram, a history section, references, ouch, it risks getting dense and overwhelming. linas 00:40, 3 Jun 2005 (UTC)
Each article should have an introduction and it should be informal but correct. I dislike however the terms "loosely speaking", "jocularly" or some such. I like to say "in some sense". That means that I am being informal and not going to go into something technical right now, yet precise. --MarSch 13:08, 3 Jun 2005 (UTC)
The very point of the informal introduction is to drive the point home. Any means are fine for that. If you get a spark light up in the mind of the reader, you hooked him. If the price to pay for that is hand-waving, so be it. That can always be rectified later with the formal defintion. Oleg Alexandrov 15:50, 3 Jun 2005 (UTC)
My experience (both in WP and without it) is that often it is impossible to give an informal introduction that is nevertheless "correct" (whatever that means — let's not even go there.). That is, sometimes there is a person who will learn something useful from an informal introduction that is somewhat incorrect, yet will learn nothing from an introduction that is actually precise. This is the kind of person I would like to make sure is covered, which is why I don't mind if an informal introduction is somewhat incorrect — as long as it is made clear, by whatever means, that they are not getting the whole story.
I think the example I gave with continuous functions is an excellent example. There are high school kids who know what graphs of functions are, and given the definition "can be drawn without lifting a pen from the paper" will immediately understand a lot about continuity. If you gave that person an epsilon/delta definition, let alone an "inverse image of open sets" definition, they would learn precisely nothing. Dmharvey Talk 17:06, 3 Jun 2005 (UTC)
I like intuitive definitions like "can be drawn without lifting your pen". This is informal yet precise. Things that can be visualized make the best introductions. The epsilon-delta def needs to be preceded by another informal description, like "the closer you get to the point a, the closer the function gets to the limit b"--MarSch 18:34, 3 Jun 2005 (UTC)
(I know this is old, but...) the point is that this is not precise. Although functions from R to R are characterised by this property, this is only because the reals are connected. Indeed, I think a lot of people have difficulties when starting in topology because they need to make the switch from the connectedness idea of continuity to the "true" preserving-closeness continuity. --Taejo|대조 23:47, 17 July 2008 (UTC)

writing style section

There are various issues of writing style that I see crop up every now and then. I have put one of them on the "how to write..." page. Please feel free to add your own favourites. Dmharvey Talk 1 July 2005 15:32 (UTC)

Thanks for this. There probably are a lot more we could add. — mjb 02:57, 9 August 2005 (UTC)

With consensus I would add that the construction "then if" is especially annoying. Why can't people just state their theorems as hypothesis-conclusion, with the stage set in a previous sentence? Orthografer 16:49, 7 June 2006 (UTC)

Encyclopedic vs conversational tone

Lately I've been working on removing spurious "note that…", "it should be noted that…" and similar phrases from Wikipedia articles. I noticed these phrases crop up a lot in the math articles. It seems to be a side effect of the conversational, second-person, lecture-like tone taken in a lot of the articles. I have mixed feelings about this writing style; it is often found in textbooks and can help the reader understand a difficult subject by holding their hand through an explanation, so I don't want to suggest that it be abandoned. However, it does run counter to the detached, 'encylopedic' tone considered ideal in Wikipedia articles, so I want to encourage authors to avoid going overboard with conversational clichés. In a lecture situation where the listener is more open to having their attention redirected, it is typical and comfortable to hear certain phrases like "note that" repeated often. But in prose, where exposition is more linear, it tends to be jarring (especially if it happens often), and reflects either poor organization (crucial points shouldn't be afterthoughts) or a lack of confidence in the reader's willingness to continue reading. Therefore, I tried to add a bullet point to this effect.

I've seen examples of math articles written very much in a conversational, lecture style, and others that are written very much in a detached, encyclopedic style. I don't remember which ones they were, though, so if someone feels like mentioning examples or further improving the guideline, please have at it. Thanks — mjb 02:57, 9 August 2005 (UTC)

I agree with the above. In the same vein, I think we should discourage the use of the "editorial we". Paul August 03:57, August 9, 2005 (UTC)
I am not as averse to the conversational tone as other people here seem to be. I would make a distinction between prose that is, for example, giving an overview of the current state of knowledge of a subject (in which case the encyclopaedic tone works well), and prose that is, for example, leading the reader through a proof of a theorem (in which case the conversational tone works better). In the first case, constructions like "note that...." are usually spurious and can be rewritten without much trouble. However, I think it is more difficult to remove these clichés in the case of explaining a proof, where the author is trying to draw the reader's attention to logical relations between parts of the proof.
Also, the difficulty with discouraging the "editorial we" is that it forces more frequent use of the passive voice, which I am also stylistically opposed to.
Nevertheless, I appreciate the sentiments that people are expressing here and I'd like to hear more opinions. Dmharvey Talk 10:16, 9 August 2005 (UTC)

See Wikipedia_talk:WikiProject_Mathematics#.22Tone.22.2C_pronoun_use.2C_etc._in_math_articles (current version) and the related Talk:Knot_theory#You.2FMe (current version) and Talk:Braid_group (current version) for discussion on this topic. I was unaware of the discussion here, otherwise I would have directed people here instead. --C S (Talk) 05:47, 14 May 2006 (UTC)

I think we might be missing some subtleties. And that's not the editorial "we", nor the Royal "we", it's the first person plural "we". We in a math paper does not refer to the author (speaking of himself with editorial plural) but to the cooperation of the author with the reader; that is, we assume... means that you and I have to assume this; it's not about my assumptions (as in a scientist conducting an experiment), but about our common assumptions, which we pointedly recognize as critical in the process of deductive reasoning (as in, the defintions of "definition" and "set" are not in logic texts, we assume them). Also, consider refers to Subsequent statements shall refer to the hypotheses formulated here e.g. "consider a group G with multiplicatively denoted identity e and..."; if you remove the word "consider" there is no sentence. But we are hypothesizing something to which we shall refer in subsequent text. "Consider" is a short and simple way of encapsulating that. There's nothing conversational in most technical mathematics papers, really. It's much more formal language than in this encyclopedia. In fact I wish we permitted ourselves more explanatory prose, more often. Pete St.John (talk) 21:01, 12 February 2008 (UTC)

TeX vs. non-TeX

Recently, User:Jitse Niesen reverted edits by User:MathKnight to spectrum of an operator, citing this article as the reason for the revert. The things that were reverted were primarily the TeX-ification of plain-markup formulas, for example, the conversion of the plain-markup


to the TeX formula


I don't really like this revert at all, and I don't like the plain-text markup, for several reasons. TeX formulas can be converted to plain html, or not, depending on one's settings of Special:Preferences. Thus, if the page is marked up with TeX, the user can control conversion to HTML by changing thier preferences. By contrast, if a formula is in HTML, it's stuck there forever, and can't be TeX-ified. Thus, the general WP reader has far more control over TeX formulas than plain formulas. (Disclaimer, I am sensitive to this issue because my browser seems to be lacking fonts with the ∈ symbol, so it looks like a dumb square in my browser.) I would like to see a policy spelled out here that explicitly enourages the use of TeX, and discourages the use of plain HTML for math markup. linas 6 July 2005 00:57 (UTC)

A similar discussion was just taking place today concerning Fermat's little theorem or maybe it was Proofs of Fermat's little theorem. I also would like something spelled out. Perhaps the discussion at Wikipedia:How to write a Wikipedia article on Mathematics#Typesetting of mathematical formulas could be modified. I would like to see something that says "All equations should ideally be done using TeX, except inline equations where the PNG rendering would disrupt the text flow." It sort of says that already, but it's not very insistent. I know not everyone agrees with this, please jump in and give your opinion. Dmharvey Talk 6 July 2005 01:59 (UTC)
It all depents. If the TeX formula is inline, and becomes PNG, it must not be allowed. On my laptop the PNG images look huge, and look bad surrounded by text. On the other hand, if the formula is on a separate line (displayed formula), it is preferable to have them PNG I think. Oleg Alexandrov 6 July 2005 03:29 (UTC)
Yes, but it is exactly the inline formulas where this is a problem. The display formulas already are mostly in TeX, and aren't a problem. Have you tried changing your formula display preferences, to see what this page looks like? linas 6 July 2005 04:04 (UTC)
I believe editors better keep the preferences set to default when it comes to displaying formulas. Then we will see the same things as the readers. Now, if I change my preferences to render all formulas as PNG, I think things will look worse. If I force all of them HTML, they will also look worse, as html does not render well some math formulas. Oleg Alexandrov 6 July 2005 04:36 (UTC)

This is a topic that returns regularly, see for instance Wikipedia talk:WikiProject Mathematics/Archive4(TeX). Of course this does not mean that it is not worth having, for instance, I didn't realize that some people do not have a font for ∈ which must be very annoying. However, PNG in running text looks very ugly to some people (including myself). I think that past discussions have showed that there is not a good solution at the moment which makes everybody reasonable happy.

However, it may be possible to change the software so that a decent solution will be possible. One alternative is to support MathML, and I'd love to find out how feasible that is, both on the server side and on the client side. The other possibility is to improve the routines that convert the TeX to HTML. It should be possible to do a better job, and then we could use <math> tags everywhere. -- Jitse Niesen (talk) 6 July 2005 19:34 (UTC)

Help_talk:Formula#Maynard_Handley.27s_suggestionsOmegatron 02:18, 1 November 2005 (UTC)

(The link right above is a bit of a mystery to me: can anybody please explain?)
I agree with most of the above. Having started a small sub-article myself recently, I wan't sure what to do with the "central dot" for function notation. The HTML "central dot" (⋅) is understood by e.g. Firefox but not by e.g. Internet Explorer. So I decided to use TeX. I hoped that WP would be smart enough to render this in HTML for browsers that support the HTML ⋅, and leave the PNG for those that don't. Alas, it looks like it's not so smart ATM.
The guidelines in this manual of style do not make it clear enough what one should do. In fact, it looks like they encourage quite the opposite: "However, still try to avoid in-line PNG images". I think this is missing the point entirely, as one should not think-ahead and write math depending on how it will look like on this or that browser. I'll be even more radical and say that there should be just *one* correct and accepted way of writing math, and all the burden of rendering should be put on the server-side. The server should be able to display the correct thing depending solely on the formula, on the browser used and on the user settings. This should be transparent to authors and readers alike. Hope this makes sense, I can be more specific if unclear. PizzaMargherita 19:42, 1 November 2005 (UTC)

Downsampling a too-big graph

See also Wikipedia_talk:WikiProject_Mathematics#graphs

Hello. In the discussion of graphs on Wikipedia:How to write a Wikipedia article on Mathematics, it is suggested to make the graph too big, then downsample it. I understand the concept but I'm not familiar with the commands. Can someone state the commands that are needed to do that? I think it would help a lot if we can bypass the need for reading through man pages or whatever to find it. Thanks for your attention to this topic & happy editing, Wile E. Heresiarch 01:14, 11 July 2005 (UTC)

I HATE when people force you to read through man pages.  :-) I added some menus. Anything else? - Omegatron 01:44, July 11, 2005 (UTC)

For Windows users, You have to install Ghostscript to open .ps files in the GIMP. I linked to the instructions but those instructions aren't the best. You should really set enviroment variables instead of copying the file to your system directory. You need to right-click My Computer --> Properties --> Advanced tab --> Environment Variables --> New and create variable names and variable values as such:

C:\Program Files\gs\gs8.51\bin\gswin32c.exe
C:\Program Files\gs\gs8.51\lib

Though your path name may vary. I don't really want to put all these instructions in the middle of the text, though. Maybe this information should go under the GIMP or Ghostscript articles, and we can link to that? It's too "how-to", though, for the WP. - Omegatron 14:41, July 22, 2005 (UTC)

I agree, let's move the graphs to its own page. - Omegatron 18:59, July 22, 2005 (UTC)

Every time I upload a picture with one of these methods, I include more and more detailed instructions. They should really just be made general, go in the graph section instead, and save me a lot of work. Here are the lastest, though: Image:Butterworth response.png - Omegatron 17:20, July 23, 2005 (UTC)

oleg's rearrangement

Yes I like the "typesetting" part leapfrogged to the end. Dmharvey Talk 02:44, 19 August 2005 (UTC)

Math or Maths?

moved from Talk:American and British English differences

It is often abbreviated maths in Commonwealth English and math in American English. — 23:15, 20 August 2005

(I signed your post for you.) In the USA it's not just often, it's pretty much always "math." People will look at you funny if you say "maths." I don't know what advice should be given to authors. Perhaps the shorter terms should be avoided altogether, and people should be advised to write out "mathematics" or "arithmetic" instead. What do the others here think? — mjb 06:05, 21 August 2005 (UTC)
I agree that writing out mathematics is best in an encyclopedia. However, when an abbreviated term is more appropriate for some reason, the preference of the original author should be respected, in accordance with WP:MOS#National varieties of English. —Caesura(t) 21:10, 11 October 2005 (UTC)

"It is easily seen that ..."

Recent manual of style edits by User:Crasshopper deprecate this commmon linguistic style. But I wonder if that is the right thing to do; in fact, I think its not. When a mathematician says "its easily shown that", they are not trying to belittle the reader, (and the reader should not feel belittled or stupid), rather, it is a verbal hint about the length of the proof of a theorem. There is many a time that I've been stumped by some formula, while faced by the mocking words "it is easy to show...". This is always followed by a slap to the forehead, "but of course ... its obvious". For that is the very nature of math. So what shall we write instead of the words "its easy to show"? Should we say instead "the proof of this proposition is very short"? Instead of writing "its easy to show", should we start inserting very short proofs that show it? No I think not. linas 04:24, 2 September 2005 (UTC)

I agree, that section of the manual sounds a bit anal IMHO. Some deprecated expressions are just widely used and accepted idioms of writing maths. PizzaMargherita 20:12, 1 November 2005 (UTC)
I disagree. Although the phrase is commonly used between mathematicians, i think it can be problematic on Wikipedia. What can be easily shown by a degree-level student could be extremely difficult for a high-school student: it's all a question of perspective, and the phrase would be discouraging to those high school students. Personally I would prefer the very short proof to be provided - it's frustrating to follow through a proof and then get lost on one step, but I can see that that would be impractical at times. As the current manual suggests, hinting at HOW it can be shown is more useful. Hermajesty 19:17, 14 January 2006 (UTC)
Of course I agree with myself, but I'd like to weigh in again here, in response to Linas' comments. I personally often feel belittled when reading maths documents that use phrases like "clearly" and "obviously", and such words don't seem (to me) to make texts any more readable. Even if they are standard in current textbooks, that doesn't make them good. In fact I see them as a kind of jargon that reflects poorly on mathematicians (thus perpetuating innumeracy, yadda yadda yadda). In the first place these words bristle at the reader, in the second place they are unnecessary (do most readers actually care how easy or difficult a proof is? I know I don't; I just want the result), and in the third place they are frequently untrue (see Linas' comment about being stumped and then afterwards thinking, "but of course ... it's obvious". If it were obvious then one would not be stumped). Whether or not mathematicians intend to insult readers with their language is beside the point. I think we should take care in our verbal exposition to use our words more judiciously and with more purpose. If you mean "It only takes a few lines to prove," say that. If you need to segue from one idea to another, do so - but don't add insulting words needlessly. Crasshopper 18:52, 20 February 2006 (UTC)
I definitely disagree with the second point: it's important to me whether a proof is short or long, and whether it's routine or requires some major idea. Perhaps "clearly" and "obviously" should not be used, though I don't find them belittling (they signal that if it isn't obvious to me, then I need to study it more, not that I'm stupid). Alternatives: Straightforward, or A short proof / routine argument shows that. It might be good to keep in mind that some people find clearly / obviously belittling, but for advanced maths, the readers are probably used to the style and won't mind. -- Jitse Niesen (talk) 20:20, 20 February 2006 (UTC)
To rephrase Jitse,
In mathematics, there is an immense raft of specialized jargon. The phrases "Clearly," "Obviously," and "It's easy to show that ..." are a part of that jargon. Although they resemble the English language, their true meaning is subtle.
Mathematicians often encounter head-scratching claims in the papers they read, claims that make them stop and wonder "what does this mean?", and "how could this possibly be true?", or "how could the author presume such a thing without any justification whatsoever?". These head-scratchers come in two basic varieties: the simple, forehead-slapping, "duhh, of course" kind, and the complicated kind. These two types can be very hard to tell apart, and one can loose hours or days on them. There are some well-known stories of strong mathematicians who spent weeks on problems only to wake up in the middle of the night with a "duhh of course" inspiration. The phrases "Clearly," "Obviously," and "It's easy to show that ..." are used to indicate to the reader that what follows is of the forehead-slapping variety. They do not imply that what follows is somehow "easy"; its usually not -- if it was actually easy, then the author wouldn't need to coach the reader with this "com'on you can do it" pep-talk.
Yes, texts that use these phrases may seem intimidating, but that comes from an unfamiliarity of math jargon. No one expects that the claim following an "Obviously..." will be obvious to anyone without years of preparation. linas 01:32, 21 February 2006 (UTC)
Key words: In mathematics,
This is an encyclopedia; not a mathematics text. I'm sure there's a wording that conveys what you just said in a way that non-mathematicians will understand without knowing mathematician jargon. — Omegatron 01:56, 21 February 2006 (UTC)
I seriously doubt that there are any non-mathematicians reading any of the WP math articles. For starters, you need at least an undergrad degree in math, if not advanced degrees, to understand most of these topics. Heck, I have a PhD and a postdoc under my belt, and I still don't understand most of the articles. Yes, there are some articles that are aimed lower, but I don't think those use this style anyway. linas 05:58, 21 February 2006 (UTC)
When writing a Wikipedia article, you have to decide on the audience. Some topics in mathematics, like Fermat's last theorem, will attract non-mathematicians, and for those jargon should not be used. However, other topics are so advanced that it is not possible to explain them without assuming that the reader has a grounding in maths (e.g., de Rham cohomology). I see no reason why those articles should not be considered as a mathematics text. Mathematicians do not use jargon to keep non-mathematicians out (at least, they ought not), but they use jargon to denote concepts more succintly and precisely than is possible without using jargon. -- Jitse Niesen (talk) 14:11, 21 February 2006 (UTC)
It's a common joke that "from which easily follows that" and similar phrases are mathspeak for "I don't know the proof, but I think it's true". Seriously though, I really hate it when books do that. If it's so easily shown, then show it. Shinobu 01:01, 21 December 2006 (UTC)
A good place find examples of this type of thing is On Numbers and Games. In my copy (2nd ed.) I counted 7 identities whose "easy 1-line proofs" were omitted in Chapter 1 alone. Even in the theorems were Conway writes out the proof they're usually full of ellipses signifying "and a bunch of similar expressions" or the like. In this case it made sense; filling in those proofs and writing out everything that the ellipses represent would turn the chapter into an impenetrable forest of symbols which would, if anything, be more intimidating than the text as is. 'Easy' in this case is used in a relative sense, not necessarily easy for anyone who might pick up the book, but easy when compared to the other proofs in the chapter. The problem arises when authors abuse this kind of editorial discretion. In the corresponding Wikipedia article, Surreal number (this is a snapshot), I counted three statements that are described as easy to show or clear. In two cases the statements are easy to show from the rule xL<x<xR, the catch is that this rule is never stated anywhere in the article (that I could find, correct me it I'm wrong). The third statement (G + -G = 0) is one where Conway writes out the proof. In this case it might have been instructive to write out the meaning of the theorem and proof in English (which amounts to giving a winning strategy for the second player to move to win the game G + -G). There are two lessons from this little example, I think. First, if an author does use a phrase like "It's clear that ..." they must take extreme care that it really is clear from just the facts presented in the article and not using author's outside knowledge. Articles are in a constant state of flux so the facts needed for the "easy" proof may disappear tomorrow, making the proof difficult. At least the author should put a specific indication of what facts would be used in the "easy" proof, e.g. "From the principle stated above that all men are mortal, and the fact stated in the previous paragraph at Socrates was a man, it's easy to see that Socrates was mortal." Second, if the proof of a statement is mathematically trivial then it may be a good idea to translate it into plain language so that people who are not familiar with the subject can understand it and thus understand the subject better. The upshot of all this (imo) is that a certain amount of "it's easy to show... " may be useful in some cases, but for Wikipedia it will probably require such case and thought to do it appropriately that you may as well just give the proof anyway.--RDBury (talk) 00:54, 24 March 2008 (UTC)
I agree with that, and the assessment linas gives above. In most cases, if you we mention the principle from which a claim follows, it's no longer necessary to use the "easy" or "clear" phrase. Compare:
"From the principle stated above that all men are mortal, and the fact stated in the previous paragraph at Socrates was a man, it's easy to see that Socrates was mortal."
"It follows from modus ponens that, if all men are mortal and Socrates was a man (as discussed above), then Socrates was mortal."
People may (and should) consult our articles to remember why something is obvious, and expect us to tell them directly. In a textbook, by comparison, the author often wants to make the reader think through everything rather than simply telling the reader what's going on. We don't need that sort of indirect (but pedagogical) exposition. — Carl (CBM · talk) 02:01, 24 March 2008 (UTC)

Italics for points and variable subscripts

I want to add a new section entitled Points, stating, "Points are usually written in uppercase italics, such as point A, P, O." All text books I checked use uppercase italics for point labels.

Secondly, we currently have the following statement under Variables. "Descriptive subscripts should not be in italics, because they are not variables. For example, mfoo is the mass of a foo." The Superscripts and subscripts section also states superscripts and subscripts should have no other formatting. Should we add a sentence or phrase to both sections stating whether or not superscripts or subscripts that are variables should usually be/not be in italics? An example follows.

σij  versus  σij

Although text books usually show variable superscripts/subscripts in italics, I believe it might be acceptable (for HTML formulas) to use unemphasized variable superscripts/subscripts for on-line purposes. Italic subscripts are slightly less legible on-line, whereas italic and upright subscripts are equally legible in text books. --Simian, 2005-10-02, 22:06 Z

That depends on your browser. Italic subscripts look just fine to me. — Omegatron 02:21, 1 November 2005 (UTC)
I vote for italics, because that is the standard typographical convention. Indices are themselves a kind of variable. Once again, browser shortcomings should not affect the way we write. The server-side can take care of that. PizzaMargherita 20:41, 1 November 2005 (UTC)

Italics vs. bold vs. bold italics

Concerning italics vs. bold vs. bold italics, this manual of style seems to contradict itself and Wikipedia:Technical terms and definitions. From what I can infer, the relevant rules according to that article are

  1. In the first sentence, explain the article title, writing it in bold.
  2. Throughout the article, for each technical term, do one of the following:
  • The first time it is used, define it, rigorously or nonrigorously, writing it in bold italics; each subsequent time it is used, write it in italics.
  • The first time it is used, leave it undefined, writing it in italics; each subsequent time, leave it in plain face.
  • The first time it is used, link to an article that defines it; each subsequent time, leave it in plain face. (I added that one.)

Actual WP math articles use a variety of conventions, but they often give defined terms in bold, not bold italics, and leave subsequent uses in plain face. On the other hand, this 'Manual of Style (mathematics)' seems to give them in bold sometimes and italics sometimes. (Also, is there a reason why 'Style' is capitalized?) It might be nice to agree on a simple set of conventions. Joshuardavis 17:06, 22 October 2005 (UTC)

Style for constants

When I learnt (La)TeX, I also learnt that the "mathit" (or italics in the mathematical environment) should be used only for valiables (e.g. x or i as an index in a sum) and generic functions (such as f(x)). This is why, for example, we have special TeX commands for well-known functions, such as "log" or "sin". I also remember vividly (but unfortunately cannot find a reference) that this also applies to any other non-variable and non-function, be it a less-known function, a subscript having a non-variable meaning (e.g. , or a constant. I know it would be a pain now to put "mathrm"s everywhere, but can anybody confirm that is the (if often neglected even in authoritative books) typesetting rule? Thanks. PizzaMargherita 21:10, 1 November 2005 (UTC)

Yeah, I've been adding mathrm's all over the place for non-variables. I don't know of a better solution. — Omegatron 23:54, 18 November 2005 (UTC)
BTW, the argument of an elementary function should be preceded by a reduced space, such as sin x.

Minus vs. Negative

I'm looking at the -40 article, and wondering if there is a rule or guideline about the use of the words minus and negative. My understanding is that negative is a unary operator and so it is correct to speak of the number negative forty but incorrect to speak of minus forty, while minus is a binary operator and so three minus five is correct while three negative five is not. Can someone please confirm or deny this? And if it is the case, should the wording in the article be changed? I would like it to read negative forty personally, but it is much much more common when speaking of temperatures to hear minus forty. Macho Philipovich 15:50, 21 December 2005 (UTC)

This question arose before, I think at Wikipedia talk:WikiProject Mathematics. I'm sorry I can't be more precise than suggesting you look through the archives. I seem to remember that there was no conclusion on what to use. -- Jitse Niesen (talk) 14:51, 23 December 2005 (UTC)
Yeah, I think some people liked minus, and some negative. In US, I think they indeed say "minus forty" for the temperature (when I was in Minnesota :) but I was told that when teaching math one should say "negative forty". So I prefer negative forty myself, but I don't know.
By the way, you can ask again at Wikipedia talk:WikiProject Mathematics if you want, that page is visited more often than this one. Oleg Alexandrov (talk) 21:07, 23 December 2005 (UTC)

Typesetting of mathematical formulas

I think a large part of the contents can be moved to meta:Help:Formula. That page is currently biased towards TeX. Moving these HTML instructions/guidelines in that (Meta) page would make it self-contained, and would avoid duplication/contradiction with this page.

I think in this (Wikipedia) project should keep referencing that page, and keep only WP-specific guidelines, like colon for indentation and rendering settings. PizzaMargherita 21:59, 14 January 2006 (UTC)

Such a move may open a big can of worms. I am not sure it is worth pursuing. Oleg Alexandrov (talk) 00:23, 15 January 2006 (UTC)
 ? PizzaMargherita 09:40, 15 January 2006 (UTC)
I agree that m:Help:Formula is biased towards TeX. Do have a go at it. But I think you shouldn't delete anything here. Duplication and even contradiction is not a bad thing. m:Help:Formula should only give the facts while this page can mix them with the policy on the English Wikipedia. -- Jitse Niesen (talk) 13:34, 15 January 2006 (UTC)
  • Duplication is always a bad thing because it makes maintenance impossible.
  • Contradictions can't be right, by definition.
I agree on the rest: meta should expose the hard facts and this page set out guidelines specific to WP. I'll give it a try when I have some time. PizzaMargherita 14:41, 15 January 2006 (UTC)

The example of an in-line formula on line 5 of this section does not show up (on my browser, anyway). Is this a general problem? Hgilbert 21:07, 2 March 2006 (UTC)

Typesetting Algorithms

I haven't been able to find any official guidelines for typsetting algorithms, particularly mathematical algorithms. I note that Itoh-Tsujii inversion algorithm and Pohlig-Hellman algorithm both use a fairly standard pseudocode style that is common in mathematics. Is there any chance of formalising some guidelines for presenting mathematical algorithms? Leland McInnes 04:50, 29 January 2006 (UTC)

Have you read User:Dcoetzee/Wikicode and surrounding pages? Then you are probably aware that this might be harder to achieve than you think, unless the guidelines are very flexible. Personally, I find that in practice I prefer to write out the algorithm in prose instead of using a semi-formal presentation (my background is in numerical analysis). Nevertheless, I've nothing in principle against adding some suggestions.
Looking at the examples you mention, I think that Itoh-Tsujii inversion algorithm is fine. I don't like Pohlig-Hellman algorithm that much; it mixes explanation of the algorithm with the algorithm itself, and I think it would be better presented as prose, or perhaps as a combination of algorithm plus explanation of prose (is this clear?). -- Jitse Niesen (talk) 13:11, 29 January 2006 (UTC)
I have read the Wikicode debate. I'm not suggesting anything so strong, simply some basic guidelines to provide consistency in formatting mathematical algorithms. That would mean, for example, that when formatting an algorithm as a numbered set of steps it might be reccommended to do
 :'''Inputs''' Description of inputs
 :'''Output''' Description of output
 :# Description of the first step on the algorithm
 :# If the algorithm has substeps due to conditional or looping constructs
 :## Substeps should be nested numbered like so
 :## Etc.
With a few other guidelines based on what seems to be common practice (for instance ← is the popular assignment operator for mathematical algorithms, and "return" rather "output" seems to be the preferred way to denote that the algorithm should terminate outputting a specific value). Indeed, that might be the ideal place to add a few suggestions like trying to keep explanation of the algorithm outside of the numbered steps.
This, of course, doesn't preclude someone using Wikicode, their own pseudocode, or an implementation in a specific language - rather I'm suggesting have some basic formatting guidelines for the general style of algorithm description used here. I guess I mean guidelines of the form "If you are formatting your algorithms in this sort of format, here are soem guidelines on conventions, preferred style, and how to use Wiki markup suitably". Leland McInnes 21:43, 29 January 2006 (UTC)

Colour in latex now possible

I thought that people may like to know that colour mathematics is now possible, like this: . —Preceding unsigned comment added by Lupin (talkcontribs)

Cool! But I would argue that one should be very conservative when attempting to use colors in formulas, in the same way as avoiding if possible colored html text. Oleg Alexandrov (talk) 01:28, 1 February 2006 (UTC)
I'm reminded of a paper in an obscure Swedish journal which purported to prove the inconsistency of ZF, using a strange notation with red/black formulas where the color was significant. (It was later generalized to a proof of the inconsistency of PA in a Finnish (?) journal.) Arthur Rubin | (talk) 02:48, 1 February 2006 (UTC)
Whoa! — Omegatron 03:54, 1 February 2006 (UTC)


Any consensus on the policy on fractional powers? We write the squareroot sign for powers of one half, but what about cube roots? Do we put the squareroot with the 3 above, or do we put ^1/3? And the others? yandman 14:26, 10 October 2006 (UTC)

I always use the root sign when there's a mathematical reason that the exponent is 1/integer. But I prefer not to use non-integer values that way... unless it makes the equation more readable (which is rare). Shinobu 00:53, 21 December 2006 (UTC)

Definitions: use := or \equiv?

I didn't see anything about which infix to use for definitions. Some use , but I find this very misleading, since it already has two other meanings: equivalence (hence its Latex code) and identity (first use). I would therefore advocate := or the equal sign with "def" underneath. (Sorry, I don't know the Latex code for that.) — Sebastian (talk) 01:43, 19 October 2006 (UTC)

I suggest you ask this question at Wikipedia talk:WikiProject Mathematics where more mathematicians hang around. Oleg Alexandrov (talk) 02:38, 19 October 2006 (UTC)
Note: Discussion has been moved there, but so far no clear decision has been reached about which policy to recommend. Please participate in that discussion. — Sebastian (talk) 23:01, 24 October 2006 (UTC)

Square and cube

Are we allowed to use ² and ³? (They're much easier to type than the alternatives.) Shinobu 18:41, 20 December 2006 (UTC)

I would use <sup>2</sup>, as it ensures universal readability. —Preceding unsigned comment added by Mets501 (talkcontribs)

I think browsers that don't get ² and ³ are just as rare as those that don't get sup. Shinobu 00:49, 21 December 2006 (UTC)

The problem is that ² and ³ look horrible in many fonts (they are usually far too small). Compare
  • 1.0 g/cm³
  • 1.0 g/cm3 (1.0 g/cm<sup>3</sup>)
  • (<math>1.0 \text{ g/cm}^3)
With my browser and setttings, the <sup>...</sup> sample is easiest to read, and the ³ by far the hardest. I don't think ¹, ², and ³ should be used at all for superscripts. It also doesn't play well with others: n² and n2n would look bad on the same page. 21:24, 26 December 2006 (UTC)
Even worse is R²n, where the superscript font sizes, weights, and baselines are different (for my viewing setup). And although superscript 1, 2, and 3 glyphs are available in common fonts, superscripts 4 through 9 and 0, and all subscript digits, are not. For me, the size of the glyphs for these Unicode characters is something like this: R2n. With such a tiny size, I have great difficulty distinguishing a 2 from a 3.
Perhaps we can help with the typing ease. The typical way to type the superscript-2 character is to use an entity name, ². One way to type a generic superscript is to manually type the tags, 2. However, in both cases we have an "insert" button for the edit window, and the latter is bigger and more convenient; Fitts' law predicts it will be faster. The button that inserts the tag version is clever. If text is selected, that gets the tags wrapped around it. Otherwise, place-holder text is used, but preselected so typing replaces it. While editing, look immediately above the region containing the text for a button that looks like this: Button upper letter.png.
Incidentally, we can use the superscript and subscript tags for simple built-up fractions, like 355113. --KSmrqT 07:37, 28 December 2006 (UTC)

I agree that ² etc. should not be mixed with sups. As for the ² being too small, I can't confirm that, here it looks okay. Unlike sup it doesn't interfere with the line height. So stylistically it depends on the particular situation, I'd say.

@The typical way to type the superscript-2 character is to use an entity name: no. The typical way to enter them is AltGr-2 etc. Fitts' law predicts I'll probably use ² when I'm feeling lazy. Shinobu 22:45, 28 December 2006 (UTC)

If you use ² that's fine, but be prepared for others to correct it to <sup>2</sup> or <math>^2</math> for the reasons explained above. 05:45, 29 December 2006 (UTC)

Section on notational style

I feel that we should have some section on respect for different notational styles in mathematics articles. Something along the lines of Wikipedia:Manual_of_Style#Disputes_over_style_issues. As long as two notations are acceptable it is inappropriate for an editor to change from one style to another. There have been extremely long-winded debates over such issues (e.g. roman i vs. italic i or := vs. ≡) which always end up going nowhere and draining huge amounts of time. It would be nice to point to this article to end such debates before they get out of hand. -- Fropuff 18:33, 21 December 2006 (UTC)

Fropuff's suggestion seems important to me right now because of a current debate about notation for probabilities and common probability operators. While I have read quite a lot of stuff about probability and statistics, I honestly have never run across some of the notations people are describing in that debate, so it might be good to clarify some of that notation in this manual. I'm not saying we ought to pick one set of symbols and make it the only one, but it would be good to create a reference list of the acceptable notations for quantities like Probability, Expected value of a random variable, Variance, Covariance, etc. DavidCBryant 20:03, 22 February 2007 (UTC)
Well, I suggest using . Var is especially controversial because (as it is rarely used) everyone writes it as he wants, and probably we should leave it to the editor. P and E are sometimes staight sometimes italic (e.g. Probability by Shiryaev vs Brownian Motion by Revus and Yor). I prefer straight because they are operators, I mean in TeX (ideally) they should be written as \E and \P as \sin and \sum. Please, cite some modern books on probability theory to support your opinion. Amir Aliev 21:45, 22 February 2007 (UTC)

I like , coded in TeX as \Pr, because sometimes a capital P is used for a particular probability measure, as when one writes

etc. Michael Hardy 22:07, 24 February 2007 (UTC)

Follow-up guideline

I am working on a follow-up guideline: Wikipedia: Writing about math. It is more focused on the body rather than notation and has differences. If it passes, I would like it meged with this guideline. --Ineffable3000 23:47, 25 December 2006 (UTC)

The additions you propose run counter to the current guidelines, and are ill-advised. I would strongly object to inclusion. --KSmrqT 06:34, 26 December 2006 (UTC)


Is there any consensus how to format categories? Sometime one sees (mathbf) or A, sometimes (mathcal). Jakob.scholbach 22:42, 12 March 2007 (UTC)

You can ask at Wikipedia talk:WikiProject Mathematics. More people watch those pages. Oleg Alexandrov (talk) 08:59, 13 March 2007 (UTC)

ISO 31 style guide

It might be a good idea to reference some of the style guidance given in international standard ISO 31, in particular ISO 31-0 and ISO 31-11. In particular the following come to mind:

  • Typeset variables (including function variables) in italics (e.g., x, y, f), but all constants (e.g., 2×cos x = e2iπx + e−2iπx) and units of measurement (e.g., kg, m) in upright font:
  • Use the multiplication sign × instead of the center dot · whenever it is adjacent to a digit (to avoid confusion with the decimal dot)
  • In order to refer to the numeric value of a quantity in a given unit (e.g., "mass in milligrams"), simply divide the (unit-independent) quantity variable m by the desired unit mg: m/mg (several good examples appear the moment magnitude scale article)

Markus Kuhn 17:44, 5 May 2007 (UTC)

Partial derivatives

I always write

rather than

Should we have a norm prescribing this usage? Michael Hardy 18:45, 23 June 2007 (UTC)

I say yes. The first form is more legible. hajhouse 15:24, 14 November 2007 (UTC)

Font size

Hi, could anyone exlain why these two expressions are so different in size of font? Is there an easy way to make the font size larger in the second expression?

sbandrews (t) 09:08, 26 June 2007 (UTC)

Answering my own question - its because the top one has a superscript and a subscript - so:

works although its obviously the wrong equation,

does the same with an empty subscript bracket - there must be an easier way! sbandrews (t) 14:54, 14 July 2007 (UTC)

There is! use a \ after the math tag :<math>\ R(r) = A r^l e^{-\alpha r}</math> sbandrews (t) 15:02, 14 July 2007 (UTC)

That will put extra white space at the start of the equation. I do this instead by starting the equation with \displaystyle, the standard TeX command for forcing an equation to be set using large symbols etc. \scriptstyle is sometimes also useful to make a too-large equation smaller. —David Eppstein 16:57, 23 October 2007 (UTC)

Divisions involving terms with subscripts

I'm trying to figure out how to make a legible division equation with terms that have subscripts in them (like abeta, etc.) 16:40, 23 October 2007 (UTC)

Is Something Wrong?

In section 5.1 of this article, when the LaTeX formula is shown on its own line, it is not formatted as LaTeX. Can this be explained?

JIMOTHY46ct 00:20, 21 November 2007 (UTC)

Never mind, I figured out the problem and corrected it myself.

JIMOTHY46ct 00:33, 21 November 2007 (UTC)

Add links to aid contributors

It seems useful to have links to how-to-articles on forming equations for articles that otherwise are hard to find. Brews ohare (talk) 19:30, 29 November 2007 (UTC)

See Help:Displaying a formula. The link should be on the main page though, imo.--RDBury (talk) 19:29, 23 March 2008 (UTC)

Proposal to formalise the relationship between MOS and its sub-pages

Dear fellow editors—The idea is to centralise debate and consensus-gathering when there are inconsistencies between the pages.

The most straightforward way is to have MOS-central prevail, and to involve expertise from sub-pages on the talk page there, rather than the fragmentary discourse—more usually the absence of discourse and the continuing inconsistency—that characterises WP's style guideline resources now. If consensus has it that MOS-central should bend to the wording of a sub-page, so be it. But until that occurs in each case that might occasionally arise, there needs to be certainty for WPians, especially in the Featured Article process, where nominators and reviewers are sometimes confused by a left- and right-hand that say different things.

Of course, no one owns MOS-central, and we're all just as important to its running as other editors. I ask for your support and feedback HERE. Tony (talk) 12:20, 5 February 2008 (UTC)

Upper vs. lower case

Is there, and if not should there be, a convention on which types of objects are denoted with upper case letters and which with lower case? My understanding is that the current de facto standard is variables, functions and elements of sets are denoted with lower case, and sets and more complicated objects are denoted with upper case. For example, one might have "Let x be an element of the group G," rather than "Let X be an element of the group g." The standard seems to change over time, e.g. a group theory book from 50 years ago might well use X for an element of a group, so it wouldn't do to carve such a convention in stone. But it would make articles look neater if a standard matching current usage was followed. The reason I'm bringing it up is that the constant of integration in Lists of integrals is denoted C rather than c. I'm more used to seeing c and that's what I used on a different page (before I saw the first article). --RDBury (talk) 19:03, 23 March 2008 (UTC)

Any such convention would have to be specific to the subject area within mathematics. For instance, in triangle geometry (e.g. see Heron's formula) the standard convention is that vertices or other points associated with a triangle are given capital letters; edges or other lengths associated with a triangle are given lower case letters. —David Eppstein (talk) 19:25, 23 March 2008 (UTC)

Introducing notation

The Article body section has the following sentence, 'If you need to use non-standard notations, or if you introduce new notations, define them in your article.' It seems to me that, given OR guidelines, non-standard notation should rarely be used and new notations should hardly ever be used. Non-standard might be used if there doesn't seem to be any standard notation or if the the existing standard is so unwieldy that it can't be used in the article while preserving clarity. In that case the notation itself should have reference, such as 'Using the notation appearing in ...' or 'As defined in ...' If there are competing standards then the article should mention all of them and discuss the differences. A new notation might conceivably be used if there are very few sources for the topic and none of them has notation that is suitable for an article. In this case, perhaps an explanation of the situation on the talk page of the article would be appropriate. Standard notation as well should be either defined or have link to a page defining it, if it might not be familiar to someone at the level that the article is targeting.--RDBury (talk) 17:17, 27 April 2008 (UTC)

Notation can mean something as simple as a variable name. It would be pointless to go through the literature and say that this article uses x, y, and z, this other uses α, β, and γ, while a third uses P, Q, and R. Nevertheless we need to choose a variable name convention within each article and we need to say what each variable means. It would hardly count as original research, in this context, to use a different set of variable names (say i, j, and k) than any of your sources. So your comment doesn't really address this aspect of notation and of introducing new notations. —David Eppstein (talk) 18:04, 27 April 2008 (UTC)
I didn't think variable names came under the heading of notation since nobody would expect the same variables to be used outside the paragraph or section of text where they are introduced. I admit this could be a fuzzy distinction though. For example, if you wrote 'Let O be the center of circle C,' nobody would expect O to always be the center of a circle. But if you wrote 'Let O[C] mean the center of a circle C,' it would be natural to assume that this defines the expression O[X] in any context where X is a circle. My comment was intended to address only the second situation. However, variable names usually do have a standard case, typeface etc., see the previous thread. --RDBury (talk) 19:59, 27 April 2008 (UTC)

Examples revisited

It would be nice if the MOSMATH could address the issue of what sort of examples might be appropriate in a mathematical article. At present, the is the Wikipedia policy WP:NOT#TEXTBOOK seems rather firm about the inappropriateness of certain types of examples:

It is not appropriate to create or edit articles which read as textbooks, with leading questions and step-by-step problem solutions as examples.

To my mind, this clearly does not exclude the "good" examples from mathematics articles. However, I think some further stylistic advice on what kinds of examples are "good" might be helpful. I know for a fact that there have been lengthy discussions about this in the past, but now the MOS does not give much guidance on which examples are desirable, and which are undesirable.

To that end, I suggest explicitly mentioning that the purpose of an encyclopedia is to inform rather than instruct. (See this edit.) It may or may not be appropriate to do this in a separate section of the MOS so that it can receive a more comprehensive discussion. silly rabbit (talk) 12:38, 9 May 2008 (UTC)

Yes, I think many of our best math editors agree with this. We are somewhere between a CRC manual and a textbook in the amount of detail and the amount of pedagogy in our articles, and we don't want to err too far to either side. — Carl (CBM · talk) 15:27, 9 May 2008 (UTC)


I have recently discovered the command \scriptstyle, which causes inline PNG formulas to be smaller, often aligning better with the surrounding text. For example, consider

...where and


...where and

This trick doesn't seem to be discussed here or at the meta:Help:Formula page (although I may have missed something). silly rabbit (talk) 13:36, 19 May 2008 (UTC)

Both align pretty well in my browser. The purpose of \scriptstyle is to reduce the font size for use in superscript and subscript, as well as tighter spacing. How well it aligns in text will depend on the browser font settings. What you are looking for may be \textstyle, which intends to reduce the vertical space for in-text use:
  • Textstyle: blah blah blah blah blah blah
  • Displaystyle: blah blah blah blah blah blah (this is for use in stand-alone equations)
(Hmm, I see now that my Wikipedia settings your first example is converted to HTML, whereas the second and my ones are not due to the presence of the \ commands) Han-Kwang (t) 09:39, 4 August 2008 (UTC)

Punctuation of block-displayed formulae

Lambiam and I have a disagreement on interpretation of the MoS when it comes to punctuation of block-displayed formulae which are parts of sentences. I say that

Jones suggested that the correct formula were

is acceptable as a sentence that comes to an end, whereas Lambiam asserts that the MoS requires that this be punctuated with a period

Jones suggested that the correct formula were

In support of his interpretation, Lambiam notes subsection 5.3 (“Punctuation”) which states “Just as in mathematics publications, a sentence which ends with a formula must have a period at the end of the formula.” I interpret this as in reference to in-line formula elements, and support my interpretation by reference to the MoS itself, which in prior sections has multiple block-displayed formula elements that end sentences but are not followed by periods. (Lambiam notes that the MoS is not itself an article in mainspace, and in any event could simply fail to conform to its intended prescriptions while maintaining the intentions.)

We have agreed to move our disagreement here, in the hope that a consensus will support some clarification. —SlamDiego←T 09:06, 13 June 2008 (UTC)

I believe Lambiam is correct, the formula needs a period even if it is on its own line. This is accepted mathematical practice, and is present in all mathematical books I have ever seen. Enigneering books do skip the period though. Oleg Alexandrov (talk) 14:25, 13 June 2008 (UTC)
I'm willing to accept a uniform style for mathematical expressions across disciplines, if the MoS calls for such. But I would note that, in this case, the article whose editing prompted the question is, properly, one of economic theory. If the MoS adopted a distinct prescription for engineering articles based on what prevailed in engineering articles, then a survey should properly be made of economic articles to determine a style for these. —SlamDiego←T 19:00, 13 June 2008 (UTC)
I concur with Oleg Alexandrov. Omitting the punctuation in a displayed formula is an error, however minor, and is not done in properly typeset mathematical work. Ozob (talk) 18:16, 14 June 2008 (UTC)

Textstyle vs scriptstyle

Ozob just took out the recommendation to use scriptstyle, and replaced it with in the following:

If an in-line formula needs to be typeset in LaTeX, often better formatting can be achieved with the \textstyle{} LaTeX command. Compare the formulas <math>\sum_{n=0}^\infty 1/n^2 = \pi^2/6</math>, which produces the too tall , with <math>\textstyle\sum_{n=0}^\infty 1/n^2 = \pi^2/6</math>, which produces the more compact .

My experience is that scriptstyle, while semantically wrong, works a lot better for matching typical browser text size. For this example it would be . In my browser, the scriptstyle version is a little smaller than the browser text, but close enough to flow with it, while the textstyle version is so huge that it might as well be a separate displayed equation. Shouldn't we be recommending scriptstyle rather than textstyle? —David Eppstein (talk) 15:57, 9 August 2008 (UTC)

Actually, I just added the scriptstyle recommendation, and Ozob corrected it to textstyle, which seemed reasonable to me. I think sometimes scriptstyle does look better for typical browser settings, but perhaps the manual should be expanded to include some discussion of both possible settings. Personally, I think the style manual should recommend textstyle for formulas displayed inline as part of the guideline, and allow for the possibility of scriptstyle for particularly troublesome cases. siℓℓy rabbit (talk) 16:14, 9 August 2008 (UTC)
I'd rather have textstyle for a few reasons:
  • We can't control browser settings. If the default WP font size makes TeX markup look bad, then we should lobby for a change in TeX output.
  • There are a few times when you need scriptscriptstyle, and if you start at scriptstyle the result looks bad. For instance, compare , which is textstyled, with the scriptstyled . In the former, the 2 is in scriptstyle and the N is in scriptscriptstyle. In the latter, both are in scriptscriptstyle and consequently the N is too big.
I agree that, given the current output of texvc, there are cases when scriptstyle is appropriate for inline equations. But the right thing to do would be to improve texvc, not use scriptstyle everywhere. Ozob (talk) 21:03, 9 August 2008 (UTC)
Agreed. How about a change that supports either textstyle (which should certainly be favored over displaystyle for inline formulas) or scriptstyle (which is good on a few rare occasions)? siℓℓy rabbit (talk) 00:07, 10 August 2008 (UTC)
I agree with Ozob. \textstyle is semantically correct and it should be a fairly trivial change to the TeX rendering engine to change the font size when an equation starts with \textstyle. It would be even better if the rendering engine could recognize automatically whether <math> tags are inlined or displayed, because the problem with both \textstyle and \displaystyle is that it overrides formatting as HTML. Han-Kwang (t) 08:18, 10 August 2008 (UTC)
It's all very well to say it's semantically correct and that it would be a trivial change to fix the rendering. It's a very different thing to actually, you know, change the rendering. If you're going to request people to use textstyle, are you also going to do anything to make their textstyle formulae less ugly? —David Eppstein (talk) 15:25, 10 August 2008 (UTC)
We could file a feature request, but it's more likely that the request wil be honored if there is a clear consensus from us about what needs to be done. The math rendering engine in Wikipedia has improved a lot over the years. It used to typeset html formulas in the default sans serif font (1, /, I, l all looked the same) and it would not recognize quite a few LaTeX commands. I think I filed bug reports for those issues somewhere in 2004 and they have been resolved. So can we build a consensus? So far rabbit, ozob, and I seem to like the idea of getting texvc changed. You? Han-Kwang (t) 16:16, 10 August 2008 (UTC)
I'm certainly in strong support of getting texvc changed in a way that would make textstyle more useful and usable. I don't have much idea how to go about getting it done. —David Eppstein (talk) 17:01, 10 August 2008 (UTC)
So, it seems that we have a problem. Browsing through old MediaWiki TeX feature requests I found [1], where one person makes the very good point that small fonts are illegible for some users. (I should have thought of this myself, as I know someone whose vision is so poor that she can hardly read.) The present situation isn't ideal for these users, but it's better than it would be with a smaller font size.
The right solution, then, would be to modify MediaWiki and texvc so that it allowed users to configure the font size used for TeX output. Then we could choose a good default and let people adjust it as needed. I'm not familiar with the internals of MediaWiki, but I would guess that it would be at least several days of work. We can still try making a request to the developers, but it would be best if we reached some sort of consensus here as to precisely what was wanted.
The first problem that occurs to me is: What exactly do we mean by "choosing a font size"? The font sizes for \textstyle, \scriptstyle, and \scriptscriptstyle are all different, so it's not a matter of choosing a single point size. It seems that we could reasonably allow a user to choose a \magstep or a single factor to multiply all the font sizes by. The available choices should be wide but not unrestricted, or else it may become possible to perform a denial of service attack by asking WP to render so many different equations in so many different sizes at once that it runs out of resources. Also, if font sizes are scaled, the TeX engine would need font metrics for each size; this is another advantage to allowing only a fixed number of choices, because then the metrics would only need to be generated once.
I'm not really an expert on TeX fonts, so I don't know what would be the best choice or even if I've exhausted the possibilities. Does anyone else have any insight? Ozob (talk) 22:16, 10 August 2008 (UTC)
Personally, I think it would be nice if the TeX renderer would make an effort to match the font and size of the existing text. Right now I'm working on some text which says something like "Corresponding to the cardinals 0, 1, 2, 3 … are the ordinals …" On my browser at least, the dotted numerals are 50% larger than the other ones and in a completely different style. Also, is /scriptstyle documented anywhere? I couldn't find it in the formula help page. --RDBury (talk) 02:14, 11 August 2008 (UTC)

(Unindent) Wikipedia has, because of browser differences, a complex way of specifying the HTML font size in monobook/main.css, which boils down to 14 pixels for the main text with default 16px browser font settings. What I mean by choosing a font size is to match inline math (in \textstyle) to the default font size, even though I have my browser setup for sligthly smaller fonts. I am pretty sure that the vast majority of users stick with the default font size since it's typically located under "Advanced settings" in the browser.

The problem of small font sizes is of course that, starting from 14-pixel math fonts, subsubscripts and supersuperscripts tend to become too small. This could be dealt with by recommending in the MoS/Math that \textstyle is only used for very simple equations without fractions and nested subscripts. Displayed equations could still be shown in the current, large font sizes. That way, the smallest font that would be displayed in an equation under normal circumstances would be the same in displayed equations and textstyle equations.

Re what \scriptstyle etc. mean: they are documented in the TeXbook by Donald Knuth. \displaystyle is the default for displayed equations; \textstyle for equations in-text. Although the base font size (i.e., used for ordinary letters) is the same, large constructs such as \sum, \int, \frac are typeset differently. Inside a displayed equation, some parts are automatically formatted as \textstyle, for example when they are inside an \array or \frac. Then, \scriptstyle is for subscripts and superscripts, and \scriptscriptstyle for second-order sub- and superscripts, so they are supposed to have different sizes from \textstyle.

Re matching browser fonts: it is very hard to do this automatically. The Wikipedia CSS files only specify that the font is sans serif, which can mean different things on different computers. Math equations should not be typeset in sans serif, or you get problems reading I=l/2 (uppercase i is ell divided by 2).

Han-Kwang (t) 08:42, 11 August 2008 (UTC)

If I understand what you're proposing, you'd like to replace the default textstyle font (which is probably cmr10) with something smaller (say cmr8) and to choose appropriately smaller fonts for scriptstyle and scriptscriptstyle. I would have agreed with you a couple days ago. But since I've realized that it would make the text illegible for some users with poor vision, I have to oppose your proposal (as I understand it). We should not make the default font size any smaller until users have the option of making it larger. In fact, I believe that we should actively avoid using \scriptstyle to make an equation match the surrounding text size, because this will make it more difficult for vision impaired users. Most people with vision impairment only need a little help to be able to read. (For example, my parents are now this way.) The extra size we now have goes a long way towards helping them.
To put it more jokingly: How many mathematicians with glasses do you know? Ozob (talk) 19:25, 11 August 2008 (UTC)

Vertical alignment of formulas

In addition to the above issues with \textstyle, I'd like to propose a lobby for better vertical alignment of in-text formulas. For example the baseline of sticks out below the baseline of the surrounding text. Compare with that is better aligned because there is a j. Currently, in the Wikipedia CSS there is the CSS rule[2]

 img.tex {  vertical-align: middle; }

and the equation is something like <img src="blabla.png" class="tex">. With some effort (requires changes in the database and mediawiki code), it could be replaced by something like <img src="blabla.png" class="tex" style="vertical-align: -5px">, where the database stores the vertical offset (-5px) with every equation, obtained during the TeX rendering process. Han-Kwang (t) 08:42, 11 August 2008 (UTC)

This bug has been open since November 2007: [3]. The correct solution seems to be to remember how many pixels the image has below the baseline and put this into an HTML tag like you propose. You might want to contact User:Random832, who opened the bug originally and who has a page demonstrating what correct output would look like at User:Random832/Math baseline. Ozob (talk) 19:31, 11 August 2008 (UTC)

ONLY since November 2007???? We've been talking about this one since the beginning of 2003. Michael Hardy (talk) 19:31, 23 August 2008 (UTC)

Too much HTML?

It was just recently when there was an argument of TeX vs HTML, where it was reaffirmed that in general PNG images inline are not that preferrable. However, it seems that recent changes to this manual of style push that too far. Now it reads that one should not use LaTeX inline to start with, which I think is a bit too much. Opinons? Oleg Alexandrov 15:35, 9 August 2005 (UTC)

I don't know if you're referring to my edits or what. When I was adding headings and reorganizing, I tried to qualify the statements about PNG images (I made it more clear that they're dependent on user prefs), and in the process, I noticed that there were conflicting guidelines about when it was OK to use LaTeX. The 'Using LaTex markup' section said inline LaTeX was discouraged and gave some reasons why, but then went on to advise people on what to do if they did want to use LaTeX, whereas the 'Very simple formulas' section was very strongly against LaTeX inline. I tried to reconcile the statements but could not really ascertain what was considered ideal, so I changed the latter section to match the less-prescriptive tone of the former. — mjb 15:52, 9 August 2005 (UTC)
I think Oleg referred to your changing "Having formulas as in-line PNG images, as above, is generally discouraged" to "Having LaTeX-based formulas in-line, as above, is generally discouraged". The problem is not with having LaTeX-based formulas using <math> tags, but with formulas which render to PNGs.
I do not like the addition of "Article authors should avoid referring to "we" or addressing the reader directly." as referring to "we" is normal style for mathematical articles and recommended in at least one style book. I'm also rather surprised by the warning to write "<" instead of "<". Does the latter really cause problems in some cases? -- Jitse Niesen (talk) 18:53, 9 August 2005 (UTC)
Yes, this is exactly what I meant. I am happy with Jitse's changes now. Oleg Alexandrov 20:19, 9 August 2005 (UTC)
Yes "we" is normal style for mathematics articles, but I don't think it is necessarily appropriate for an encyclopedia. What style book recommends it? I think that "conversational style" and "addressing the reader directly" are more appropriate for didactic material, but less appropriate for reference works. I especially dislike the "editorial we" (perhaps because it reminds me too much of the royal we ;-) — Paul August 20:41, August 9, 2005 (UTC)
I agree with the above conclusion that there is no method currently that makes everyone happy. I like the idea of improving the automatic TeX to HTML rendering (as the current stuff is horrendous and part of the reason I've been doing HTML inline), but how feasible is it to change the wiki software like this to render HTML that everyone will deem acceptable? I see a lot of "force render"s because the HTML conversion is so awful.
I used to be opposed to HTML rendering until I found better fonts to use on my machine. This may or may not continue to be a problem in MathML, depending on the implementation. We also have to wait until most people have MathML by default in their browsers before we can make a major push to convert to it. There is also the issue that MathML (like most XML) tends to be extremely verbose and may make editing and writing a hassle. Perhaps writing everything in TeX and doing automatic conversion to MathML will be better, so long as the rendering is much better than the TeX to HTML rendering that we have now.
Finally, I would like to use this opportunity to push for some diagramming standard for Wikipedia, as I am a big fan of abstract nonsense and feel somewhat naked without being able to easily include commutative diagrams in my articles. I know that I can create static images, but my real desire is to create diagrams that can easily be edited by other users. Either xypic or some sort of SVG standard would be a godsend. Thanks for listening. - Gauge 03:19, 21 August 2005 (UTC)
  • Is there a list of recommended browser fonts, and how to get them? I'm running Debian, I thought I'd installed every font I could find... but ∈ still doesn't render. Might be a browser issue, not a font issue? linas 18:14, 21 August 2005 (UTC)
Have you tried DejaVu? --Yecril (talk) 15:09, 23 September 2008 (UTC)
  • I believe that the web server and the web browser exchange a list of capabilities. In particular, a web browser can announce that it supports MathML, in which case the server can generate and send MathML. Clearly, this needs to be explored, and enabled, on WP. For markup, TeX would be best, as it can be converted to HTML, png or MathML, and is also easy to edit. linas 18:14, 21 August 2005 (UTC)
TeX is not the best, it is just incomparable to HTML. Wikitext is much stronger than HTML. --Yecril (talk) 15:09, 23 September 2008 (UTC)
  • Do we have a general "which browsers support what from the WP math standpoint, and how do we configure the danged thing?" type page anywhere? We should, shouldn't we? linas 18:14, 21 August 2005 (UTC)
  • In the meanwhile, the most future-compatible thing to do would be to not change markup on existing pages from inline math tags to HTML, as this seems like a step back from the stated direction. linas 18:14, 21 August 2005 (UTC)
I agree with the manual, and even recommend stronger wording, stating that in-line formulas should be entered as HTML if possible. I further would recommend stronger wording stating that even non-in-line simple formulas should be entered as HTML whenever possible. Why should an image (i.e., bloat) be added whenever an efficient ASCII or highly-portable HTML character is acceptable? As stated above, conversion from LaTeX doesn't work correctly; and it might be far in the future before it works well across all browsers and operating systems worldwide.
Aside from this, the bloating of web pages with unnecessary images is a very bad design practice and should be discouraged. Wikipedia web pages already have excruciatingly slow load times for many users. Keep in mind, about 80% of home users worldwide have slow connection speeds. Using unnecessary images for simple formulas bloats pages significantly further, putting an even far greater strain on the servers. Of course use LaTeX when there's a real reason, but for simple formulas, HTML is far better, provided it can be understood and has very good portability across browsers worldwide. --Simian, 2005-09-21, 02:21 Z
Except that html is ugly as sin, making the page hard to read and hard to understand. Math is hard enough already, understanding it shouldn't be hobbled by bad typography. linas 22:15, 21 September 2005 (UTC)
While it is a matter of personal taste, I do not find e0 = 1 ugly. I admit it looks a bit different but it does not impair my ability to understand the exposition as much as the images do. --Yecril (talk) 15:09, 23 September 2008 (UTC)
My above post addresses simple formulas that can be understood as HTML. I tried to reiterate that in the last sentence of my above post. In regard to one of your earlier points, simple formulas look great as HTML (far better than a bloated image for every quantity) if the user sets their browser or Wikipedia preferences to Times New Roman font. If you're using a sans serif font (or the Wikipedia default is a sans serif font), therein lies a mistake and part of the problem.
Wikipedia is rendered in sans-serif and so let it be. The {{math}} template renders formulas in serif as required. --Yecril (talk) 15:12, 23 September 2008 (UTC)
Don't try to outguess the end user and force a style just because someone chose an inferior font. Wikipedia pages should emphasize content, not style, keeping the layout as simple and plain as possible, and therefore portable and configurable by the end user. At least one skin, maybe two, specifies no font or Times New Roman. If you're choosing a wrong, poorly-defined font (i.e., a sans serif font) to try to view math quantities, etc., then we shouldn't blame HTML for a bad design choice and/or a bad skin choice. There's a reason why virtually all newspapers and most text books use Times New Roman -- legibility.  --Simian, 2005-09-25, 14:28 Z
Actually, Cambria is superior to Times. --Yecril (talk) 15:09, 23 September 2008 (UTC)
Ok, help me get this right. Shouldn't the burder of rendering (in an ideal world) be entirely on the server - based on user preferences, the formula at hand and the browser used? And shouldn't the authors be able to write what they mean in one single format (I vote for TeX) and let the server decide what to do in each case? I'm confused... (thanks) PizzaMargherita 21:01, 1 November 2005 (UTC)
Well certainly, albeit I vote for wikitext. --Yecril (talk) 15:09, 23 September 2008 (UTC)

Own toughts

1) I dislike the idea to let MediaWiki decide to render an easy <math></math> Tex command in plain HTML code (called "HTML if very simple or else PNG" in the user's preferences). This sometimes really makes it hard to recognise variables for being the same, for example, the "letter a" looks different in TeX () than the "HTML a", ax. When registering a new user, I must say it would be better to always activate the option Always render PNG by default. Therefore, I generally prefer to always use <math></math> TeX tags in formulas to have a unified look throughout the article.

Actually, wikitext gives you ax with a round a. --Yecril (talk) 15:27, 23 September 2008 (UTC)

2) Right now, many articles in the Wikipedia don't have a unified base for the variables used - one article uses


another article uses

Why is that a problem? Incidentally, both look the same at my place. --Yecril (talk) 15:27, 23 September 2008 (UTC)

Another difference is, for example, and - two ways for writing vectors. An additional example is . It often confuses the reader to have different variables for basically the same thing - more confusingly, sometimes two totally different variables have the same placeholder. I wonder that there doesn't seem to be an ANSI standard / IEC standard or comparable standard that helps to unify placeholders. It'll be great in my eyes if there was an own Manual of Style about that topic.

3) When writing in direct HTML, is it better to use the correct Unicode symbol or the Ampersand+name HTML entity? For example: Unicode α instead of α, λ instead of λ, instead of ? I prefer to use the Unicode encoding, as it is easier to read.

It is much harder to read actual symbols in a monospaced font used for editing. --Yecril (talk) 15:27, 23 September 2008 (UTC)

It'll be great if some of you could comment on my thoughts. Thanks, --Abdull 14:06, 19 August 2005 (UTC)

-- I think that <math>\alpha</math> is preferable to α, even with the math rendering problems, with either preferable to the Unicode. But I've written so many equations in Microsoft Equation Editor/MathType, WordPerfect Equation Editor, TeX ('Tex' is just wrong; 'TeX' is closer, 'TeΧ' is closer yet), and other formats, that I don't have any trouble writing TeX as if it were WYSIWYG, so I may not be the best person to comment -- Arthur Rubin 21:55, 24 September 2005 (UTC)

1) I think the two "a"s are a small price to pay. I quite like the default settings as they are (also see below in the Tex-vs-non-TeX section). I don't understand how using <math></math> would help you in this, as WM would transform in HTML where possible... Mind you I'm quite new to WP so maybe we're not on the same page here.
2.1) phi vs varphi - minor but should be standardised.
2.2) Same for vs . We should have a guideline. Although is semantically superior to (it uses keyword "vec"), it is also more messy-looking IMHO.
3) Again, I agree we should have a guideline. I don't know which is preferable, it depends on browser support I guess. But once again, see below my comment on TeX vs non-TeX. These issues should not waste our time. There should be just one way of writing it (e.g. TeX) and the server should work out what is the correct thing to do in each situation, depending on the formula, user settings and browser used. PizzaMargherita 20:03, 1 November 2005 (UTC)

More WikiTeX macros, please?

Sorry, but I am a bit of a newbie around here. I would like to do something which is easily available in LaTeX, but not easily available in TeX. I need to be able to set characters (or expressions) over other characters (or expressions). For example:

0\rightarrow A\overset{u}{\rightarrow}B\overset{v}{\rightarrow}C\rightarrow 0

(I normally use \mathop, \xrightarrow, or the xypic LaTex package for such things, but these are less intuitive and none of them happen to be supported by TeX.) The only thing I can think of is:

but this clearly looks bad as far as the typesetting goes. Any suggestions or solutions? Silly rabbit 22:57, 18 November 2005 (UTC)

A u B --Yecril (talk) 16:01, 23 September 2008 (UTC)

You could fake it:

but yeah, it would be nice if it was supported natively. — Omegatron 23:54, 18 November 2005 (UTC)

Actually, thanks a lot Omegatron. I was only looking for a bandaid in some particular formulas. My solution involved \vspace and \hspace which aren't TeX builtins either. What you suggest ought to work, though. Thanks. Ok, now here's a commutative diagram that I would like to.... no, just kidding.
On a related note, is there an attempt to LaTeX-ify Wikipedia? There may be possible security issues with running LaTeX on a public server. But I suspect that the WikiMedia software already does the rendering in a locked-down sandbox anyway. Does anyone know if they are working on this?
Thanks, Silly rabbit 00:20, 19 November 2005 (UTC).

Small HTML Rendering

Is there any reason that LaTeX codes that render as HTML are smaller than if they were just written as HTML? For example, for me (using MSIE and with "Recommended for modern browsers" selected at the preferences):

ab + cd = f and (coded ''ab'' + ''cd'' = ''f'' and <math>ab+cd=f</math>, respectively)

both render as HTML but the first one is a larger font thatn the second. Any ideas, or is this just some problem that only I'm having? --mets501 03:52, 12 March 2006 (UTC)

Depends on the browser setting I think. On my current screen LaTeX rendered as html indeed looks a bit smaller than text, but LaTeX rendered as PNG looks much huger. No good answer I guess. Oleg Alexandrov (talk) 04:48, 12 March 2006 (UTC)
Same thing with mine. --mets501 15:10, 12 March 2006 (UTC)
The reason probably is that the default style sheet specifies that mathematics is rendered in a serifed font (see the span.texhtml section), while the normal text is in a sans-serif font. I fixed this by adding
span.texhtml { font-family: sans-serif; }
to User:Jitse Niesen/monobook.css. You might try to do the same. -- Jitse Niesen (talk) 07:49, 13 March 2006 (UTC)
Having a different font height for embedded formulas is actually a good thing because it makes them visually distinct from the enclosing text. --Yecril (talk) 17:12, 23 September 2008 (UTC)
Works for me. Thanks Jitse :-) AdamSmithee 07:55, 13 March 2006 (UTC)
Thanks guys! --mets501 22:26, 13 March 2006 (UTC)

New guideline? Explanation of symbols

Maybe there should be a guideline on how symbols are to be explained.

Example 1: The foocity is given by

where b and a are the barness vector and coefficient and r is the gnat vector.


Example 2:The foocity is given by


  • b is the barness vector,
  • a is the barness coefficient,
  • r is the gnat vector.

Style 2 is used quite often in Wikipedia articles, especially in physics.[4] [5] [6] [7] (links obtained from random clicking in Category:Fundamental physics concepts; apparently style 2 is used in about 20% of the articles) However, in all professionally typeset academic-level physics and mathematics texts that I have seen, style 1 is used. Style 2 is sometimes used in high school and college level textbooks. Han-Kwang (t) 15:55, 16 July 2008 (UTC)

Any objections if I add a section recommending style 1 to the MOS page? Han-Kwang (t) 06:50, 28 July 2008 (UTC)
I object to recommending one style over another. Although I prefer the first style, presumably there are situations in which the second makes for more readable text. For instance, if the variables require more than one sentence to explain them. (See, for instance, some of the physics formulas in heat equation.) I don't feel strongly one way or the other, and I think that common sense and readability should be a good enough guide for editors to decide between which style is better suited to their needs, and that adding this recommendation to the MoS will just be more instruction creep. siℓℓy rabbit (talk) 12:47, 28 July 2008 (UTC)
I also prefer style 1 but oppose instruction creep. CRGreathouse (t | c) 18:31, 8 August 2008 (UTC)
I'm seeing far too many articles using style 2 even when every definition is just one damn single word, and many even omit the commas. So I think in this case instruction creep isn't the worse evil. --A r m y 1 9 8 7 ! ! ! 23:34, 3 September 2008 (UTC)


A couple of items related to WP:JARGON. First, in #Encyclopedic vs conversational tone above, there's a discussion about phrases such as "it should be noted". I think it would be a big help if, when copyeditors remove material, they remove it for the most accurate, least offensive, most persuasive reasons. So: removing something due to core content policy should be at the top of the list, and if that's the reason for the edit, then we shouldn't be sniping about poor word choice. Likewise, I sometimes see "it should be noted" removed with the less-than-helpful edit summary "per WEASEL". I think that's the wrong reason; "it should be noted" is common in academia in general and in math articles in particular, and in many contexts, it's not confusing at all. It means "This is important; now let me list the reasons why I think it's important". That's actually perfectly good expository writing style, in a math article, but IMO it's not appropriate for Wikipedia because it is a kind of WP:JARGON. Your neighbor doesn't say "it should be noted", and you don't read it in the newspaper or hear it on TV (unless you watch Numbers (TV series)!) It's academic-speak. So, would you guys mind if I move it out of WEASEL and WP:WORDS and into WP:JARGON?

Second, WP:JARGON now contains "... as a rule of thumb, if expressing an equation requires LaTeX (as most do), do not assume the reader will understand what it means. It is also considered polite (but not always necessary) to explain how the symbols are read, e.g. "A ⇔ B means A is true if and only if B is true". That seems like too much and not enough at the same time. It's not enough because it really should be on the style page that discusses LaTeX, which is this page. It's too much because something shorter would be less of a turn-off to some people; it would also be useful to promote this (MSM) page by pointing people here instead of trying to cover it there. Any objections to putting something like this at WP:JARGON? "Mathematical symbols can sometimes be jargon, to be avoided, written out in words, or explained and given pronunciation; see [proper section of WP:Manual of Style (mathematics)]." - Dan Dank55 (send/receive) 23:11, 19 September 2008 (UTC)

Use nbsp to keep formulas together?

I've noticed that many inline statements and formulas do not use a non-breaking space or method to keep it from wrapping to the next line. It seems stupid to see "A+" on one line and "B" on another line. There are four possible inline versions that I can imagine:

  1. No spaces: ''f'':''X''→''Y'' gives f:XY
  2. Spaces: ''f'' : ''X'' → ''Y'' gives f : XY
  3. Non-breaking spaces: ''f'' : ''X'' → ''Y'' gives f : X → Y
  4. Use a style: <span style="white-space: nowrap;">''f'' : ''X'' → ''Y''</span> gives the same as #3

In my browser, #1 looks terrible. #2 looks good, except when it breaks the line, but #3 is an ugly HTML mess if you have to edit it. #4 is nice, but a bit lengthy, especially for a series of statements. I think it would be useful to start using some method to control wrapping, and I would like to hear others' opinions. - grubber 00:26, 18 September 2006 (UTC)

Good idea. You can fix everything by adding this your monobook.css, then SHIFT+Refesh in your browser:
span.texhtml {
        white-space: nowrap;
        font-family: serif;
+mwtoews 21:32, 8 February 2007 (UTC)
Actually, this begs me to question: why doesn't the default monobook.css have this? Currently, it only specifies the font-family, and that's it. Would it be too much trouble to add it to the default? It doesn't make sense to break up equations using the current markup. Anyone? +mwtoews 21:39, 8 February 2007 (UTC)
I have this thing too. It should be raised at MediaWiki talk:Monobook.css, or rather at BugZilla:10438 since it now belongs to shared.css. --Yecril (talk) 17:20, 23 September 2008 (UTC)

Boxed (display) equations

Action (physics) uses a boxed equation using some ad-hoc markup. For consistency, I think it's better to use a template for this. Is there already such a template? If not, I suggest {{box eq}} as a template name. I also think the big black box is a bit harsh - we could use something more playful like toc colours. Shinobu 04:27, 4 October 2006 (UTC)

I think this is irrelevant here.

The editor may want to put any information in a box.

except that it does not look like encyclopaedia any more. --Yecril (talk) 17:52, 23 September 2008 (UTC)

Derivatives italicised?

We seem to be using a mixture of typographic styles for derivatives in Wikipedia: using either an italic or roman 'd'.


Both styles are used in the literature. The same issue applies to integrals and other uses of differentials. — ras52 (talk) 18:12, 5 December 2007 (UTC)

I looked through some the textbooks I have on my bookshelf; of the four (3 math, 1 physics) all used an italic d. It's a small sample but it convinces me to vote for italic as the standard. Besides Help:Displaying a formula already favors italic.--RDBury (talk) 19:22, 23 March 2008 (UTC)
The differential operator d is not a variable, therefore it should rather remain in roman face. --Yecril (talk) 19:05, 23 September 2008 (UTC)
It seems to me that the prevailing convention in most mathematical publications is that d should be italicized. I suppose I have seen other typesetting conventions used, but they are by far the exception rather than the rule. None of the books currently literally within arm's reach of my present position use a Roman face d. One of these books happens to be the (quite authoritative) G.H. Hardy A course in pure mathematics. Another is Hilbert and Courant's Mathematical methods in physics, Volume 2. Still another is Gaspard Monge's Application de l'analyse à la Géométrie. A number of lesser books in my immediate vicinity confirm that the past and present typographical convention is to use an italic d. siℓℓy rabbit (talk) 19:20, 23 September 2008 (UTC)
International standards for the use of math in physical science (eg. ISO 80000, previously ISO 31, also the AIP, and IUPAC style guides) specify an upright d.
Most of the best academic publishers also either expect/recommend it in their style guides (e.g. Cambridge Pniversity Press, Springer, Princeton University Press). The fact that (lazy/sloppy) authors don't adhere to this (or care much about it) and many publishers don't bother to properly edit the manuscripts they receive is no excuse for not doing the right thing in Wikipedia. Just because a maths book is authoraitative it doesn't follow that it's typsetting is also authoritative. The use of the upright d to for the differential (and upright font for descriptive subscripts/superscripts etc. is standard in well edited science texts and conveys useful information about the quantities in an equation (whether they are variables, constants, operators etc.). All scientific articles in Wikipedia should follow this convention. —Preceding unsigned comment added by (talkcontribs) 23:14, 1 October 2008 (UTC)
Yes, upright d is what I usually use, except that in articles which already consistently use italic d I continue using it for consistency. I think the current guideline ("Both forms are correct; what is most important is to consistency within an article, with deference to previous editors.") is entirely reasonable. -- Army1987!!! 12:59, 2 October 2008 (UTC)
I think the reason for this abomination is aesthetic, not semantic. We can still have dx to preserve semantics if you insist. --Yecril (talk) 19:31, 23 September 2008 (UTC)
I have no idea what you mean. siℓℓy rabbit (talk) 21:51, 23 September 2008 (UTC)
In other words, the majority of your books write dx not because d is a symbol of the same kind as x but because dx looks unpretty. Unlike the typesetters of printed books, we can leverage the richness of HTML markup to properly differentiate between d and x without loosing the semantic difference between the two and without making the formula unpretty. Does that make sense? --Yecril (talk) 15:48, 29 September 2008 (UTC)
In the end, if the d is italiized, then I don't think there's much practical benefit to more complex wiki markup than ''dx''. We're still using PNG images for displayed formulas, after all. If we wanted properly semantic math markup we would have to switch to MathML. There's a benefit to keeping it easy for editors to edit mathematical formulas; I don't see much advantage to switching to code like {{math|<I>d</I><VAR>x</VAR>}}. — Carl (CBM · talk) 16:07, 29 September 2008 (UTC)
Yes, if it were up to me, I'd always use semantic tags wherever possible, but apostrophe-apostrophe is far more common on Wikipedia for a reason, and I'd rather be consistent with that. (The reason is that it is easier for editors not fluent in HTML. This was pointed out in the MoS somewhere, but I can't find it right now.) -- Army1987!!! 12:27, 30 September 2008 (UTC)
There was a furious discussion about this at Wikipedia talk:Manual of Style (text formatting) after an editor changed the MoS to mandate <var> for all variables; that was later reverted. The proper solution to marking semantics is content markup in MathML, but unfortunately it's quite verbose and very hard for humans to write. Ozob (talk) 15:30, 30 September 2008 (UTC)
Correct me if I am wrong. I think '' is common on Wikipedia because it resembles a quote and works like one and it is great for marking external text embedded in the current paragraph; ''' is an extension of that concept. There are other uses of italic variant that should not be quoted in this way, e.g. EM for emphasis. Bold text, where it is required for definition, can be served as a hyperlink to itself; I do not know what other uses of bold are legitimate in running text. All this has nothing to do with entering formulas that are technical by their nature and obviously require more sophisticated mechanisms (preferably templates).
Of course, expert editors that do not want to learn semantic markup should not be forced to do this; otherwise they would have no time for sharing their expert knowledge. However, they should not be encouraged to ditch the post-processing work done by markup editors.
--Yecril (talk) 15:46, 30 September 2008 (UTC)
No, '' is used because it is common typographical practice to put variables in italics. Also, you might want to look at [8] to see just how awkward it is to enter MathML content markup; but as far as I know there's no better solution. Ozob (talk) 23:13, 30 September 2008 (UTC)
There are several ways to put variables in italics, of which '' is the worst and it is not for variables exclusively, not even mainly. Per Wikipedia, Wikitext is a better solution than MathML because it does not require any client-side support.
--Yecril (talk) 09:14, 1 October 2008 (UTC)

Bad style examples

Examples of bad style should be explicitly marked as such, otherwise the readers tend to memorize them along with, or instead of, the examples of good style, especially if they come first. It should be explicit even if the example is taken out of context. I am going to add DEL+red markup to bad examples and INS markup to good examples as in my recent edit. --Yecril (talk) 16:13, 30 September 2008 (UTC)

I'm afraid I find the markup more confusing than helpful, especially the symbol. If you do want to mark examples of bad style (and that's not a bad idea), I would suggest putting something like "(BAD)" in front of them.
More importantly, I disagree with the rule "Terms in running text should be preceded by a short English word that briefly describes what they mean" that you added. This may be good advice in some circumstances, but not all. -- Jitse Niesen (talk) 17:25, 30 September 2008 (UTC)

This is meant to be a guideline. A guideline by definition is a good advice in some circumstances but not all. In particular, it is much more natural and appropriate to use the English word describing the symbol in order to avoid starting a sentence with a symbol than to invent conjunctions for the purpose as the current text does. How do you recommend differentiating between BAD because missing and BAD because present?

I would appreciate an example where obeying this guideline would be detrimental to the content. --Yecril (talk) 18:07, 30 September 2008 (UTC)

Is this discussion about this text [9]?

  • Terms in running text should be preceded by a short English word that briefly describes what they mean:
  • Any group G that fulfills the conditions above may be decomposed into cosets as follows.
  • Let H be the corresponding subgroup of the group G. Then the group H must be finite.

Doing so will make the text easier to understand when it is being listened to. This recommendation does not apply to embedded statements like x = 0.

That style differs from all published mathematics I am used to, and all mathematical writing style guides I have seen. Of course the first use of a variable has to explain what the variable represents; but uses after that don't need to repeat that. This is the purpose of variables, after all.

More fundamentally, the variables in the terms above aren't needed at all and should be omitted:

  • Any group that fulfills the conditions above may be decomposed into cosets as follows.
  • Any such subgroup of the original group must be finite.

— Carl (CBM · talk) 02:02, 1 October 2008 (UTC)

Of course, the example was trivial so that it can be short, and no wonder it can be simplified further. I agree it is best to write without any symbols at all; it was meant to demonstrate the recommended style when symbols are necessary.
The purpose of variables is to name objects; the purpose of the introductory word is to explain that the following letter is a name for an object. I agree it is not necessary for names as Peter; however, it is common to write e.g.  the village Tucaneoa. The problem is even more acute with mathematics than with geography because mathematical formulae are generally harder to pronounce.
I am afraid most mathematical books out there are not meant to be read aloud.
--Yecril (talk) 09:25, 1 October 2008 (UTC)
Also when speaking, I think these words are often not necessary (and in fact harmful). For instance, in the example
"Let H be the corresponding subgroup of the group G. Then the group H must be finite."
I think the second "the group" should not be there, regardless of whether the text is written down or spoken. It's an ugly repetition and unnecessary. The first "the group" may be useful to remind the reader what G is, depending on the context. This is assuming that the variables do need to be introduced. And of course, most people read Wikipedia from the screen, so that should guide our writing.
In answer to your earlier comments, a sentence with should in the Wikipedia Manual of Style is supposed to be valid in almost all situations and entertain only the occasional exception.
In reply to "How do you recommend differentiating between BAD because missing and BAD because present?": By putting bad and corrected examples next to each other, it's clear what is bad about the bad example. So, I would write the current examples as something like
(BAD) Suppose that G is a group. G can be decomposed into cosets, as follows.
(GOOD) If G is a group, then G may be decomposed into cosets as follows.
and I would probably add some formatting so that the examples line up and there is some spacing between the tags (BAD) and (GOOD) and the actual text. -- Jitse Niesen (talk) 11:01, 1 October 2008 (UTC)
Is it possible to write down a recommendation that is advisory and not obligatory? Because I still think this style would make things easier for people who cannot read.
Besides, as User:CBM correctly noticed, the example marked as GOOD is still BAD, although in a different way. --Yecril (talk) 21:34, 5 October 2008 (UTC)

templates for established symbols

I am considering the possibility of making a template for π and π to discern the two in formulae. Another option would be π and π. The advantage to the reader would be that she can hover over the symbol do discover its meaning. I am not sure how these templates should be named; perhaps {{math/perim}} and {{math/pcf}}? --Yecril (talk) 21:47, 5 October 2008 (UTC)

It seems to me that consistent use of the latter two templates would lead to overlinking. It's fine the first time, but what about the twentieth? As for the first two, I don't see what benefit they provide, since the s that you insert don't get styled. (And how would you style them, since they're both just a pi?) Ozob (talk) 01:28, 6 October 2008 (UTC)

Hover over the symbol to see the benefit. This agrees with what you do when you see something you do not know: you focus on it, you examine it, and, quite probably, you move the mouse pointer over it. I need your opinion about which way of doing this is fine: a wikilink, which also provides a title but happens to change the colour as well, or a plain title. I am concerned with overlinking as well so it seems having just the title is a bit safer. --Yecril (talk) 13:00, 6 October 2008 (UTC)

Myself, I don't think these are needed, for the general reason that we should used text to explain things. If it isn't clear that π is meant to be the prime counting function, then the article should come out and say it, not hope the reader will hover over the symbol. This improves the prose, is still usable when the article is printed or viewed without a mouse, and is generally better expository style.

In any case, don't start any massive changeover to the new style without getting some agreement first about it. This is true of any massive style change; these are not well received in general. — Carl (CBM · talk) 14:08, 6 October 2008 (UTC)

For example, this is a textbook example of where these templates are not needed. The very same sentence already explains clearly what the symbols represent. — Carl (CBM · talk) 14:40, 6 October 2008 (UTC)

I never opposed using plain text to introduce things, or suggested that special templates could be used instead; I only think it can be a convenient reminder to the reader when it is likely that a formula would make him scratch his head. And you cannot explain things in the middle of the formula so the user has to scroll somewhere else, losing context. In a printed work, you have to look it up in an index of symbols, where you can find the right meaning if you are lucky. An interactive medium such as HTML can do better than that.

I included the templates in new sections in case only one section is selected to be viewed. --Yecril (talk) 14:50, 6 October 2008 (UTC)

A reader in the middle of the article on Skewes' number is unlikely to forget that the π, which just a moment ago represented the prime counting function, still represents it. If they did for get that, readers would just scan around for the definition. The benefit to the templates seems to be mainly hypothetical. — Carl (CBM · talk) 15:56, 6 October 2008 (UTC)
Having links within formulas is seldom a good thing to do. Not only do they look extra-ugly to people who have set "Underline links: Always" in their preference (though I believe that they deserve that! :-) ), but also see the last-but-one point in Wikipedia:Access#Text. I once viewed a Wikipedia article on a cellphone, and I wasn't able to see where links pointed by "hovering" on them. It is much better to explain what symbols means, when it's not obvious from context. (BTW, I think you meant to link pi, not Perimeter.) -- Army1987 (t — c) 15:16, 7 October 2008 (UTC)

Using HTML attributes

So apparently we can treat the math tags like any HTML tag, add style to them, change the border, and even add an alternate description. So my question is how to best give an alternate description to the equation above.

The limit as h approaches zero of the difference between f of (x + h) and f of x over h

Is it understandable? Too wordy? — Dispenser 03:09, 20 October 2008 (UTC)

The alternate text defaults to the contents of the math tags (in this case: \lim_{h \to 0}{f(x+h) - f(x)\over{h}}.) People familiar with LaTeX will find that very clear because that is what they are used to. On the other hand, it will mystify people that do not know LaTeX. The problem with your text is that it is ambiguous; apart from the formula to the right, it can also refer to or . -- Jitse Niesen (talk) 12:22, 20 October 2008 (UTC)
The LaTex does not fit well with the "Imagine you're writing for an audio cassette" suggestion for alt text. — Dispenser 13:33, 20 October 2008 (UTC)
At present I don't think <math> allows us to specify alt text; the only choice is raw LaTeX. Ozob (talk) 17:50, 20 October 2008 (UTC)
If you do a view source of this section you see that the alt text of the equation is the text above rather than the latex. My fealing at the moment is that loss of information is marginally worse than not knowing latex. The effort of adding specific alt text probably does not justify the advantage. --Salix (talk): 18:47, 20 October 2008 (UTC)
Too wordy, but "The limit as h → 0 of the ratio between f(x + h) − f(x) and h" would be better (but I understand that was meant to be an example). Army1987 (t — c) 12:13, 21 October 2008 (UTC)

Latex should be preferred over HTML

I would like to raise concerns about the guidelines for the use of HTML-based 'sub' and 'sup' tags for creating simple mathematical formula in Wikipedia. I think that these HTML tags do a rather bad job of separating content from style: I think that all mathematical entities should be surrounded by <math></math> tags,nd we shouldn't have multiple ways of writing such things. Down the track, Mediawiki will surely become better software, and the minor issues of line-alignment, font sizing, etc will be overcome, and with <math></math> tags we will have a much clearer markup that reflects the true meaning of what is being written, eg an italicised 'c' is not a mathematical thing, but clearly is. User preferences could then be harnessed to highlight mathematical objects in a different color, etc, etc, but this is only possible if users are discouraged from 'hacking' math using HTML. Furthermore it saves people from having to learn two entirely different markup systems (eg HTML entities for the infinity character, versus latex markup for the infinity character).

I think that use of <math></math> tags is the future-proof semantic markup that we should be using, and it really does do the job of separating style from content in a way that HTML does not. Jdpipe (talk) 11:21, 23 October 2008 (UTC)

These "minor" issues of line-alignment, font sizing, etc. have been pointed out a gazillion times for ages, and they were never overcome, so why are you so optimistic for the future? (Not to mention the fact that too many PNG images make pages take longer to load.) -- Army1987 (t — c) 12:54, 23 October 2008 (UTC)
Maybe it is time for a FAQ about why certain controversial guidelines are the way the are. Han-Kwang (t) 14:16, 23 October 2008 (UTC)

Use of unicode characters for exponents in units of measurement

When typing values for measurements that include units of measurement, it is vastly more readable when editing a page if the writer has used unicode characters as in N/m², compared to N/m<sup>2</math> or even worse N&cdot;m<sup>-2</sup>. It's not hard to learn how to type these special characters, and they do make editing a much more pleasurable process. Furthermore, these unicode characters render correctly in text-only browsers such as Elinks and Lynx, but superscript characters do not (contrary to what is stated in this Manual of Style page). The argument is made that using these <sup> tags somehow aids separation of style and contents. This is a dud argument, because the superscript location of the '2' in W/m² is part of its meaning -- this is not a '2' in the sense of 'multiplied by', so without its correct position, it means something else.

The argument about using <sup> for mathematical formulae is what I argued against earlier. For units of measurement the case is different however, because exponents greater than 3 in units of measurement are extremely rare. I can only think of the stefan-boltzmann constant as a case where higher exponents are used in units of measurement. Given that digits up to 3 are available in standard fonts in unicode, I think it is best to use them for units, so that values can be easily read by as many users as possible, and without clogging up pages with excessive markup. For particularly complex units of measurement, I think that using HTML markup is appropriate, but this happens only quite rarely.

Units of measurement within mathematical formulae are another case; obviously then latex markup (nonitalics) must be used.

Jdpipe (talk) 11:21, 23 October 2008 (UTC)

As for "separation of style and contents", we use <sup>, not , so what do you mean exactly? -- Army1987 (t — c) 12:57, 23 October 2008 (UTC)
The separation I'm talking about is ² which means 'squared' (note: means) and <sup>2</sup>, which conveys that a '2' is to be placed in a high place -- this is a typographic style thing, and meaning is not conveyed in the same clean and succinct way (and furthermore is unrenderable in text-only browsers, FWIW). Jdpipe (talk) 12:50, 24 November 2008 (UTC)
No, the unicode character does not mean "squared". It means "high 2". I'm not saying it should or should not be used on units, just that the argument is faulty. — Arthur Rubin (talk) 21:44, 24 November 2008 (UTC)

Long numbers

Consider the value of π in Pi:

We currently have: 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 582

Greg L would have us use: 3.14159265358979323846264338327950288419716939937510582

I think this is both ugly to edit and difficult to read, in spite of the international standards for 3-digit spacing. — Arthur Rubin (talk) 22:28, 7 October 2008 (UTC)

How ugly it is to edit can be seen that the last "span style" got mangled when I attempted to copy it from his draft of Pi, causing the last margin to be negative. — Arthur Rubin (talk) 22:37, 7 October 2008 (UTC)
My proposal is that mathematical constants should have 5-digit spacing after the decimal point, especially if there are more than 12 digits after the decimal point. — Arthur Rubin (talk) 22:39, 7 October 2008 (UTC)
  • This is absurd. Delimiting every three digits it is done on Wikipedia in accordance to
  1. BIMP: 5.3.4 Formatting numbers, and the decimal marker, and per
  2. NIST More on Printing and Using Symbols and Numbers in Scientific and Technical Documents: 10.5.3, Grouping digits, and
  3. ISO (which follows what the BIPM says)
Greg L (talk) 23:15, 7 October 2008 (UTC)
We don't follow the "international standards" on KiB / MiB, because no one in the real world does. This case isn't as bad, but it would be interesting to compare representations of numbers of more than 20 digits, rather than just normal 7-digit physical quantities. This case isn't as extreme, but the de facto standard in mathematics articles, for numbers of over 12–15 decimal places, is undoubtably 5-digit grouping. To do otherwise requires a consensus for change. — Arthur Rubin (talk) 23:26, 7 October 2008 (UTC)
  • Is that the best argument you can make? There was no “international standard” with regard to the IEC’s proposal on the binary prefixes (KiB, etc.). Why? Because it was just that: a “proposal.” And if flew like a wet noodle. After ten years, no computer manufacturer still adopted the proposal when communicating to their end users. Wikipedia wisely decided to follow the way the real world works and use the conventional binary prefixes (megabyte, etc.), notwithstanding their shortcomings.

    Now stop trying to divert us away from the real issue here and get busy and provide some evidence for us to back up your allegation that the mathematics world decided to flout the rule of the SI (and the NIST and the ISO) and standardize on delimiting numbers every five digits to the right of the decimal marker. I think you are wrong about your facts. Greg L (talk) 23:56, 7 October 2008 (UTC)

Dicklyon gives some examples of real-world examples of the five-digit grouping at Talk:Pi#delimiting values every five digits. Apparently a majority of books (based on a Google books search) prefer to split Pi into five digit groups. However, I have no strong opinion either way on the matter. siℓℓy rabbit (talk) 00:17, 8 October 2008 (UTC)
  • I think Pi is a special exception to the general rule and will back off on demanding that it conform to the rule of the SI. People are fascinated with counting all those digits, and groups of five helps. Still…

    I think we need to resolve whether there is any truth to the suggestion that mathematics departs from what is clearly spelled out by the BIPM for compliance with the SI (and which is further supported by the NIST and the ISO) with regard to delimiting every three digits on the fractional side of significands.

    If a Ph.D. mathematician who has had a couple of papers published can weigh in here and resolve this issue, that would be much appreciated. If it can be shown that mathematics flouts the rule of the SI and there is a well-established style in the mathematics world, then, please advise. Short of any proof that mathematics marches to the tune of a different drummer, it is too unwieldily to discuss this in two forums. May I suggest we keep this all here on WT:MOSNUM? Greg L (talk) 04:21, 8 October 2008 (UTC)

Abramowitz and Stegun is the canonical book of tables of (and identities for and other information on) special functions for applied mathematicians and physical scientists. It uses groups of five digits throughout. That is the only relevant source that I have to hand, and it may be that it is an unusual exception — but the five digit groupings do seem to add to the readability of A&S's tables. — ras52 (talk) 07:50, 8 October 2008 (UTC)
I do not concur with keeping this at WT:MOSNUM. I was proposing this as a guideline here even if there were a guideline for 3-digit grouping at WP:MOSNUM. (In fact, I thought there was a guideline there, except that, after some research, I discovered that Greg L had recently placed it there without evidence of consensus.)
Also, most mathematicians don't work with numbers, as oxymoronic as that might appear, so number formatting issues are not at the forefront of their thoughts.
Finally, see Arthur Rubin for a few publications, none of which have actual numbers in them. — Arthur Rubin (talk) 18:07, 8 October 2008 (UTC)
I believe the mathematical convention is no spaces at all. This is what's used in the OEIS, for example. It's also used in Ribenboim's The Little book of Bigger Primes. It may seem counterintuitive, but as Arthur Rubin notes, we don't work with numbers, only letters. (I once told a literature person that, and she said with a smile, "Oh! Then we do exactly the same thing!") Ozob (talk) 21:36, 8 October 2008 (UTC)
This should therefore be referred to a chemist or physicist. In lieu thereof, I cite the CRC Handbook, 84th edition. Their Table of Fundamental physical constants, at the beginning of section 1, spaces every three decimal places; almost all the other long decimals do not space. Their mathematical tables used to space every 5 decimal places, but are now published separately.
This is the merely rational way to do things; do what is clearest in each place, without the hobgoblin of a foolish consistency getting in the way. MOSNUM, even more than the rest of MOS, is a waste of time, imposed on us by bot, to satisfy the will to authority of a handful of "editors" who find it easier to invent rules than to actually contribute content or convince others to do what they would like.
When it is unprotected from its latest edit war, it should be considered whether any of it should be a guideline at all. Septentrionalis PMAnderson 05:38, 26 November 2008 (UTC)


Please forgive if this is the wrong guideline, but looking through the Linear regression articles, I've noticed a plethora of notations for the transpose of a matrix X.

  1. (X')
  2. (X^T)
  3. (X^\mathrm T)
  4. (X^\top)

Number 2 is obviously bad, and I think number 1 is hopeless; if we ever start differentiating, the ambiguities are obvious. I'd like to propose that we standardize on number 4, or with possibly number 3 as an option. — Arthur Rubin (talk) 15:36, 7 November 2008 (UTC)

for the transpose of the matrix A is done far more frequently in the statistics literature than is the superscript-T notation for transpose. It's also done in Herstein's Topics in Algebra, but the superscript-T is used in Weisberg's Applied Linear Regression, so I privately jocularly thing of the superscript-T notation as the Weisberg notation and the prime notation as the Herstein notation. Michael Hardy (talk) 17:37, 7 November 2008 (UTC)
Hasn't anyone seen as the derivative of X with respect to time a spacial parameter? (In fact, last year, I had occasion to try to describe the derivative of a matrix with respect to time, where the matrix is a function of other time-varying matrices and vectors. I didn't use that notation, because it was specifically forbidden by our style manual, but....) — Arthur Rubin (talk) 18:32, 7 November 2008 (UTC) (changed 16:06, 26 November 2008 (UTC))
I use for the derivative of a matrix. I checked seven books in my bookcase and all seven use option 2 so I wouldn't call it obviously bad. As far as I'm concerned, we don't need to standardize this. -- Jitse Niesen (talk) 16:48, 26 November 2008 (UTC)

Lay person's understanding

I know this will probably be considered anathema to many here, but, if possible, shouldn't a mathematics-related article explain the topic in lay language? Currently, the manual of style, suggests that math-related articles be written in simple terms. But, an overwhelming number of articles seem to consider "simple terms" to be paired down definitions that are still, alas, filled with technical nomenclature and jargon. A "simple" intro that still has four or five blue-colored (linked) jargon-words that a lay person would have to look up is not really that simple. The definition may be simple to you and me, but I don't get the sense that it would be for most people. The article, Pell number, is an example of an Wiki entry whose intro ought to be clearer for lay people. Now this isn't always possible, and, often, an introduction will try its best to be intelligible to a wide audience but will inevitably leave some readers scratching their heads. But, if possible, simplification of introductions should be achieved. If others agree, perhaps, this instruction can be added to the Manual of Style for mathematics. In the end, the more people that understand Wikipedia's mathematics articles, the better it is for the math as a whole, no? ask123 (talk) 15:45, 26 November 2008 (UTC)

If possible are the key words here. What is the lay language for non-linear partial differential equation? Septentrionalis PMAnderson 16:44, 26 November 2008 (UTC)

I just read the first three paragraphs of Pell number, and I think reasonable high-school students would understand. (But "lay person" usually means someone who doesn't know high-school math.) Michael Hardy (talk) 23:29, 26 November 2008 (UTC)

It's been considerably rewritten since it was tagged. Septentrionalis PMAnderson 19:07, 28 November 2008 (UTC)


I draw an analogy to this page over at WT:Layout#Proposal; if my analogy is wrong, let me know (either there or here, depending on where you want the thread). - Dan Dank55 (send/receive) 18:19, 12 December 2008 (UTC)

C function?

continuous function is...a function from one topological space to another that preserves open sets? That is loosely speaking? That DO is wrong. It is open map.--刻意 21:14, 20 December 2008 (UTC)

Hidden proofs

I've tried to revive the discussion on different styles of proof over at Wikipedia talk:WikiProject Mathematics/Proofs - please come join the discussion! I was torn as whether to put it here or there... SetaLyas (talk) 11:18, 28 December 2008 (UTC)

Redundancy in descriptions

I and another editor disagree over the phrase "square, symmetric, positive definite matrix" in the Matrix decomposition article. I am of the opinion that squareness is implied by symmetric and therefore redundant. He takes the point of view that "some readers may not notice that symmetric implies square, so the redundancy makes it clearer". I disagree with that too but that's not really relevant to my current posting. (It's not really an argument between us as there has only been one revert but it raised for the first time for me an important question about Wikipedia's approach to these type of situations.) Obviously the Wikipedia:Use common sense guideline is always in effect but in this case it's not so clear which makes more sense. Could somebody point more to a section of the MoS that advises on redundancy issues? I skimmed Wikipedia:Manual of Style (mathematics) but did not find a section that addresses this problem specifically. Advice appreciated too. Jason Quinn (talk) 14:00, 20 February 2009 (UTC)

I doubt there is a specific guideline. I take no position on what is most clear in this case—calling the matrix square might help some readers, but it might wrongly suggest to others that there is a definition of a non-square symmetric positive definite matrix. If you and the other editors cannot come to an agreement as to what is most clear, you might try asking on Wikipedia talk:WikiProject Mathematics. Ozob (talk) 21:27, 20 February 2009 (UTC)
The readers who "may not notice that symmetric implies square" are the ones who just don't know what symmetric means in that context, so saying "square, symmetric" isn't going to help them any more than just "symmetric": in order to understand that sentence, they would have to look up "Symmetric matrix" anyway, which starts with "In linear algebra, a symmetric matrix is a square matrix ...". So I would be slightly in favour of omitting square there. --A. di M. (talk) 12:06, 23 February 2009 (UTC)

Using scriptstyle to make in-line symbols "fit"

User:CBM and I are having a discussion (User talk:CBM#MSE) about the use of \scriptstyle to adjust symbol size. Symbols with decorations (hat or tilde, for example) automatically display as PNG, and those without, or with simple super/sub scripts, displayed as HTML. When I was working on the Maximum spacing estimation article, I used \ss to make many of the decorated symbols appear "normalized" (in my opinion) with the in-line HTML, as I had my settings set as per the MoS (HTML if simple, PNG otherwise). CBM believes that they should always be shown as displaystyle, and the simple ones forced to display using \,. I pointed out that this was not in agreement with the Math MoS, and he suggested that we bring this for discussion here, as scriptstyle is too small in his opinion. Here is how the scriptstyle looks on my browser (FF 3.0 under WindowsXP) [10]. Here is a comparison on CBM's browser [11]. The article as it stands now has CBM's changes in it. What is the opinion of the greater WP:MATH community on this? Thank you. -- Avi (talk) 18:57, 6 March 2009 (UTC)

Both look bad. Why not use clean LaTeX source and simply wait for the math rendering to get fixed one day. If Planetmath can do it and commercial publishers can do it why not Wikipedia? Then there will be a lot of kludges to fix. Why add to them? Jmath666 (talk) 04:05, 9 March 2009 (UTC)
Because it has been so badly broken for so long (for many years), with not the smallest step taken towards fixing it, that even the most optimistic person has stopped hoping it will ever be fixed? Ghod, can't even show in non-PNG mode without a space between the minus and the one which shouldn't be there... --A. di M. (talk) 07:31, 9 March 2009 (UTC)
I would say that scriptstyle is slightly too small, displaystyle is way too big, so the first is better. But Jmath666 might have a point... And what about the problem that inline math is very different from displayed Some people write italic g to avoid this, but then, italic f is disastrous, so some people use ƒ, about which I have no idea where it comes from. A di M (Al di Meola?), what do you suggest for this problem? All of this is ridiculous and hopeless to optimize, I'm afraid. So, arriving at the end of this paragraph, I say that Jmath666 is right, and for the sake of our mental health, we should just write in normal LaTeX, and accept that it looks bad on wikipedia... A question: on WHOM or WHAT does it depend on when this rendering will be fixed? --GaborPete (talk) 08:08, 9 March 2009 (UTC)
Ultimately, the MediaWiki developers. However, they currently depend on a package called texvc. While several people have tried making replacements, so far none of them has displaced texvc. Ozob (talk) 18:20, 9 March 2009 (UTC)
My understanding is that texvc is just a wrapper for LaTeX. It doesn't directly participate in the process of generating PNG images for the Wiki software. That job still belongs to LaTeX. So unless the Wiki development team is currently working on a replacement for LaTeX — which is extremely unlikely at any point in the foreseeable future — I suspect that this is a permanent problem with TeX on Wikipedia. Workarounds should therefore be encouraged, within reasonable limits. Sławomir Biały (talk) 16:23, 17 May 2009 (UTC)
Perhaps you mean replacement of a particular LaTeX rendering package that wikipedia uses and which is not working properly? LaTeX as such is fine. Other sites I mentioned above use LaTeX too and all is well there. Jmath666 (talk) 16:44, 17 May 2009 (UTC)

Layperson's understanding

I agree with the top post in this discussion page. I just came here to say exactly that, and noticed that somebody already had. I'd like to extend the notion a little bit to say that, even if Wikipedia is not *obligated* (ethically, or according to its own policies) to provide layman's explanations, it would really be nice if there were such an encyclopedia mathematica for laymen somewhere, and what better medium than Wikipedia to be that.

The problem with explaining mathematical ideas in jargon terms is that the learning curve for people who aren't already highly educated in mathematics to learn about a concept this way is ridiculously steep, maybe not even practical. Perhaps you might argue that someone not highly educated in mathematics wouldn't need to look up things like, for example, 4-d rotation, or how to make a Bezier spline, but I've found myself in this position *often*. Wikipedia could be a great portal between the layman's and the mathematician's worlds.

I'm sure those who *do* know their maths could argue that they shouldn't have to wade through descriptions put into layman's terms where a more concise terminology would suit them better, but I'm not proposing that the layman's-terms descriptions act as a replacement for the concise definitions - just that writing additional sections where things are thoroughly (or even summarily) explained in simple terms in a guiding way could be encouraged.

Also I'd like to see more algorithms posted for how to arrive at mathematical results. That's usually what I basically need, and having an algorithm there would be 1000x easier for me than trying to understand an abstract mathematical description and then coming up with my own algorithm. And even to people who understand these terms, I would think a formal definition alone doesn't necessarily imply some highly efficient algorithm for arriving at the given result that some mathematician may have come up with.

Maybe not every article can guide a layman to an understanding of the mathematical concept in a self-contained manner without including an entire lecture series in higher maths, but between having links to other articles and striking a good balance between generality and specificity, I think a very informative middle-ground could often be reached.

Inhahe (talk) 19:21, 20 April 2009 (UTC)

This question arises frequently. The consensus as I understand it is that while some mathematical articles are poorly written, much of the underlying content is difficult and cannot be made substantially easier to grasp. I invite you to browse the archives of Wikipedia talk:WikiProject Mathematics, where you'll find more discussion of this. Ozob (talk) 20:41, 20 April 2009 (UTC)

Blackboard bold

Is there a consensus as to when it's appropriate to use blackboard bold and when not? Right now, the MOS has a section, WP:MOSMATH#Common_sets_of_numbers, which, in my opinion, can be read to endorse either bold or blackboard bold for, e.g., the real numbers R, the complex numbers C, or the quaternions H. My own opinion is that blackboard bold is ugly and hard to read in print: The two vertical lines create a sharp, distracting contrast between whitespace and ink. For this reason I prefer to use blackboard bold only on blackboards. But we don't seem to have a policy. This became an issue recently at quaternion when an anonymous user switched boldface to blackboard bold and User:Virginia-American and I disagreed over which we should use. Does anyone have an argument for one or the other? Ozob (talk) 14:44, 2 June 2009 (UTC)

You have already stated the argument for using simply bold: it is typographically superior. On the other hand, many (most?) professionally published mathematics texts nowadays use blackboard bold in print, and the appearance is decent enough. The wikipedia tradition for these sorts of minor issues is to leave each article as it was formatted by the first major editor. — Carl (CBM · talk) 14:48, 2 June 2009 (UTC)
I would suggest the guiding principle should be simple: do what ever the majority of recent sources do. — ras52 (talk) 15:29, 2 June 2009 (UTC)

Angle brackets

Is there a preference with respect to the usage of "proper" Unicode angle brackets versus "faking" them with less than/greater than signs? Apparently, the angle brackets in an expression like 〈v,w〉 (using 〈 and 〉) are not displayed properly for many users. Should one write this expression as <v,w> instead? —Tobias Bergemann (talk) 08:50, 10 June 2009 (UTC)

The proper use are the r/l angles. If they don't display correctly, these won't be the only things to not display correctly. This isn't the internet of 1995, and any modern browser uses default fonts which supports them.Headbomb {ταλκκοντριβς – WP Physics} 06:49, 25 June 2009 (UTC)

Good advice

can be found at, esp. part II. I found this info out far too late to be of any use to me, but I felt good knowing that someone made explicit the process of writing theorems (or I was away at the lecture they told everyone else)...

Perhaps this should be basic knowledge for anyone actually writing a maths article on WP. Otherwise a link to it may be helpful. (talk) 02:22, 16 July 2009 (UTC)

Italicization of π / Pi

The Greek letter pi is italicized in some parts of the Pi article, and roman in others. That needs to be fixed, but which is correct? (talk) 02:37, 17 September 2008 (UTC)

Pi should be italicized; π should not be. Septentrionalis PMAnderson 16:58, 20 September 2008 (UTC)
Not exactly consensus, but I agree and boldly made the change throughout (in celebration of this glorious day), but e still appears italicized. Note that, as a constant, this is different from the several variables that appear italicized (d, r, etc.), although I'm not 100% sure what's proper there, either. Out of curiosity, would be an option for the article body? Or ? /Ninly (talk) 16:04, 14 March 2009 (UTC)

WRONG. π should always be italic, for the following reasons..

  1. The tradition of mathematical typography is to italicize π. There is discussion of whether this is 'correct' but the lower-case italic form is the most widespread in the literature. (π is italic when it denotes the standard meaning of pi in trigonometry, calculus, physics, etc -- but deviant statisticians use π and Π to symbolize other stuff).
  2. MathML, LaTeX, and Wikipedia tags {{math}} or <math> all italicize .
  3. From Edward Tufte's website:
  4. According to Stephen Wolfram:
  5. Most fonts are non-mathematical and render π as "π" (non-italic). But mathematical typesetting packages render \pi as "" (italic).
  6. The Pi article even shows this italic image of the letter! --- Pi-symbol.svg

I believe this article should follow mathematical convention, so I would prefer to italicize the π's. Any objections? ~~ Ropata (talk) 05:38, 17 June 2009 (UTC)

The Wikipedia Manual of Style clearly asks not to italicize π (or any other Greek letters for that matter, except possibly when they are variables). The discussion really belongs to WT:MSM, not here. — Emil J. 11:54, 17 June 2009 (UTC)
The discussion is already here, not at WT:MSM. The Manual of Style does not enforce rules, it merely states a few conventions. Wikipedia ought to follow mathematical convention not reinvent it. ~~ Ropata (talk) 11:00, 20 June 2009 (UTC)
That the discussion already started here does not make the choice any more appropriate. People who are interested in conventions for formatting Greek math symbols are supposed to watch the MoS page, they are not supposed to watch every article which uses the symbols such as this one. — Emil J. 14:25, 23 June 2009 (UTC)
My understanding is that italicizing Greek is redundant because Greek letters are already somewhat slanted (or at least their supposed be even though some computer fonts don't show them that way. For another project Angr wrote:

The Greek alphabet doesn't distinguish between italic and roman types; Greek letters themselves are usually printed slightly inclined to the right, especially in fonts used for Ancient Greek rather than Modern Greek. (Modern Greek fonts are often assimilated to the Latin alphabet, having completely vertical lines and distinguishing between serif and sans-serif fonts.) At any rate, even though the Greek will look slightly italicized to people used to the Latin alphabet, it shouldn't be set as italics.

--RDBury (talk) 05:37, 25 June 2009 (UTC)

π should be italicized in a math context because that matches TeX style, and obviously we do use TeX. If writing words in Greek, then one follows different rules outside of the jurisdiction of the WP:MOSMATH policy page. Clearly "sin θ" looks different from "sin θ".

It is not clear that Angr was writing about mathematical typesetting! (If so, he was wrong because TeX italicizes the lower-case π. If not, then he shouldn't get quoted as an authority in this discussion.) Michael Hardy (talk) 00:10, 29 July 2009 (UTC)

The TeX argument is bogus, TeX italicizes all letters by default. \gamma\pi\rho\mu gives . Pi as a constant is straight, Pi as a variable is italicized. A diameter of 3π but A parity eignenvalue of π = 1. Like wise sin is straight when it means the sine, and italicized when it means s*i*n. Headbomb {ταλκκοντριβς – WP Physics} 18:22, 4 August 2009 (UTC)
Not really, constants and variables should both be in italics. Function names and the like should be in simle Roman. ~~ Dr Dec (Talk) ~~ 18:29, 4 August 2009 (UTC)

Inline math notation

(moved from Talk:Torque)

So, apparently inline LaTeX is discouraged, but not prohibited. From the guidelines it is seen that you still can use LaTeX without getting the full size PNG, which keeps the height of the line almost the same as when using text. For example, is obtained using LaTeX but it is not as big as . I think both symbols are better than using the text symbol τ, which is nowhere close to the symbol from the equation. So, I am asking for people's opinion on this matter. How do you want the article to look like: with inline equations using text or LaTeX? sanpaz (talk) 04:06, 17 July 2009 (UTC)

In a perfect world I'd like to see <math></math> used for everything, but as things currently are, LaTeX PNGs stick out from the rest of the text like a sore thumb. (Too bad the MathML option on Wikipedia is so wimpy—just about the only time it seems to kick in is with simple fractions.) Getting consistency in appearance between the text and the out-of-line equations is definitely a problem, and I can definitely see why so many editors prefer inline PNG rendering. Strad (talk) 18:30, 17 July 2009 (UTC)

Is there some reason you bolded the tau in your text symbol example? Either the regular τ or the italic τ looks better, I think. On my browser, all your TeX-formatted examples are significantly larger than the size of the text. My opinion: text wiki formatting of math is ugly but mis-sized inline bitmap images are even uglier. So I prefer the wiki formatting. —David Eppstein (talk) 00:15, 18 July 2009 (UTC)

I don't think this should be anything individual editors have to worry about. Ideally, editors would simply tell the software that some text is is mathematical, and then the software would display it appropriately. Having editors use different markups just to circumvent the limitations of the software is just a hack. If this view is shared by a majority, then I could enter an enhancement request at bugzilla. (There seems to be none yet ; see — Sebastian 00:21, 18 July 2009 (UTC)
Would you propose to fix this by instituting the mis-sized bitmaps whenever any text is called out as mathematical, or by restricting mathematical formulae to the limited options available in wikiformatting? Neither is satisfactory for all purposes, and until all browsers support MathML they're what we're stuck with. —David Eppstein (talk) 01:02, 18 July 2009 (UTC)
To be honest, I don't know enough about the technical implementation, and maybe I'm misunderstanding something here. What I'm getting out of the conversation so far is that we have two basic ways to enter simple mathematical text: (1) without markup, as in "τ"; (2) with markup, as in <math>\tau</math>. (Each of these can be modified, e.g. by bolding it or by adding "\,\!", but I'm glossing over these subtleties here.)
I only thought about it at the level of how we enter the text. My proposal is on this higher level, not about a specific bug fix. (This is why I think of it as an enhancement.)
Now, let's assume that we have sufficient consensus that the bitmaps are uglier than the inline text. So far, we have been trying to address this through the MOS, by discouraging inline math markup. But if we have that consensus, then there is no reason to even offer the choice. The enhancement I propose would shift that worry onto the software, so that editors only need to decide whether a text is mathematical or not. If an (inline) math text can be displayed as plain text, then the software will do so. If not, it will display as a bitmap. I think this is a more elegant and logical solution. — Sebastian 02:16, 18 July 2009 (UTC)
Besides text and math markup, you can also use html tags which is what the x2 and x2 buttons above the editor window generate. Theoretically, you could also type in the MathML directly as well, but there are a lot of browsers that still don't support it (as mentioned above). In my experience there is no good solution, at least the way things stand. For example, what do you do with something like ? It's impossible (or at least very difficult) to do without math markup but putting a single character in it's own line seems silly. What I try to do to carry on with the established style in the article, even if I disagree with it, on the theory that eventually the situation will improve and it's not worth tweaking formulas until then.--RDBury (talk) 06:11, 18 July 2009 (UTC)
Just some background info: As I understand it (correct me if I'm wrong) the way the server handles math markup is to first try to convert it to either html or MathML, depending on the user's preference settings. Only when the formula is too complicated, which it usually is, is it converted to PNG. In an ideal world, the server would be able to convert any LATEX code to MathML code, but the conversion program to do that is still under development. So the math markup is usually converted to PNG, and that conversion is done by an open source program developed externally. The problem with that program is that it doesn't know what font you're using in your browser so it picks a size that it thinks is reasonably legible. You can see this by bumping up the font size in your browser; all the text gets bigger but the math that gets converted to PNG stays the same size. In fact, you could "fix" the size mismatch problem by fiddling with the font settings in you browser, but then you've got huge text and there are still alignment problems.--RDBury (talk) 06:41, 18 July 2009 (UTC)

Imaginary unit

Some articles (such as Z-transform) needlessly use j instead of i for imaginary unit, which can confuse readers. Can there be any addition in this Manual of Style (or maybe somewhere else) that will encourage the usage of i as imaginary unit? -- (talk) 13:31, 19 July 2009 (UTC)

That's common in electronics and by extension signal transforms because i might stand for current. Dmcq (talk) 13:40, 19 July 2009 (UTC)
Articles in question don't use electrical currents in their formulas and certainly don't use lowercase i for electrical current, so there is no need to confuse readers by usage of j for imaginary unit in those articles.
Also, electric current is usually written as uppercase I. -- (talk) 14:03, 19 July 2009 (UTC)
Perhaps the articles don't mention electrical currents, but if I'm not mistaken, the Z-transform is frequently used in electrical engineering. Certainly an article using j for the imaginary unit should say that that's what that notation means. Michael Hardy (talk) 15:25, 19 July 2009 (UTC)
See Wien bridge for a simple example of i and j occurring together. In fact there they have iin, iout but people also say I and i to distinguish them. The usual rule in wikipedia for things like this is the first person to write a article sets the style. Dmcq (talk) 16:11, 19 July 2009 (UTC)
Also, it's inappropriate to force one convention across all of Wikipedia when several conventions occur in practice (just as in American vs. British spelling). As long as each article makes clear what i and j stand for, then we're doing as well as we can. Ozob (talk) 21:28, 20 July 2009 (UTC)
Fully agree. Both mathematicians as well as electrical engineers should know these formulae anyway and can figure out what j stands for in this context--Tprosser (talk) 11:18, 21 July 2009 (UTC)
Yes, only electric engineering articles should use j for imaginary unit, preferably with short notice in every such article that states something like "In this article j is used for imaginary unit, because i is used for electric current". All other articles should use i for imaginary unit, as most people use it. --antiXt (talk) 14:31, 23 July 2009 (UTC)
Personally I wouldn't be surprised if there aren't more electrical and electronic engineers, telecommunications engineers, signal processing etc etc than everybody else put together who ever comes in with occasional contact with i. Dmcq (talk) 15:40, 23 July 2009 (UTC)

How come those electrical engineers don't mix up current density j with their imaginary unit j? And why do they have to use lowercase i for electric current while it is standardized to use the uppercase I? -- (talk) 10:13, 21 August 2009 (UTC)

epiphenomenal spacing characters

Why does this page say one should write

<math>\sin x \,\!</math>


<math>\sin x \, </math>

would do the same thing? The purpose of the spacing character is to force png rendering, and one is enough. It does not actually affect the appearance to the reader unless something inside the math tags comes after the spacing characters. It's better to keep things simple when complicating them would do nothing except to complicate them. Michael Hardy (talk) 00:02, 29 July 2009 (UTC)

I don't think most people are aware of this feature, namely that extra whitespace is cropped:
\,\!: test text.
\, alone: test text.
If the whitespace were not cropped, then \,\! would be a better choice, and I'd guess that's why the MoS currently suggests \,\!. Ozob (talk) 14:27, 29 July 2009 (UTC)

The whole point is that \, by itself does not force PNG rendering if math preferences are set to "HTML if possible or else PNG", whereas \,\! always does. — Emil J. 14:40, 29 July 2009 (UTC)

Plural nouns

Shouldn't the plural form of formula be formulae? The article uses formulas. ~~ Dr Dec (Talk) ~~ 19:28, 3 August 2009 (UTC)

Well, to be picky, it would be formulæ. -- Avi (talk) 01:39, 4 August 2009 (UTC)
"æ" is just a ligature for "ae"; linguistically they're identical.
"Formulae" is the Latin plural of formula. This is the English wiki, so we use "formulas". Ozob (talk) 04:07, 4 August 2009 (UTC)
Well, it could also be an ash, which is a full letter in many languages, :) -- Avi (talk) 04:12, 4 August 2009 (UTC)

Ozob, formula itself has a Latin root! If this is English Wikipedia then maybe we should stop using formula too? My dictionary lists eight meanings for formula:

  1. A mathematical relationship
  2. A chemical formula
  3. A fixed form of words
  4. A method or procedure
  5. (before or after a noun) denoting a rule or style
  6. A list of ingredients
  7. An infant's liquid food
  8. A classification of racing car, e.g. formula 1

Here's the key: my dictionary says that the plural form in senses 1 and 2 is formulae, and the plural form in senses 3 to 8 is formulas. This is backed up by the fact that in every published mathematical article I have ever read the word used is formulae. Also, Avi, "to be picky" it should be formulae and not formulæ, the latter is the exact Latin word, the former is the English language derivative. ~~ Dr Dec (Talk) ~~ 10:32, 4 August 2009 (UTC)

IIRC, and I may be wrong, the word came into English as "formulæ". It was a later evolution that separated the digraph. English is known for its being replete with loanwords. I am not sure that there is a word that may be traced to Old English that carries the meaning of formula :) -- Avi (talk) 14:38, 4 August 2009 (UTC)
Maybe you're right that it came into English as formulæ, but non of the online dictionaries have entries for formulæ. The Oxford English dictionary and Merriam–Webster both list formulas and formulae, but not formulæ. As I said above: The OED explicitly says that formulae applies to mathematical and chemical formulae, where as formulas applies to the other meanings. Merriam–Webster makes no such distinction. It would be interesting to see some publisher's guidelines on the topic. Like I said: I've only ever seen formulae in publish academic works, but that doesn't mean that all journals insist upon that spelling. Maybe some give the author the choice. ~~ Dr Dec (Talk) ~~ 16:08, 4 August 2009 (UTC)
And just to add a little weight to why we should follow the OED: The OED article tells us that it "is used by the United Nations, the World Trade Organization, the International Organization for Standardization, and many British academic publications, such as Nature, the Biochemical Journal, and The Times Literary Supplement." ~~ Dr Dec (Talk) ~~ 16:13, 4 August 2009 (UTC)
And as a dumb American, what does that mean to me? :-P -- Avi (talk) 16:21, 4 August 2009 (UTC)
If you are "dumb" as you claim, then why waste everyone's time making silly comments on what was intended to be a productive discussion thread? ~~ Dr Dec (Talk) ~~ 17:01, 4 August 2009 (UTC)
That was a somewhat humorous attempt to point out the wikiepdia manuals of style are not based specifically on British English; I guess it fell flat. -- Avi (talk) 17:20, 4 August 2009 (UTC)
No, you're right: Wikiepdia manuals of style are not based specifically on British English. Nor is the OED; it simply happens to be published in England! It actually uses the American English endings -ize instead of the British English -ise. I wouldn't call the United Nations, the World Trade Organization or the International Organization for Standardization British establishments either. But if such powerful and respected organisations use the OED as their standard English language reference then who are we to argue? If the OED says that it's formulae and not formulas then who are we to argue? ~~ Dr Dec (Talk) ~~ 17:31, 4 August 2009 (UTC)
Personally, as long is an article is consistent with usage (-as, -ae, -æ) I'm fine with that. Usually, the editor who writes the majority of the article sets the precedent. -- Avi (talk) 17:40, 4 August 2009 (UTC)
I see your point: consistancy is key. But when I read formulas it just feels ameature to me. It feels like the person using the word doesn't have enough understanding of where the word came from. When I read formulæ it feels like the person is trying to be smart, when the oposite is actually true: we don't use the character æ in the English alphabet, we only use it when we quote Latin. I don't know, maybe I'm being a pedant, but if I am, so is the OED, the UN, the WTO, and the IOS. ~~ Dr Dec (Talk) ~~ 17:50, 4 August 2009 (UTC)
I guess I'm one of those people failing to be smart Face-blush.svg; I like the digraph, and while it is archaic, it is not improper. The word is still English; just an older form. And, for the record, there is nothing wrong with being a pedant (in the original sense of the word) :) -- Avi (talk) 19:18, 4 August 2009 (UTC)
It's interesting that you also link to pedant. This article links directly to minutiae, the plural form of minutia. Although they mention minutiæ, there is certainly no mention of minutias ~~ Dr Dec (Talk) ~~ 19:47, 4 August 2009 (UTC)

(←) Hmm. I find the objections presented here quite interesting. So, my point about English plurals versus Latin plurals runs, in more detail, like this:

  1. "Formula" is (essentially) a Latin word.
  2. If we were speaking Latin, we would say "formulae".
  3. We are not speaking Latin, therefore it can be grammatically correct to say something other than "formulae".
  4. We are speaking English. (At least, I try to speak English. Sometimes it doesn't come out so well.)
  5. It is grammatically correct to use the English-language plural "-s" suffix for many foreign loanwords.
  6. Therefore, I think that it is at acceptable, though perhaps not necessary, to use "formulas".

There are, of course, several assertions here that can be debated. But even if you were to knock down every one of those assertions, I'd still vote for "formulas", and for reasons that are admittedly subjective and aesthetic. My taste is guided mostly by my own professional experience: I, in my life as a professional mathematician, use "formulas" exclusively, and so does everyone else I know. "Formulae" sounds pretentious to me; you might be able to convince me that it's grammatically correct, but it crashes, discordant, against my ear. Ozob (talk) 23:40, 4 August 2009 (UTC)

Ozob you say that formulae sounds pretentious, for me it's the oposite, hearing formulas is like hearing someone say inexplainable (instead of inexplicable) ~~ Dr Dec (Talk) ~~ 23:45, 5 August 2009 (UTC)

I also commonly read and use "formulas" as a mathematician. I see on google books that Paul Halmos, Stephen Cole Kleene, Donald Knuth, and Nicolas Bourbaki used "formulas" as well; so does the Chicago Manual of Style. This points to the issue being one of style rather than correctness. In such matters, we usually simply stick with the convention first established in each article. — Carl (CBM · talk) 02:40, 5 August 2009 (UTC)

The OED (online reprint of the 2nd ed.) lists the plural of formula as either formulæ or formulas (and has quotations for formulae too, as well as a quotation—from 1864, no less—for formulas in the mathematical sense). The AHD (4th ed.) lists the plural as either formulae or formulas. They're all acceptable. Consistency is what's important. Strad (talk) 02:54, 5 August 2009 (UTC)
Above, Declan Davis makes a contrary claim about the OED: "[OED] says that the plural form in senses 1 and 2 is formulae, and the plural form in senses 3 to 8 is formulas". I'd like to see an explicit citation (to edition and a quotation from it), since I'm feeling skeptical about this claim. In addition, while he may never have seen "formulas" used in a math paper, I've seen it plenty of times. For example, one can easily see its usage in well-known journals such as Inventiones Mathematicae, (one easy way to check this is put in the name of the journal into Google scholar plus the term "formulas" and weed out the excerpts that have only the singular form). --C S (talk) 23:16, 5 August 2009 (UTC)
C S, I feel quite hurt by the tone of you post. Do you think that I'm going to lie? If I wanted to go around lying to people I wouldn't chose something that has millions and millions of copies is circulation. My dictionary is "The Oxford Compact English Dictionary", second edition, revised. The ISBN is 0-19-860-713-X. ~~ Dr Dec (Talk) ~~ 23:33, 5 August 2009 (UTC)
I get the feeling that I'm flogging a dead horse here. The majority of editors are Americans, or people used to American English, and the Americans always seem to favour simplification of language, e.g. using color instead of colour and thereby losing any links to the word's French roots, and of course formulas instead of formulae. ~~ Dr Dec (Talk) ~~ 23:45, 5 August 2009 (UTC)
The tone was perhaps too harsh. By the way, did I mention that according to google books, Nicolas Bourbaki used "formulas" (in the English translation, of course), and Dieudonné as well? On the other hand some Americans use "formulae". I think it is more a question of what one is used to and what one's editor requires, and this may vary some by field as well. In a similar example, we tend to use "indices" in recursion theory even though the American standard has sadly become "indexes". — Carl (CBM · talk) 00:22, 6 August 2009 (UTC)
I know what you're saying. But the majority of American authors would use formulas and the majority of British English speaking authors would use formulae. Of course there are exceptions to every rule.

I am not inclined to believe that formulae (or formulæ) is significantly more prevalent that formulas in mathematical writing, but if someone can produce data to the contrary I will gladly support an addition to WP:MSM recommending formulae. Strad (talk) 00:46, 6 August 2009 (UTC)

Such data would be, most probably, impossible to come by: who has the resources to sift through every mathematics article ever written in the English language? Those with such resources will be occupied with the greater good and not out little linguistical discussion. One thing I would try to remeber is that journals change the spellings. In my latest article to be published in Geometriae Dedicata, the Springer editors insisted upon changing all of my spellings to American English. (The link is to an original copy so the British English is still in place. See my user page for details of the paper, then you'll be able to compare the post Americanised version with my originally submitted version). ~~ Dr Dec (Talk) ~~ 18:35, 6 August 2009 (UTC)
Then in lieu of such data we can only assume that formulae, formulæ, and formulas are all acceptable plurals for mathematics articles. Strad (talk) 03:21, 7 August 2009 (UTC)

(<-)In my opinion, for what it is worth, I would like to reiterate that this is wikipedia, not Encyclopædia Mathematicæ; it is written by many, many different people. As long as individual articles are consistent with a correct usage (-as, -ae, -æ), I do not see the need to force uniformity across articles. -- Avi (talk) 01:23, 6 August 2009 (UTC)

I don’t feel very comfortable hearing people say things like “formulae is the Latin plural, we speak English, so we should use formulas.” Well, what exactly is the English language? The indigenous tribes of what is now the British Isles spoke a Gaelic language Brythonic language, a language very like modern day Welsh. The along came the Angles and the Saxons from what is now Germany speaking an ancient Germanic language. Then the Romans came to settle, bringing with them Latin. The Vikings made the British Isles their home bringing with them ancient Scandinavian dialects. Finally the Normans came with a language not dissimilar to modern day French. All of these languages and cultures mixed to give rise to the English language and the British people. To say that “We are speaking English, and that’s not Latin!” is like saying, “We are eating an omelette, and that’s not eggs!” Also, we always use the Latin plural form many words. For example, do you say basises, or bases? The Latin plural of basis is bases. ~~ Dr Dec (Talk) ~~ 13:45, 6 August 2009 (UTC)

I feel like you're missing my point. I agree that languages change and evolve, and that one goes fluidly into the next; all the same, it's been about DCCIX yeres syn Ich laste spoke Middle English. We're not speaking Middle English right now, we're speaking Modern English. We should speak as other Modern English speakers do—which, in my experience, is to say formulas and not formulae.
As far as collecting usage statistics goes, I don't think it would be too hard. The arXiv has a tremendous collection of mathematical and scientific preprints from all over the world. If we could survey their usage—which ought to be possible—then we'd get a more definitive answer. Ozob (talk) 23:09, 6 August 2009 (UTC)
The following is irrelevant to the topic of the discussion, but the areas of Great Britain that were settled by the Angles and the Saxons were previously inhabited not by Gaelic-speaking peoples, but by Brythonic-speaking peoples (our article on Welsh begins, "Welsh [...] is a member of the Brythonic branch of Celtic"). Strad (talk) 03:18, 7 August 2009 (UTC)
Strad, I'm sorry, I don't follow... ~~ Dr Dec (Talk) ~~ 00:44, 9 August 2009 (UTC) Oh now I see. Well you're right: your comment doesn't make much difference to my point. My point was that modern English is a mixture of other languages including, most importantly in this discussion, Latin. Given that I'm a mathematician and not a language expert I would have hoped that you may have taken my comments in good faith and tried to understand the general meaning. I don't see how the subdivision of insular Celtic languages relates very much to the overall meaning of my comment, and it certainly has nothing to do with the formulae/formulas debate. ~~ Dr Dec (Talk) ~~ 10:36, 9 August 2009 (UTC)

Minima or minimums? Media or mediums? Bases or basises? I'm sure you would agree that the latter options are quite ugly and most uncommon; the traditional forms seems to win the day. Then what about formulae or formulas? ~~ Dr Dec (Talk) ~~ 00:15, 9 August 2009 (UTC)

The plurals of minimum, medium, and basis are not relevant. I cannot argue that the preferred plural of eye is eyen simply because the preferred plural of ox is oxen. The only thing that matters is this: What plural(s) of formula are currently used in written Standard English? I have attempted to answer this question by citing two major reference dictionaries, the OED and the AHD, whose editors have determined that formulae/formulæ and formulas are all commonly used plurals of the word formula. If you do not want Wikipedia to use formulas, you need to present similar statistical evidence (either directly, through a corpus search, or indirectly, through a corpus-based dictionary like the OED) showing the formulas is sufficiently uncommon in mathematical (or general) texts. Strad (talk) 17:44, 9 August 2009 (UTC)
Do you own a copy of the OED? Have you read the thread above? The OED seems to say that formulae is used for mathematical and chemical formulae and that formulas is used for thr other meaning. We want consistancy in our language. Lets make a list of mathematical plural:
  1. Matrix & matrices (not matrixes)
  2. Basis & bases (not basises)
  3. Minimum & minima (not minimums)
  4. Medium & media (not medias)
These are just some examples. We use the Latin plurals most of the time... why not use it with the plural of formula?! ~~ Dr Dec (Talk) ~~ 18:00, 9 August 2009 (UTC)
As I understand it, the plural of eye really did used to be eyen. But not anymore, of course; fortunately that's not under dispute.
I commonly hear "matrixes" and "vertexes"—in fact, I first learned the plural of "vertex" as "vertexes". And I do hear people say "minimums" and "maximums". I get funny looks if I say "complices" for "complexes" (I've tried it). And people seem to use "simplexes" and "simplices" interchangeably. Now, I have to admit to being a bit of a language snob myself (that's why I tried using "complices" instead of "complexes"). But the trend seems pretty clear to me here: People tend to use an -s suffix to pluralize Latin loanwords. The only real exception I'm aware of are words like "basis" which already end in an "s".
I tried searching the reference desk archives and I came up only with the following unhelpful but slightly amusing result: Wikipedia:Reference_desk/Archives/Mathematics/2006_November_14#help i want to pass in maths exams of mvita school based kenya. So I've asked: Wikipedia:Reference desk/Language#Plural of "formula". Hopefully there will be someone knowledgeable who can solve our problem. Ozob (talk) 19:03, 9 August 2009 (UTC)
Ozob, where exactly have you heared people talking about vertexes, etc? The only time I have ever heared that usage is when a Spanish friend of mine was giving a talk in English. And trust me, I've been to a lot of conferences! See my user page. You really seem to live in a parallel universe. Besides, Ox and Oxen are Old English and not pure Latin, so how does that have anything to do with Latin plurals? Please, for the love of God, stick to the point and stop picking up on side issues! ~~ Dr Dec (Talk) ~~ 19:54, 9 August 2009 (UTC)
The remark on ox, oxen, eye, and eyen was a comment on Strad's remark: He says above, "I cannot argue that the preferred plural of eye is eyen simply because the preferred plural of ox is oxen." Note that according to Middle English#Nouns, the plural of "eye" was "eyen" between about 1066 and 1650. This is relevant to my point: Just because you retain an older plural form in some words does not mean that you must do so for other words. And conversely: Just because you use a more contemporary plural form for some words does not mean that you must do so for other words. I am sure that you would say both "oxen" and "eyes", not "oxes" and "eyen".
Regarding the plural of vertex, I am told that "vertexes" is the standard terminology in the computer graphics community; while I hear it less frequently than "vertices" in my own trade it seems to be gaining popularity. If you Google "vertexes", ignore "Did you mean: vertices", and skip the first two pages of results (which are mostly encyclopedia articles), then you start to see real hits, mostly involving computer graphics (which is consistent with what I've been told). That doesn't make "vertexes" right; I say "vertices" just like you do, and I think it's more correct. "Vertexes" is a minority usage which is incorrect in formal, written English, except within computer graphics.
I believe that the situation is different with "formulas". As an experiment, I went to the arXiv and tried their full text search (at [12]). I got:
  • 55870 hits for "formulas".
  • 45490 hits for "formulae".
Based on that, I think we can confidently conclude that both "formulas" and "formulae" are acceptable in formal, written mathematical English. Ozob (talk) 23:12, 9 August 2009 (UTC)
I have access to the full, complete, up-to-date OED through my university's online subscription. I assume (since you are a professional mathematician, and therefore most likely have university affiliation) that you do as well. When the UN, the WTO, ISO, Nature, etc say "the OED", they mean the full, complete, up-to-date version, not a condensed print version. Perhaps the usage note in your print version takes advantage of new information since the publication of the formula entry in the full OED (it was effectively written over a century ago, after all), but that is only speculation.
Just to rehash: the language on Wikipedia needs to reflect contemporary, written Standard English, not notions of what should happen based on arguments from etymology or consistency. Having consulted several dictionaries—whose information is drawn from observations about contemporary, written Standard English—I conclude that formulae/formulæ and formulas all appear with reasonable frequency in contemporary, written Standard English, and thus they are all acceptable pluralizations for use in Wikipedia. Unless new information enters the discussion I don't think I have anything more to contribute to this topic. Strad (talk) 21:14, 9 August 2009 (UTC)
Well, yes you do. I was branded a liar by C S for just saying what was in my dictionary. Let's have some quotes, some references, and some links. Get off your high horse ("Unless new information enters the discussion I don't think I have anything more to contribute to this topic." - what an arrogant thing to say!) and let's aproach this topic as people with a common goal; as we all are! ~~ Dr Dec (Talk) ~~ 21:34, 9 August 2009 (UTC)

Someone said above that formulae is BE and formulas is AE. Actually, I am pretty sure it's the other way round in my field (model theory): formulae is AE and formulas is BE. This would also be in accordance with what an older (British) colleague told me about topoi (AE) vs. toposes (BE), and with the general principle that AE is more conservative than BE except for (1) Noah Webster's reforms such as theater, which were not followed in the UK, and (2) some spellings such as -ise, where BE remains closer to French. (Actually (1) can also be seen as a special case of (2).)

Model theory literature is currently dominated by Europeans, and within the field formulas is standard for this technical term (see well-formed formula), outnumbering formulae by at least 2:1 according to my Google Scholar tests. Note that for such tests one needs to put even the single words formula or formulae into quotation marks. I believe Google changed their algorithm recently. Hans Adler 10:50, 21 August 2009 (UTC)

Templates using <math></math> and conditional statements

I am wanting to create a new template for dental formulas, but I keep getting a "Failed to parse (lexing error)" whenever I try it out. The code I'm using is:

<math alt="Upper: {{{upper}}} / Lower: {{{lower}}}{{#if: {{{total|}}} |, Total teeth = {{{total}}}|}}">\tfrac{ {{{upper}}}}{ {{{lower}}}}{{#if: {{{total|}}} | \times 2 = {{{total}}}|}}</math>

Admittedly, this is the first complicated template I've ever written, although I have read Help:Template. If I take the \tfrac part out, and leave <math>...</math>, no errors are generated and the alt text comes out correctly. If I leave the 1 & 2 variables in the \tfrac, but remove the conditional statement, it works fine. For some reason, it objects to the conditional statement, which will allow me to either show a general dental formula or show the formula along with the total number of teeth. Is there something I'm doing wrong, or do I have to create two separate templates? –Visionholder (talk) 16:12, 15 September 2009 (UTC)

Sorry, I should have included examples of what the output should look like. If the user passes the following: {{DentalFormula|upper=|lower=}}, then they would get:
If the user passes the following: {{DentalFormula|upper=|lower=|total=36}}, then they would get:
Hope that helps. –Visionholder (talk) 16:32, 15 September 2009 (UTC)
Why do you need a template to do this? The resulting wikicode is not much longer than the templated version and easier to read? Plastikspork ―Œ(talk) 18:20, 15 September 2009 (UTC)
I was mostly doing this to make things easier for WP:MAMMAL. Biology people aren't necessarily math people, and previous attempts at creating dentition templates have resulted in tables that cannot be used inline. For people used to using templates rather than math markup, this might be a lot easier and require a lot less reading. Furthermore, it also ensures that alt text will be used, which cannot be guaranteed if left up to each editor. –Visionholder (talk) 19:17, 15 September 2009 (UTC)
The problem has been fixed, thanks to a suggestion at MediaWiki. For those of you wanting to use <math>...</math> in templates, follow the link to learn more. –Visionholder (talk) 08:45, 16 September 2009 (UTC)

WARNING: Technical problem

Yesterday I edited this page - ok. But today I could not edit this page via IE: "Internet Explorer has encountered a problem and needs to close. We are sorry for the inconvenience." I wrote this message via Konqueror under Linux. At the same time, other pages I had tested is ok.--Tim32 (talk) 11:06, 24 February 2010 (UTC)

Circle vs. Disk issues

Mathematically, a circle is a curve and a disk is the region enclosed by it. The same distinctions hold for sphere vs. ball, torus vs. toroid, and I'm not sure if there are different names for square (interior) vs. square (perimeter). While mathematically accurate, these distinctions fly in the face of common usage, for example the area of a circle is actually 0, it's the area of a disk that's πr2. In light of this, I think it would be better to merge corresponding articles together. I've already proposed a merge between Torus and toroid and it occurred to me that this idea could be applied more generally.--RDBury (talk) 17:31, 22 October 2009 (UTC)

Lots of people use circle to mean sphere in common usage. For example "The sun is a circle", is not an unheard of refrain. Likewise, people will use square for cube and indeed cube for square.
This does not mean that we should merge those articles. ObsessiveMathsFreak (talk) 13:17, 18 November 2009 (UTC)

Section "Very simple formulae"

This section seems to be routinely misunderstood to give free license to write mathematics as inline LaTeX, regardless of whether it displays as inline PNG (and thus conflicts with other parts of the guideline). I suggest emphasizing that this is not what is intended by changing the sentence:

"Either form is acceptable, but do not change one form to the other in other people's writing."

to read

"For very simple formulas such as this, either form is acceptable, but do not change one form to the other in other people's writing."

Second of all, the sentence

"Changing to make an entire article consistent is acceptable."

also seems to be very gameable. I think this sentence should be removed, since it is definitely not acceptable to change inline formulas to TeX if that will force them to display as PNG (unless there is an overriding necessity to do so). (talk) 15:05, 1 November 2009 (UTC)


I was just told on my talk page that my use of (A^\top) for transpose wasn't kosher; that I should be using :

For a matrix transpose, use XT (not XT) or (not or ).

From the histories, it looks like this came from rolling in old content from Wikipedia:WikiProject_Mathematics/Conventions. That topic saw only limited discussion on that talk page. While I'm all for consistency, I think I see in more textbooks. Personally, I find it clearer that it's an operator rather than just raising something to the Tth power. Finally, typographically it seems more consistent to use a symbol than a letter, to go along with for conjugate transpose and for the Moore–Penrose pseudoinverse. Orthogonally, is there any way to add a definition of \transpose to the "global preamble" so that it is available in all of Wikipedia's <math>? That would separate the typography from the semantics and would make it involve a lot less ugly curly braces in the source. —Ben FrantzDale (talk) 03:29, 18 November 2009 (UTC)

Well what do you know. Some textbooks do use the top symbol. I say some; most don't.
My opinion is that this symbol is entirely inappropriate. Typographically, it looks awful, with top not having the correct ratios for a capital "T". In addition, the conjugate transpose is also denoted for the Hermitian matrix, which matches up with . Oooo, those lovely serifs! Along these lines, the mathrm "T" is disgusting.
This looks like a fad. A bad fad started by mathematicians who've spent too much time using latex and haven't realised that they're not typographers. There is nothing wrong and everything right with using a standard "T" for the transpose operation. The standard T, not the mathrm one. There is no reason to use a symbol that was never intended for that purpose, and further there is no reason to mix italicized and regular text in the one symbol. ObsessiveMathsFreak (talk) 13:36, 18 November 2009 (UTC)
It was Arthur Rubin. Oh dear ObsessiveMathsFreak (talk) 13:53, 18 November 2009 (UTC)

There is a good reason for using \top , or a roman T, or something other than a standard T: it frees up T to be a variable name. —David Eppstein (talk) 15:44, 18 November 2009 (UTC)

I doubt anyone would confuse the transpose operation with a variable denoted by T and vice verse. I'm pretty sure I've even seen somewhere before. In any case, it doens't really free up anything as \top looks similar enough to a T to cause confusion. (talk) 16:29, 18 November 2009 (UTC)
Perhaps T (or T) should never be used for transpose. I could live with a convention that only ′ should be used, but it is absurd to recommend an italicised "T" be allowed for anything other than a variable. — Arthur Rubin (talk) 17:00, 18 November 2009 (UTC)
May I add additional hypothetical confusion; in the matrix exponential article, it would make perfectly good sense to write:
I would never do that, but if the transpose symbol were a simple unadjusted "T", it would be impossible to parse. — Arthur Rubin (talk) 17:07, 18 November 2009 (UTC)
It's already impossible to parse. Anyone who wouldn't write is not going to go about writing . They're not going to go about writing it because looks too much like . In fact, that is the very reason it is being (mis)used in place of a regular the transpose operation. Having said that....
You say that an italicised "T" should never be used for anything except a variable. This has not been my mathematical experience. I have seen and moreover used in a great many publications and used in one very recent one. I suspect this "convention" of requiring to be a recent invention of a rather small group of typographically minded mathematicians, and not something generally agreed upon anywhere. Therefore, I question its imposition by fiat in the style guide.
This conversation began when someone was told they couldn't use because "it conflicted with the style guide" or else "wasn't kosher". As far as I can see, there is no "kosher" way of typesetting mathematics, so I find the imposition of these quite foreign notions on others to be against the spirit of the mathematical community and against the ostensible aims of the site.
I recall a case from some time ago where someone attempted to rewrite all vectors in the Electromagnetism pages so that they used arrow notation and not boldface. Needless to say, this did not go down well. Why the, should essentially the same typeforcing be allowed in the case of the transpose operator for matrices? Because it is in the style guide? This is not good enough.
Having read through it, my opinion is that the mathematics style guide is best left empty. Any attempt to impose the styles, manners or symbols of one field or region onto all others is a bad idea. "Horses for courses" as the saying goes. I think people need to take a serious look at the content and indeed the place of the mathematics style guide. My recommendation is to begin by removing, entirely, conventions for the transpose operation.ObsessiveMathsFreak (talk) 13:25, 20 November 2009 (UTC)
Well the style guide can simpy serve as (useful) information about notations and as a nonbinding suggestion. The problems comes only with strict enforcement then it is likely authors will clash and we may get a lot of bad blood. So the rationale should be to consider the guide mainly as information & suggestion and not as something to be imposed on authors. As long as an author stays within in the general range of mathematical conventions, it should be up to him what to use in (his) article. In the case of heavily collaborated articles it might be useful to enforce some consistence throughout the article though.--Kmhkmh (talk) 06:31, 27 November 2009 (UTC)
As for the second part of my question, can we all agree that it would be nice to have \transpose defined universally to be whatever we agree upon? Is this technically feasible? —Ben FrantzDale (talk) 17:29, 18 November 2009 (UTC)
It would be nice, but I don't think we (as en.Wikipedia) have control over the <math> interface. — Arthur Rubin (talk) 17:42, 18 November 2009 (UTC)
Well, we could petition the developers through Bugzilla, but that's a long run, especially since they are likely to regard it as a low priority issue. — Emil J. 17:51, 18 November 2009 (UTC)
And I should add that for the same reason it's not really a good idea anyway, because any future change of the macro would also need to undergo the same process, so we would essentially lose control of this bit of MoS. — Emil J. 17:57, 18 November 2009 (UTC)
In any case, to answer the original question, there is a Unicode \top ( ⊤ ) so you may use that symbol outside of a PNG (X) if you like. —Werson (talk) 02:58, 19 November 2009 (UTC)

Does anyone have a published style guide dedicated to mathematics handy? I don't have any at present and I am curious to know what they say on this issue. — Carl (CBM · talk) 13:05, 19 November 2009 (UTC)

What is the best way to number equations?

Is there a favored way to number equations? I would think LaTeX supports putting numbers like "(1)", "(2)", etc., aligned on the right side of the page, but I can't find any documentation for it. I have seen multiple methods in articles here, all of them ugly. It would be nice to document the "right" way here and/or on WP:MATH. Thanks in advance; I would love to know how to do this. CosineKitty (talk) 18:30, 20 February 2010 (UTC)

I don't know of a good way to do it here, either. LaTeX does support it, but texvc, which Wikipedia uses, does not. There are several issues. One is that we never say \begin{equation} or anything like that; there's nothing to distinguish any use of <math> from any other, and in particular no way to distinguish which uses should be numbered. Another issue is that math tags are processed individually, not collectively; there is no way for any tag to know where it is relative to other tags, and hence no way to number. I can't imagine this problem ever going away, either. But it's not all bad; I find that rewriting my prose to avoid equation numbers often makes it better. Ozob (talk) 05:25, 21 February 2010 (UTC)
Hmmm... OK. I would settle for manually numbering the equations if I could just get it to look right. But you do have a good point about rewriting the text to avoid numbers. Thank you for taking the time to reply! CosineKitty (talk) 22:53, 21 February 2010 (UTC)
I just found a way to number equations that looks pretty nice. Take a look at BKL singularity. CosineKitty (talk) 02:00, 23 February 2010 (UTC)
And it lets you put a clickable link to the equation in your text which is nice too. I also much prefer templates if available rather than putting own code into the article pages. Dmcq (talk)

Yep, use {{NumBLK}}, {{EquationRef}}, and {{EquationNote}}. Unfortunately, there seems to be no way to have them automatically number the equations. Sławomir Biały (talk) 20:26, 23 February 2010 (UTC)

Thank you for your help. I used this in Mean anomaly, and it looks a lot better now. I think these templates should be documented (or at least linked) from this page (MOS:MATH) and/or from WP:MATH. Does anyone have an opinion on which (or both) of these is the appropriate place to document equation numbering templates? If so, would they have a problem with me adding it in either place? (I have never edited a MOS page before, and I would think it would require some discussion first.) CosineKitty (talk) 22:47, 23 February 2010 (UTC)
Actually the template should have a greater exposure so that they become known and available (in practical terms) to other authors. However when adding them to MOS:MATH it should be explicitly stated that they are optional, since MOS:MATH is often considered as mandatory and we should keep mandatory regulations to a minimum. Adding to WP:MATH looks like a good idea to me. Do we actually have a project page listing all useful templates for math articles?--Kmhkmh (talk) 13:26, 24 February 2010 (UTC)
Now that you explain it, WP:MATH does sound like a better place. I will move the conversation over there. Thanks! CosineKitty (talk) 18:48, 24 February 2010 (UTC)

Source code and pseudocode

This is to follow up the discussion here WT:WPM#Use of Matlab code in articles, and is also based on a change I made here. Would it be useful to add something on the use of source code and pseudocode in mathematical articles. E.g. based on the following points:

  • Source code is allowed is allowed, but
  • consider that not all readers are programmers or familiar with programming languages, so only use it if there is no alternative
  • use either pseudocode or a common language like C
  • always include a description or explanation
  • use syntax highlighting where possible, even on pseudocode. For example the following
<syntaxhighlight lang = "C"> Tn = (1 + n) * n / 2; // triangular number</syntaxhighlighting> 


 Tn = (1 + n) * n / 2; // triangular number

The syntaxhighlight tag seems relatively unknown and undocumented, so this is in part intended to document it. But it's also an attempt to come up with guidelines for use in code, to avoid e.g. the issues raised in the original thread where a relatively obscure programming language was used.--JohnBlackburnewordsdeeds 15:44, 10 February 2010 (UTC)

There needs to be an exception for articles that deal with language in question itself or related topics, i.e. articles about matlab topics can contain matlab code.--Kmhkmh (talk) 15:58, 10 February 2010 (UTC)
I've added another point (the second bullet point) that I think important. In reply to the above this is meant to be for mathematical topics like Simplex and Quaternions and spatial rotation. Articles on computing, with readers either knowledgeable about or interested in programming languages, will probably include source code much more.--JohnBlackburnewordsdeeds 17:17, 10 February 2010 (UTC)
I'm aware of that. However if we formulate a general guideline we should cover such cases as well, simply to avoid that later editors mainly focusing standardizing/beautifying throughout WP might take it the wrong way.--Kmhkmh (talk) 20:40, 10 February 2010 (UTC)
The guidelines are mostly meant for the use of code in mathematics articles. I see that general guidelines on syntax colouring might be helpful, though from what I've seen people writing programming articles are already mostly aware of this feature.
I've expanded the example a bit so it uses more language features and shows more colours, to better show the benefit of the highlighting. It could even be a multiline example to better show e.g. how it might be used to demonstrate an algorithm.--JohnBlackburnewordsdeeds 20:56, 10 February 2010 (UTC)
The guidelines look fine to me. In fact, I would go further and say that only pseudocode examples are allowed, except in language-specific articles and examples that illustrate features of a specific language. For an instance of why this guideline is required, take a look at Koch snowflake, a mathematics article that is being overwhelmed by a series of opaque unsourced implementations in different programming languages which add nothing to the article. Gandalf61 (talk) 09:11, 16 February 2010 (UTC)
In that article's case, the Logo implementation would be the one kept, due to appropriateness, but only if sourced, and only if preceded by a pseudocode implementation. LokiClock (talk) 14:34, 16 February 2010 (UTC)
To me, this omits the main issue regarding source code and pseudocode, which is a content one rather than a style one: either source code or pseudocode is ok, as far as I'm concerned, but redundant source code or pseudocode is not. Each piece of source code or pseudocode in an article should describe a different algorithm, in the most appropriate language to describe that algorithm. What we don't want is a pseudocode description of an algorithm followed by source code implementations of the identical algorithm in six different programming languages. —David Eppstein (talk) 16:01, 16 February 2010 (UTC)
Perhaps it would also be good to specify some minimum usage statistic for multiple algorithms, so that if more than one algorithm is to be given in an article it must be shown that each is common or considered significant. But this discussion line really concerns content bloat, not the original topic. LokiClock (talk) 14:20, 18 February 2010 (UTC)

To be clear, what's the consensus? Pseudocode, Common, or Appropriate languages, and which specifically first or only? Consider WikiProjects we should notice for input. This of course does not concern implementations that serve an encyclopedic purpose beyond being an implementation, as when demonstrating the language and not the code, or when the implementation itself has reason to be covered (e.g. for historical importance). LokiClock (talk) 20:15, 21 February 2010 (UTC)

Pseudocode first &| Appropriate LokiClock (talk) 20:15, 21 February 2010 (UTC)
  • 1. The strongest description of an algorithm is description via source code.
  • 2. All algorithms are computer sci. objects, so every reader should be familiar with programming languages.
  • 3. The most strong and well-known programming language is standard Pascal.
  • 4. C/C++/C# is not good programming language to describe an algorithm: C is not readable and has many special details for implementing.
  • 5. Some pseudocode fragments may be inserted into the listing, for example, mathematical notation for expressions n2 ≤ 10 rather than n^2<=10.
  • 6. A listing has to be written in good programming style and well commented.--Tim32 (talk) 06:35, 23 February 2010 (UTC)
  • 7. Very important: every algorithm description must be complete to be realized in computer program!--Tim32 (talk) 06:45, 23 February 2010 (UTC)
  • PS. Note: the standard Pascal is well defined (in its standards), pseudocode is undefined.--Tim32 (talk) 07:03, 23 February 2010 (UTC)
  • Comment. I agree with the sentiment already expressed that if a specific implementation is used, then in general that implementation should be relevant to the content of the article or the algorithm that it intends to illustrate. I also feel rather strongly that members of the C family (including Java) are quite ill-suited to our purpose as an encyclopedia for reasons already stated, and should be rejected as a standard. While I favor pseudocode if possible, I think that Pascal and its variants are quite close to pseudocode, and have the advantage of being well-defined languages. (Python also strikes me as a good language for exposition.) Obviously more specialized languages, like the ML family, might be more suitable for illustrating algorithms that are naturally expressed in a functional language. Sławomir Biały (talk) 13:13, 23 February 2010 (UTC)
I would disagree with using Pascal, for the same reasons I mentioned C in my first post. C is common, Pascal isn't. Not only is C common but the majority of languages people use today (C, C++, Java, C#, ...) are based on it to a greater or lesser extent: every programmer is familiar with C syntax even if they've never used the language. It's well defined by a standard, or standards though the differences between them are quite small & subtle for backwards compatibility reasons. I'm not too worried about readability as if an editor decides to express an algorithm in source code they've already decided to exclude readers who are not programmers or have no experience of reading source code.
It's clear pseudocode means different things to different people. I was thinking of 'code' like that at Quaternions and spatial rotation#Used methods, i.e. mathematical formulae written with C syntax to show calculation steps. The other sort I'm familiar with is when you write out an algorithm in natural language, for checking before replacing it with the actual implementation. But that's a programming tool, used to streamline the coding process. Here where the intent is to express the algorithm it would be better to take that natural language and edit it into a proper explanation, even if it's more verbose than the code.--JohnBlackburnewordsdeeds 14:03, 23 February 2010 (UTC)
"C is common, Pascal isn't" - it is not correct: C++ is common mistake for today practice, sorry for that. But first of all: which language did you mean: C, C++, or C#? You wrote "Not only is C common but the majority of languages people use today (C, C++, Java, C#, ...)", but C++ is not C; C++ has another philosophy and another set of common bugs! But the comparison “C vs C++” is not the subject of our discussion here. (Please, see the book by Scott Meyers under the title "Effective C++" about C++ problems. Due to the problems, today we have very bad software products and a lot of catastrophic events in the world.) Secondly, here we do not want to select the most distributed language, but we wish to select the most suitable language to describe an algorithm. Niklaus Wirth and others proved that standard Pascal is the most suitable for education and so for understanding. As for me since 1980 I printed about 100 papers in computer sci. journals, and when possible I used Pascal to describe my algorithm, and I never heard from editor or from referee that he was unable to understand Pascal. (Similar statement would be a shame for any editor!) Pascal is common; everybody is able to understand it! Please, read 35 pages only of introduction to Pascal by Wirth to understand standard Pascal -- only one day is necessary for it. Wirth’s books are excellent examples of algorithm descriptions and we should use these examples for Wiki. --Tim32 (talk) 16:03, 23 February 2010 (UTC)
I don't understand Pascal: the last time I looked at it was when it was the language of choice on the Mac, 20+ years ago, but I never actually did anything with it. Since then I've learned and used professionally C, C++, C#, Perl and ActionScript, all syntactically derived from C. I'm not going to learn Pascal to follow code written in it: I've not done it for the MATLAB examples I've come across in e.g. Simplex (I replaced it with an explanation, without ever understanding the code - see e.g. [[Talk:Simplex#Cartesian Coordinates section has major problems#here). I can't argue with Wirth about his claims about Pascal, but for whatever reasons the world outside academia uses C-style syntax even in radically different languages.--JohnBlackburnewordsdeeds 16:42, 23 February 2010 (UTC)
Again, I'm sorry, but (1) what does "C-style syntax" ("in radically different languages") mean? (2) Are you sure that Wiki is "outside academia" area? (Wiki community is academic community.) --Tim32 (talk) 17:08, 23 February 2010 (UTC)
PS And again, only one day is necessary to understand standard Pascal. To understand C++ -- much more!--Tim32 (talk) 17:22, 23 February 2010 (UTC)
PS It is interesting to note: nobody here suggested MIX language, at the same time I am sure everybody here had read Donald Knuth's monograph ;)--Tim32 (talk) 16:17, 23 February 2010 (UTC)
PPS And we all use TeX by Knuth in Wiki (for mathematical expressions) :))--Tim32 (talk) 16:23, 23 February 2010 (UTC)

The argument "C is common, Pascal isn't" is not compelling. Although it is true that C is a more common language than Pascal, Pascal is a very well established language with an intuitive syntax that is fairly close to pseudocode, and doesn't involve a lot of complicated variable declarations, incantations, etc. That argument goes the other way: just because C is more common does not mean that every article should be written just for C programmers. I'm sure that there is a very respectable number of programmers who never work with C, or languages syntactically derived from it, and so some effort must be made to accommodate all of these potential readers. As a sometime reader as well as editor, I often find C code to be full of unnecessary rubbish that detracts from the main point of an algorithm. It might be a suitable language to illustrate some of the inner workings of certain types of data structures, but it most certainly is not a language I would choose with which to describe algorithms. As for Java, I have three words for you: "public static void". Awful nonsense to be putting in an article. Also, I think MIX is a terrible idea in general and should be avoided. Sławomir Biały (talk) 20:17, 23 February 2010 (UTC)

Just for clarification, as my post seems to have been incorrectly lumped into the "turf war" mentioned below, I do not advocate any particular language, and in fact generally favor pseudocode. However, I am strongly opposed to the position that C and its syntactic cousins are the clearest choices for an encyclopedia article because they are the most common. I heartily agree with David's post above and Ozob's below. Sławomir Biały (talk) 16:50, 24 February 2010 (UTC)

I think it's quite clear here that Pascal and C-family languages are not neutral. It is the opinion of the people here who know Pascal that it is easy to read, and of C programmers the same for theirs. If either of these languages is favored over pseudocode, every person writing pseudocode for Wikipedia will have to know Pascal and how to test their program, as well as the algorithm-appropriate language they likely seek to provide in the first place. It biases the accessibility of the encyclopedia towards Pascal programmers, both in reading and editing. Pseudocode gets to the point of the procedure. Pseudocode is neutral. So let's not turn this into a language fight. The common language factor is not an attempt to establish a lingua franca. It is an illustration of how the pseudocode might be made concrete, expressed in rigid terms of a language. LokiClock (talk) 21:48, 23 February 2010 (UTC)

I seem to recall reading somewhere that wikipedia did not have a fixed rule as to which language or flavour of pseudo-code to use in articles, that decision being left to individual article authors. I think that this is a good policy to follow, purely to avoid a protracted argument over languages.
BTW my own favourite is Structured English which I managed to introduce to a class programming newbies with ease. --Salix (talk): 22:00, 23 February 2010 (UTC)
Comment: Imperative languages like C are and always have been a poor choice for clearly expressing mathematical function evaluation. If it's what you're used to there's little sense in learning a declarative language just to get your work done, but function evaluation is what declarative, functional languages are designed for - hence the name. Functional syntax is much closer to how a non-programmer competent with mathematics would naturally go about solving a problem. MATLAB, Python, Haskell and so on would be better choices for many articles. Actually, if there's a commonly accepted meta-language syntax of some sort that's used in the field of computational linguistics, that'd be my preferred choice. That'd require an expert in it to do the work, though. Sojourner001 (talk) 22:14, 23 February 2010 (UTC)

It doesn't seem like there's any consensus to pick a single language. Certainly there is no consensus for either Pascal or for C or its derivatives. Some of the arguments given above apply more widely: For instance, if we standardize on a language, then we exclude everyone who isn't competent in that language. Even languages like Pascal and Python that are intended to be easily read will not make sense to someone who has never seen them before, and we can't ask our readers to sit down for a few hours and figure out how the languages are written before they come back and read our articles.

So, that leaves pseudocode. It's hard to write good pseudocode; after all, good pseudocode is a well-commented program with all the statements taken out. I don't think it's any easier to write legible, encyclopedic code in an actual programming language, because you then have to adapt yourself to the language's idiosyncrasies. If you can write a good, legible algorithm in a real programming language, then you can certainly distill it down to pseudocode. But it's very tempting to leave all the hard details out of pseudocode so that the "algorithm" isn't fully specified. That leaves us with broken articles, a very undesirable situation.

All of the above has been rather abstract. Let's get concrete. Consider a real classic, the recursive computation of the factorial. Here it is in C:

int factorial(int n) {
    if (n == 0)
        return 1;
        return n * factorial(n - 1);

Notice that to understand this program, the reader needs to know what int stands for, that the int preceding factorial is a return type and that int n is a function argument, that curly braces are for grouping, that == stands for equality testing, and that return means output its argument. None of these are too difficult, but without them, the reader might be a little lost.

I've never seriously looked at Pascal, but I think this should work: (UPDATE: Better thanks to EmilJ; see below.)

function fact(n: integer): integer;
    if n = 0 then
        fact := 1
        fact := n * fact(n - 1)

In order to understand this, the reader needs to know about := and needs to figure out the syntax for function arguments and the function's return type. He will probably think the semicolons are typos. (UPDATE: See JohnBlackburne's reply below.)

We could also write the program in Perl:

sub factorial ($) {
    my $n = shift;

    if ($n == 0) {
        return 1;
    } else {
        return $n * factorial($n - 1);

This is probably even more confusing to the reader. What's sub? What do all the $s mean? What's shift?

We could try Python:

def factorial(n):
    if n == 0:
        return 1
        return n * factorial(n - 1)

This is better: You still need to figure out return and ==, which aren't too bad, and you may wonder about def, but at least factorial(n) looks like math notation.

Or we could pay homage to that system we use so much and write:

 \f@ctorial #1%
  \multiply\x by #1%
  \n=#1\advance\n by -1

There are obvious problems with expecting the uninitiated to read this. (UPDATE: See EmilJ's reply below.)

On the Haskell page, I found:

factorial 0 = 1
factorial n = n * factorial (n - 1)

which is as near to pure math as I think we can get. But this is sort of cheating, because Haskell is designed so that these kinds of things are easy. Even the type declaration, factorial :: Integer -> Integer, looks nice. The downside of this is that this definition is useless outside of a language which does pattern matching on its arguments like Haskell. It only works in Haskell, and there is no way to adapt it to any of the other languages.

There are corner cases, like COMEFROM, where no traditional programming language suitably expresses the underlying concept.

Which of these, if any, do people think would work best? My own vote is that we not standardize on anything. There should be a requirement that all code is clear, well-document, and encyclopedic. I think both pseudocode and actual programming languages can satisfy that, depending on the situation. We shouldn't limit ourselves; we should use whatever communicates best. Ozob (talk) 05:05, 24 February 2010 (UTC)

  • "Pascal is a very well established language with an intuitive syntax that is fairly close to pseudocode, and doesn't involve a lot of complicated variable declarations, incantations, etc."
(Sławomir Biały)
Status := Status + [StickyFlag];
Status := Status - [StickyFlag];
Status |= StickyFlag;
Status &= ~StickyFlag;
(Comparison of Pascal and C#Bitwise_operations)

const char * const authorName = "Scott Meyers"
(Scott Meyers, Effective C++, Chapter 1, rule 1.)
"First, since C++ includes C as a subset, it inherits many of the criticisms leveled at C. For its large feature set, it is criticized as being "bloated", over-complicated, and difficult to fully master." "...C++ is more complex than some other programming languages..."
Criticism of C++
  • Bad pseudocode example:
 L:=0; R:=N + 1;
   while (P:=(R - L)/2) > 0 do      %Integer division.
    case sign(A[P:=P + L].Key - X)
     -1:L:=P;          %A[P].Key < X.
      0:Return(P);     %A[P].Key = X.
     +1:R:=P;          %X < A[P].Key.
"case sign(A[P:=P + L].Key - X) -- looks like too original to be understanded by any every reader!"
(Talk:Binary search algorithm#The_"Design"_section)
  • Conclusion.
1) C++ is over-complicated. It is very easy to write bad code (for algorithm description) in C.
2) A pseudocode may be unclear as well.
3) Pascal or Pascal-like pseudocode may be recommended for common cases.
4) Of course any good sources in C/C++ are welcome. For example, see: Robert Sedgewick, "Algorithms in C", Addison-Wesley.--Tim32 (talk) 08:22, 24 February 2010 (UTC)

This discussion is rapidly headed nowhere. Recommending some particular programming language (as Tim32 is doing for Pascal above) is completely inappropriate for the manual of style. We can make general suggestions (pseudocode preferred to actual code, proprietary languages to be avoided) but I don't think we should go much beyond that, and it's highly non-constructive to repeat here all the old arguments about which programming language is best that have been gone over before countless times on countless internet forums. —David Eppstein (talk) 08:31, 24 February 2010 (UTC)

Yes. Let's please get this back on track. However, the previous criticisms, particularly in Ozob's post, are still useful tips for writing good pseudocode; it can be easy to forget sometimes what parts of a language, in which you are fluent, need explaining. LokiClock (talk) 10:14, 24 February 2010 (UTC)

I am disagreed with Eppstein's criticisms of this discussion. Of course, we unable to select the best language, but we have to recommend more confortable languages to describe an algorithm. As well as we have to note problems of pseudocode usage (see above). And also, in the result of this discussion we can agreed that good sources in every language or in pseudocode are welcome.--Tim32 (talk) 11:02, 24 February 2010 (UTC)

I agree With David's criticism. The discussion could use some common sense and stick to what really matters to readers and authors instead of turning into turf war over specific languages & notations and "the best mandatory solution for all".--Kmhkmh (talk) 13:30, 24 February 2010 (UTC)

I do not understand, where Kmhkmh did find a war? Dear Kmhkmh, did you read (Talk:Binary search algorithm), for example? Is it the war? Do you think that a lot of many discussions (which method to describe an algorithm should be selected) in different talk pages is better than this one here? And would you be so kind, Sir Kmhkmh, as to reread my post?: I wrote "recommend more comfortable languages", but you replaced this my offer with "the best mandatory solution for all"! Do you feel any difference? --Tim32 (talk) 15:59, 24 February 2010 (UTC)

I am definitely in favor of only using pseudocode unless in a language context. With pseudocode if there is something which is not obvious one can rephrase it to be understood better. With a computer language the language constrains how things may be said and the restrictions are rather arbitrary. Editing for improved understanding requires knowledge of the language. Wikipedia is for transferring the idea not an implementation. Dmcq (talk) 17:57, 24 February 2010 (UTC)
+1--Kmhkmh (talk) 19:07, 24 February 2010 (UTC)
I agree that in the article proper there should only be pseudocode. However, there is nothing stopping us from making subpages under the article with vetted code examples. -- Avi (talk) 18:00, 24 February 2010 (UTC)
I disagree: I think there is WP:NOT stopping us. Among the other things Wikipedia is not, it's also not a code repository. Any "subpage under the article" is an article itself and must meet our normal standards for inclusion as an article in Wikipedia. In particular, an article whose only purpose is to provide an original code implementation of an algorithm described elsewhere is not an acceptable Wikipedia article. —David Eppstein (talk) 21:30, 24 February 2010 (UTC)

Make sure to bold your votes, if you're making them! Otherwise it can be difficult to tally. LokiClock (talk) 00:14, 25 February 2010 (UTC)

"I disagree: I think there is WP:NOT stopping us. Among the other things Wikipedia is not, it's also not a code repository" -- I disagree: perhaps, Wiki is also not an algorithm repository? ;) --Tim32 (talk) 08:50, 25 February 2010 (UTC)

Copyright status of code

Another issue that we need to beware of is the copyright status of code. All the code that appears in a book or journal has a copyright that we are bound to respect, both by Wikipedia policy and the law. We can't reproduce Wirth's implementation of binary search because the book we're taking it from is still under copyright. Neither can we reproduce Knuth's implementation. Nor anyone else's. In fact, I can think of only one way to reproduce an implementation and not violate copyright, which is when the implementation has been released freely: For example, if we take our binary search from an open source library whose license is compatible with CC-BY-SA 3.0 and the GFDL. This is a pretty tough spot, because I'm sure that finding that sort of reference will be difficult for a lot of algorithms. But we are in violation of policy if we know that our reference is a copyright violation or is unsourceable.

Given that, perhaps it would be better to mandate pseudocode. Since pseudocode is English-language text, we don't have to reproduce it character-for-character from a source. Instead we can paraphrase the source, and not only is it irrelevant what language the source is in, but we would not violate copyright and also have an inline citation. (Of course, we need exceptions to this, for example because of articles on individual programming languages. I don't know how to phrase that well.) Ozob (talk) 04:19, 25 February 2010 (UTC)

Are you sure about that? We cannot cut & paste the source code example in a book, but you quote snippets and or simply write that piece of code yourself (different variable names and such). There is no need for an identical letter by letter reproduction - not for regular text, not pseudocode and not real code. In other words you can treat all 3 cases the same and imho there should be no copyright issue providing the author works properly.--Kmhkmh (talk) 11:59, 25 February 2010 (UTC)
Well, perhaps I was wrong to say "character-for-character" above. If you changed all the variable names then you would, if I understand the legal jargon correctly, have created a derived work. Derived works are still subject to copyright restrictions. Put another way, the problem is that if one makes only trivial changes to the code, then it is still the property of the original author, whereas if one makes non-trivial changes to the code, then the source the code was originally from can no longer be used for inline citations. It may be permissible to quote snippets as fair use (this is the same justification that we have for quoting other non-fiction books that are still in copyright), and the book may even explicitly permit quoting snippets in some contexts. Because of that it may be permissible to quote a whole algorithm. However, we would have to worry whether we are, across all of Wikipedia, quoting too much from that one book; we couldn't take a single book on algorithms and use it as a reference for every article about algorithms, nor could we take a single book on a specialized type of algorithm and use it as a reference for every article on that type of algorithm. (The exception, of course, being books whose algorithms are presented in pseudocode, because we can paraphrase those.) The easiest solution I can see is to prefer pseudocode whenever possible. Ozob (talk) 23:20, 25 February 2010 (UTC)
I still don't see a difference between pseudo code and source code here, i.e. the issue is the same for both. Essentially I agree with JohnBlackburne's assessment below. Using copyright as an argument for pseudo code and against source code, seems to be as a rather artificial construction that doesn't hold in reality.--Kmhkmh (talk) 12:01, 26 February 2010 (UTC)
The copyright concerns are the same as any other WP text, as are the general prohibitions against close paraphrasing. So an editor should not just copy and paste code, much as they should not copy and paste text, unless it's attributed and relevant. Which I can't imagine it will be in a maths article, so maybe just editors should never copy and paste code, they should always write it from scratch. If they don't understand it well enough to do so they should not be inserting it.
The only other concern might be if an algorithm that is covered by some other law: some algorithms are patented, others are outlawed by the DMCA, in which case it cannot even be written from scratch. I don't know what WPs policy is here, but I imagine it comes up so rarely and is so specific to particular instances that it's dealt with on a case by case basis. I.e. there's probably no need to worry about it.--JohnBlackburnewordsdeeds 00:24, 26 February 2010 (UTC)
No problem: please, see Wikipedia:Citing sources--Tim32 (talk) 08:32, 26 February 2010 (UTC)
My understanding is that it is implementations of an algorithm which may be covered by a patent, not the description of the algorithm. The concerns that are applicable are copyright, intellectual property, and security. Copyright is covered above pretty well. Intellectual property and security concerns cannot be ignored just because an algorithm has 'gone wild' in the public. If there are good citations in a book or suchlike though the wildness has probably got to the stage where the concerns are moot. Dmcq (talk) 12:10, 26 February 2010 (UTC)

So, after looking at our articles on software patents, I can confidently say that this area of patent law is in flux right now as we speak, and nothing is certain. See In re Bilski for evidence of this. It appears (to my unlawerly and untrained eyes) that one cannot now patent an algorithm or a mathematical process; I don't think the RSA patent would have been granted under the present rules. (And, curiously enough, the RSA article says that RSA was invented independently by Clifford Cocks, who was doing classified cryptography research in Britain. If that had been publicly known, RSA wouldn't have been able to get a patent at all.)

According to U.S. copyright law, the definition of a copyrightable work is given in 17 USC §102(b) [13], which doesn't mention computer code explicitly. The principle of analytic dissection says that code is a copyright violation if, after removing all those parts which cannot be subject to copyright protection, what is left is substantially similar. My argument above was that all implementations of a particular algorithm would have to be substantially similar (by definition); but because an idea is uncopyrightable, what must be substantially similar is what you might call "the code modulo the idea of the algorithm". Thus, for example, if a block of code may be a copyright violation if it uses the same variable names and the same comments as another piece of code implementing the same algorithm; or if, every time there is some flexibility as to what order certain operations may be performed in, the two blocks of code being compared always perform the operations in the same order.

My conclusion, therefore, is that I think we're safe as long as we don't copy character-for-character. Of course, IANAL (but I play one on Wikipedia). Ozob (talk) 17:23, 27 February 2010 (UTC)

Comments on programming language examples above

I, Ozob, am reorganizing the comments on the programming language examples above, because the interleaved comments have made it impossible to tell who wrote what without having been here.

Responding to my C language example, JohnBlackburne wrote:

trivially the following is better (no need to know what == is and it won't do interesting to debug things with non-positive inputs). It's a bad example though: it's more an example of how recursion can be used. If I came across it in a code review I would rip it out and replace it with a simple loop as it's horribly inefficient and also unsafe, potentially causing stack overflows even with sensible inputs.--JohnBlackburnewordsdeeds 17:05, 24 February 2010 (UTC)
int factorial(int n) {
    if (n > 1)
        return n * factorial(n - 1);
        return 1;
I, Ozob, am now replying: The new code is incorrect in that it will return the wrong value for n less than zero. Of course, the old code is incorrect in that, as you say, it will cause a stack overflow for n less than zero. I also agree that nobody should use either one in production code. If it were up to me, I think I'd use a lookup table; there aren't that many valid inputs you can give before overflowing. Ozob (talk) 00:50, 25 February 2010 (UTC)

Responding to my Pascal example above, EmilJ wrote:

It's not terribly important, but the brackets around n = 0 are superfluous, and so is the semicolon on the last but one line.—Emil J. 13:08, 24 February 2010 (UTC)
I, Ozob, am now replying: I see. I have modified my original post to remove these. Ozob (talk) 00:50, 25 February 2010 (UTC)

Responding to my TeX example above, EmilJ wrote:

(Sorry for intruding in the middle, but I couldn't figure out who wrote this post and where does it end.) I doubt that anyone would advocate to use TeX as the standard language on Wiki, but why is the example deliberately obfuscated with all those @'s? The following would do just fine:
      \multiply \x \n
      \advance \n -1
(In other situations it would be also nice to put an \expandafter on the last but one line to make it tail-recursive, but it's pointless here since the factorial results in an arithmetical overflow anyway for n>12.)—Emil J. 13:08, 24 February 2010 (UTC)
I, Ozob, am now replying: The @'s make it so that you don't pollute the global namespace. If someone wanted to make a table of factorials, they might want a \factorial function to perform each computation and a \dofactorial macro to make all the rows of the table. They would be surprised to find that you've already defined \dofactorial. \f@ctorial avoids this. In principle, you can still get this sort of bad interaction, but between packages or between a package and LaTeX or plain TeX itself. But if you prefix everything by something like mypkg@@ then you avoid even that.
In other respects, though, your code is better. I'm not a particularly good TeX programmer, and I cringe at \expandafter. Ozob (talk) 00:50, 25 February 2010 (UTC)
(Now we are really getting off-topic.) Polluting namespace is a problem completely tangential to explaining snippets of code in a Wikipedia article, the reader is supposed to take care of such issues themselves if they decide to actually use the code. We are not writing a package. (Note by the way that \n and \x are much more likely to cause conflicts than the \dofactorial.) Furthermore, despite it being established as a sort of tradition, there are plenty of less convoluted ways of simulating namespaces in TeX macro names than using these @ signs (e.g., \mypkgMacroname). None of them is guaranteed to work, because they are not real namespaces: there is nothing stopping anybody to define a \f@ctorial macro conflicting with yours. The @ signs do not avoid anything, it's just a matter of reducing the likelihood that someone else also uses the same name. If \dofactorial seems too obvious, you can substitute it with \wikipediainternalfactorial, but there is no need to change \catcode's.—Emil J. 11:57, 25 February 2010 (UTC)

Where is the exact disagreement now?

The discussions seems to get sidetracked somewhat. Originally we started with something like:

For the description algorithms pseudo code is preferable, but code in a common/popular languages is permissible. The decision for a particular article is in doubt at the discretion of its author. The use of the syntaxhighlight tag is recommended.

Can't we all more or less agree on that?--Kmhkmh (talk) 12:08, 25 February 2010 (UTC)

Support. But the grammar in your text needs to be fixed. —David

Eppstein (talk) 16:08, 25 February 2010 (UTC)

Actually the line above was not meant as a literal text suggestion, but just to focus the discussion on an agreeable content, since we got somewhat sidetracked above.--Kmhkmh (talk) 19:41, 25 February 2010 (UTC)
I originally proposed in particular we recommend C or something like it, but I see now there's no consensus for that or any language. Because of this I would change the above to make it clear that code is by far the worst choice. But also I would add that in a mathematics article that code or pseudocode is not a substitute for a proper mathematical description, which should always be there. Not only for readers without access to or knowledge of programming tools, but for other editors to improve or replace the code. So something like
  • Source code is allowed but:
  • It should not be used instead a clear mathematical description, which should always be present, and may be all that's needed
  • Pseudocode is much better than source code in a particular language which is likely only known by a subset of readers
  • Steer clear of powerful but obscure languages and language features which will only make the algorithm more difficult to follow
  • use syntax highlighting ...
I.e. not recommending any language, just a collection of things to consider with the emphasis on only using source if it really helps the article.--JohnBlackburnewordsdeeds 16:29, 25 February 2010 (UTC)
sounds fine to me--Kmhkmh (talk) 20:04, 25 February 2010 (UTC)
Support (Blackburne: Hope you don't mind that I redo your bullet indentations) – LokiClock (talk) 01:12, 4 March 2010 (UTC)

There's no consensus for "Pseudocode is much better than source code in a particular language" etc. According to these rules we will have to rewrite almost all existed articles about algorithms -- it would be impossible absurd. --Tim32 (talk) 08:47, 26 February 2010 (UTC)

Well there seems to be a clear preference for pseudo code at least (this is also not the first discussion of that sort). Nobody suggested to rewrite almost all the articles about algorithms containing nor do those rules imply that. The first line clearly states: source code is allowed. In addition this discussion is only about algorithms in math articles and not algorithms in general.--Kmhkmh (talk) 12:05, 26 February 2010 (UTC)
But the 3rd line states: Pseudocode is much better than source code. What is "source code"? If for example, following fragment from Binary search algorithm is Pascal-like pseudocode:
  min := 1;
  max := N; {array size: var A : array [1..N] of integer}
    mid := (min + max) div 2;
    if x > A[mid] then
      min := mid + 1
      max := mid - 1;
  until (A[mid] = x) or (min > max);
(Niklaus Wirth: Algorithms + Data Structures = Programs. Prentice-Hall, 1975),
then the consensus may be possible for the rule Pascal-like pseudocode (or well-designed C-like pseudocode) is much better than undefined pseudocode. --Tim32 (talk) 16:27, 26 February 2010 (UTC)
PS BTW, Is Binary search algorithm math article? --Tim32 (talk) 16:33, 26 February 2010 (UTC)
PPS Please see above "Bad pseudocode example" from talk page of Binary search algorithm. (the case of undefined pseudocode) --Tim32 (talk) 16:37, 26 February 2010 (UTC)
That to me is a good example of why source code, or pseudocode that is essentially source code, should be discouraged: I have to stare at it for a non-trivial amount of time to see what it's doing, as it's a completely alien language to me. Other readers would have a similar reaction to C-like samples, while still others will be put off by any use of programming language elements.
Non-source based pseudocode might be something like
 Given a sorted list of numbers, to locate a value x in that list
  Find the midpoint of the list, halfway between the first and last elements
  Compare this to x
   If it is less than x then x must lie in the half of the list above the midpoint, 
   Otherwise it must be in the half of the list below the midpoint, 
  Repeat with the half-list x lies in as the new list
Continue until the midpoint equals x or the list has no length
Not tied to any particular language, so it could be implemented in any or carried out by hand. Perhaps a bad example as it is more a computing topic than a maths one, and readers of computing articles are likely to know at least some programming, but that's what I'm thinking of. --JohnBlackburnewordsdeeds 17:04, 26 February 2010 (UTC)

@Tim32: I don't quite get what you are trying to argue. That you can write bad pseudocode? Obviously yes. That people should not write bad pseudocode?- Obviously yes again. I mean essentially that's just saying people should not write bad articles - of course they shouldn't. I don't really see there any relation in the pseudo code versus source code issue. Pseudo code only means that you don't have to stick to formal requirements of a particular programming language to describe an algorithm. Meaning you might use indices instead of arrays, that you can use various math operations or functions, without bothering about the exact name or whether it exists in some standard library. The primary intent of such an article is, that people understand how the algorithm works or as Johns has put it, that you can perform by hand or with pen and paper. The primary intent is not to be a substitute for numerical recipes or teach programming conventions/implementations. Having said that, personally I don't like John's example for the binary search better than the pascal pseudo code. Mainly because it is too close to a plain description as regular text of the article. In such a scenario I'd rather go with a text description of the algorithm and then provide the pseudo pascal code. As far as formulation for the guideline are concerned, I'd suggest to remove the "much better" by something less stronger like "preferable". Keep in mind we are looking for guideline that allows a large variety of authors to work comfortably and produce content being beneficial to readers. We are not looking for guideline reflecting what each of us individually might consider the optimal presentation. --Kmhkmh (talk) 17:49, 26 February 2010 (UTC)

The problem with Pascal-like pseudocode is the same as with any other language specific example: it is only easily understandable if you know the language. Pascal in particular is little used outside academia and looks little like other languages, so has a particularly small potential audience. But the same is true of any language, hence my attempt to steer editors away from writing in any particular language.--JohnBlackburnewordsdeeds 18:30, 26 February 2010 (UTC)
Pascal is not that widespread outside academia, but basically any programmer can read such code snippets. In fact math books do use them as well (in particular textbooks not numerical math). And again i don't quite agree with your premise of steering (or ultimately even forcing) editors in a particular direction. In doubt editors should be allowed to pick whatever they want, as long as it is common use and somewhat reasonable. For that matter many numerical math textbooks use pascal or algol like notations of algorithms, hence so can editors in here (for math articles).--Kmhkmh (talk) 19:12, 26 February 2010 (UTC)
  • Kmhkmh wrote: “Tim32: I don't quite get what you are trying to argue. That you can write bad pseudocode?” – No, I’m not author of that bad pseudocode example. Please, see Talk:Binary search algorithm#The_"Design"_section for more info. JohnBlackburne wrote: “Find the midpoint of the list, halfway between the first and last elements” -- here he described the formula

Any formula may be described via such manner by natural language. For example, JohnBlackburne may try to describe FFT formula:

But we have special mathematical notation (formal language) for such case. Similar formal language is strong defined pseudocode based on suitable programming language (Pascal, C, MIX, etc.). These formal languages (mathematical notation and defined pseudocode) are preferable in non-trivial cases (FFT, for example). Kmhkmh wrote: “Meaning you might use indices instead of arrays, that you can use various math operations or functions, without bothering about the exact name or whether it exists in some standard library.“ Yes, it is right: you can write in pseudocode fragment the expression:

instead of

(x[1]+x[2]) /2

but defined statements (if-then-else, case, for-loop, while-loop, repeat-loop etc.) should be used from particular programming language. Oherwise we will have “case sign(A[P:=P + L].Key - X)” which “looks like too original to be understanded by every reader”! Standard Pascal is (1) strong defined programming language, (2) very simple language. As Kmhkmh wrote: “basically any programmer can read such code snippets”. C/C++ obviously may be used, too. But C++ is over-complicated (See Criticism of C++), so editor of an article has to spend additional efforts to provide C-like pseudocode readability. Fragments like

const char * const authorName = "Scott Meyers"

should be rejected. If some reader does not know modern mathematical notation or set theory or basical programming principles then it is problem of this reader. We need modern mathematical notation and set theory for mathematical articles, as well as we need strong defined pseudocode to describe algorithms in computer sci. articles.--Tim32 (talk) 09:12, 27 February 2010 (UTC)

This discussion keeps coming back to how to write pseudocode, and other unrelated issues. For the last time, that is not the topic of discussion. If you want to seek to define good and allowable pseudocode, raise a discussion elsewhere. Let's assume for the purposes of this discussion that pseudocode means readable pseudocode that isn't biased towards one language. Judging readability or biasing of pseudocode is a tangent topic of discussion. Then my point of view is that using a particular language is not as accessible as such pseudocode, but more accessible than no implementation information at all. Pseudocode is a common language already, so an additional language would in most cases be redundant. It is on this logic that I am basing my opinion that pseudocode should be given with priority, and an appropriate language should be allowed as well. LokiClock (talk) 02:31, 3 March 2010 (UTC)

  • "an appropriate language should be allowed as well" -ok, but the current example:
  primes = sieve [2..]
  sieve (p : xs) = p : sieve [x | x <- xs, x `mod` p > 0]

is not readable! Also the "common language already" (Pseudocode) from Sieve of Eratosthenes is:

  1. Create a list of consecutive integers from two to n: (2, 3, 4, ..., n),
  2. Initially, let p equal 2, the first prime number,
  3. While enumerating all multiples of p starting from p2, strike them off from the original list,
  4. Find the first number remaining on the list after p (it's the next prime); let p equal this number,
  5. Repeat steps 3 and 4 until p2 is greater than n.
  6. All the remaining numbers in the list are prime.

where step 5 looks like:

if p^2<=n then goto 3

What about structured programming without goto? It was introduced for readability! Here you try to return to Fortran-4. Another hard example for such pseudocode is Floyd–Warshall algorithm. But more sophisticated tasks are real as well. --Tim32 (talk) 19:09, 5 March 2010 (UTC)

I added the Haskell. It was not meant to be a suggestion of what to use, as I made clear in the footnote. I thought a few days a go it needs an example, but didn't want to add my C one above as I thought some editors might not like it, and didn't want to add any Pascal for the reasons given above, so was on the look out for something very obscure. It's compact and one where the benefits of syntax colouring are obvious, but is a real example and interesting – if you're interested in obscure programming languages. --JohnBlackburnewordsdeeds 21:53, 5 March 2010 (UTC)
That's why I originally argued that pseudocode should be required before an appropriate language, because the benefit to begin with is that with an appropriate language, it will be able to express the algorithm much more succinctly through it's own peculiarity (and therefore lack of common readability). ᛭ LokiClock (talk) 08:30, 6 March 2010 (UTC)
  • Anyhow, to be readable non-trivial code or pseudocode should be structured (see, structured programming) and goto should not be used. --Tim32 (talk) 10:52, 6 March 2010 (UTC)
This is an encyclopedic project with a rather heterogenous set of authors and not a programming 101 class, where some instructor might push his favoured programming style. That aside is "goto"-issue is to some degree a myth. Using "goto" in the example above is just a loop, i.e. essentially not different from while/,repeat..until or similar. The only real issue with "goto" is the so called Spaghetti code, i.e. if you use it for jumping all over the place. But if you essentially use to emulate/represent a common structural loop, there's hardly any issue with it at all.--Kmhkmh (talk) 11:38, 6 March 2010 (UTC)
Yes. Like a language fight, an attempt to standardize the programming discipline of us editors is a Mac vs. PC argument. ᛭ LokiClock (talk) 12:10, 6 March 2010 (UTC)
  • Very strange reasons, today the majority of modern programming languages (modern Fortrans, Pascal, C/C++, modern Basics etc) are based on structured programming conceptions: not only "if, for, while, repeat", but also "begin, end" (or {,} etc.). And the majority of modern books with algorithms descriptions and other sources (journal articles, Internet resources etc.) are based on structured programming as well. The fact is that today every wiki article has own original style for algorithm description and another article has different style. In discussed project we want to define common wiki standards for mathematical articles, so we have to recommend style standard for computer sci. wiki articles with algorithm description. The current stage of this section in the project is not good, this section is incomplete. In the result similar discussions will take place again and again in talk pages of computer sci. articles. --Tim32 (talk) 08:43, 7 March 2010 (UTC)

Let me recompose my view

  • Firstly, an algorithm's implementation in an appropriate or common language should not preclude its implementation in pseudocode, and in turn a pseudocode implementation should not preclude a sound explanation of the algorithm.
  • Secondly, implementations in proprietary languages should not be allowed.

The first to define guidelines for the ideal content of the article, without condemning articles that do not already conform. The second to keep the encyclopedia free, both in the monetary sense, in the case of languages without free resources necessary for usage, and in the sense of independence, in that the languages rely upon the proprietor to maintain the resources required to make use of the information, making the content depending upon it unstable. ᛭ LokiClock (talk) 05:47, 18 March 2010 (UTC)

While I agree with your first argument, I can't follow you with the second. Your argument concerning the "proprietor" makes no sense to me, not to mention that most languages in question do not have a particular proprietor to begin with. I'd rather regard any version (pseudocode or a common programming language) wich is common in literature as permissible in WP in doubt. The only real harm to WP is done, if we have editors constantly bickering about such things and forcing other editors to do it "their way", that's a recipe for losing authors and creating a bad climate. In project such as WP you have to accept that articles will not meet your personal expectation of an optimal article or style and as long as they fulfill certain minimal standards that's something people simply have to live with. From that perspective pseudocode and common languages are both ecceptable and any attempt to "outlaw" either is imho very misguided.--Kmhkmh (talk) 11:37, 18 March 2010 (UTC)
The very issue that prompted this discussion is the use of MATLAB, a proprietary language which must be paid for to be used, in the article. This is not a matter of trying to force someone's way of doing things on someone. Also, I meant the accessibility of the information is made unstable. As soon as the proprietor ceases to maintain their code, the information becomes progressively useless. It's an infrastructure issue. ᛭ LokiClock (talk) 09:50, 19 March 2010 (UTC)
Since much of the later discussion was about pseudocode versus pascal/modula/java/C/lisp/haskel and alike, I apparently misread your meaning of "proprietary software". As far as keeping matlab codes out of algorithm descriptions I tend to agree. However the issue with potential uselessness over time is not really a question of propriety or not, but more the popularity/spread of the software. It is true that the proprietary software such as matlab/maple/mathematica might fade away with their associated companies. However the same can happen with open source or free software, when they stop being actively maintained/extended. I'd be similarly skeptical towards using Octave or Maxima to notate algoritms.--Kmhkmh (talk) 14:51, 19 March 2010 (UTC)
Ah, I see. You can't maintain backwards compatibility forever, so at some point, no matter how popular the software, you'll have to buy an old OS and/or computer system to run the software. With an open source project, on the other hand, the resources for recovering the build environment will be available, no matter whether the project is abandoned. A dead protocol is much more helpful than a dead and gone protocol. ᛭ LokiClock (talk) 15:14, 19 March 2010 (UTC)
I agree, however that is mostly a theoretical possibility that doesn't really concern the (average) WP reader of the article. He is either somewhat likely to make use of the code/be able to read it, because it is common/widespread language (proprietary or not) or he isn't. The fact that an open source system could be revived/reused doesn't really concern him in most cases.--Kmhkmh (talk) 16:07, 19 March 2010 (UTC)
It seems like I'm making an existential argument, because the point is that utilization is possible in even the worst case scenario, but the same factors make another difference because the language is more likely to remain accessible long past its initial popularity by way of independent interest. We have a window as great as the lifetime of the information for noticing that the language is no longer popular and developing a substitute, compared to the lifetime of the software and hardware compatible with the final release. If you still disagree, a more conservative prohibition on languages without free (in both senses) usage will still address the original concern. Otherwise, this is off the subject of my second view and back into the first. Of course commonness is beneficial, but you have to make a tradeoff, in most cases, when selecting a language appropriate for the algorithm. Assuming there's pseudocode and a good explanation of the algorithm, a common language implementation is more or less icing on the cake. But without those things, an appropriate language does not constitute adequate coverage of the algorithm's implementation, whence the first statement. So I personally would not object to an Octave implementation, but including only that is just better than no information on the algorithm at all, and both an appropriate and common language implementation again only just better. ᛭ LokiClock (talk) 16:45, 19 March 2010 (UTC)

Technical problem for pseudocode syntax highlighting

For Pascal source:

if p^2<n then goto 3

better Pascal-like pseudocode would be:

if p2<n then goto 3

but there is no “exception” tag to insert math formula into source code. We need such tag to write readable pseudocode!--Tim32 (talk) 09:03, 7 March 2010 (UTC)

HTML or CSS formatting I agree with, but not for LaTeX. The former two cover ubiquitous, linear mathematical conventions such as sub/superscripts, but once you get into the freedoms of LaTeX, such as dividend-vinculum-divisor notation, you're leaving visual sugar territory for indiscrete mathematical concepts (that is, if you need LaTeX, it's not likely simple enough for a computer to parse), and eliminating the syntactic structuring of an average computer language that separates it from mathematical notation. ᛭ LokiClock (talk) 08:24, 15 March 2010 (UTC)
But pseudocode is not for a computer to parse, it is for reading by man only!--Tim32 (talk) 09:11, 16 March 2010 (UTC)
If you find pseudocode (or source code) unreadable then don't use it. The guideline is not encouraging you to use pseudocode, it was added as pseudocode is already used in many mathematics articles, to suggest some guidelines so it is used and presented as well as possible. I would say an ideal mathematics article has no pseudocode as there will always be readers who have little or no programming experience and will skip straight over it, and almost always an algorithm can be better expressed in some other way, using e.g. text and LaTeX formatted formulae. --JohnBlackburnewordsdeeds 11:27, 16 March 2010 (UTC)
Ideal computer sci. article about non-trivial algorithm should use pseudocode! The majority of computer sci. books and journals use pseudocode and so we have to use pseudocode as well. Otherwise it would be original research. Sorry, colleagues, but today every mathematican must know programming languages. --Tim32 (talk) 10:16, 17 March 2010 (UTC)
Not so: I did a degree in mathematics which involved no computing - it was an optional module which I did not do. I taught myself how to program around a formal maths education. At a less advanced level maths courses generally involve no computing, and that is the level most articles should be written for. And this is the MOS for maths not computer-science. Mathematics texts generally avoid source code: they give the formulae then use worked examples and exercises.--JohnBlackburnewordsdeeds 10:32, 17 March 2010 (UTC)
Did you the degree today?--Tim32 (talk) 10:40, 17 March 2010 (UTC)
I know someone who got a math PhD about a year ago who has zero programming experience. He doesn't even know what the XOR operator is. Pure (as opposed to applied) mathematicians almost never program. Ozob (talk) 11:00, 17 March 2010 (UTC)
Perhaps, somebody did a degree in mathematics which involved no set theory. And so, today he says: “mathematical articles generally avoid set theory, do not use it whenever possible.” I think it would be absurd reason. If any university does not involve programming courses then this does not mean that we should take this strange fact into account. I’m sure that if a person does not know what Boolean functions (and, or, xor etc.) are, then he is unable to write good article about an algorithm!--Tim32 (talk) 11:13, 17 March 2010 (UTC)
PS Vladimir Arnold wrote that even in USA he observed some students who had written “1/2+1/3=(1+1)/(2+3)=2/5”--Tim32 (talk) 11:27, 17 March 2010 (UTC)
Mathematics texts often don't include computer algorithms due to a limit of scope, not because it's not important or helpful to do so. This is an encyclopedia, thus it should cover the subject in the terms of all of the fields in which the knowledge is relevant. Mathematics itself is often viewed from a strictly applied perspective; that is, as the toolbox of a programmer. It's not our job to decide whether we should cater to pure or applied mathematicians of either extreme. We should instead recognize that there are people who need the information with different sets of prerequisite knowledge that should be expected of them for understanding of the article. Consider also accessibility for people with a mottled set of knowledge (Beta distribution, anybody?), who will then only need to know enough of either set of knowledge to understand the concept. ᛭ LokiClock (talk) 05:34, 18 March 2010 (UTC)

Previous discussion from Wikiproject Computer Science

I thought it might be worth pointing out that this issue has come up before several times. It gets heated, often with language proponents suggesting their language is actually ideal, or better known, or perfectly adequate, or what have you. Ultimately the best answers I've seen amount to pseudocode being the best choice as it is the most accessible to the widest audience. Of course that ideally involves standardising pseudocode, which is a recipe for disaster in and of itself. You can read User:Dcoetzee/Wikicode for an archived copy of an abandoned effort along those lines. At Wikiproject Computer Science the eventual decision was to go with some rough guidelines to help constrain pseudocode. Indeed, I think the eventual results there are pretty good: Wikipedia:WikiProject_Computer_science/Manual_of_style_(computer_science)#Algorithms. I should also point out that the recommendations there are actual code is really suitable only to give samples of the language on, for example, pages about the language. I won't comment further, having already been through all these arguments once, except to say: good luck; I hope you can come to a reasonable consensus. -- Leland McInnes (talk) 23:14, 16 March 2010 (UTC)

"Within this WikiProject, the consensus has generally been that where possible algorithms should be presented in pseudocode."(Wikipedia:WikiProject_Computer_science/Manual_of_style_(computer_science)#Algorithms) Very worth link! Thank you! Or somebody here thinks that computer science is not mathematical area? ;-) --Tim32 (talk) 10:26, 17 March 2010 (UTC)
Actually, we've established that computer science is not a mathematical area. Just look at Talk:Gödel's incompleteness theorems, where the discussion makes it clear that mathematicians and computer scientists mean something completely different. — Arthur Rubin (talk) 02:57, 1 April 2010 (UTC)
There is Mathematics#Theoretical_computer_science in Mathematics#Fields_of_mathematics section. So, "computer science is not a mathematical area", but theoretical computer science is a mathematical area ;-)--Tim32 (talk) 09:41, 1 April 2010 (UTC)
At the same time, I am agree with Arthur Rubin: computer science (and, particularly, theoretical computer science) is not a mathematical area. Because in contrast with classical mathematics the computer science is experimental science (Allen Newell and Herbert Simon said this in their 1975 ACM Turing Award -- "Computer Science as Empirical Inquiry: Symbols and Search", Communications of the ACM, 1976, 19(3), 113).--Tim32 (talk) 09:51, 1 April 2010 (UTC)
It seems that Mathematics article should be corrected!--Tim32 (talk) 09:53, 1 April 2010 (UTC)
And here we should write that algorithms are not mathematical objects, but computer science objects, so see Manual_of_style_(computer_science)#Algorithms.--Tim32 (talk) 10:01, 1 April 2010 (UTC)
Experimentation is not in contrast with "classical mathematics." If the rest of mathematics wasn't experimental, nothing would have grown out of it or will grow out of it. This Pure vs. Applied feuding is laughable. This is like listening to a classical music fan try and argue that hip hop isn't music. Why do people want so badly to write the other end of the spectrum from their preferences out of the picture? Rubin, you did not link to the section in which you claim that the body of editors have clearly decided that computer scientists are not mathematicians. And even if there was a consensus in that talk page, the talk page for that article's subject should not determine whether a different subject should be considered of the same vast category as it. You do not decide whether Wikipedia considers Calculus a mathematical field in the article for the parallel postulate. If you want to "correct" the Mathematics article and this manual of style, you should look for more than two people's opinions on a controversial subject, and in a more appropriate place. ᛭ LokiClock (talk) 02:38, 6 April 2010 (UTC)
Mathematicians use abstractions and logical reasoning, experimenters use observations and real objects testing. See Mathematics, Experiment.--Tim32 (talk) 09:53, 7 April 2010 (UTC)
And no true scotsman would come to a theoretical conclusion by rigorous representation of his experimental observations, so Joseph Fourier is only a physicist and the Fourier Transform has nothing to do with mathematics at all. Experimentation and abstract thinking are not mutually exclusive acts, and doing one does not mean you can be in isolation of the other. All mathematicians and scientists employ a bit of both, and those don't make you one or the other. Being able to write a format argument does not make you a logician, because you aren't experimenting with the process of the logical formalism, and you aren't changing the abstract object of study (logic itself) in any way. ᛭ LokiClock (talk) 06:20, 9 April 2010 (UTC)
Joseph Fourier was a mathematician and physicist: it is possible to combine mathematical methods and experimental methods. But Fourier died in 1830. Today many mathematicians are isolated in abstract approach only. Morris Kline wrote about this problem in his book "Mathematics. The Loss of Certainty." New York, Oxford University Press, 1980. --Tim32 (talk) 08:13, 10 April 2010 (UTC)
Not by definition. Even as you use it, it's framed as a problem with the average modern mathematician. And it's not a combination of mathematical and experimental methods, it's a combination of abstract reasoning and experimental deduction in mathematics and physics. Experimentation or abstract reasoning does not qualify you as either. We're off the subject by now, though. Computers themselves are mathematical contraptions, and constructs. They exist because of boolean logic, signal processing, the mechanics of binary numbers, formal language. They were created, and still exist, to compute mathematical functions, i.e. to model and process mathematics in the stead of humans. Moreover, in building them we have created a larger mathematical structure, worthy of study in and of itself, and in studying it we develop new ideas about the rest of mathematics from the perspective of the theoretical construct. ᛭ LokiClock (talk) 01:09, 12 April 2010 (UTC)
Real computer is not mathematical model, but Turing machine, for example, is… Turing machine may be emulated in real computer, but classical mathematics does not need such emulation. "They exist because of boolean logic, signal processing," – Yes, as well as accountancy exists because of Boolean logic, etc. Classical pure mathematics uses abstract reasoning, and computer is not necessary for this. Today many mathematicians use computer as typewriter tool to submit a paper to a journal only. --Tim32 (talk) 08:39, 12 April 2010 (UTC)


I was looking for a guideline regarding fractions, but didn't find one. So here's my question: if using HTML, should we write 1/2 or ​12 (using {{frac}}) or even ½? —bender235 (talk) 14:40, 31 March 2010 (UTC)

I think ​12. ½ is definitely wrong, as there are only a few characters like that, so if used with other fractions the formatting would be inconsistent. 1/2 is what you do when typing a fraction and you don't have access to formatting. Not only do you have access to HTML formatting but there's a template to make it easy.
The only exception is , using the LaTeX renderer. Personally I try and avoid using it for inline formulae, but there may be an occasional need.--JohnBlackburnewordsdeeds 15:46, 31 March 2010 (UTC)
This ​12 is not limited to certain characters. You could also write ​4372123, see Template:Frac/doc. --bender235 (talk) 16:59, 31 March 2010 (UTC)
You misunderstood me. ½ is a unicode character, as are ⅓, ⅔, ¼, ¾, ⅕, ⅖, ⅗, ⅘, ⅙, ⅚, ⅛, ⅜, ⅝ and ⅞. Those are all of them (that I can find). If you want to represent a seventh, three tenths or one over pi there is not such character, and you have to do it in a way which will look different.--JohnBlackburnewordsdeeds 17:37, 31 March 2010 (UTC)
Okay, I got it now. ;-) --bender235 (talk) 17:42, 31 March 2010 (UTC)
That there is only a limited selection of Unicode fractions available is no problem, since these kinds of fractions are only used in limited contexts where the list more than suffices. One rarely, if ever, needs to write 1/7 or 3/10 as a fraction in a non-mathematical context, and certainly not one over pi. That ½ looks inconsistent with ​12 is an error of the template, not of the Unicode character, whose appearance follows standard typographical practice.—Emil J. 17:59, 31 March 2010 (UTC)
In mathematical context, it's definitely 1/2. The shifted fractions are never ever used in professional mathematical typesetting: the only notations employed are 1/2 and (or actually outside displayed formulas, as here). You can use ½ for cooking recipes (take 1½ cups of flour ...) and similar kind of measurements, but not for mathematics. I can't imagine any situation where ​12 would be appropriate, let alone the fact that it looks pretty ugly.—Emil J. 15:53, 31 March 2010 (UTC)
Well, in my opinion 1/2 looks pretty ugly. But would be a good-looking compromise. --bender235 (talk) 17:01, 31 March 2010 (UTC)
template:frac is used here on thousands of pages: see Special:WhatLinksHere/Template:Frac. As for mathematical typesetting one tends to use TeX but then one's using TeX for everything, so there's not the problem encountered here with TeX mismatching the HTML around it.--JohnBlackburnewordsdeeds 17:37, 31 March 2010 (UTC)
There's no TeX needed for 1/2, and even if it were that's no reason to invent notation unheard of outside Wikipedia. I am perfectly aware that the template is used on many Wikipedia pages, and I hope that now that the problem has been raised here, maybe something will be done about it finally.—Emil J. 17:59, 31 March 2010 (UTC)

For some context, see the recent edit history to Riemann hypothesis, and also a brief discussion on my talk page. My position is exactly what EmilJ stated above. —David Eppstein (talk) 17:03, 31 March 2010 (UTC)

As I see it there are two reasons to prefer ​12 over 1/2. First it looks better: entirely subjective but someone created and then many people used the template without being prompted: I've never seen a guideline about it and only started using it because I saw it on a page. The other reason partly explains why it's used more outside of mathematics: it's the only way to do mixed numbers such as ​3 17. Written like 1/2 it looks like 31/7, unless you introduce a typographically incorrect space, and wrap it in template:nowrap to stop it breaking, to finally get 3 1/7. A lot of the current uses are in conversion templates, converting e.g. metric to imperial measurements for use in infoboxes, in a better looking way than decimals.--JohnBlackburnewordsdeeds 18:11, 31 March 2010 (UTC)
I prefer 3 to ​3 17, but for mixed fractions and common weights and measures I think {{frac}} can be ok. I don't want to see it in articles about research mathematics, though. —David Eppstein (talk) 18:36, 31 March 2010 (UTC)
And do you prefer over 1/2 as well? —bender235 (talk) 19:22, 31 March 2010 (UTC)
I prefer both of those over ​12. Whether to use or 1/2 depends on context. —David Eppstein (talk) 19:27, 31 March 2010 (UTC)
Okay. I prefer and12 over 1/2, because 1/2 is just ugly and misleading. Anyway, I hope we'll have some sort of guideline regarding fractions at the end of the day. --bender235 (talk) 19:37, 31 March 2010 (UTC)
I noticed that a section had been added on this coming down on one side of the frac vs. slash debate, which we're not agreed on that I can see, and ignoring the one thing I think we can agree on about unicode, so I've updated appropriately.--JohnBlackburnewordsdeeds 22:03, 31 March 2010 (UTC)
I prefer . The use of 1/2 is ugly, but unambiguous, since everybody can see the relationship to what's typed. I can see the point in ​12, but I wouldn't like to see it in mathematics articles, where it would get confused with superscripts and subscripts. -- Radagast3 (talk) 22:45, 31 March 2010 (UTC)

Here is how TeX renders an inline (not displayed) fraction: . I prefer for us to match that, by using "1/2" when we write in plain text. This is the usual style of mathematical typesetting. Based on my reading of style guides and typesetting books, things like ​12 are used only in non-mathematical contexts, e.g. novels. I view them as a quaint anachronism, like old-style figures. Given that this is the manual of style for mathematics articles, not literature articles, I would not like to see it recommend ​12. — Carl (CBM · talk) 22:50, 31 March 2010 (UTC)

I have to admit that I did see one technical paper today that used raised-number slash lowered-number to indicate a fraction, in an exponent, something like So saying it's never used is an overstatement. My reaction to it was the same as when I see it here, though: that's ugly and I wish the authors wouldn't do it. —David Eppstein (talk) 23:31, 31 March 2010 (UTC)
I have to admit I cannot tell whether the epsilon is in the denominator of the fraction there.... — Carl (CBM · talk) 00:19, 1 April 2010 (UTC)
Yes, that's another good reason not to use this style. —David Eppstein (talk) 03:28, 1 April 2010 (UTC)
In good mathematical typesetting, fractions in exponents are usually written with a slashed form, like , not as a double-decker fraction, like . The slashed form is also typical in similar situations, such as fractions that themselves appear in the numerator or denominator of a fraction. See also Chapter 17 of the TeXbook. —Bkell (talk) 05:03, 1 April 2010 (UTC)
Getting arcane here but there's a Unicode symbol for division, the Mapping of Unicode characters#Fraction slash. Here's it is, compared to the usual one, both in default and example text format: 1/2 = 1⁄2 & 1/2 = 1⁄2. There are others in Unicode but this one seems intended for use in fractions.—Preceding unsigned comment added by JohnBlackburne (talkcontribs) 14:10, 1 April 2010 (UTC)
As explained in detail in the very section you linked to, the Unicode character ⁄ (U+2044 FRACTION SLASH) is a special-purpose device which is supposed to automagically combine with adjacent digits to form ½-like fractions, if the rendering technology supports it. It is therefore wrong to use it for 1/2-like fractions in contexts where these are not supposed to turn into ½. For exactly the same reason, it also looks bad (when not combined as mentioned), because it is too slanted (in fonts where it looks differently from /). I don't see a need to use anything other than the ASCII / (U+002F SOLIDUS) for 1/2-like fractions as it is a nearly universal convention to do so, but in any case the correct replacement would not be the above mentioned fraction slash, but ∕ (U+2215 DIVISION SLASH): 1∕2. (I note that it also looks too slanted in the font I happen to see here.)—Emil J. 17:38, 2 April 2010 (UTC)
I looked at this comment in four different OS X browsers (Safari, Camino, Firefox, and Chrome). The division slash looked almost the same as a normal ascii slash in Safari and Chrome, but horrible in Camino and Firefox, worse than any of the other slashes. Not only is it too slanted but it's also too big, maybe twice the normal line height. I think we should just stick to a normal ascii slash. —David Eppstein (talk) 18:07, 2 April 2010 (UTC)
Yes, I think it's more a curiosity. First it is different, but how varies by font: there's no consistency and certainly nothing that to me says it would be more use in division. The main thing is it seems to be zero width, so in theory better for putting things either side of, but in practice I don't think we have any problems as it is. It's special behaviour I was only able to get by switching to Apple Chancery and trying it in TextEdit. There it half worked, in that it made any denominator (any string of chars flush with it, to the next space) smaller on the fly, but not the numerator. So it's really something that needs to be done in HTML. It's only benefit might be for screen readers, which might be better able to tell it apart from a normal slash, much like using a minus sign instead of a dash.--JohnBlackburnewordsdeeds 18:24, 2 April 2010 (UTC)


Since David Eppstein and me disagree on what is "consensus" here, let's find out.

Proposal #1

Recommend the use of in general, and condone the use of ​12 in non-mathematical context. Discourage the use of 1/2 and ½.

  • Pro , because 1/2 looks ugly. ​12 might not be used in mathematical textbooks, but it should be allowed in non-mathematical contexts like this. --bender235 (talk) 10:01, 1 April 2010 (UTC)
Proposal #2

Recommend the use of in general, and condone the use of 1/2 in non-mathematical context. Discourage the use of ​12 and ½.

Proposal #3

Advise that , ​12 and 1/2 are all acceptable. Advise against the use of ½.

  • Pro I prefer {{frac}} but think it should be up to the editor, except for unicode where there are good reasons not to use it.--JohnBlackburnewordsdeeds 10:22, 1 April 2010 (UTC)
Proposal #4

Recommend the use of and 1/2 in mathematical context, and discourage the use of ​12 and ½ in mathematical context. Leave non-mathematical context unregulated.

  • Pro I would actually like to see the god-awful abomination of ​12 gone for good, or at least fixed so that it does not stick out of the line and uses a decent kerning (i.e., to make it look like ½) so that it conforms to reasonable typographical standards, but that looks like a too big a fish to fry ATM.—Emil J. 10:43, 1 April 2010 (UTC)
I just had a go at fixing it – 1π, 12, 1+23 – by copying {{frac}} wrapping HTML small tags around the fraction part. It seems to work, i.e. it makes the fraction small enough that it does not obviously break kerning, at an cost in readability but it is possible. I don't think we want to modify {{frac}} as it's so widely used, but a second template would be OK: there are multiple fraction and subscript ones already.--JohnBlackburnewordsdeeds 11:04, 1 April 2010 (UTC)
This looks better, but it still sticks out of the line. In 1+23, the top of 2 should not (significantly) exceed the top of 1, and the bottom of 3 should not descend below the bottom of 1, cf. 1⅔.—Emil J. 12:07, 1 April 2010 (UTC)
  • ProBkell (talk) 13:35, 1 April 2010 (UTC)
  • Pro12 should not be used in mathematical contexts. The use of 1/2 should be preferred in plain (non-TeX) inline text, I certainly don't see it as ugly (from long familiarity?) and used correctly it should never be ambiguous. Paul August 14:15, 1 April 2010 (UTC)
Just wondering, but why is it that Wikipedia:Manual of Style (mathematics)#Multiplication sign explicitly says "Do not use the letter x as a substitute for ×", but on the other hand we allow people to use slash as a substitute for solidus? --bender235 (talk) 14:27, 1 April 2010 (UTC)
I would say because fonts vary more on how they display x. Compare x and ×. Now compare / and /. Also for general division there's ÷ which is impossible to confuse with anything else.--JohnBlackburnewordsdeeds 14:39, 1 April 2010 (UTC)
I agree there. As a pedant, I'm all for using solidus rather than slash for fractions, but unlike times, they just don't look different in most fonts. I wouldn't oppose someone "fixing" such slashes, but really, their time would be better spent on other things. —Ben FrantzDale (talk) 15:07, 2 April 2010 (UTC)
  • Pro Seems appropriate. I do admit that, working in the cyclic number fiasco, ​20199 would be difficult to avoid, but it probably should be , even if it produces alignment problems. Contrary to Bender235's objection to 1/2, I see no objection to its use as a standalone number in mathematics articles. It's only a problem if as part of an inline formula. His edit to Reimann Hypothesis is ugly. — Arthur Rubin (talk) 14:58, 1 April 2010 (UTC)
  • Pro This one gets my !vote. Gandalf61 (talk) 15:02, 1 April 2010 (UTC)
  • Pro This is the standard for fractions in all mathematical discourse, and should therefore be the standard in Wikipedia mathematics articles as well. Jim (talk) 15:07, 1 April 2010 (UTC)
  • Pro We definitely need both 1/2 and ; for instance, the slashed form should be used in an exponent, a subscript, or in a formula that's part of a bigger fraction. —David Eppstein (talk) 15:09, 1 April 2010 (UTC)
  • Pro First, this manual of style should not provide guidance out of its scope, so I oppose proposals 1-3 which give non-mathematical recommendations. Within a mathematical context, I support , , and 1/2 while opposing ​12 and ½. Obviously within the preferred styles there are times when one form is better than another: should almost never be used inline (as I just used it), for example. CRGreathouse (t | c) 19:43, 1 April 2010 (UTC)
  • Pro This is consistent with the notation used in "the literature". Jwesley78 19:24, 2 April 2010 (UTC)
  •  Question: This proposal seems to make no distinction between the usage of and "1/2". There are situations where one should be preferred over the other. (Perhaps this would be a separate issue/proposal?) That is, one should use for coefficients or alone, but for superscript/subscripts one should generally use 1/2. I find using "1/2" alone or as a coefficient, almost (but not quite) as egregious as using ​12. Jwesley78 19:24, 2 April 2010 (UTC)
  • Some of my concerns appear to be addressed in the "Observations" below. Jwesley78 20:18, 2 April 2010 (UTC)
Proposal #5

Leave the decision to (main) authors working on the concerned articles and find something else to argue.

Then why have a Manual of Style at all? Why not leave every decision to authors, resulting in 3.2 million articles with 3.2 million different styles. --bender235 (talk) 11:37, 1 April 2010 (UTC)
Not every decision, just this one. See WP:CREEP. While I don't really agree with Kmhkmh, he has a valid point.—Emil J. 12:11, 1 April 2010 (UTC)
The issue at hand is not the MOS itself but a rather special subitem of it, which imho requires no regulation. There is no question that we need a few ground rules and hence a MOS. There is however a question of how extensive this MOS is supposed to be. Regarding that issue I personally prefer a rather lean MOS, that sticks to the really important things. A very extensive MOS (as part of even much larger system of guidelines) is imho somewhat of a deterrence for (future) editors. Also there is a certain risk that we start to develop guidelines for its own sake rather than to deal "real" issues. Moreover if we (often) have a very few people devising some very specialized guidelines, then it might not be at all clear whether they actually represent some larger consensus (the ratio of (semi)active math authors and the people that will participate in this poll might provide some pointers to that regard).--Kmhkmh (talk) 12:17, 1 April 2010 (UTC)
Okay, you've got a point. But then again we have recommendations like using × instead of x as multiplication sign, and dozens of other guidelines on those small items. Those aren't exactly rules that aren't allowed to be broken (like WP:NPOV or WP:V), but suggestions. I think there should be a section Wikipedia:Manual of Style (mathematics)#Fractions, telling people how fractions should be displayed in Wikipedia, even if it was only for those editors (and I was one of them) who did not know about {{Frac}}. --bender235 (talk) 12:36, 1 April 2010 (UTC)
But this guideline is about mathematics articles, and the frac template generally should not be used in mathematics articles. As this page already says, the general advice for non-matheamtical articles is at Wikipedia:Manual_of_Style_(dates_and_numbers)#Fractions, which does mention the frac template. — Carl (CBM · talk) 13:18, 1 April 2010 (UTC)
Okay, so let's add a guideline that says "Use to display fractions (in mathematical articles)". Just make sure we don't encourage the use of 1/2, because it is ugly and error-prone (e.g. does 1/2t mean or ?) --bender235 (talk) 13:51, 1 April 2010 (UTC)
Problems that I still have with that are:
  • a) "ugly" is somewhat fuzzy term and very much in the eye of the beholder.
  • b) In Latex you can produce all of the suggested versions (even more or less with "default" formatting) and you can find all versions in (math) literature depending on the exact context (things like text style, display style, appearance in exponents, indices, numerators, denominators, etc.)
  • c) Does it really matter for the quality of an article which version a particular author has used? Is it really wirth quarreling about it?
  • d) 1/2t imho can be only read as , whereas would be 1/(2t)
    • To my mind 1/2t can only be read as a mistake. It should be either t/2 or 1/(2t). And 1/2t is even more of a mistake because the variable should be italicized. But this is irrelevant: the ability to misuse a notation is not a reason to ban its legitimate uses. —David Eppstein (talk) 17:28, 1 April 2010 (UTC)
  • e) The 1/2 style is essentially something I'd call "ascii math notation". There a few contexts, where such notation might be considered useful or natural despite its potential ugliness. Namely article subjects where ascii math is used such as various math software, calculators, programming and algorithmic descriptions, etc.
  • f) Regarding WP:CREEP. I can understand people having personal preferences regarding the notation of a particular fraction and so do I. However I can't honestly say any of them is "so bad" that I see a justified need to "forbid" them, so consequentially I see no good reason for additional regulation here. As partially already mentioned before: All versions are found in literature and all versions are easily understood by readers (if properly used).
--Kmhkmh (talk) 15:03, 1 April 2010 (UTC)

It seems like the above discussion isn't separating some important concerns:

  1. What versions of inline fractions are acceptable at all? (Case fractions like ½ versus inline like 1/2 versus stacked .)
  2. What versions are appropriate in what context? (e.g., mathematics rarely if ever uses case fractions.)
  3. What are acceptable displays? (Plain text like 1/2 versus extended characters like ½ versus fancy HTML like 12 versus LaTeX-generated images like versus fancy Unicode tricks.
  4. What is feasible to generate with a template?

Personally, I find the {{frac}} template ghastly, typographically. However, making the denominator doubly <small> rather than <sub> helps a lot: 100200 rather than 100200. To my eye, that first version seems competative with the case fraction symbol while still be extensible beyond the existing case-fraction symbols (compare 12 ½).

  • Considering 1. above, it seems all three versions have their place. Stacked fractions in some mathematical contexts, case fractions in cooking, for example, and 1/2 is fairly common (I could see trying to prefer case fractions, but suspect it is the Right Way in some contexts and so shouldn't be forbidden.)
  • Regarding 2. above, this seems like something that can't be prescribed universally; individual fields have their conventions.
  • As for 3. above, stacked fractions can only be done as an image (unless there is crazy HTML or Unicode voodo magic to do it), so images have to be acceptable. As for the others, most browsers support either the HTML or the case fraction, so 3. seems like mostly a non-issue.
  • Regarding 4., feasibility of a template, case fraction symbols are the odd one out as they can't be made for arbitrary fractions, and even choosing among the existing set is tricky at best (are templates Turing-complete?)

With all that in mind, it looks like most commeters agree that the giant is out and many dislike the existing HTML-built case fractions, but I think my version looks pretty darn good. How about this proposal for inline fractions:

  • Change any inline to .
  • Change {{frac}} to produce 12.
  • Either case fractions or 12 (generated with the tmplate) are acceptable.
  • Prefer case fractions to full-sized fractions such as 1/2 and to stacked fractions, but only when appropriate in context.

Would that answer everyone's concerns? —Ben FrantzDale (talk) 15:07, 2 April 2010 (UTC)

I don't think that has consensus at all. The comments above almost universally oppose {{frac}}. My thoughts:
  • I oppose any version of a fraction template which uses <big> or <small>: the former has been dropped from HTML5, while the latter has semantic meaning not shared by fractions.
  • I weakly oppose the use of a fraction template on typographic grounds.
  • I oppose the use of precomposed fractions (which you are calling case fractions, though the article you link to calls special fractions) in mathematical contexts.
CRGreathouse (t | c) 17:09, 2 April 2010 (UTC)
We may not disagree that much.
  • I am all for pedantic reading of HTML5 standards; I'm sure it has some way to get what I got above.
  • Do you oppose the idea of using a template for fractions or do you oppose the content it produces? That is, If {{frac}} produced , would that be OK with you? To me it seems easier to maintain a wiki-wide style with {{frac}} and that should be orthogonal to how the fractions are displayed.
  • I am also generally opposed to case/composed fractions in mathematcis for reasons of ambiguity (although I think some simple cases such as x½ looks nicer than x1/2, with no loss of clarity).
Am I missing something else? —Ben FrantzDale (talk) 18:20, 2 April 2010 (UTC)
One objection, but quite strong: don't change {{frac}}. It's used on thousands of primarily non-mathematical pages, and changing it would invite I'm sure complaints and result in a swift reversion due to worsened readability – in e.g. image captions and infoboxes where text is often smaller. Create a new template by just copying and changing it, as I did for {{User:JohnBlackburne/smFrac}}. There's already a {{1/2}}, a {{2/3}}, another fraction template would not be out of place. Add a link to it on {{frac}} and vice versa and editors can use which they want.--JohnBlackburnewordsdeeds 18:42, 2 April 2010 (UTC)
I oppose using the current {{frac}} template for math content; I agree, in principle, that an appropriate template could be created for math pages. My main point was not my personal feelings, though, but that your proposal seems to differ significantly from the wishes expressed by most commenters above.
I don't know how to reconcile your feelings about maintaining consistency vs. JohnBlackburne's desire to leave {{frac}} unchanged; these seem diametrically opposed. I think I fall into your camp here more nearly than his: if a template is doing the Wrong Thing, it should be fixed. Of course I'm not sure of what the Right Thing is. I don't like any of the solutions proposed so far for fractions in exponents, for example: the ½ in x½ is too small, the 1/2 in x1/2 is too long, etc.
CRGreathouse (t | c) 20:05, 2 April 2010 (UTC)
I think we are drifting off topic (and I think I am partially to blame). In as much as we agree that {{frac}} should be avoided in mathematical contexts, then refining it is outside of the scope of this talk talk page. Within the context of mathematics, I am farly agnostic. I don't mind "slash" fractions in exponents as long as it is unambiguous and avoids unnecessary parenthesis, so would be better written and would be better written .
That said, I see no reason to fix lousy spacing in the {{frac}} template. There is good reason to have a template that generates case/composed fractions. As long as the intent of the template isn't changed (i.e., "a template that makes a case fraction that isn't too small"), I don't see how other pages' editors would have a problem with removing its decenders and making its "one over two" look more like the ½ glyph. Let's move that discussion there. —Ben FrantzDale (talk) 12:34, 5 April 2010 (UTC)

intended for mathematics articles

According to this page, "This subpage of the Manual of Style contains guidelines for writing ... articles on mathematics." (my emphasis). I don't see that we need to go out of our way in this page to talk about how to write non-mathematical pages. The section "fractions" is not intended to talk about fractions such as "3 ​12 Oak Street", it's about fractions in mathematical contexts. For other contexts, the general advice is here. — Carl (CBM · talk) 11:40, 1 April 2010 (UTC)

notation of logarithms

After noticing irritation of some readers with the notation of logs in WP, it seems to me a recommendation in the style guide might useful. The biggest problem here is with or , where the specific base might not be obvious to average readers. While in the context of a particular book or article the above notation is usually non-ambiguous, it becomes ambiguous in WP, where all these contexts mix (see Logarithm#Implicit_bases). Therefore I'd suggest that articles should always use non-ambiguous notation like or . Alternatively authors insisting on using should at least provide a footnote explaining which base is used. Keep in mind while the base might be obvious to the author, for an arbitrary reader with a rather different background and different context in mind it might not be.--Kmhkmh (talk) 08:44, 9 April 2010 (UTC)

I believe log(x) should be reserved for cases where the base is arbitrary and consistent, e.g. log(x)/log(y)=logy(x). ᛭ LokiClock (talk) 09:02, 9 April 2010 (UTC)
Though I should note such usage threw me for a loop the first time I saw it, and logn would be even better. ᛭ LokiClock (talk) 09:05, 9 April 2010 (UTC)
That is actually another problem is not just ambiguous regarding the base, but it could also stand for "base independent", which in a way is another level of ambiguity.--Kmhkmh (talk) 10:53, 9 April 2010 (UTC)
I think it's better to just clarify in prose which logarithm is meant, if there is potential for confusion. For example, I would feel silly writing "ln" in the context of complex analysis; the right notation there is just "log". — Carl (CBM · talk) 11:49, 9 April 2010 (UTC)
I don't think there's an easy way around this problem. Nobody working with logarithms specifies the base every time, so we can't expect editors to do that. And "log" on its own will never be completely clear: To me, it will always mean "natural log", whereas to an engineer, it will always mean "common log". I think often the meaning of log will be clear from the context: In advanced mathematical articles it will mean natural logarithm, and in advanced engineering articles it will mean common logarithm. But in those articles where it is not clear, the convention should be specified explicitly. That seems like the best solution available. Ozob (talk) 12:08, 9 April 2010 (UTC)
Also in computer science it mostly means log2. Fortunately it's also mostly used within O-notation where the base doesn't matter. —David Eppstein (talk) 19:54, 9 April 2010 (UTC)
At present we don't have much consistency in Wikipedia mathematics articles. Euler–Mascheroni constant, harmonic number and Stirling's approximation use , Riemann zeta function and Von Mangoldt function use - and prime number theorem and Chebyshev function use both ! Gandalf61 (talk) 15:32, 9 April 2010 (UTC)

Empty Set

What should be the notation for empty set? Should it be or ? Mpd1989 (talk) 10:26, 20 April 2010 (UTC)

I prefer the second, but I think the first is acceptable. Ozob (talk) 03:27, 21 April 2010 (UTC)
I prefer the first, as the second looks very eccentric to me. I am not aware of any serious mathematical literature that uses the second. Hans Adler 12:47, 26 May 2010 (UTC)

Whatever happened to Blackboard Bold?

I raised this issue in Talk:Set (mathematics), but it is probably better here. Blackboard bold is the font of our craft. Why does mere bold font (N) seem to be preferred to blackboard bold ()? I was genuinely confused when I saw bold font being used for one of these sets. NathanZook (talk) 02:46, 21 April 2010 (UTC)

This MOS has a detailed paragraph on this exact issue. — Carl (CBM · talk) 02:56, 21 April 2010 (UTC)

RFC which could affect this MOS

It has been proposed this MOS be moved to Wikipedia:Subject style guide . Please comment at the RFC GnevinAWB (talk) 20:52, 24 May 2010 (UTC)

Inner products

There has been a discussion at Pythagorean theorem about the notation for inner products. Since this is a common "newbie" mistake, I think the MOS should clarify that less-than and greater-than signs should not be used for inner products. Acceptable symbols include parentheses and angle brackets, either in plain text or in math mode. — Carl (CBM · talk) 12:44, 26 May 2010 (UTC)

Same thing with Bra-ket notation. (Which is closely related to the inner product notation.) --Robin (talk) 13:48, 26 May 2010 (UTC)
Sounds good to me. Ozob (talk) 00:22, 27 May 2010 (UTC)
It should be noted that if we write an inequality about inner products with the improper symbols, it becomes unreadable: <v,v>>0 --Tercer (talk) 01:11, 2 June 2010 (UTC)


After this discussion, I removed the text from this MOS about scriptstyle. I didn't add any language against scriptstyle, though. So the current MOS is silent on the issue. I think that gentle advice against using scriptstyle would be reasonable, if it was worded well. — Carl (CBM · talk) 14:27, 17 July 2010 (UTC)

When I wrote that paragraph (I do think it was me who wrote it), there was a vocal contingent that argued for \scriptstyle on the grounds that it produced better formatting (i.e., more similar to the surrounding text). They seem to have vanished, and with their vanishing I think the MoS can (and should) be more critical of \scriptstyle. However, I do regret the loss of the discussion of \textstyle. \textstyle is an important command when writing TeX inline, and I think that the MoS ought to have a mention of it. Ozob (talk) 00:43, 18 July 2010 (UTC)


Please comment at WT:MOSNUM#Fractions about any conflict between WP:MOSNUM#Fractions and WP:MOSMATH#Fractions, and the desired outcome. — Arthur Rubin (talk) 19:39, 21 July 2010 (UTC)

WikiProject Statistics discussion about usage of ƒ for mathematical functions

There is a discussion at Wikipedia talk:WikiProject Statistics#ƒ or f about whether the symbol ƒ should be used for mathematical functions in Wikipedia articles. —Bkell (talk) 17:47, 18 November 2010 (UTC)

proposed summary of when to use Tex and HTML

I would like to add a summary similar to the following to the article. Details may change; in particular, some people would prefer \textstyle to \scriptstyle. Nonetheless, I feel that finding this relevant information in the article is harder then it should be. TStein (talk) 22:11, 1 December 2010 (UTC)

Preferred formatting for inline equations
method when to use sample code formats as
HTML using {{math}} preferred Lorem ipsum, {{math|∇ × '''B''' {{=}} ''μ''<sub>0<sub>'''J'''}}, tuo quantum... Lorem ipsum, ∇ × B = μ0J, tuo quantum...
HTML using {{nowrap}} or {{nowrap begin}} (disputed, see discussion below) Lorem ipsum, {{nowrap|∇ × '''B''' {{=}} ''μ''<sub>0</sub>'''J'''}}, tuo quantum... Lorem ipsum, ∇ × B = μ0J, tuo quantum..
LaTeX textstyle when not possible in HTML Lorem ipsum, <math>\textstyle\sum_{n=0}^\infty\frac{x^n}{n!}</math>, tuo quantum... Lorem ipsum, , tuo quantum...
Preferred formatting for separate line equations
method when to use sample code formats as
LaTeX :<math>\nabla \times \mathbf{B} = \mu_0\mathbf{J}</math>
HTML using {{math}} and the option big=1 :{{math|big=1|∇ × '''B''' {{=}} ''μ''<sub>0</sub>'''J'''}} ∇ × B = μ0J
HTML using {{math}} :{{math|∇ × '''B''' {{=}} ''μ''<sub>0</sub>'''J'''}} ∇ × B = μ0J
HTML :∇ × '''B''' = ''μ''<sub>0</sub>'''J''' ∇ × B = μ0J
Scriptstyle should not be used for things other than subscripts. If something needs to be done in LaTeX, it should just be put in LaTeX. Scriptstyle produces all sorts of abominable results, like the μ0 in your example where it is not easy to tell that 0 is a subscript. The poor appearance of LaTeX in the current system is a good reason to prefer HTML, but not a reason to use scriptstyle. — Carl (CBM · talk) 22:22, 1 December 2010 (UTC)
The use of scriptstyle definitely should be limited, but the use of plain Tex is often just as bad in different ways. I think the main use of scriptstyle should be for single characters not found in HTML such as script letters. Perhaps I can move this under regular LaTeX and use an asterisk for when it should be used. TStein (talk) 23:10, 1 December 2010 (UTC)
Regarding "Do not use inline"; The {{math}} template is explicitely designed for inline use. So why would that line be there? I should actually be at the top, preferred over HTML. EdokterTalk 22:59, 1 December 2010 (UTC)
Unfortunately, the inline use of {{math}} got horked by a recent change that made all html math larger so that it roughly agrees with the LaTeX png font size. Even when it is smaller like it is one of my computers it still reserves a large amount of space pushing the lines apart around it. TStein (talk) 23:10, 1 December 2010 (UTC)
I'm not sure what change you're referring to, but IMO the {{math}} template has been and remains the best way to format inline math. As Edoktor said, it should be placed at the top, above HTML. Jim.belk (talk) 02:50, 2 December 2010 (UTC)
I once attempted to make {{math}} math the output of TeX, but that was unsuccessfull. It now scales to the surrounding text, only compensating fontsize due to the different typeface where needed. Though I do agree that the lineheight could be tweaked. EdokterTalk 12:31, 2 December 2010 (UTC)
I like the concept of the {{math}} template but as it stands it is still the worst option available (at least on my system). Not only is the subscript too big but the nabla is stretched too tall. TStein (talk) 14:41, 2 December 2010 (UTC)
{Math} only uses a serif font (just like LaTeX), so if it is busted for you, you need to check your font setings. It is not 'busted' in any way, so that comment should defenitely be removed. EdokterTalk 15:56, 2 December 2010 (UTC)
I agree with you that the article's current description of when to use HTML and when to use LaTeX is distinctly subpar, but in part I think that's because there's some dispute on what's appropriate. See WT:WPMATH#Request for comment concerning formatting of standalone equations.
Also, \scriptstyle is an abomination. Ozob (talk) 03:54, 2 December 2010 (UTC)
Maybe I am being overly optimistic, but that is why I am doing this so that we have one more opportunity to get this fixed.
I don't know why you think \scriptstyle is that bad. On my system, using the {{math}} template is significantly worse (the subscript is even bigger relative to the font and the del operator is stretched too tall). Further, I think you are giving the \displaysize too much credit. Scriptstyle may be an abomination, but for one character symbols not found in HTML it is the only option. TStein (talk) 14:41, 2 December 2010 (UTC)

I made some tweaks to try and address concerns.

  1. added option to put LaTeX equation on own line to inline preferences
  2. moved {{math}} template up as an alternative that is currently busted.
  3. moved scriptstyle down and put as its only use single characters not found in HTML.

TStein (talk) 14:58, 2 December 2010 (UTC)

Don't move scriptstyle anywhere, remove it. It's just wrong. We've already had an extensive discussion on that topic before.—Emil J. 15:09, 2 December 2010 (UTC)
Also, fix your Latin. It's ipsum.—Emil J. 15:11, 2 December 2010 (UTC)
hehe. The stuff after the inline equation is completely made up as well. Rest assured that if there is enough consensus to put this in the article that I will look up the 'canonical' Lorem ipsum, etc. I wasn't a part of that discussion about the scriptstyle and my understanding is that there was no real consensus. On the other hand, I don't necessarily want to open old wounds and with so much hate for the scriptstyle I will remove it as well if I put it in the main article.TStein (talk) 19:54, 2 December 2010 (UTC)

I just added some spacing to the HTML equations, and I italicized the Greek letters. Feel free to revert if you don't like these changes. Jim.belk (talk) 15:30, 2 December 2010 (UTC)

Everyone should feel free to change anything. You are right, I was sloppy about both the spaces and the italicized variable. Anything that helps to reach a consensus and improves this is greatly appreciated.TStein (talk) 19:54, 2 December 2010 (UTC)

Using {{math}}

I made some alterations, preferring {math} for inline. I also noted why; apart from the serif font, HTML will cut in the middle of a formula if the is no 'no-wrap' mechanism in place (which {{math}} has). (Did you know you can assign your own font for .texhtml in your vector.css file?) I also added the "big=1" option for seperate line formulae. EdokterTalk 21:57, 2 December 2010 (UTC)
I made additional alterations: \textstyle is now specified for inline LaTeX (it should be always used if it is relevant; unfortunately it is not relevant for the current example formula); I removed \scriptstyle entirely; and I required the use of {{nowrap}} for HTML not enclosed in {{math}}. (Note that nowrap is used by some high-quality articles, such as Group (mathematics).) Also, I removed any guidance as to what should be used for a displayed equation since that depends on the outcome of an aforementioned discussion at WT:WPMATH. Ozob (talk) 02:04, 3 December 2010 (UTC)
I've changed the example to show something where the \textstyle matters, and which cannot be (reasonably) represented in HTML. Also, I'm not sure whether it's necessary to require {{nowrap}} for displayed HTML: the displayed text starts close to the left margin, hence it should not need to wrap (and if the browser window is so narrow that it wraps anyway, the {{nowrap}} version would make it stick out of the right margin, which I think is no more helpful than letting it wrap).—Emil J. 11:13, 3 December 2010 (UTC)
Good point. I've removed that instance of {{nowrap}}. Ozob (talk) 11:39, 3 December 2010 (UTC)
Sorry, but I cannot imagine why HTML using {{nowrap}} would be preferred, especially since it requires no less typing, {{math}} already ensuring no-wrapping, and the formula would be dispayed in the wrong typeface. In my understanding, formulae should always be didplayed in serif; this would solve numerous problem. I just saw a whole discussion on WT:WPM regarding f and f, which would be instantly solved if only {{math}} were used consistently. EdokterTalk 14:07, 4 December 2010 (UTC)
As I see it, {{math}} displays things in the wrong typeface; for that reason, I prefer not to use it. Good mathematical writing should read well and look good on the page, and displaying math in a different typeface from running text is jarring. To my eye, f(x) is easier to read than f(x) because the latter startles you. Let's look at an example. Here's a paragraph from Logarithm done both ways. First, with {{nowrap}}:
A compact way of rephrasing the point that the base-b logarithm of y is the solution x to the equation f(x) = bx = y is to say that the logarithm function is the inverse function of the exponential function. Inverse functions are closely related to the original functions: the graphs of the two correspond to each other upon reflecting them at the diagonal line x = y, as shown at the right: a point (t, u = bt) on the graph of the exponential function yields a point (u, t = logbu) on the graph of the logarithm and vice versa. Moreover, analytic properties of the function pass to its inverse function. Thus, as the exponential function f(x) = bx is continuous and differentiable, so is its inverse function, logb(x). Roughly speaking, a differentiable function is one whose graph has no sharp "corners".
Next, with {{math}}:
A compact way of rephrasing the point that the base-b logarithm of y is the solution x to the equation f(x) = bx = y is to say that the logarithm function is the inverse function of the exponential function. Inverse functions are closely related to the original functions: the graphs of the two correspond to each other upon reflecting them at the diagonal line x = y, as shown at the right: a point (t, u = bt) on the graph of the exponential function yields a point (u, t = logbu) on the graph of the logarithm and vice versa. Moreover, analytic properties of the function pass to its inverse function. Thus, as the exponential function f(x) = bx is continuous and differentiable, so is its inverse function, logb(x). Roughly speaking, a differentiable function is one whose graph has no sharp "corners".
I prefer the first. What does everyone else think? Ozob (talk) 16:43, 4 December 2010 (UTC)
I definitely prefer the latter, as that definitely looks more professional and properly typeset; the way formulae are meant to look, which is exactly the purpose of {{math}}. LaTeX does use serif with a reason, becuase that is the established typesetting for formulae, and {{math}} only help ensuring consistency between both rendering methods. What bothers me the most is the mix between formulae with serif and sans-serif on an article, that needs to be consistent, otherwise it looks liek a mess. EdokterTalk 17:34, 4 December 2010 (UTC)
By default, LaTeX uses Computer Modern everywhere: It uses a serif font for mathematics only because that's the default font for everything. Book designers are welcome to change the font if they like. For example, Knuth, Graham, and Patashnik's book Concrete Mathematics uses a slab serif font, Concrete Roman, for its text, and matches it with a similar weight script font, AMS Euler, for its mathematics. Concrete Roman text with Computer Modern mathematics looks terrible because the two have such different weights. My opinion is that the font used by {{math}} clashes with the font used for ordinary text: The contrast is too high, the x-height does not match, and the transition from sans serif to serif is too sudden. Ozob (talk) 20:05, 4 December 2010 (UTC)
(←) The x-height should match, but may be off due to use of non standard fonts. Common.css defines .texhtml for each skind based on the default font height. For Vector .texttml defines a serif font, 120% larger that the regular (sans-serif) font, and an adjusted line-height. This is based on the default fonts used in most (Windows) based browsers; Arial and Times New Roman. In some circumstances, you will never achieve a perfect blend if mismatched fonts are used, but still, my opinion is that formulae must be displayed in serif. EdokterTalk 22:18, 4 December 2010 (UTC)
I don't have anything to say to that (except that I still disagree); except I would really like to solicit the opinions of others, since it seems that we are at an impasse. Ozob (talk) 22:54, 4 December 2010 (UTC)
Agreed. I'll set up an RfC. EdokterTalk 10:31, 5 December 2010 (UTC)

Request for comments: serif vs. sans-serif

Should inline formulae coded in HTML be displayed in a serif font (similair as used by LaTeX), in order to make formulae more recognizable as such, or should it be displayed in sans-serif font (same as default font in monobook and vector), so that the formula retains the same typeface as the surrounding text? EdokterTalk 10:31, 5 December 2010 (UTC)

Copied from above:

Here's a paragraph from Logarithm done both ways. First, with {{nowrap}} (sans-serif):

A compact way of rephrasing the point that the base-b logarithm of y is the solution x to the equation f(x) = bx = y is to say that the logarithm function is the inverse function of the exponential function. Inverse functions are closely related to the original functions: the graphs of the two correspond to each other upon reflecting them at the diagonal line x = y, as shown at the right: a point (t, u = bt) on the graph of the exponential function yields a point (u, t = logbu) on the graph of the logarithm and vice versa. Moreover, analytic properties of the function pass to its inverse function. Thus, as the exponential function f(x) = bx is continuous and differentiable, so is its inverse function, logb(x). Roughly speaking, a differentiable function is one whose graph has no sharp "corners".

Next, with {{math}} (serif):

A compact way of rephrasing the point that the base-b logarithm of y is the solution x to the equation f(x) = bx = y is to say that the logarithm function is the inverse function of the exponential function. Inverse functions are closely related to the original functions: the graphs of the two correspond to each other upon reflecting them at the diagonal line x = y, as shown at the right: a point (t, u = bt) on the graph of the exponential function yields a point (u, t = logbu) on the graph of the logarithm and vice versa. Moreover, analytic properties of the function pass to its inverse function. Thus, as the exponential function f(x) = bx is continuous and differentiable, so is its inverse function, logb(x). Roughly speaking, a differentiable function is one whose graph has no sharp "corners".
  • Sans-serif. Inline mathematics is more readable when it is set in the same or a similar typeface as the surrounding text. Suddenly switching to a different typeface is jarring. There are several reasons why the typeface used by {{math}} (and by LaTeX that has been converted to HTML) clashes with the surrounding text: It is larger than the surrounding text and a larger distance between baselines, has a different x-height, more overshoot, more contrast between horizontal and vertical strokes and the presence of an angle of stress; altogether a very different and very inconsistent look. Professionally published mathematics often uses the same or a similar font for text and mathematics. By default, LaTeX uses Computer Modern for everything. Palatino and Times New Roman are also popular. It's not necessary to use the same font for text and math; Knuth, Graham, and Patashnik's Concrete Mathematics uses Concrete Roman for text and the harmonious AMS Euler for math. But it is necessary to use a font which meshes well: Concrete Roman text does not go well with Computer Modern math. Similarly, the default font for running text on Wikipedia does not go with the output of {{math}}. I would prefer that we not use {{math}} or that Wikipedia's style sheet be changed so that the output of {{math}} is not so inconsistent with everything else. (In fact, the latter option might be the best of all, as this would make LaTeX which has been converted to HTML also look consistent.) Ozob (talk) 13:03, 5 December 2010 (UTC)
  • Serif. Mathematical formulae have historically been set is a serif typeface. This has been the rule in publishing for a long time, regardless of the font used in running text. Serif helps adding and retaining meaning to the various symbols used, which would be lost in a sans-serif font (sparking discussion like this one) and helps identify a formula within the running text. Serif is also consistent with the font used by LaTeX, which cannot be changed easily. Regarding metrics; The .texhtml CSS in the various skin CSS files strives to match the metrics between the formula and running text as close as possible. Using the default browser fonts (Arial and Times New Roman), this will result in a near perfect match. There may be discrepancies when non-default fonts are used, but they appear to be negligable. As a side note: I propose that Cambria be used as the prefered font for .texhtml, as this typeface is specifically geared towards math, has a wide installed base (standard since Vista and available through Office 2007 and it free viewers), and matches quite well with Arial in terms of style and metrics. EdokterTalk 13:44, 5 December 2010 (UTC)
  • Comment. It seems to me that this argument does not need to be resolved. Instead of presenting an opinion on whether serif or sans-serif is better, the MoS should simply present both options, indicating the advantages and disadvantages of each. All that needs to be agreed upon is some neutral language describing the two options.

    I do agree, however, that the .texhtml style in the style sheet should be changed so that the results have higher overall quality. Most importantly, instead of simply specifying a serif font, some list of fonts should be given that increase the chance of high-quality output on a typical computer. In addition, it is possible that the 125% font size and 1.25 em line height should be toned down a bit to get better matching of the x-heights. Jim.belk (talk) 15:56, 5 December 2010 (UTC)

    • The x-height are already a pretty good match (but can always be finetuned). And I did propose to use Cambria as a preferred font, as it is the most comprehensive math font available (other suggestions welcome). As for presenting both options; that creates the inconsistency that I am trying to get rid of. It looks really unprofessional to have formulae in all kinds of different styles. (Edit:) here is a comparison: Template:Math/testcases. EdokterTalk 16:10, 5 December 2010 (UTC)
      • I looked at Template:Math/testcases using Firefox, Chrome, and Internet Explorer on my computer. Bizarrely, the current template looks terrible in Internet Explorer 8, while in Firefox and Chrome the current template looks exactly the same as the "Times New Roman" version displayed second. I have taken some screenshots of this phenomenon:

        I never use Internet Explorer, so these represent the default settings for that browser. Has anyone else been experiencing this issue? It would certainly help to explain some of the difference of opinion on the {{math}} template.

        Jim.belk (talk) 20:37, 5 December 2010 (UTC)
        • Even if you never used it before, some other software may have played with IE's setting. Check IE's font settings (Internet Options > Fonts); it should say 'Times New Roman' under Latin. It works OK on my end with Chrome, Firefox and IE8. EdokterTalk 21:00, 5 December 2010 (UTC)
          • The (Internet Options > Fonts) indeed says 'Times New Roman' under Latin, though that was a good thought. Whatever it is, it doesn't happen on your computer, so I guess it's not a very general problem. Jim.belk (talk) 22:14, 5 December 2010 (UTC)
            • Apparently, IE chooses a different serif font (it's not Times New Roman), but I don't know what's causing it. However, when the the font name(s) will be incorporated, it should no longer be a problem. EdokterTalk 01:09, 6 December 2010 (UTC)
    • I finetuned the metrics even further, testing it in all browsers and a (software) loupe, with each rendering method (plain, smoothing, cleartype). I find that 120% / 1em lineheight gives the most consistent results with Cambria and Times New Roman (with Arial as the base font); they now have equal heights accross the board. I adjusted the samples on the testcases page. For a font defenition, a good start would be font-family: 'Cambria', 'Times New Roman', serif;. Any more suggestions for use with formulae? EdokterTalk 21:36, 5 December 2010 (UTC)
      • It seems to me that the Times New Roman output looks a bit better than the Cambria. Jim.belk (talk) 22:14, 5 December 2010 (UTC)
        • As a Mac user who doesn't use Office, I don't have Cambria installed. Firefox and Safari both fall back to Times. Ozob (talk) 00:03, 6 December 2010 (UTC)
  • Comment. I think the {{math}} version is prettier than the {{nowrap}} version. And there are strong advantages to using serif fonts over sans-serif fonts for mathematicial formulae, where precision is essential: they don't lead to confusion between l (lower case ell) and | (vertical bar, e.g. in absolute value signs) and 1 (number one) and I (capital letter eye). For this reason I would be strongly opposed to mandating sans-serif over serif. But I'm not convinced that the math template is a good enough solution that we should mandate it. What we really need is something more like MathJax. As for fonts, both serif and Times are better than Cambria. —David Eppstein (talk) 22:20, 5 December 2010 (UTC)
    • The sole purpose of {{math}} is to provide proper typefacing for simple (inline) HTML formulae, nothing more. Not every editor is accustomed to the intrecacies and steep lerning curve of math markup languages, so HTML is unavoidable. For more complex formulae, TeX has not let us down yet. EdokterTalk 01:03, 6 December 2010 (UTC)
      • I don't want to derail this thread, so let's just say that I disagree: Wikipedia's TeX support is quite a bit of a let-down, much worse than it could be and much worse than some other sites currently have. —David Eppstein (talk) 05:41, 6 December 2010 (UTC)
  • Sans serif, that is, it should use the same font as the surrounding text. Mixing two fonts, especially a serif and sans serif one, is unesthetic, typographically wrong, and visually distracting.—Emil J. 15:45, 6 December 2010 (UTC)
    • "Typographically wrong" is debatable. As for unesthetic and visually distracting, priority must be given to functionality over beauty. Two other editors have already explained that sans-serif lacks the ability to distinguish between certain characters, which is a problem that can only be solved by using serif, even if it means that it "looks ugly". EdokterTalk 17:52, 6 December 2010 (UTC)
      • In sans-serif the lower case ell can be displayed using the character, vertical bars looks exactly as they should: |x|, number 1 can't possibly be confused with anything else, and only letter I is unfortunate (however in many cases it could be replaced with either J, or , or ). // stpasha » 19:24, 17 February 2011 (UTC)
  • Sans serif. At any rate the appearance of the serif font solution may or may not match that of LaTeX: it really depends on the user's font settings. In some browsers that I uses, the serif font resembles LaTeX and in others it does not. The lack of uniformity is an additional visual distraction that I find hinders the readability of the result. Sławomir Biały (talk) 15:53, 15 December 2010 (UTC)
  • Serif. Usability is more important. Further, I don't think it is desirable to have the equations completely blend in with the surrounding text. I often need to go back to scan a paragraph for an equation that I missed or forgot. The key is the balance of how much you want them to stand out. In the ideal world italicizing the variables and bolding the vectors should be sufficient. In my opinion, though, having a slightly different font with serif in addition to the italics doesn't really hurt. In any case, other than the usability issue, we are rearranging deckchairs on the titanic here. TStein (talk) 16:37, 15 December 2010 (UTC)
p.s.: can a better math symbol font be specified as well. The nabla is being stretched incorrectly on the browsers I use. Further, the subscripts are too big to the point that they are almost unusable. TStein (talk) 16:37, 15 December 2010 (UTC)
I Proposed Cambria, but that had no consensus, so now Times New Roman is used. You can try putting .mathhtml .texhtml { font-family: Cambria, serif; } in your vector.css. EdokterTalk 16:58, 15 December 2010 (UTC)
The class name is actually "texhtml", and as I just found, styling it in vector.css has no effect unless the rule is marked !important.—Emil J. 17:24, 15 December 2010 (UTC)
  • Serif. I think distinguishability of the math symbols from each other is more important than blending into the body text. In fact, I'm not convinced that blending in is a virtue at all: distinguishing math from text, as the serif options do, is also helpful. —David Eppstein (talk) 17:29, 5 January 2011 (UTC)
  • Serif.
    • Legibility: basically lI|1 oO0 rnm ij vvw, extremely important when outside actual words and thus one cannot get context - if I'm an elementary school student, how would I know that current is symbolized by I and not l ("ay" and not "el")?
    • Aesthetics: Does one really read through variables in a text as they would the main body, processing them just like any other word? Also, it is even more difficult to read through an article with actual equations when variables cited inline look completely different - aa is one egregious example, or the confusion when Greek variables are not set aside inline in some way: wω iι vγ.
    • Continuity: Can we please get some consensus, mainly from those who are actually in the mathematical-sciences community? I really have some frustration when people are reverting every which way in some of these technical articles, especially when they think that that is the mandated guideline (which this article makes completely unclear). SamuelRiv (talk) 04:51, 14 January 2011 (UTC)
  • Serif. I prefer the maths bits to stand out in the running text and match up to any bits in LaTeX. It is just wrong for instance I think to start exponentiation with an, and then get into:
The letter 'a' looks completely different in the two cases never mind the 'n', and there's all that trouble with pi. I would like to completely rewrite that so it starts with an and continues on not having big differences between the bits of maths formatting. Dmcq (talk) 09:51, 25 March 2011 (UTC)
  • Serif. That's what all mathematics literature and text books use. In mathematics text, fonts matter a lot - using different fonts for the same alphabet may denote entirely different things. So, to be consistent with mathematics literature, use of Serif font is must. Even when it's an inline formula and <math> tag is not desirable, the Serif font must be used using the {{math}} tag. - Subh83 (talk | contribs) 22:37, 15 April 2011 (UTC)

.texhtmlf font defenition

While the discussion regarding serif or sans-serif is ongoing, there is at least consensus that for the serif part, the font defenition of 'serif' alone is not adequate. I proposed Cambria as a prefered font, but Times New Roman has the obvious preference. So I will change the font defenition to 'Times new Roman', serif; in the skin files to reflect this. EdokterTalk 15:43, 6 December 2010 (UTC)

If the idea is to match TeX output, you can as well add cmr10, 'Latin Modern Roman'.—Emil J. 17:04, 15 December 2010 (UTC)

Italic Greek letters

I believe the idea that Greek letters used in maths should always be upright because Greek does not have italic letters is based on a wrong idea. They are not Greek letters when they are used in maths, they are maths symbols derived from the Greek alphabet. Consistency with maths is more important in maths than consistency with Greek. Dmcq (talk) 13:46, 19 February 2011 (UTC)

This is up to editors, in that you can use italic or upright Greek for variables, but constants should upright, or at least that's how I read MOS:MATH#Greek letters. Personally I think upright works better: being cursive Greek letters like α, β already look like italic forms: with serif fonts the italic form is usually cursive. Italicising greek letters just looks odd. E.g. compare α and α / . I suspect this is very subjective and depends also on font/browser/OS combination.--JohnBlackburnewordsdeeds 14:56, 19 February 2011 (UTC)
  • Looking at the books on my shelf, 16 of them use italic greek letters, and 2 use non-italic. Out of those 2 one book is very old, published in pre-computer era, while the other is quite new. Looking at some research papers downloaded from different journals, 39 of them had italic greek letters, and 3 non-italic. So I guess the current MoS's claim that "greek letters are usually non-italicized" is dubious at best. Besides, the LaTeX installation used on Wikipedia comes with italicized greek letters, so using the italic greek letters both in LaTeX formulas and in inline text would help making formatting in the article more consistent.  // stpasha »  21:25, 20 February 2011 (UTC)
I agree with italicizing Greek variables, and the MOS should be clarified to reflect this. Then again, we may be nowhere near resolving the serif-vs.-sans-serif issue, so I'm not sure how everyone would react.
Just a side note to all this typography debate: historically, using blackboard-bold in textbooks was an accident of cross-medium imitation (blackboard to print). Use of italics in equations may have served a similar purpose in clearly separating variables from main text and thus are an accident of print. Though the dialogue of mathematics evolves as naturally as language, scientists as a professional duty have some obligation to be conservative/procedural about convention, and thus may issue prescriptivist recommendations (such as refraining from blackboard-bold in print).
Readability is the first concern by far (as when a condensed-matter paper uses π for momentum when there are a bunch of ρs lying around that look like ps), but after that we should look at prescription and precedent, as done above. SamuelRiv (talk) 21:15, 9 March 2011 (UTC)

Diagrams and graphs

How about this:

There is no general agreement on what fonts to use in graphs and diagrams. In geometrical diagrams points are normally labelled using upper case letters, sides with lower case and angles with lower case Greek letters.
Recent geometry books tend to use an italic serif font in diagrams as in A for a point. This allows easy use in LaTeX markup. However older books tend to use upright letters as in A and many diagrams in Wikipedia use sans-serif upright A instead. Graphs in books tend to use LaTeX conventions, but yet again there are wide variations.
For ease of reference diagrams and graphs should use the same conventions as the text that refers to them. If there is a better illustration with a different convention though the better illustration should normally be used.

I think that describes the situation. Any thoughts? Dmcq (talk) 09:30, 25 March 2011 (UTC)

Anyway I've stuck it in which is better for seeing what people think! Dmcq (talk) 23:40, 25 March 2011 (UTC)
For drawings it might not only be of interest which font old and ne text books, but als what is used in various popular programs used for geometry or geometrical drawings. However personally I don't think it really matters (at all) which font is used as long as the notation in the general (not the font) is easily matched with the notation in the article.--Kmhkmh (talk) 00:20, 26 March 2011 (UTC)

Square brackets

I've added a section on square brackets when used within html, this also treats the case of intervals specially as they occur often. I don't think the problem of people fixing the brackets happens so often with Latex markup. You can see where I've applied the templates in atan2 (it uses all four different types!) Dmcq (talk) 13:06, 16 March 2011 (UTC)

I wonder if it would be a good idea for the MOS to adopt the international standard notation. What do you think? It certainly looks more intuitive and consistent to me. --Waldir talk 01:21, 1 May 2011 (UTC)
I've always thought that looked bad: In conventional American notation, parentheses and brackets match up somewhat like they do in an algebraic formula. The ISO notation always makes me think someone's made a typo. Ozob (talk) 02:19, 1 May 2011 (UTC)
Yes, but on the other hand it is much more intuitive than the American convention, which you can't figure out without prior knowledge about what each type of bracket means in that context. The ISO convention makes it at least guessable. --Waldir talk 14:19, 22 July 2011 (UTC)
For what it's worth, the "conventional American notation" is also the convention in the UK and Australia; I wouldn't be surprised to find that it's the de facto standard for anyone writing about mathematics in English. A peek at ISO 31-11 reveals that the ISO standard includes both styles; it's not clear whether either is officially preferred. I think en.wikipedia should stay with what we're currently using. Jowa fan (talk) 12:58, 31 July 2011 (UTC)

Allowed characters in HTML

The editor I use on wikipedia shows the following characters or templates as available for sticking into the text under 'math and logic'

− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤
≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩
∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ ⟨ ⟩
{{frac||}}   − <math></math> {{math|}}

And personally I'd like to use the characters in the math template so they'd appear in inline maths as

− × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤
≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩
∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ ⟨ ⟩

Do people agree that all these are now supported well enough that they are okay to use in Wikipedia articles and the current advice in MOSMATH that R be used instead of ℝ (or R instead of if using the math template) because of possible lack of support in browsers should now be removed?

Another thing to think about if these are okay then perhaps \textstyle math could also generate html when it comes across these characters instead needing to generate PNG images. I believe that would make a lot of inline maths look better. Dmcq (talk) 16:09, 26 March 2011 (UTC)

ok to use - yes, but mandate - no.--Kmhkmh (talk) 16:40, 26 March 2011 (UTC)
Some of these characters are horribly broken on my setup. And I use Vista with all SPs and Firefox 4.0. The characters that do not look ok at all are the set characters (e.g., subset-of) and the logical-arrow characters. The worst is element-of, which has a completely different appearance for smaller (and regular) font sizes than when I increase the font size: it looks like being overly stretched in height. Nageh (talk) 17:15, 26 March 2011 (UTC)
Odd. I just checked in IE 8.0, and all the characters render differently, in both Courier New and Sans Serif font. The element-of and logical-arrow characters are ok now, but instead the blackboard characters are hardly distinguishable. Nageh (talk) 17:34, 26 March 2011 (UTC)
That is extremely strange. Check your FF settings. All the above characters look fine on Win 7 + FF 4, both in the standard font Arial (I think) and in the edit box. It's possible that Win 7 has updated fonts compared to Vista. Tijfo098 (talk) 00:25, 4 May 2011 (UTC)
I'm happy with that: for me ℝ is better for the reals as it's less ambiguous than R. But we should get more feedback as it's not just a matter of what looks good but what works on different OSes with different browsers. I think the biggest problem is XP with older versions of IE. On the TeX renderer I think there's less of a problem with that as it's something users can adjust if necessary in preferences. I suspect it's a lot less trivial to do though as I think the TeX renderer is part or MediaWiki, not just an English WP script or setting we can adjust.--JohnBlackburnewordsdeeds 17:21, 26 March 2011 (UTC)
I just tried google Chrome, Firefox 4, Opera and IE8. Chrome was very good and looked the best for me. Firefox 4 and Opera were okay, Firefox had some horizontal lines darker than they should be but it was acceptable, and IE though it rendered all the characters just didn't look good at all. In particular in IE8 the blackboard bold was really nasty as noted before above. I'm on Windows 7. It looks like there is a real problem with IE8 which is ... a bit of a bummer. Perhaps Wikipedia is doing a special stylesheet for IE which is causing problems? Dmcq (talk) 18:05, 26 March 2011 (UTC)
I checked IE 9 in Win 7 and all characters above display fine. IE9 seems to use a slightly different math font for some symbols compared to FF 4, e.g. for ℍ and the other blackboard letters, but it's not a major style issue. Tijfo098 (talk) 00:31, 4 May 2011 (UTC)
I'm almost certain that both FF 4 and IE 9 use a form of font substitution, i.e. they pull the Unicode math symbols from whatever font has them available. They seem to have different default fallback fonts lists though. For example in FF4 the double and triple integral symbol are from the same font, but the single integral is from another. In IE9, the single and triple ones are from the same font, while the double is from another. Pretty weird. Tijfo098 (talk) 00:40, 4 May 2011 (UTC)
FF 4 gets all the symbols from Unicode math#Miscellaneous Mathematical Symbols-B correctly whereas IE9 only gets a few (squares for the rest). But other than that MS made a fair bit of progress in that department, almost all other tables there display fine in both browsers, although FF has some "line too thick" issues for some symbols as noted by Dmcq above (this is more obvious in the larger font sizes). The first line from Unicode math#Miscellaneous Mathematical Symbols-A doesn't display most of the symbols in the first line in either browser though on Win 7; I need more/otehr fonts I guess. Tijfo098 (talk) 00:47, 4 May 2011 (UTC)
I can see all the characters in Firefox 4 and Safari 5 on Mac OS 10.6, except possibly □ (fourth from the right on the bottom line; it renders as a square). But we can't rely on these characters until everyone can see them, and from the sound of it, that's years away. Even then I object to the blackboard bold letters. As the page currently says, "Traditional mathematical typography never used printed blackboard bold because it is harder to read than ordinary boldface." This is still true; as Serre said, blackboard bold should only be used on a blackboard. Ozob (talk) 01:36, 4 May 2011 (UTC)
It is a square, if it wasn't there you'd see a taller rectangle! So in fact you see them all okay. Dmcq (talk) 07:41, 4 May 2011 (UTC)
By the way I discovered that IE and Word on Windows was substituting MS Mincho for the maths characters when using Times Roman which isn't exactly ideal. My Firefox was sticking in Dejavu instead I think and why they all do something different I do not know. Dmcq (talk) 07:53, 4 May 2011 (UTC)
I don't believe the argument "Traditional mathematical typography never used printed blackboard bold because it is harder to read than ordinary boldface." is well-founded. First of all, Wikipedia isn't a printed book, and even in print, blackboard bold has a tradition, and is widely used in textbooks. Whether it is harder to read than ordinary boldface for symbols that appear alone, is a matter of font design and personal preference. One aim of mathematical notation is to make it stand out from ordinary text. — Preceding unsigned comment added by (talk) 05:19, 31 July 2011 (UTC)
I don't think the issue is primarily paper versus monitor. I think the main problem is that blackboard bold letters have extremely high contrast double lines where most typefaces have solid lines, creating an inconsistent weight and a large amount of unusually placed negative space. It's the opposite of the very legible Century Schoolbook typeface. I think all of this is worse on a monitor, where the resolution is so much poorer than in print, but the problem is still there in both media. It's also there on a blackboard, but on a blackboard it's better looking than true boldface because true boldface is so much higher weight than ordinary writing. Ozob (talk) 13:17, 31 July 2011 (UTC)

RFC: restructuring of the Manual of Style

Editors may be interested in this RFC, along with the discussion of its implementation:

Should all subsidiary pages of the Manual of Style be made subpages of WP:MOS?

It's big; and it promises huge improvements. Great if everyone can be involved. NoeticaTea? 00:43, 25 June 2011 (UTC)

'Times' character

The template {{times}} is now available, to display a typographically correct 'times' character (&times; in HTML); for eample 4{{times}}100 renders as 4×100. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:14, 6 August 2011 (UTC)

That seems totally pointless. It's fewer keystrokes to just type &times;. (talk) 04:52, 8 August 2011 (UTC)
Now at TFD Wikipedia:Templates for discussion#Template:Times.--Salix (talk): 07:20, 8 August 2011 (UTC)
The point is improved readability for novice editors and others not familiar with HTML. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:14, 8 August 2011 (UTC)

Italicizing Greek letters in mathematical notation

I was surprised to find at Wikipedia:MOSMATH#Greek_letters that

Greek letters are not commonly italicized, so that one writes, for example, λ + y = π r2,

But look at what happens in TeX:

I had thought the over-arching rule was that things italicized in TeX are to be italicized in non-TeX mathematical notation. Thus:

TeX italicizes lower-case Greek letters, but not capital Greek letters.

So it should be in non-TeX notation. I propose that this languate in WP:MOSMATH be changed. Thoughts? Michael Hardy (talk) 18:44, 29 June 2011 (UTC)

PS: I've posted this same thing at Wikipedia_talk:WikiProject_Mathematics#Italicizing_Greek_letters_in_mathematical_notation. Michael Hardy (talk) 18:44, 29 June 2011 (UTC)
Currently the example is ''&lambda;'' + ''y'' = &pi; ''r''<sup>2</sup>, with lambda italicised but pi not, which seems irregular to me. This should be explained or fixed. I thought in the past I read that Wikipedia’s rule was Greek symbols weren’t italicised, maybe something like because Greek script is traditionally cursive to begin with. Not sure exactly where I got that idea though.
 Also, quickly looking at the markup for some of the rest of this MOS page gives me the impression that most of the Greek symbols here aren’t italicised. Vadmium (talk) 12:06, 2 September 2011 (UTC).
I did some playing around and it also seems that Media wiki converts Greek Tex to HTML without specifically italicising it. Try playing with the “Math” rendering options in Special:Preferences#preftab-1 and compare
  • (using <math>)
  • π = 3.1 (plain wiki code)
  • π = 3.1 (apostrophes for italic)
  • (<math>)
  • e = 2.7 (roman, unitalicised, wiki code)
  • e = 2.7 (italic apostrophes)
Vadmium (talk, contribs) 04:13, 29 September 2011 (UTC).
I've fixed the abovementioned example. I personally have a preference for maximal similarity of TeX and inline symbols (and hence italic Greek symbols), but to make this into a guideline will evidently have to be initiatied via a WP:RFC. Quondum (talk) 09:59, 30 October 2011 (UTC)
The "TeX" above is not rendered as actual TeX. to do that, you have to add \,\! at the end of the formula. The "textified" TeX is what one sees above, which is a modifiable in a separate template, same as that of the {{{1}}} template. So:
( <math> TeX forced into PNG format)
( <math> allowed to render into HTML text)
Πi e^[ i * i π ] = 1/2 \( {{math}} with appropriate italics)
Πi e**[ i × i π ] = 1/2 ( {{math}} with opposite italics)
And just to restate my opinion, tagging is critical, and unless I can think of some viable way to get <math> to perfectly decided when and when not to render, I'm firmly supporting use of the {{math}} template. SamuelRiv (talk) 05:28, 1 November 2011 (UTC)
Your second example ("<math> allowed to render into HTML text") actually renders as PNG with my set preferences, which I believe are the default. This renders as HTML for me:
I agree that the automated PNG/HTML selection is badly done - it is difficult to predict what determines it. This is a different topic. — Preceding unsigned comment added by Quondum (talkcontribs) 06:07, 1 November 2011 (UTC)

Commas in numbers?

In many countries it is customary to use commas in large numbers (e.g. 123,456.789). I need to know if this is done in negative numbers. Is it correct to write -123,456.789? What is recommendation? –droll [chat] 22:30, 25 August 2011 (UTC)

Here in America I would consider it correct. (But on Wikipedia we usually do not use commas.) Ozob (talk) 01:20, 27 August 2011 (UTC)
Thanks. –droll [chat] 02:58, 27 August 2011 (UTC)

Branch - blackboard bold

A previous section almost got into discussing the use of Blackboard Bold as a font subtype, namely for denoting the named sets (reals, integers, etc). I think it warrants at least a little discussion or even guidelining. I personally have no strong opinions, since there's plenty more horrible uses of 20 different fonts of the same letter to denote different things in the same textbook, but I will point out that the typesetter-in-chief Donald Knuth disapproves of bbold in print, even for sets. Also, see an interesting outside discussion on this. SamuelRiv (talk) 05:10, 5 September 2011 (UTC)

Use of boldface for terms

Hello. I'm interested in encouraging the use of boldface for certain terms appearing for the first time in the body of math articles. At the project discussion page, User David Eppstein gave the following interpretation of the current MoS:

...use boldface for the first introduction of the title of the article (or for terms that redirect to it, or terms that do not have an article but could reasonably redirect to it), italics for emphasis, and italics for new terms being defined that are not the article title or a reasonable redirect.[14]

This is pretty much what I envisioned adding to the MoS:Math. The only thing I would want to clarify is that I think this should also apply to terms appearing in the body of the article. The reasoning is: when people are redirected they can immediately see what they are looking for. Naturally boldface shouldn't be overused, and perhaps a cautionary note about overuse would appear alongside the above interpretation. Rschwieb (talk) 15:21, 6 October 2011 (UTC)

Use of LaTeX

I'd like to have to following downside of inline <math> blocks added:

  • Copy-pasting of inline math images will often not work.

Also, has anybody looked at how commonly used accessibility tools for visually impaired users handle math blocks? I assume they will not work well, which would be another reason to not use them when not absolutely required.

    SkyLined (talk) 14:37, 14 November 2011 (UTC)
Visually impaired users can set their math preference to show the raw TeX code, so that no images are generated. — Carl (CBM · talk) 14:53, 14 November 2011 (UTC)

Thanks, that takes care of that concern. If nobody objects within the next week or so, I'll add the remark about copy+pasting.    SkyLined (talk) 17:00, 14 November 2011 (UTC)

 Done     SkyLined (talk) 22:02, 21 November 2011 (UTC)

Comment by‎

Do we want the outsiders of the mathematical culture to get an easy way in or do we not?

I would like to comment on the how to write an Article Introduction section:

What is said there is sound and good, and I would like to add this.

Mathematical writers should be aware of that they are influenced by the math academic culture they belong. This is not generally true for many of their intelligent readers.

I stumbled across this article by Marvin Minsky that is well worth reading: [ Not that the readers are alians:) (But not far from sometimes..) The article discuss fundamental aspects on how to communicate, math and other things. ]

 Communication with Alien Intelligence by Marvin Minsky

— Preceding unsigned comment added by (talk) 11:12, 19 December 2011

It's a nice link, but not really relevant here, where our readers are human and capable of, well, reading. With training one can get through the most advanced mathematics articles, and inversely the advanced mathematics articles are only really relevant to those with training (but please play nice for the physicists and chemists). That said, we can and should always strive to make mathematics text and articles more readable (anywhere, not just on WP but in any academic or lay publication). For myself at least, it's a constant learning process. However, your link is not really about writing and educating in mathematics at all, but rather about the fundamentals of communication itself. SamuelRiv (talk) 17:46, 22 December 2011 (UTC)


Sensible point raised on a GA [15] - what's a good way to reference derivations? (Personally I'd say something along the lines of, 'The following derivation follows from Wizard, 2004 and do a single cite, but I'm well out of my area...) Failedwizard (talk) 21:26, 21 December 2011 (UTC)

Derivations have historically been a touchy subject. But I think everyone agrees that if there is a derivation in a book or paper that is being reproduced in the article, it can be cited just the same as any other fact would be. The difficulty is more when small changes are made, just like when some source is paraphrased in a different subject - editors can discuss whether a certain paraphrase is adequate, or whether a certain derivation is too novel. There's no hard and fast rule, but he have to keep both WP:OR in mind and our goal to present the subject in an clear and encyclopedic manner. — Carl (CBM · talk) 22:00, 21 December 2011 (UTC)
I think the point is whether there be some word or phrase used to indicate that the material is paraphrased rather than citing a specific fact. I've gotten into the habit of using "Following..." before a cite to do this. See, for example, cites 2,5 and 8 in Isosceles triangle theorem. This hasn't been questioned until now but none of the articles have had a GA review either.--RDBury (talk) 19:25, 29 December 2011 (UTC)

Variables in {{mvar}}

Is it right that the guideline, and specifically WP:Manual of Style/Mathematics#Variables does not mention {{mvar}} as an alternative to wikicode italics? Templates are more customizable. Incnis Mrsi (talk) 19:24, 22 February 2012 (UTC)

I'm sure you remember the brief discussion Wikipedia_talk:WikiProject_Mathematics/Archive/2012/Jan#Template:mvar. The one person who commented (other than us) seemed to think that {{mvar}} was acceptable. Given that, I don't see anything wrong with mentioning it here. I would only object if you wanted the MoS to say that it was required or preferred or that plain italics were discouraged. I think that putting {{mvar}} everywhere is not a good investment of our resources. Better <math> support is supposed to be coming soon, and my hope is that when that's available we can switch everything to <math>. Ozob (talk) 22:53, 22 February 2012 (UTC)

Update due to MW 1.19

With MediaWiki 1.19 it's no longer possible to render LaTeX as HTML, i.e. formatted like the {{math}} template for simple formulae. Those options have simply been removed. With this the sections 'Very simple formulae' and 'Forcing output to be an image' no longer made any sense. I've removed them and added a note about the quarter space and other formatting which will still appear in many formulas, with {{anchor}} section links for the old titles. To discourage anyone from going around and removing all this formatting I've suggested they should only be removed when otherwise updating a formula, which I think is the best advice.--JohnBlackburnewordsdeeds 21:57, 2 March 2012 (UTC)

Sans-serif maths font

Is there any reason why one would or should use sans-serif fonts in maths formulas, such as for the letter "I" at Tensors_in_curvilinear_coordinates#Vector_operations, 1. Identity map? If not, I shall probably revert the recent addition of a section on sans-serif letters in Help:Latex to discourage people from its use. Nageh (talk) 11:37, 6 May 2012 (UTC)

Continued from Help talk:Displaying a formula#\mathsf (sans serif)
Matrices and tensors can be written in bold capital, sans serif, double underarrow/double underscore/whatever, the list could go on and on depending on the author's preference. I am not saying sans serif should become dominant in WP, and that all sources use sans serif, again it’s only an alternative font for editors to use in the odd cases when different fonts are used.
Obviously we can't use sans serif all the way through an article (unless LaTeX is not used). Given that we should use the same notation styles in the literature, this should not be done anyway, so people can and should just use the defualt fonts in the LeTeX rendering. I would suggest that in Wikipedia:Manual of Style/Mathematics#Notational conventions we write something along these lines, (I know I'm the cause, but I don't have much time for this right now). F = q(E+v×B) ⇄ ∑ici 13:21, 6 May 2012 (UTC)

Just to outline my recommendations:

  1. Vectors: capital or lowercase, plus underline (perhaps for tuples)
    or arrow/bold (for "geometric/physical" vectors/vector fields associated with a direction):
    of course either case is usual and interchangeable. However sources also use lowercase sans serif for row/column vectors:
    so I don't know if people would use this in conjunction with sans serif matrices...
  2. Matrices/dyadics/2nd order tensors: capital and bold
    or bold/non-bold sans serif
    (presumably the former may be preferable). The exceptions to these are if the context simply uses italics as though they were scalars (see the Dirac matrices in the Dirac equation or Pauli matrices ).
  3. Tensors in general: use bold sans serif, as in
    rather than just bold or bold-italic , and not blackboard bold... as currently used in the Navier–Stokes equations:
    which could be written:
  4. Standard sets: (real, complex numbers etc) use blackboard bold as usual: , rather than ordinary bold as sometimes used, which would be reserved for vectors/matrices.

In this way, ambiguity is prevented, since

  1. The lower case "l" (ell) for (say) a vector will not be in sans serif, but usual serif (and preferably curly) , or even .
  2. The identity operator/matrix written as next to other letters should not be confused for a vertical bar such as , also . For statements like:
    in tensors in curvilinear coordinates, it should be clear that " is the identity map" is not a "misplaced bar" (or whatever): ...
  3. Tensor equations (without resort to indices) can be written
    rather than
    where the first may be confused for a vector equation, the second is less obvious for which quantities are vectors or tensors for someone who doesn't know. (The equations should obviously be clarified in the context anyway, but the notation may appear inconsistent for some, and it would be more obvious and followable for the reader if bold serif was for vectors, bold sans serif for tenors).

Anyway that's how I propose to use sans serif with everything else, if used at all... I will not use it myself, unless this is accepted (so to speak, even then only very occasionally). =| Best, F = q(E+v×B) ⇄ ∑ici 15:37, 6 May 2012 (UTC)

Actually, sans serif looks better with bold upright, and serif looks better in italic. --The Doctahedron, (talk) 22:14, 13 June 2012 (UTC)

"Divisible" or "evenly divisible" in general interest articles

User:Connor Behan has been systematically changing "evenly divisible" to "divisible" in general interest articles such as "Gregorian calendar" and "Year 2000 problem". It had been my impression that mathematicians would use "divisible" but the general public might be confused by the fact that any two integers may always be divided, possibly with a non-integer quotient. So I looked in American Heritage Dictionary 3d. ed. and the guidance wasn't clear. There was no listing for "evenly divisible" and for "divisible" I found

divisible adj. Capable of being divided, especially with no remainder: 15 is divisible by 3 and 5. [Pronunciation omitted]

So what is the best term to use in a general interest article to mean that the result of dividing two integers is an integer? Jc3s5h (talk) 11:27, 18 June 2012 (UTC)

This topic is being discussed at Wikipedia_talk:WikiProject_Mathematics#Mathematical_language_must_be_precise. Gandalf61 (talk) 11:31, 18 June 2012 (UTC)

Inline math notation 2

The method of displaying Inline math notation has been discussed before, but it appears inconclusive. It would be helpful if the Manual of Style/Mathematics at least offered a preference over whether to use (a) <math>/PNG images (b) {{math}} (c) MathJax (d) MathML (e) HTML. Would an RFC be the way forward? --Iantresman (talk) 17:45, 13 August 2012 (UTC)

The situation has been in flux lately with working MathJax support (in user preferences rather than via custom scripts) only a few weeks old. So my preference would be to wait for now. In the meantime, I think rules similar to WP:RETAIN should remain in play: format individual articles consistently, but don't gratuitously change the formatting of an article. —David Eppstein (talk) 18:04, 13 August 2012 (UTC)
As I just remarked on a talk page of a heavily math loaded article, I have now activated MathJax (again). I admit that it makes all math —that is, inline and standalone— look significantly better. Major drawback is that some articles take even more significant ages to load :-( - DVdm (talk) 18:06, 13 August 2012 (UTC)
MathML would seem to be the standard to strive for, though I find MathJax unusable (too slow). But giving people the option to enable it in preferences is a fine solution. --Iantresman (talk) 19:20, 13 August 2012 (UTC)

Conflicting instructions

Copying from the main MOS discussion page, since this is a math-internal discrepancy:

WP:Manual of Style (mathematics)#Choice of type style says "The most well-known functions—trigonometric functions, logarithms, etc.—have no parentheses. For example: ". But WP:Manual of Style (mathematics)#Functions says "f(x) = sin(x) cos(x)".

Do we want two acceptable styles, with some guidance as to when we use each? Allow random use, as long as it's consistent within an article? Choose one and proscribe the other? — kwami (talk) 00:09, 21 October 2012 (UTC)

Tagged the offending passages, noting that the conflict. — kwami (talk) 20:14, 24 October 2012 (UTC)
Have you written mathematics very much? The parentheses are sometimes needed, so they cannot be forbidden:
vs. ; vs.
But at the same time they are often omitted in simple formulas. — Carl (CBM · talk) 22:14, 24 October 2012 (UTC)
Sure. But that's not what the MOS says: it says that trig functions "have no parentheses". I think that absolute injunction needs to be moderated, but what wording would be best? "Parentheses may be omitted from well-known functions, such as trigonometric functions and logarithms, when they are not needed for disambiguation", maybe? Or they "are not used" unless needed for disambiguation? — kwami (talk) 23:35, 24 October 2012 (UTC)
I think it was just a slip of the tongue, nothing major. I edited the page before my last comment; feel free to edit it more. I don't think it's a very big issue. There's no need for the page to try to micromanage they way that people use parentheses. — Carl (CBM · talk) 23:39, 24 October 2012 (UTC)
Yes, I doubt the mathematically literate are going to argue about this, unlike punctuation in prose, so it probably doesn't matter. — kwami (talk) 23:46, 24 October 2012 (UTC)
Thanks for fixing it. Art LaPella (talk) 03:11, 25 October 2012 (UTC)

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

There seems to be no uniformity in the use of a·b = &middot; = &#x00B7; (Unicode MIDDLE DOT) and a⋅b = &sdot; = &#x22C5; (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.[16][17]. 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 &sdot; 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)
&sdot; has broad coverage. &middot; 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)


See also Talk:Differential_of_a_function#Detalic. — Preceding unsigned comment added by Wikispaghetti (talkcontribs) 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. (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 Hn (should be italics) or Hen (should be upright). For example the MathWorld page on Hermite polynomials displays Hn and Hen this way. You could argue that Hen are standard functions just as sin is, but then Hn 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 ,
<math>\operatorname{myfunct}(x)</math> gives ,
<math>\mathit{myfunct}(x)</math> gives .
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∧Ŝc2ħεИτ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∧Ŝc2ħεИτ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 (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 C0(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 (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):
  • With \textstyle:
  • With \scriptstyle:
  • With \displaystyle:
  • With :<math>: :

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∧Ŝc2ħεИτlk 17:54, 10 March 2014 (UTC)


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


a right   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 (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. . 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 [18], 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''<sub>1</sub>]], rendering as H1 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.

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 (talkcontribs) 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:

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∧Ŝc2ħεИτ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:

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):

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:


\mathsf (shows sans serif in PNG too)

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

Also not working in MathJax but working in PNG:


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

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:
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, log2, 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 and 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
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? (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
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 or , 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
11:42, 1 January 2016 (UTC)

Are algorithms "invented" or "discovered"?

Are mathematical algorithms "inventions" or are they "discoveries"? -- (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.):

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 , 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: . The creators of LaTeX never intended ":" to be used in map notation, and hence "," 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 . 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 to . 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 ex 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 xx 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)


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:

:An online encyclopedia
:A print encyclopedia

which forms the HTML:

  <dd>An online encyclopedia</dd>
  <dd>A print encyclopedia</dd>

and the final result:

An online encyclopedia
A print encyclopedia

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

Pi is the constant

which form the html:

<p>Pi is the constant</p>

and results in:

Pi is the constant


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

which form the html:

<p>Pi is the constant</p>

and results in:

Pi is the constant


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:

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):



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
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:
is a letter
Instead we get this:

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:

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