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:
<syntaxhighlight lang = "C"> Tn = (1 + n) * n / 2; // triangular number</syntaxhighlighting>
Generates
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.-- JohnBlackburne words deeds 15:44, 10 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)
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)
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)
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;
else
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;
begin
if n = 0 then
fact := 1
else
fact := n * fact(n - 1)
end;
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
else:
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:
\catcode`@=11
\newcount\x
\newcount\n
\def\factorial#1{%
\x=1
\f@ctorial #1%
\the\x}
\def\f@ctorial#1{%
\ifnum#1>0
\multiply\x by #1%
\n=#1\advance\n by -1
\f@ctorial\n
\fi}
\catcode`@=12
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)
Status := Status + StickyFlag;
Status := Status - StickyFlag;
Status |= StickyFlag;
Status &= ~StickyFlag;
const char * const authorName = "Scott Meyers"
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. esac; elihw; Return(-L);
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)
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 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)
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)
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)
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) [1], 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)
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:
int factorial(int n) {
if (n > 1)
return n * factorial(n - 1);
else
return 1;
}
Responding to my Pascal example above, EmilJ wrote:
Responding to my TeX example above, EmilJ wrote:
\newcount\x
\newcount\n
\def\factorial#1{%
\x=1
\n=#1
\dofactorial
\the\x}
\def\dofactorial{%
\ifnum\n>0
\multiply \x \n
\advance \n -1
\dofactorial
\fi}
\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.\expandafter
.
Ozob (
talk)
00:50, 25 February 2010 (UTC)
The discussions seems to get sidetracked somewhat. Originally we started with something like:
Can't we all more or less agree on that?-- Kmhkmh ( talk) 12:08, 25 February 2010 (UTC)
Eppstein ( talk) 16:08, 25 February 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)
min := 1;
max := N; {array size: var A : array [1..N] of integer}
repeat
mid := (min + max) div 2;
if x > Amid then
min := mid + 1
else
max := mid - 1;
until (Amid = x) or (min > max);
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
@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)
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
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
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)
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:
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)
Let me recompose my view
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)
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)
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)
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 1⁄2 (using {{ frac}}) or even ½? — bender235 ( talk) 14:40, 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)
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 1⁄2 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 1⁄2. — Carl ( CBM · talk) 22:50, 31 March 2010 (UTC)
Since David Eppstein and me disagree on what is "consensus" here, let's find out.
Recommend the use of in general, and condone the use of 1⁄2 in non-mathematical context. Discourage the use of 1/2 and ½.
Recommend the use of in general, and condone the use of 1/2 in non-mathematical context. Discourage the use of 1⁄2 and ½.
Advise that , 1⁄2 and 1/2 are all acceptable. Advise against the use of ½.
Recommend the use of and 1/2 in mathematical context, and discourage the use of 1⁄2 and ½ in mathematical context. Leave non-mathematical context unregulated.
Leave the decision to (main) authors working on the concerned articles and find something else to argue.
It seems like the above discussion isn't separating some important concerns:
Personally, I find the {{frac}}
template ghastly, typographically. However, making the denominator doubly <small>
rather than <sub>
helps a lot: 100⁄200 rather than 100⁄200. To my eye, that first version seems competative with the case fraction symbol while still be extensible beyond the existing case-fraction symbols (compare 1⁄2 ½).
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:
{{frac}}
to produce 1⁄2.Would that answer everyone's concerns? —Ben FrantzDale ( talk) 15:07, 2 April 2010 (UTC)
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 1⁄2 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)
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)
What should be the notation for empty set? Should it be or ? Mpd1989 ( talk) 10:26, 20 April 2010 (UTC)
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)
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)
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)
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)
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)
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)
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)
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... |
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 |
I made some tweaks to try and address concerns.
TStein ( talk) 14:58, 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)
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? — Edokter • Talk • 10:31, 5 December 2010 (UTC)
Here's a paragraph from Logarithm done both ways. First, with {{ nowrap}} (sans-serif):
Next, with {{ math}} (serif):
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)
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)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. — Edokter • Talk • 15:43, 6 December 2010 (UTC)
cmr10, 'Latin Modern Roman'
.—
Emil
J.
17:04, 15 December 2010 (UTC)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)
How about this:
I think that describes the situation. Any thoughts? Dmcq ( talk) 09:30, 25 March 2011 (UTC)
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)
The editor I use on wikipedia shows the following characters or templates as available for sticking into the text under 'math and logic'
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)
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. Noetica Tea? 00:43, 25 June 2011 (UTC)
The template {{
times}} is now available, to display a typographically correct 'times' character (×
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)
I was surprised to find at Wikipedia:MOSMATH#Greek_letters that
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)
''λ'' + ''y'' = π ''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.\,\!
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:
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)
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)
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:
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)
I'd like to have to following downside of inline <math> blocks added:
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.
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)
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 ( http://web.media.mit.edu/~minsky/papers/AlienIntelligence.html)
— Preceding unsigned comment added by 85.164.125.248 ( talk) 11:12, 19 December 2011
Sensible point raised on a GA [3] - 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)
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)
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.-- JohnBlackburne words deeds 21:57, 2 March 2012 (UTC)
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)
Just to outline my recommendations:
In this way, ambiguity is prevented, since
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)
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)
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)
Copying from the main MOS discussion page, since this is a math-internal discrepancy:
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)
@ Mikhail Ryazanov: ( [4])
MOS:MATH#Multi-letter_names gives an example using \text
but https://tex.stackexchange.com/a/98407 says this "might seem ideal, but it changes font according to the context, so the subscript would appear in italics in a theorem statement."
Are we sure we want to recommend \text and not \mathrm? It does eliminate spaces and hyphens in label names, but those arguably shouldn't be there in the first place. — Omegatron ( talk) 17:53, 1 February 2021 (UTC)
{\rm ...}
and similar: these are
long-obsolete OFSS commands and should not be used at all. Then, as mentioned above, \mathrm{...}
means "roman type in the math mode" and should be used for that purpose (for example, some people believe that derivatives must be typed like instead of just , and in this context "" is really a "roman" mathematical symbol), while \text{...}
means "regular text within a formula", so it should be used for all notation that would be used without special markup in regular text. Regarding the JFET article, I don't think that things like "GS" are mathematical symbols. For example, if "gate–source (GS) junction" is italicized in regular text, it should become "gate–source (GS) junction" rather than "gate–source (GS) junction", so the same rules should apply to it when it is inside a formula ("gate–source bias VGS is..." → "gate–source bias VGS is..."), exactly what \text{...}
does in LaTeX (although this is hardly important in WP). In any case, \text{...}
is also shorter than \mathrm{...}
:–) and treats spaces and hyphens properly (which are legitimate symbols in indices). —
Mikhail Ryazanov (
talk)
14:44, 2 February 2021 (UTC)\operatorname
for "Effectiveness", but since "SUE" is used with an argument, it probably should be typed so. (Besides this, I also suggest reading
MOS:MATH about indentation and punctuation; and
MOS:CAPS for the terms in the lead: they all should be lower-case, even if taken from sources with different style guides.) —
Mikhail Ryazanov (
talk)
20:40, 5 February 2021 (UTC)I know that there has been a lot of discussion about blackboard bold vs. boldface already, but right now I feel that the text
is worded so as to hint that authors who use boldface are behind the times and dying out, whereas the truth is that there are plenty of younger mathematicians at the highest level (as well as older ones) who seem to prefer boldface. Some examples are Terence Tao, Jacob Lurie, Song Sun, Bhargav Bhatt and Peter Scholze in their prismatic cohomology article, Brian Lawrence and Akshay Venkatesh in their work on the Mordell conjecture, the authors of the Stacks project, and so on. Also, I feel that there are plenty of other widely accepted uses of blackboard bold, such as those listed below. Therefore I would suggest replacing the text above with something like
Ebony Jackson ( talk) 22:16, 15 March 2021 (UTC)
The version reverted by Ebony Jackson got a consensus at WT:WikiProject Mathematics/Archive/2020/Nov#MOS:MATH#Blackboard bold. So, it should not be reverted without a new consensus, and the reverted version must be restored. However, as I am the main author of this version, I leave this to another editor. D.Lazard ( talk) 11:14, 24 March 2021 (UTC)
Certain objects, such as the real numbers R, are traditionally printed in boldface. On a blackboard or a whiteboard, boldface type is replaced by blackboard bold. Traditional mathematical typography never used printed blackboard bold because it is harder to read than ordinary boldface. Nowadays, however, some printed books and articles use blackboard bold.This suggest strongly that it is not a good practice to use blackboard bold. If this would an impact outside Wikipedia, this would be a serious issue. In any case, we must have a version that corrects this non-neutral formulation. D.Lazard ( talk) 11:14, 24 March 2021 (UTC)
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:
<syntaxhighlight lang = "C"> Tn = (1 + n) * n / 2; // triangular number</syntaxhighlighting>
Generates
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.-- JohnBlackburne words deeds 15:44, 10 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)
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)
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)
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;
else
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;
begin
if n = 0 then
fact := 1
else
fact := n * fact(n - 1)
end;
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
else:
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:
\catcode`@=11
\newcount\x
\newcount\n
\def\factorial#1{%
\x=1
\f@ctorial #1%
\the\x}
\def\f@ctorial#1{%
\ifnum#1>0
\multiply\x by #1%
\n=#1\advance\n by -1
\f@ctorial\n
\fi}
\catcode`@=12
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)
Status := Status + StickyFlag;
Status := Status - StickyFlag;
Status |= StickyFlag;
Status &= ~StickyFlag;
const char * const authorName = "Scott Meyers"
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. esac; elihw; Return(-L);
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)
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 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)
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)
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)
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) [1], 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)
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:
int factorial(int n) {
if (n > 1)
return n * factorial(n - 1);
else
return 1;
}
Responding to my Pascal example above, EmilJ wrote:
Responding to my TeX example above, EmilJ wrote:
\newcount\x
\newcount\n
\def\factorial#1{%
\x=1
\n=#1
\dofactorial
\the\x}
\def\dofactorial{%
\ifnum\n>0
\multiply \x \n
\advance \n -1
\dofactorial
\fi}
\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.\expandafter
.
Ozob (
talk)
00:50, 25 February 2010 (UTC)
The discussions seems to get sidetracked somewhat. Originally we started with something like:
Can't we all more or less agree on that?-- Kmhkmh ( talk) 12:08, 25 February 2010 (UTC)
Eppstein ( talk) 16:08, 25 February 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)
min := 1;
max := N; {array size: var A : array [1..N] of integer}
repeat
mid := (min + max) div 2;
if x > Amid then
min := mid + 1
else
max := mid - 1;
until (Amid = x) or (min > max);
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
@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)
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
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
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)
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:
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)
Let me recompose my view
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)
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)
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)
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 1⁄2 (using {{ frac}}) or even ½? — bender235 ( talk) 14:40, 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)
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 1⁄2 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 1⁄2. — Carl ( CBM · talk) 22:50, 31 March 2010 (UTC)
Since David Eppstein and me disagree on what is "consensus" here, let's find out.
Recommend the use of in general, and condone the use of 1⁄2 in non-mathematical context. Discourage the use of 1/2 and ½.
Recommend the use of in general, and condone the use of 1/2 in non-mathematical context. Discourage the use of 1⁄2 and ½.
Advise that , 1⁄2 and 1/2 are all acceptable. Advise against the use of ½.
Recommend the use of and 1/2 in mathematical context, and discourage the use of 1⁄2 and ½ in mathematical context. Leave non-mathematical context unregulated.
Leave the decision to (main) authors working on the concerned articles and find something else to argue.
It seems like the above discussion isn't separating some important concerns:
Personally, I find the {{frac}}
template ghastly, typographically. However, making the denominator doubly <small>
rather than <sub>
helps a lot: 100⁄200 rather than 100⁄200. To my eye, that first version seems competative with the case fraction symbol while still be extensible beyond the existing case-fraction symbols (compare 1⁄2 ½).
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:
{{frac}}
to produce 1⁄2.Would that answer everyone's concerns? —Ben FrantzDale ( talk) 15:07, 2 April 2010 (UTC)
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 1⁄2 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)
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)
What should be the notation for empty set? Should it be or ? Mpd1989 ( talk) 10:26, 20 April 2010 (UTC)
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)
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)
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)
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)
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)
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)
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)
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... |
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 |
I made some tweaks to try and address concerns.
TStein ( talk) 14:58, 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)
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? — Edokter • Talk • 10:31, 5 December 2010 (UTC)
Here's a paragraph from Logarithm done both ways. First, with {{ nowrap}} (sans-serif):
Next, with {{ math}} (serif):
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)
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)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. — Edokter • Talk • 15:43, 6 December 2010 (UTC)
cmr10, 'Latin Modern Roman'
.—
Emil
J.
17:04, 15 December 2010 (UTC)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)
How about this:
I think that describes the situation. Any thoughts? Dmcq ( talk) 09:30, 25 March 2011 (UTC)
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)
The editor I use on wikipedia shows the following characters or templates as available for sticking into the text under 'math and logic'
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)
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. Noetica Tea? 00:43, 25 June 2011 (UTC)
The template {{
times}} is now available, to display a typographically correct 'times' character (×
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)
I was surprised to find at Wikipedia:MOSMATH#Greek_letters that
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)
''λ'' + ''y'' = π ''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.\,\!
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:
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)
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)
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:
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)
I'd like to have to following downside of inline <math> blocks added:
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.
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)
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 ( http://web.media.mit.edu/~minsky/papers/AlienIntelligence.html)
— Preceding unsigned comment added by 85.164.125.248 ( talk) 11:12, 19 December 2011
Sensible point raised on a GA [3] - 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)
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)
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.-- JohnBlackburne words deeds 21:57, 2 March 2012 (UTC)
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)
Just to outline my recommendations:
In this way, ambiguity is prevented, since
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)
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)
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)
Copying from the main MOS discussion page, since this is a math-internal discrepancy:
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)
@ Mikhail Ryazanov: ( [4])
MOS:MATH#Multi-letter_names gives an example using \text
but https://tex.stackexchange.com/a/98407 says this "might seem ideal, but it changes font according to the context, so the subscript would appear in italics in a theorem statement."
Are we sure we want to recommend \text and not \mathrm? It does eliminate spaces and hyphens in label names, but those arguably shouldn't be there in the first place. — Omegatron ( talk) 17:53, 1 February 2021 (UTC)
{\rm ...}
and similar: these are
long-obsolete OFSS commands and should not be used at all. Then, as mentioned above, \mathrm{...}
means "roman type in the math mode" and should be used for that purpose (for example, some people believe that derivatives must be typed like instead of just , and in this context "" is really a "roman" mathematical symbol), while \text{...}
means "regular text within a formula", so it should be used for all notation that would be used without special markup in regular text. Regarding the JFET article, I don't think that things like "GS" are mathematical symbols. For example, if "gate–source (GS) junction" is italicized in regular text, it should become "gate–source (GS) junction" rather than "gate–source (GS) junction", so the same rules should apply to it when it is inside a formula ("gate–source bias VGS is..." → "gate–source bias VGS is..."), exactly what \text{...}
does in LaTeX (although this is hardly important in WP). In any case, \text{...}
is also shorter than \mathrm{...}
:–) and treats spaces and hyphens properly (which are legitimate symbols in indices). —
Mikhail Ryazanov (
talk)
14:44, 2 February 2021 (UTC)\operatorname
for "Effectiveness", but since "SUE" is used with an argument, it probably should be typed so. (Besides this, I also suggest reading
MOS:MATH about indentation and punctuation; and
MOS:CAPS for the terms in the lead: they all should be lower-case, even if taken from sources with different style guides.) —
Mikhail Ryazanov (
talk)
20:40, 5 February 2021 (UTC)I know that there has been a lot of discussion about blackboard bold vs. boldface already, but right now I feel that the text
is worded so as to hint that authors who use boldface are behind the times and dying out, whereas the truth is that there are plenty of younger mathematicians at the highest level (as well as older ones) who seem to prefer boldface. Some examples are Terence Tao, Jacob Lurie, Song Sun, Bhargav Bhatt and Peter Scholze in their prismatic cohomology article, Brian Lawrence and Akshay Venkatesh in their work on the Mordell conjecture, the authors of the Stacks project, and so on. Also, I feel that there are plenty of other widely accepted uses of blackboard bold, such as those listed below. Therefore I would suggest replacing the text above with something like
Ebony Jackson ( talk) 22:16, 15 March 2021 (UTC)
The version reverted by Ebony Jackson got a consensus at WT:WikiProject Mathematics/Archive/2020/Nov#MOS:MATH#Blackboard bold. So, it should not be reverted without a new consensus, and the reverted version must be restored. However, as I am the main author of this version, I leave this to another editor. D.Lazard ( talk) 11:14, 24 March 2021 (UTC)
Certain objects, such as the real numbers R, are traditionally printed in boldface. On a blackboard or a whiteboard, boldface type is replaced by blackboard bold. Traditional mathematical typography never used printed blackboard bold because it is harder to read than ordinary boldface. Nowadays, however, some printed books and articles use blackboard bold.This suggest strongly that it is not a good practice to use blackboard bold. If this would an impact outside Wikipedia, this would be a serious issue. In any case, we must have a version that corrects this non-neutral formulation. D.Lazard ( talk) 11:14, 24 March 2021 (UTC)