To view an explanation to the answer, click on the [show] link to the right of the question.
Are Wikipedia's mathematics articles targeted at professional mathematicians?
No, we target our articles at an appropriate audience. Usually this is an interested layman. However, this is not always possible. Some advanced topics require substantial mathematical background to understand. This is no different from other specialized fields such as law and medical science. If you believe that an article is too advanced, please leave a detailed comment on the article's talk page. If you understand the article and believe you can make it simpler, you are also welcome to improve it, in the framework of the BOLD, revert, discuss cycle.
Why is it so difficult to learn mathematics from Wikipedia articles?
Wikipedia is an encyclopedia, not a textbook. Wikipedia articles are not supposed to be pedagogic treatments of their topics. Readers who are interested in learning a subject should consult a textbook listed in the article's references. If the article does not have references, ask for some on the article's talk page or at Wikipedia:Reference desk/Mathematics. Wikipedia's sister projects Wikibooks which hosts textbooks, and Wikiversity which hosts collaborative learning projects, may be additional resources to consider. See also: Using Wikipedia for mathematics self-study
Why are Wikipedia mathematics articles so abstract?
Abstraction is a fundamental part of mathematics. Even the concept of a number is an abstraction. Comprehensive articles may be forced to use abstract language because that language is the only language available to give a correct and thorough description of their topic. Because of this, some parts of some articles may not be accessible to readers without a lot of mathematical background. If you believe that an article is overly abstract, then please leave a detailed comment on the talk page. If you can provide a more down-to-earth exposition, then you are welcome to add that to the article.
Why don't Wikipedia's mathematics articles define or link all of the terms they use?
Sometimes editors leave out definitions or links that they believe will distract the reader. If you believe that a mathematics article would be more clear with an additional definition or link, please add to the article. If you are not able to do so yourself, ask for assistance on the article's talk page.
Why don't many mathematics articles start with a definition?
We try to make mathematics articles as accessible to the largest likely audience as possible. In order to achieve this, often an intuitive explanation of something precedes a rigorous definition. The first few paragraphs of an article (called the lead) are supposed to provide an accessible summary of the article appropriate to the target audience. Depending on the target audience, it may or may not be appropriate to include any formal details in the lead, and these are often put into a dedicated section of the article. If you believe that the article would benefit from having more formal details in the lead, please add them or discuss the matter on the article's talk page.
Why don't mathematics articles include lists of prerequisites?
A well-written article should establish its context well enough that it does not need a separate list of prerequisites. Furthermore, directly addressing the reader breaks Wikipedia's encyclopedic tone. If you are unable to determine an article's context and prerequisites, please ask for help on the talk page.
Why are Wikipedia's mathematics articles so hard to read?
We strive to make our articles comprehensive, technically correct and easy to read. Sometimes it is difficult to achieve all three. If you have trouble understanding an article, please post a specific question on the article's talk page.
Why don't math pages rely more on helpful YouTube videos and media coverage of mathematical issues?
Mathematical content of YouTube videos is often unreliable (though some may be useful for pedagogical purposes rather than as references). Media reports are typically sensationalistic. This is why they are generally avoided.
This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:
This page is within the scope of WikiProject Mathematics, a collaborative effort to improve the coverage of mathematics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MathematicsWikipedia:WikiProject MathematicsTemplate:WikiProject Mathematicsmathematics articles
Apparently there were some kind of puzzles or codes in the recently released Book of Bill (related to the childrens' TV cartoon Gravity Falls) whose answers included "Triangle" and "Eye of Providence", with the result that those pages have seen massive view spikes. Triangle went from a norm of about 800–900 views per day up to 500,000 views yesterday, and possibly more today.
If anyone wants to have improvements to a mathematical page widely seen, Triangle could use some love.
@Jacobolus Triangle was used to be FA. If anyone wants to improve, especially to revive it, I think I can help, but I need a lot of work. Some advices or comments may be required. Whether the goal is to become GA or FA, that implies the article is suitably referenced and on-topic. Dedhert.Jr (talk) 00:58, 12 August 2024 (UTC)[reply]
It's unfortunate that we don't yet have an article spherical triangle, and that spherical trigonometry and spherical geometry are so incomplete. These and the many related topics which are currently red links or redirects are on my long-term todo list, but fixing even a few of them properly is a large daunting job and it's hard to get started. I'd eventually like to make a substantial number of diagrams similar to those at Lexell's theorem, but each one takes at least an hour of fiddling, sometimes several. Anyhow, both spherical triangles and hyperbolic triangles are types of geodesic triangles, with edges that are geodesics of their respective spaces.
What your linked article calls the "Thurston model" of hyperbolic space is a discrete (infinite) polyhedron analogous to the regular icosahedron as a model of a sphere. The vertices are those of the order-7 triangular tiling; if you wanted you could put them all on one branch of a 2-sheet hyperboloid in 3-dimensional Minkowski space of signature (2, 1), and then the flat faces would be space-like triangles in the ambient Minkowski space. You could project from the hyperbolic plane onto those triangles, e.g. using the Gnomonic projection, or you can draw shapes directly in the space of the polyhedron. You could do something similar with any other kind of polyhedron. I don't think the article triangle needs to spend much if any time discussing triangles drawn the surfaces of polyhedra. –jacobolus(t)18:07, 14 August 2024 (UTC)[reply]
Another problem: Do you think the conditions about the importance of similarity and congruence sections should be trimmed away? Not something beneficially useful including the article on triangles in general; HL and HA theorem may be included in Right triangle instead. The same reason for the similarity of triangles via trigonometric functions. However, one exception that I include is its relation with trigonometric function, defining their functions as a ratio between both sides in a right triangle, and then including the law of sines and cosines as well. Dedhert.Jr (talk) 05:43, 15 August 2024 (UTC)[reply]
Ahh, I think something is missing here. Can somebody remind me, or give me more ideas to expand more in my sandbox? I could think of removing "triangles in construction" as in the Flatiron Building and truss; most of these topics are supposed to be triangular prism and isosceles triangle, respectively. The same reason for calculating the median, circumscribed and inscribed triangles, and many more, since they do have their own articles. Dedhert.Jr (talk) 05:43, 15 August 2024 (UTC)[reply]
"Triangles in construction" isn't the best section title or scope, but there should definitely be at least a section about how triangles are the only polygon which is rigid when the side lengths are fixed but the sides can rotate independently about the vertices; this is why triangles are the fundamental shape used in a truss, explains why a 4-bar linkage is the most basic type (a "3-bar linkage" can't move), is a reason triangulation works in surveying, and so on.
@Jacobolus. Okay. I would probably do more research and apply them to my sandbox. One problem here is I still cannot find the sources about the rigidity of a triangle and its tessellation with a hexagon. Dedhert.Jr (talk) 05:55, 16 August 2024 (UTC)[reply]
Completion
@jacobolus. The article is done for refactoring and rewriting. But some sources may needed to complete the article. Do you have any comments about something is missing or superfluous in the article? Let me know. Dedhert.Jr (talk) 07:48, 17 August 2024 (UTC)[reply]
I've made a smattering of edits to fix small prose matters and fill in some citations. It's still a little under-referenced, so anyone else who'd like to jump in and work on that should feel more than welcome. XOR'easter (talk) 23:30, 19 August 2024 (UTC)[reply]
I appreciate your work, as well as the compliments. Still have problems, however, especially with the sources of Heath's book The Thirteen Books. The first book's Definition 20 describes the isosceles triangle definition according to Euclid, but I think this is a mismatch with the given page in Isosceles triangle, or it is hidden in the Greek writings. Pinging @David Eppstein for further explanation. There is a similar reason for Heath's footnotes being more numerous. Dedhert.Jr (talk) 02:51, 20 August 2024 (UTC)[reply]
Maybe I'm misreading your comment: do you mean there is a mismatch in Euclid's definition, or just with the formatting of the reference? If the former, you should read the Usiskin & Griffin source from both articles. There are two different and incompatible ways of classifying shapes:
In exclusive classification, all cases must be disjoint: each shape can have only one type
In inclusive classification, special cases are subsets of more general cases
As our isosceles triangle article states, Euclid uses an exclusive classification, in which isosceles triangles must have exactly two equal sides and in which equilateral triangles are not isosceles. Many other sources use an inclusive classification in which equilateral triangles are special cases of isosceles triangles. But both remain in use.
Using an inclusive classification and allowing classes to be subsets of each other can be more flexible and avoids unnecessary case analysis. For instance, when Euclid proves a theorem about isosceles triangles, he would have to prove the same theorem again for equilateral triangles, because the givens from the first theorem would not match the definition needed for the second theorem. And when does a special case become separate from the general case? Maybe isosceles right triangles aren't isosceles triangles, because they are in a different special case class?
The same issue comes up even more strongly for quadrilaterals, where one may reasonably ask whether parallelograms are trapezoids, whether rectangles or rhombi are parallelograms, and whether squares are rectangles or rhombi. And then one must reconcile this classification with cyclic quadrilaterals, tangential quadrilaterals, orthodiagonal quadrilaterals, kites, bicyclic quadrilaterals, etc. In the isosceles triangle case, either definition was easy enough to write, but for many of these other cases of quadrilaterals, the inclusive definitions are easy to write (it's a quadrilateral for which a specific constraint is true) and the exclusive definitions are much messier (the constraint is true but also some other constraints that would cause it to be a more specific special case are all false).
Most of the time we use inclusive classification in our Wikipedia articles, but this distinction should be explained. And it's important that this choice be made in a principled way rather than randomly and inconsistently from one article to another because of the sources you happened to read when you were working on the article.
If I'm misinterpreting and this was all purely about page numbers then sorry for the off-topic rant. The important part of the Euclid reference is "Book 1, definition 20". —David Eppstein (talk) 04:25, 20 August 2024 (UTC)[reply]
@David Eppstein What I meant is in the article Isosceles triangle, you cited Euclid's definition on page 187 [Heath (1956), p. 187, Definition 20.] But I cannot find that definition on that page. What I meant about Greek letters is, even though I found the "Definition 20" on a different page, I will never find that the definition, and it is possibly written in Greek language. This is why I leave this to you since you are the nominator of that GA. and I have no clue about the article's expansion back of the day. Anyway, thank you for your explanation above. Dedhert.Jr (talk) 05:12, 20 August 2024 (UTC)[reply]
I can check my copy the next time I'm in the office. Are you sure you're looking at Vol.1 of the Dover three-volume edition? There are a lot of different reprints of Heath's translation. If you're reading it in Greek then I think you have a different one; I would have referred to an English translation. —David Eppstein (talk) 05:33, 20 August 2024 (UTC)[reply]
@David Eppstein I have searched it on Heath's citation, which I pointed out in the recent replies. As far as I'm concerned, the page describes the Greek language as the definition and English is probably the further explanation and comments. Look at the page 292 that I linked here [2]. Dedhert.Jr (talk) 05:45, 20 August 2024 (UTC)[reply]
"Heath's citation" is ambiguous. There are many reprints of Heath's translation of Euclid. Again, are you sure you're looking at Vol.1 of the Dover three-volume edition? The link you give is to Book 7 in Vol.2, not to Book 1 in Vol.1. —David Eppstein (talk) 06:09, 20 August 2024 (UTC)[reply]
Ideally we should be citing the Cambridge University Press 2nd edition from 1926, which was later reprinted by Dover, and including a link to a scan of the appropriate page with every reference. Unfortunately the internet archive only has a scan of volume 3, and many of their scans of dover reprints are blocked or need to be "checked out" (though they shouldn't be, since the copyright is still 1926, and expired). HathiTrust has a scan of vol 2 (and vol. 3). –jacobolus(t)15:49, 20 August 2024 (UTC)[reply]
Is this it? Of trilateral figures, an equilateral triangle is that which has its three sides equal, an isosceles triangle that which has two of its sides alone equal, and a scalene triangle that which has its three sides unequal.XOR'easter (talk) 17:49, 20 August 2024 (UTC)[reply]
Well, the article is down to a handful of uncited statements. I'm not sure that all of them need to be kept in the text. I can try to scrape together the time to work on it more, but maybe someone else would rather take a swing at it. XOR'easter (talk) 18:33, 23 August 2024 (UTC)[reply]
It seems that most of the areas are sourced, only some of the "citation needed"-tags and untagged areas are the remaining problems. Yet, is there anything that can include other related topics of a triangle here? Dedhert.Jr (talk) 01:16, 28 August 2024 (UTC)[reply]
One more thing: Do you think the article about triangles should include their appearances on some higher-dimensional objects such as polyhedrons, tesselations, etc.? I suppose these things would rather be included in some specific triangles: Isosceles triangles appears on five Catalan solids, infinitely pyramids and bipyramids; Equilateral triangle appears on deltahedron, fractal triangles as in Sierpinski triangles, and so on. Bipyramids and pyramids may be included in the article as isosceles triangles, but they are right (their height is exactly perpendicular to their base), not in the case of arbitrary triangles in obtuse case. Dedhert.Jr (talk) 09:45, 12 September 2024 (UTC)[reply]
Oh, but what about other appearances of triangles in real life, as in architecture, science, etc.? I mean, if we are talking about WP:ONEDOWN, this will target the elementary students. Some unexpected arrangements of sections may perplexe most users, and this leads to the same questions about excluding them in the general triangle, but rather including them in some specific type of triangles. Dedhert.Jr (talk) 15:29, 29 September 2024 (UTC)[reply]
I agree it seems a bit weird that these are separate articles. But, presumably, the coherent condition article can handle a situation outside the scope of the Mac Lane coherence theorem (which is only about a monoidal category), since there can be several coherence theorems. Maybe one option is to have a general article on coherent theorems, since I don’t know if focusing on "conditions” is a good idea from the encyclopedic perspective (if it is so from the mathematical perspective). -— Taku (talk) 13:03, 17 September 2024 (UTC)[reply]
Thank you for your reply. If someone create a general article on coherent theorems, I would suggest changing the title to "Mac Lane coherence theorem for monoidal categories" for clarity. --SilverMatsu (talk) 15:47, 21 September 2024 (UTC)[reply]
Coherence conditions typically occur in definitions. They are requirements that something has to fulfill in order to be covered by the definition, as, for example, in this definition of adjoint functors (from arXiv:quant-ph/0008021):
if there exist natural transformations and satisfying the coherence conditions and
Just to somehow reiterate my early comment (for clarity). I think, aside from math, this is essentially a matter of stylistic choices in Wikipedia. In Wikipedia, it seems we give a prominence to results like theorems over conditions. Thus, for example, we have the Zorn's lemma article instead of the inductive set article. So, having theorems or results articles seem fitting. My only reservation is that, well, category theory is a bit weird; in part, it feels like a philosophy than science so maybe prominence of results may or should not apply. I am happy to leave the matters to specialists. —- Taku (talk) 11:40, 1 October 2024 (UTC)[reply]
Thank you for your interesting comment. Indeed, for example, the term "functor" was originally introduced by the philosopher Rudolf Carnap. Also, "category" was originally a philosophical term. --SilverMatsu (talk) 16:37, 5 October 2024 (UTC)[reply]
By the way, what about the term "strictification"? Which do you like better, include the explanation of the term in the Mac Lane coherence theorem or create a new article? --SilverMatsu (talk) 16:58, 5 October 2024 (UTC)[reply]
As far as I can tell, strictification seems essentially the same as coherence theorems; i.e., some weak statements like equalities can be upgraded to less weak (stronger??) statements (pretty much like, the regularity theorems in differential equations). For example, according to refs given in Mac Lane coherence theorem, the theorem can be understood that way. I think it makes sense to have an article on strictification, which can also discuss various coherence theorems. —- Taku (talk) 11:43, 8 October 2024 (UTC)[reply]
Transition to MathML rendering as default
A possibly important change to the maths engine is in progress T271001• TTransition to MathML rendering as default. There is a phased introduction, with test wiki being created first and roll out to production wikis by December. It will rely on the native MathML support in Firefox, Chrome version > 109 (we are currently on v128). I think this means the end of server-side rendering of maths equations.
It looks like the technical work is done and the next phase is
Phase 2A: Production
Communication to tech news and wikitech-l about plan and pilot wikis
This is bad. Many of the "torture test" items at https://www-archive.mozilla.org/projects/mathml/demo/texvsmml.xhtml look extremely bad in both Firefox and Chrome. (Examples: in the continued fraction of #6, for me, the 1 at the top is tiny, much smaller than the rest, for me in both browsers. In #14, the varphi has turned into the other kind of phi. In #17, there is a huge space between the integral signs.) I hope this is not "the end of server-side rendering of maths equations" because if there is a preference to keep the old rendering I will likely use it. But not-logged-in readers will not have that choice. —David Eppstein (talk) 07:59, 18 September 2024 (UTC)[reply]
To be fair one should never convey meaning through the difference between phi and varphi and epsilon and varepsilon. This is just a difference in font, that for mysterious reasons Knuth decided to assign different commands.
As for the torture test, the ones that bother me are the wrong sizes of binomial coefficients in #8 and #9, the wrong sizes of the summation symbol in #10, #12, and #21, the wrong sizes of the integral signs in #16, #17, #21, and the wrong size of the determinant symbol in #24. That's for Firefox. Chromium has much deeper problems. Tercer (talk) 09:36, 18 September 2024 (UTC)[reply]
The MathML torture test is a very old document, the first comment is 23 years old. The MathML is encoded as raw MathML code and may not be the best way to represent the corresponding latex. For example take no 12, if I set my Wikipedia rendering mode to MathML, and enter the obvious latex for this, I get much better than in the Torture Test.
Good point, I didn't know it was obsolete. I've typed a few more of the tests in User:Tercer/math. They look fine. I couldn't figure out how to get the side-by-side rendering, so to get the comparison I opened that page in a tab, then changed my math rendering preference, and opened it again in another tab.
They say in phab that we eventually change defaults and deliver fallback images really as a fallback, so doesn't that mean they intend to keep server-side tex-to-img rendering as a backup option? Given lingering issues in the torture test that you note (although I'm just seeing the comment above that we should re-test the torture test), I'd say this option will be necessary for the foreseeable future. Also as a backup for accessibility. SamuelRiv (talk) 15:55, 18 September 2024 (UTC)[reply]
This seems like a bad and fairly pointless idea that completely ignores people's longstanding practical requests for improvements to the current renderer. Why don't the technical team ever ask for what mathematical authors need rather than wasting tons of time on whatever ticks miscellaneous marketing boxes. "roll out to production wikis by December" – if it renders current pages poorly, then it's certainly not acceptable to roll out to "production" in English Wikipedia. Math editors, and the rest of the Wikipedia community, will fight you every step of the way. –jacobolus(t)02:53, 19 September 2024 (UTC)[reply]
There's no point in saying how bad MathML is anymore, since there's no need to beat a dead horse. So, I will just say that TeX is the gold standard for math typesetting and Computer Modern is the gold math font family. MathML doesn't even come close, but MathJax and KaTeX do. Popular math sites like Stack Exchange and Brilliant use MathJax/KaTeX; in my opinion, MathJax with SVG output looks the best.
So Wikipedia should ditch MathML rendering as default and instead it should fix its broken MathJax implementation and make that as default (or implement KaTeX), provided that we really need a change. A1E6 (talk) 18:16, 21 September 2024 (UTC)[reply]
gold math family – Computer Modern isn't inherently better than other well-produced math fonts, and there is plenty of excellent mathematical typography which uses a variety of other fonts (though because typesetting math requires many unusual symbols, there is a significantly smaller choice than with general-purpose fonts). Computer Modern is the most common in recent years because it is the LaTeX default, but we certainly don't have to use it. It is not my personal favorite, and with a deliberate process I think Wikipedia could choose a better collection of fonts – for headings, body copy, captions, tables, footnotes, mathematical notation, ..., and maybe even promote the use of consistent fonts in maps and diagrams. I'm sure if there was significant outreach made to the community at large (including mathematicians, mathematical typesetters, type designers, TeX experts, ...) we could get some quality feedback, if there were a goal to pick a different font. Any math font(s) used by Wikipedia need to have proper support for all of the features used by Wikipedia articles. Or we could try to pick body copy fonts which better harmonize with Computer Modern. (For either criterion, let me throw Charis SIL in as an example at least worth looking at.) The appropriate chapter of Hoenig (1998) TeX Unbound may be helpful. Irrespective of what fonts we choose, there are a lot of subtle details of spacing, sizing, and positioning of elements on the printed page with a well-established centuries-old traditional set of conventions whose details can be found in books like Chaundy, Barrett, & Batey (1954) The Printing of Mathematics, Swanson (1971) Mathematics into Type, Krantz (2000) Handbook of Typography for Mathematical Sciences, etc. Any kind of rendering technology needs to be carefully implemented to sweat the particulars, so that the result is legible, consistent, and ideally beautiful. LaTeX's typographical output is not the only way to do things, and I often find that LaTeX makes typographical choices that I disagree about in edge cases, sometimes based on difference of taste/preference and sometimes for technical reasons. As a simple example, parentheses around sums using \left( and \right) are nearly always too large in LaTeX because these commands pick the size based on the dimensions of a "box" of content inside, and aren't sophisticated enough to implement the convention from traditional excellent mathematical typography that parentheses should cover the symbol but not in general extend past the indices. –jacobolus(t)19:31, 21 September 2024 (UTC)[reply]
And of course, there will be some typesetters who can justify using font families other than Computer Modern. The thing is, I think that MathJax with SVG output and KaTeX are the best solutions out there. We can't let MathML be default. A1E6 (talk) 00:24, 22 September 2024 (UTC)[reply]
I tried enabling MathML-only rendering in Firefox and looking at four equation-heavy articles. There were many visible problems. It becomes much more obvious if you view the same article with both renderings side by side in separate tabs or windows.
Display style mathematics is centered and much smaller than SVG in general. Maybe this size matches the body text, but it feels too small to me, more like textstyle than displaystyle. Centered display vs indented left display for other renderings makes it impossible to match with other formatting that is not pure mathematics on each line (such as a displayed equation plus a reference footnote): if you format those other lines to match the centered display of mathml it will not match the left-indented display of svg and vice versa.
In golden ratio, the top bar of the square root sign in is misaligned. The first one has visibly narrower thickness than the radical sign it connects to, and some others have visible gaps.
In Gamma function, the multiline equation in "Euler's definition as an infinite product" has several visible "[8pt]" annotations, and there is too little spacing around the cdots. Later, after "In particular, with z = a + bi, this product is", the displayed equation has a huge left vertical bar, mismatched with the right vertical bar.
In Dehn invariant, under "Platonic solids", the formula has unusually wide spacing around the division sign. Under "Realizability", there is too much space between the two symbols in . More problems with sqrt5: the bottom of the sqrt sign sits above the baseline when it should be below. In , the minus sign is much heavier than the solidus. Strangely, when I view exactly the same formula on this page, it looks different, with a thicker solidus and much tighter spacing between the minus sign and the solidus.
In continued fraction, under "Basic formula", the numerators and denominators get increasingly larger as one goes farther into the fraction: b2 is bigger and bolder than b1, and b3 is bigger and bolder than b2. The same thing happens for other continued fractions on the same page.
It seems there are still plenty of bugs. Here's another one: in Tsirelson's_bound#Tsirelson's_problem the automatic resizing of \langle and \rangle is done incorrectly, screwing up the bras and kets. Is there perhaps a proper place for reporting them? I don't think it is productive to make an exhaustive list here. Tercer (talk) 07:56, 19 September 2024 (UTC)[reply]
I am confused. I have thought that "Transition to MathML rendering as default" was dead, basically because of the lack of browser supports. My impression is that MathML is a seemingly nice idea that went nowhere, perhaps because we already have latex. So, we cannot expect the future where mainstream browsers natively support MathML and so, directionally speaking, aiming for MathML as default seems wrong. My understanding is that the developers are volunteers so they can work on whatever they would like to work and also providing MathML as an option itself need not be disallowed. But I don’t think it can be a default in the near future (I don’t know about the distant future like 2044). Taku (talk) 05:23, 19 September 2024 (UTC)[reply]
Since the beginning of 2023 Chrome supports MathML which seems to be the game changer and make MathML which was part of HTML5 from the beginning also a de facto standard. The new MathML language which adapted to "modern" CSS developments has also an updated version of the torture test. To me, the issues pointed out by @David Eppstein: are helpful. These examples can be used to be checked if there is a problem with the MathML code (which I will be most likely able to fix a few minutes) or if there is a problem in the browser (there it may be fixed the sooner the more noise one makes). I personally think it is a good idea to switch to MathML after actual bugs are fixed and tolerate the things you wouldn't see if you don't use two windows (as suggested by @David Eppstein:). Over the years, I got used to the way HTML displays formulae and today I can live with it, while I think a Wikipedia style like https://latex.vercel.app/ would be better. Plan for the transition to native MathML rendering. See phab:T271001 A few arguments for MathML
It is accessibility for people with limited vision for example via Braille keyboards
It supports copy and paste
the page is much smaller and thus loads faster and consumes fewer energy
...
As far as I understand, it is not possible for technical reasons to keep the current SVG based system running longer than November + \epsilon this year. The details are above my level of understanding. Physikerwelt (talk) 14:59, 19 September 2024 (UTC)[reply]
it is not possible for technical reasons to keep the current SVG based system running longer than November + \epsilon this year. – "Not possible" or just "nobody wants to do it"? Social/technical effort should go into fixing that instead, because the current MathML rendering is flat out unacceptable and adopting it by default would make Wikipedia math articles look worse than they have at any time in Wikipedia's history. The old pixelated PNG image LaTeX rendering was significantly better. The problem is that the spacing of everything in the MathML version is completely wonky and broken: sometimes symbols are too crammed together, other times they are too widely spaced, sometimes baselines are too high, other times too low. Lots of the individual symbols are ugly, illegible, and poorly sized to the context; sometimes their appearance is gratuitously different from the LaTeX version intended by authors. I don't know if the various problems are due to bad MathML design, bad browser MathML implementations, careless CSS, a poor choice of fonts, or what, but I imagine it would take significant (we're talking years of peeping and tweaking the details) technical effort for Wikipedia itself to workaround every MathML bug and quirk and render something that looks professional, far beyond my understanding of Wikipedia's technical capacity. But what's there now looks like deranged incompetent scribbling. If it is really and truly "not possible" to maintain the current SVG renderer, then we should look to adopt MathJax or KaTeX instead. From personal experience these can be made to render professional looking math typography. It would still be a tremendous and annoying amount of work to replace all of the subtle adjustments made in articles' math markup assuming the current renderer to adapt to a new renderer instead, but at least there would be some light at the end of the tunnel. –jacobolus(t)15:50, 19 September 2024 (UTC)[reply]
Of course it's in principle possible to keep the SVG rendering system running, but nobody wants to spend the huge effort needed for something that has no future anyway. The entire internet has moved away from serving math as images, for very good reasons. Only Wikipedia is stuck in the 20th century. That effort is much better spent fixing bugs in MathML and MathJax. Note that MathJax rendering is already an option. Tercer (talk) 16:18, 19 September 2024 (UTC)[reply]
The current version of "MathJax" rendering also sucks, with a lot of brokenness in edge cases. Maybe it's not shipping/using the right fonts? The 20th century was a fine century, and what editors and readers care about is whether their content renders correctly, not how trendy the developers were. –jacobolus(t)03:33, 20 September 2024 (UTC)[reply]
This is not about being "trendy". Serving math as images is a terrible idea, and I'm glad Wikipedia is finally moving away from it. Note that there's nothing wrong with MathJax per se; Stack Exchange uses it, for instance, and it looks great. Wikipedia just needs to fix its bugs. Tercer (talk) 10:03, 20 September 2024 (UTC)[reply]
@Tercer There is nothing wrong with MathJax per se as a technology, and I have used MathJax to make great looking mathematical typography in my own off-wiki projects, but the visual results when I click "MathJax" in my Wikipedia preferences are unacceptably bad, so some effort would need to go into figuring out what the issue is and fixing that before we can meaningfully consider adopting it as a default.
"nobody wants to spend the huge effort needed" – What you are advocating for as an alternative is forcing author volunteers to spend probably >100 times more than that supposedly "huge effort" fixing every math-using page on the site, with an end result that will still be visually worse than what we had before, but hopefully at least not completely broken. I think I speak for most wiki authors when I say nobody wants to spend that effort on the downstream side. Indeed, I think the proposal is in the vicinity of insane and deeply offensive to article authors.
Serving math as images is a terrible idea – Objectively it has been working just fine for years, though certainly if there were more developer effort put into the current system many of its problems could be ameliorated, such as improved copy/paste support, better support for accessibility tools, and so on. But overall SVG seems like quite an appropriate technology for laying out complicated two-dimensional graphics such as mathematical notation. KaTeX (ab)uses HTML instead. The underlying layout technology isn't really the important part: what matters is someone doing the thousands of hours of careful peeping and tweaking of the code to make sure that the typography renders correctly, which involves many tiny spacing and positioning decisions. I don't know whether or not it's technically possible to get this right with MathML, but the current MathML demonstration is unacceptably bad. –jacobolus(t)15:24, 20 September 2024 (UTC)[reply]
No, images have not been working fine. They have been a headache since Wikipedia exists. They clash with the text font, are hard to align properly, make the pages significantly heavier, can't be copy-pasted. Because they suck people have always tried to use alternatives, such as using italic text for simple variables, or hacks such as {{math}}, {{radic}}, and {{sfrac}}. It looks terrible and it's hard to edit. What we need is a properly working <math>, and this will never happen while it's still generating images.
But overall SVG seems like quite an appropriate technology for laying out complicated two-dimensional graphics such as mathematical notation. It's such an inappropriate technology that nobody else uses it. Neither other websites, nor scientific publishers, nor LaTeX, nor Word, nothing.
I think I speak for most wiki authors when I say nobody wants to spend that effort on the downstream side. Indeed, I think the proposal is in the vicinity of insane and deeply offensive to article authors. I am a wiki author and I am willing to spend the effort, so you can stop claiming "nobody". Tercer (talk) 16:07, 20 September 2024 (UTC)[reply]
"They clash with the text font" – This is not a problem with the technology, but a problem with Wikipedia's crap approach to article typography in general. Wikipedia should host a serif math font (and should seriously consider switching all body copy to a serif font for legibility on now-ubiquitous high-resolution displays), and should use it from both plain-html and <math> tags. This font or fonts should include all of the necessary typographical niceties to properly render all of the mathematics needed in any article, including multiple optical sizes for use in nested fractions, superscripts, super-superscripts, etc. hard to align properly You mean the vertical baseline alignment is messed up? This should be a straight-forwardly technically soluble problem, and seems like something the technical team might want to work on as a helpful improvement if they care about best supporting wiki authors. make the pages significantly heavier – can you explain what you mean by "heavier"? SVG images don't require particularly much network bandwidth. can't be copy-pasted – Wikimedia should consider donating some money to the developers of MathJax to work on this problem. None of the currently preference-checkable display options have very good copy paste support. Figuring out what should be copied when someone tries to select some mathematical notation is a hard technical problem which is not unique to Wikipedia. Because they suck people have always tried to use alternatives – no, people use alternatives because this is a worldwide pseudonymous wiki and there are many thousands of random people with varying levels of knowledge, interest, and ability, and many people have contradictory preferences; this is not really a technically soluble problem, though I agree it would be nice if we could do a better job streamlining math input. "I am a wiki author and I am willing to spend the effort" (a) You are personally volunteering to fix every math-using article on English Wikipedia and (b) you have the typographical competence to make every example look as good or better under a new than it did? "One guy is willing to fix a handful of pages", and might even be able to recruit a few other people is not a compelling solution to a problem which will potentially require many man-years of effort. Judging by your personal belief that the MathML output looks better than the LaTeX->SVG output, I don't have faith in your typographic competence, with all due respect to your intentions. –jacobolus(t)19:46, 20 September 2024 (UTC)[reply]
You are being disingenuous, and insulting me to boot. I refuse to have any further interaction with you, and would appreciate if you refrain from talking to me as well. Tercer (talk) 20:38, 20 September 2024 (UTC)[reply]
When you call someone an intentional liar here, as you just did, you should be specific about what exactly you think they said falsely and with the intention of falsehood. Otherwise, people might think you are in violation of WP:NPA. —David Eppstein (talk) 21:14, 20 September 2024 (UTC)[reply]
I am being pretty harsh here, in response to several of your claims which I consider to fall somewhere between wrong and completely missing the point. But from what I can tell your argument about appearance per se boils down to "I think mismatched fonts are really ugly"; that part is a matter of taste and I don't entirely disagree, but (a) there are many alternative things we could try to do as a project to get fonts to match better, which would be well worth discussing – the choice of font is separate from the choice of rendering technology – and (b) stomping on the rest of the details of mathematical typography conventions for the primary benefit of having matching fonts is, in my opinion as someone who cares a lot about mathematical typography, a completely unacceptable trade-off. I would be frankly shocked if you could find even a single person with significant typographical expertise (e.g. a professional typesetter of math books, whether using digital tools or hand-arranged metal print) who would find the MathML examples output by Wikipedia under the current preference setting to be even minimally acceptable. –jacobolus(t)21:54, 20 September 2024 (UTC)[reply]
Thank you for your feedback. However, I don't know what to conclude from that.
I can work with the list from David above, and investigate the difference on a case by case basis and explain the differences.
For example, \sqrt5 will be translated to <msqrt><mn>5</mn><msqrt> and rendered by the browser. Live demo
The appearance of your second square root presumably depends on what font gets used? The presented list from the CSS is "Latin Modern Math", "STIX Two Math", "XITS Math", "STIX Math", "Libertinus Math", "TeX Gyre Termes Math", "TeX Gyre Bonum Math", "TeX Gyre Schola", "DejaVu Math TeX Gyre", "TeX Gyre Pagella Math", "Asana Math", "Cambria Math", "Lucida Bright Math", "Minion Math", STIXGeneral, STIXSizeOneSym, Symbol, "Times New Roman", serif; – on my browser this ends up getting rendered using STIXGeneral, which happens to be installed.
Leaving the appearance up to each reader's browser (depending on what fonts they have installed) is an extremely bad idea. We are left debugging not only MathML and parser issues but also font bugs/quirks in 17+ completely different fonts. There's no way authors can possibly work around that kind of uncertainty/variety without totally compromising good (let alone consistent) appearance.
Any math rendering in which content written in one place is intended to be read by a wide variety of people with inconsistent platform font support should be explicitly shipping down a deliberately specified font to use. I would recommend shipping something relatively similar to Computer Modern because this will cause much less disruption, and give a better apples–to–apples comparison between technologies.
Anyway, the choice between your two examples comes down to personal preferences about the appearance of the √ and 5 symbols in Computer Modern (on the left) vs. Whatever-your-computer-chose (on the right), because this is a trivially simple formula which does not involve much if any tricky spacing or stress the quirks of the implementation (I guess beyond meeting the table stakes of attaching the overline to the √). I think the "old" square root symbol looks nicer than the "new" one in my browser, but the new one is more or less okay too. But this isn't the general type of example people are going to be most unhappy about. –jacobolus(t)03:50, 20 September 2024 (UTC)[reply]
Using Firefox on my phone, no font customization or anything like that, the diagonal part and the horizontal segment in the "new" don't join properly. XOR'easter (talk) 23:46, 22 September 2024 (UTC)[reply]
MathML should be fine for the vast vast majority of use of <math> on wikis. But there are a small number of WP articles where consistent rendering of key formulas is critical. If the svg rendering system at a large scale really has to be trashed (I would ideally prefer having a forcing property within the <math> tag), I'd still propose keeping the base system available to generate static svgs on Commons, so that formulas requiring such consistency can be still edited on the platform, while reducing load on that service to negligible. SamuelRiv (talk) 17:01, 19 September 2024 (UTC)[reply]
My understanding of the technical reasons why we can't keep the current SVG based system working, is that it depends on the RESTBase which basically caches the generated images. RESTBase is 10 years old now, a bit of a pig to install, and has a bunch of problems. The other services that used RESTBase, like the Visual Editor, no longer use it, so the foundation has decided to retire it (sunset). This of course creates a problem for the maths rendering engine. There has been considerable effort put into fixing things so maths will work in some form or another. Physikerwelt has done a lot of work and I'm just an observer.
What might be a possible alternative, if we want to give users a choice, is client-side MathJax. The SVG images are, I think, generated by MathJax. A few years back, the last time maths rendering came up and we replaced the awful PNG images, client-side MathJax was the only other option. There are some problems with this, as images are generated on the fly by the browser, and it can take a few seconds for formula heavy pages to fully render, it is probably faster now. At the time the foundation said no to client-side MathJax as a default, (it has always been available as an option). Instead there was a big push by the MathJax team to do server-side rendering producing SVG's. So other than some issues like baseline alignment they should look the same.
I want to respond to User:Physikerwelt's claim if there is a problem in the browser (there it may be fixed the sooner the more noise one makes). I strongly disagree. If there are problems with the browser-side rendering, as there indeed seem to be, then our mathematics will look bad and readers will think that Wikipedia is bad at mathematics. It will not occur to them to pressure browser-providers to change the browser, and if it did occur to them it is unlikely to be effective. When they complain to Wikipedia, they are likely to receive unhelpful responses such as the comment I quoted which boil down to "we will not fix it and you will be unable to go anywhere else to fix it".
So to me, the net message I am receiving from this turn of events is: Wikimedia is continuing to show their decades-long preference for idealogical ml-purity over readable mathematics rendering that has for decades caused Wikipedia to be far behind the curve in mathematics formula display, intends to break the current display in favor of something that works badly but is more idealogically pure, and will avoid responsibility for the breakage by telling everyone that it's the browser's fault. —David Eppstein (talk) 18:50, 19 September 2024 (UTC)[reply]
I don't know the technical specifics to say if anyone's right or wrong, but I'm concerned about and specifically addressing the rhetoric: by not addressing or acknowledging the technical motivations, or constructive solutions, your comment appears to say to Physikerwelt that you are in favor of something that works badly but is more ideologically pure. SamuelRiv (talk) 18:59, 19 September 2024 (UTC)[reply]
The opposite. MathML is idealogically pure (based on *ML markup); MathJax is not (based on JavaScripts that grovel through content to find markup that does not resemble *ML and replace its rendering). MathML does not work as a human-writable markup format and has historically worked quite badly on the rendering side; MathJax works well for both. I do not care about idealogical purity in my web server-to-browser pipeline; I care about being able to write formulas simply and naturally and getting high-quality visual output. My strong impression is that those priorities are reversed within Wikimedia. —David Eppstein (talk) 19:16, 19 September 2024 (UTC)[reply]
constructive solutions – the constructive solution is a political solution: Wikimedia should spend the cash / developer time to fix whatever the upcoming issue is with the current renderer or the platform it is built on, at least until such time as a drop-in replacement can be clearly and convincingly demonstrated, which the alternative renderers supported as a preference option today are nowhere close to doing. If we go ahead with a plan which causes significant typographical regressions on every math-related article on Wikipedia, some of which may be impossible to work around, that is going to be a serious problem for the Wikipedia project: it will hamper reading, it will make everyone think we are incompetent, and it will piss off authors who poured incredible amounts of work into something that used to look professional and suddenly does not. –jacobolus(t)04:26, 20 September 2024 (UTC)[reply]
@Physikerwelt: I didn’t know a new version of Chrome supports MathML so maybe MathML might not be dead after all (last I heard, Chrome dropped the MathML support but that apparently was an old news). But since old browsers like old Chrome or Internet Explorer don’t support MathML, I would say there is a still lack of browser supports. *Obviously*, Wikipedia need to be accessible to those with old browsers.
To reiterate some of my points more explicitly, the question that should be asked is not what are bugs and how they can be fixed. No. But the question should be on the direction. Is the MathML rendering a standard now; i.e., does many mainstream websites like blogs or forums involving math formulae use MathML? My understanding is that the standard is still MathJax. So, while a developer such as yourself should work on whatever they likes, directionally speaking for Wikipedia, a reasonable course seems (1) postpone the sunseting of the current rendering and (2) meantime fix the current MathJax implementation (which is currently broken). —- Taku (talk) 07:09, 20 September 2024 (UTC)[reply]
There's a drop down menu for which font to render with, which one should I be looking at? It seems to change not just the fonts but also things like parenthesis height, and in some cases very important spacing, e.g. the space between fractions in #9.
Some fonts seem very satisfactory to me in some browsers, but in some other browsers, none of them render. (Is this the fault of my own computer?)
Regardless, I have never understood why the wiki developers can't just make it so that <math>-tagged latex consistently appears along the same horizontal lines as the surrounding text. It seems to me like that'd be the perfect solution, and doesn't seem (?) so difficult. Gumshoe2 (talk) 23:14, 19 September 2024 (UTC)[reply]
Here's a collage of my renderings: Cambria (default Windows font selection) has its unique problems (#13 and #29), which is odd. DejaVu was generally satisfactory so I didn't upload it. Libertinus has uncomfortable kerning in #14. STIX switches abruptly between straight and slanted sqrt symbols in #13 (but as you can see this is replicated in the tex2svg rendering; other fonts render in a smooth gradation). The kerning after the combination parens in #9 seems to be a little tight in all fonts. Also, the rendering of adjacent fractions with different height denominators will be inconsistent with different fonts in #9 -- TeX only preserves height in its default font for x2 and the like, but beyond that you get similar alignment consistency problems that I generally fix using phantom characters (something to test in your MathML renderings). SamuelRiv (talk) 19:09, 20 September 2024 (UTC)[reply]
The new torture test has multiple visible problems:
#3, #4. Fraction bar much thinner than text (Firefox)
#4. The denominator of the fraction in the exponent is too close to the size and baseline of the main text, making it appear attached to the base of the exponent rather than to the fraction (Firefox+Chrome)
#5, #8, #14. Spacing around the solidus too wide. (Firefox+Chrome)
#7. Fraction bars below topmost too thin (Firefox) or bottom one too thin (Chrome)
#13, #29. Bars over square root slightly too low, causing glitch where they attach (Firefox); or slightly too high, causing a similar glitch (Chrome)
#14. Ugly varphi too close to vertical bar (Chrome)
#18. The "0" is incorrectly centered under the previous two cases, rather than left-justified (Firefox+Chrome); "elsewhere" does not line up with previous lines (Chrome)
#19, 22. The textual annotations are significantly tinier than as rendered by TeX making them difficult to read (Firefox+Chrome)
#28. Triple primes too close to each other and too far away from y, causing them to appear to be a single dark blob not even part of the formula (Chrome)
#29 The plus sign in the limit is spaced as a binary operator between the arrow and the infinity rather than a unary operator attached to the infinity (Firefox+Chrome).
#30 blobby varepsilon hard to distinguish from set membership sign (Firefox+Chrome)
Which font(s) are you looking at? I hadn't seen the menu that Gumshoe2 mentioned, but I find that some fonts are not terrible, and some are. And I'm not sure what would control the font used by MathML in Wikipedia; probably a preference setting, with a reasonable default? Dicklyon (talk) 01:52, 20 September 2024 (UTC)[reply]
"I'm not sure what would control the font used by MathML in Wikipedia" whatever the browser/OS ships with and uses by default, if i'm not mistaken. Especially math users who have installed their own math fonts might be seeing results that differ from what most users would see. —TheDJ (talk • contribs) 02:39, 20 September 2024 (UTC)[reply]
"Your mathematics fonts are wrong and you need to go through [long complicated technical procedure] to fix them before Wikipedia will be readable" is exactly the sort of unhelpful answer I would expect mathml-proponents to provide to unsophisticated Wikipedia readers instead of, you know, providing a mathematics rendering pipeline that works out of the box. As for my personal setup, I haven't touched the fonts since purchasing this particular (Apple) laptop, but who knows what might have been carried over when its setup procedure copied my files through multiple generations of past laptops over multiple years when I might have done something long ago that might continue affecting things today. Also, please remember that not-logged-in readers do not have preferences that they can adjust. I did try viewing not-logged-in and did not see any obvious differences from logged-in. —David Eppstein (talk) 05:27, 20 September 2024 (UTC)[reply]
Here's an example of Continued fraction § Notations, as it currently renders using the default LaTeX→SVG renderer on the left vs. MathML on the right, in my logged-in browser.
Incidentally, there's a comment on the markup for the latex on Leibniz's notation: <!--very hacky workaround; mediawiki latex doesn't have good support for vertical alignment commands-->. I wonder how much tweaking it took to get it to look just right using our tex2svg. In sections specifically marked for historical nonstandard notations, it's kind of odd that you'd expect two renderers, even two fonts, to give consistent output. (If an image is the only thing that guarantees consistency, I agree -- and there are many ways we can run tex2svg without regenerating it every time within the article.)
Anyway, now that we know that that custom whitespace syntax isn't recognized, one could in principle simply run AWB to set any equation with such code to explicitly use a fallback rendering (though I'm waiting to hear specifically what the options are for this). SamuelRiv (talk) 07:04, 20 September 2024 (UTC)[reply]
The strong impression I'm getting from this thread, especially Physikerwelt's "it is not possible for technical reasons to keep the current SVG based system running", is that Wikimedia intends to trash any other rendering system, leaving us with no options for fallback. —David Eppstein (talk) 07:50, 20 September 2024 (UTC)[reply]
There's no "custom whitespace syntax". This is ordinary LaTeX. It just needs a cumbersome workaround because our LaTeX→SVG tool is missing some basic TeX/LaTeX features.† But it's not just the "Leibniz" notation part that is terrible in the MathML version: all of the subsequent notation variants are also typographically bad and significantly less legible because they have very poor alignment and spacing. But the most dramatically broken Leibniz example is a good example of the types of wonky equation any drop-in replacement has to be able to handle, because there are a huge number of mathematical expressions all over the project where the specific behavior of our LaTeX→SVG tool was relied on by authors and assumed to render for every reader the same way it appears to the author. The amount of time and effort it would take to find and "fix" all of these currently-working examples to kinda-sorta work under a new rendering tool is going to be incredibly high. We're talking about thousands to tens of thousands of hours of work. †: If anyone working on the technical side wanted to support article authors, adding support for a few fundamental but currently missing TeX/LaTeX spacing and sizing features would be an improvement I at least would be happy to applaud. –jacobolus(t)09:28, 20 September 2024 (UTC)[reply]
Leaving aside the broken \align, there is a cornucopia of other typographical problems at that example, for instance,
the same font is used for ordinary sized symbols and smaller symbols in inline fractions, exponents, etc., but for decent typography these need to be optically sized symbols which are relatively bolder, have wider proportions, etc., otherwise the shrunken symbols appear spindly and are difficult to read,
the ∘ (function composition) and ′ (prime) symbols are too small and the latter is placed in the completely wrong place and apparently completely screws up the horizontal spacing afterward,
the vertical bar indicating evaluation at a particular point is placed much too closely to the adjacent dy/du, etc.,
spacing around = signs is horrible, even in equations that aren't using the align environment
parentheses are mostly incorrectly sized, especially noticeably in exponents, but also parentheses wrapping larger material do not properly grow, and the result looks terrible,
the subscript on is not kerned properly,
the symbol is too small, and the vertical alignment of limits above and below is incorrect,
equations in limits have much too much space around the = sign,
More strongly, @Physikerwelt: If you want to provide a convincing demonstration to the world that MathML makes math ugly, and should not be used, going ahead is a promising way of doing this. It is not just the obvious problems listed above, but littler things where roughly the right symbols are in roughly the right places but much less harmoniously than the TeX layout. In jacobolus' continued fraction screenshot above, look at the notation credited to Gauss, . In TeX it looks natural, like this is a standard notation. In the MathML screenshot, all the symbols are floating around disconnected from each other, with too much space between them, making them look too small and making the notation look cobbled-together and not natural. The vertical fraction is too tight and its denominator off-center. It is not mathematically wrong but it is ugly. This is the kind of ugliness that people will learn is caused by MathML. —David Eppstein (talk) 17:56, 20 September 2024 (UTC)[reply]
This is a layout problem that will be ugly in TeX too. E.g. Terminal punctuation with something like a fraction, wide or asymmetric-length bounds on the sigma (try a different font or a longer expression). (Part of the reason you tolerate may be that you're used to it, or that it's an industry standard; personally I can't stand the fact that Knuth's declared preference for punctuating equation lines means that we all have to deal with that ugly crap, but at the end of the day, I should probably accept that it's not that important.
If your argument is that it looks unprofessional, then the professional standard being TeX renders in a different manner using specially-designed fonts that don't play nice with our in-line text (a common complaint, hence the {{math}} template and, even worse, sans-serif wikitext). Equations being selectable potentially improves reader accessibility. What the implementation is to do this, and what is the fallback, how to continue tex2svg when needed, how and when it's implemented -- these are things that can be discussed constructively. On the other hand, several of your comments so far, namely the opening sentence of the previous two above ("Wikimedia intends to trash" and "exactly the sort of unhelpful answer" (following a quote of a nonquote)) are simply in bad faith. SamuelRiv (talk) 19:44, 20 September 2024 (UTC)[reply]
Donald Knuth did not invent putting punctuation at the end of an equation. Essentially all mathematical publications have done this since mathematical printing was developed in the 18th century. Tito Omburo (talk) 21:28, 20 September 2024 (UTC)[reply]
For example, it is the practice recommended by Halmos (1970), which is cited in our style manual, and which Knuth read (he quotes from it on p. 183 of The TeXbook). It is also recommended by Chaundy, Barrett, and Batey's The Printing of Mathematics (Oxford UP, 1954), which Knuth also read (see p. 197 of The TeXbook). XOR'easter (talk) 06:38, 21 September 2024 (UTC)[reply]
simply in bad faith – this entire technical proposal comes across to me as dismissive of authors' expertise and practical needs, to the point of being insulting. Criticizing that harshly is in my opinion the appropriate response, and calling such a response "bad faith" is a profound misunderstanding of what we're trying to do in this project called Wikipedia. What you are seeing is a kind of immune reaction by people who will be extremely affected to changes being pushed by people who aren't themselves going to feel the impact. This kind of response is common any time you go into a relatively stable complex system and start breaking essential components. –jacobolus(t)21:34, 20 September 2024 (UTC)[reply]
I've made a version of the TortureTest which goes from our <math> extension version of LaTeX and is rendered by our system, User:Salix alba/TortureTest. There are a couple of bits where we miss things like \substack that cause problems but for the most part it works OK. There are a couple of bugs with client-side MathJax rendering which look like there are solutions in the pipeline T375241.--Salix alba (talk): 17:21, 20 September 2024 (UTC)[reply]
Just for laughs I thought I would try DickLyon's updated torture test with Chrome on Android on a recent-model Pixel phone; this is what I get when I click on its link from the Wikipedia app and I suspect very similar to what I would get if MathML rendering were used within the Wikipedia app. I have not done anything to set up nonstandard fonts on the phone. It is far worse than in my laptop browsers.
Overall: the italic letters are in a serif font but the digits are in a sans-serif font. When they appear side-by-side at the same size, the sans-serif appears noticeably heavier than the serif.
#8, #9: The binomial coefficients are rendered with normal-sized parens, not the correct extended parens.
#9. The spacing is so bad that the first close paren touches the following x, and y touches its exponent. The denominators of the two vertical fractions do not have the same baseline.
#10, #12. The summation sign is sans-serif and the same size as the text. The i underneath the one in #10 almost touches it. The p and q above the ones in #12 do touch it. The r in #12 has a lower baseline than the p and q, so low that it almost touches its summation sign.
#13. The sqrt signs are all the same size and, in order to nest within each other, float high high above their arguments. Only the innermost one is anywhere near its proper size and place, but even it is too small, with its bottom point only maybe halfway down to the baseline of its argument (it should be below the baseline). There are visible gaps where they connect to their overlines.
#14. The left and right delimiters (both paren and vbar) are all the same size as the text. The partial signs are sans-serif.
#15. The x is illegibly tiny. I have to zoom this up much larger than the TeX to read it.
#16. The integral sign is roughly text-sized and sans-serif. Its x is placed so close to it that the top point of the integral sign almost touches the crossing point of the x, and lies between the upper and lower left parts of the x.
#17. Same ridiculous text-size sans-serif integral sign.
#18. Centered rather than left-justified; text is sans-serif.
#19. The horizontal curly bracket is far too small, only covering the "..." in the middle, and too close to the text above it, which is too small and sans-serif.
#21. Same bad summation, integral signs, and sans-serif text. The π is roughly the right height but ridiculously wide, maybe three times the width of most of the italic letters.
#22. Same tiny horizontal brackets and too-close sans-serif labels. The \ell is sans-serif, does not come close to matching the k in appearance or weight, and its stroke starts somewhere in the middle rather than the bottom so it looks more like a cursive e than an ell.
#23. An illegible random scattering of serif italic letters, a sans-serif digit, and text-sized parens. I would have a hard time guessing that this is supposed to be a matrix of matrices.
#24. The vertical bars are text-sized and even for that appear a little lower than the baseline of the surrounding material.
#26. Same bad pi.
#28. The same problem I saw on my laptop: the triple primes are tiny, too close to each other, and so far away from the y that I would have no idea they are supposed to be modifying it.
#29. Same too-small misaligned gappy sqrt. 2πn are in three unrelated font styles. The exclamation point appears to be sans-serif and the parens are text-sized. The limit sign is sans-serif. But at least this time the spacing of n\to+\infty appears better than on my laptop.
#30. Det is sans-serif. Now that I see them together, the summation sign, product sign, and lowercase Greek letters all appear to be from the same font; that is, there is no visual distinction between a sum and a capital sigma, nor between a product and a capital pi. Maybe that explains why the lowercase Greek letters are so huge; it's a step towards making sums and products slightly less horrific. The n touches the product sign. But at least I can tell the set membership symbol from the epsilon.
I happened to be looking today at one of those older pre-TeX mathematics books where everything was set by a typewriter, using the best approximation to correct symbol placement one could achieve using a typewriter. That's...not good, by today's standards. But this strikes me as worse, because it's just as ugly with no excuse for it. We've been able to typeset mathematics much better than this for over 45 years. If this is what mathematics is going to render as, on mobile, it is absolutely far from ready for primetime. With SVG rendering, I've been strongly preferring LaTeX mathematics markup to our ersatz templates, but this would make me switch back. Literally the only formulas for which it can produce acceptable results are the ones that template-math works better for. —David Eppstein (talk) 07:27, 21 September 2024 (UTC)[reply]
Those stretched-out pi symbols are like a horror story from the '90s: an equation that somebody typed in Word and resized in PowerPoint, then shown off by an open-source evangelist as an example of why friends don't let friends use Microsoft products. That any descendant of TeX produces output like that is a bizarre joke. XOR'easter (talk) 23:43, 22 September 2024 (UTC)[reply]
@David Eppstein I think that typewriter based prints were a step backwards in comparison to the previously used led based printing. Maybe someone could also claim that the 100 year old typesetting looks better than MathML. I was looking at some publications from 1924 and it's hard to say.
However, RESTbase will be switched off regardless. The Phabricator bugs are (easily) fixable to the degree, that it can become as good as the MathML torture test. With the MathJax option spacing is improved for logged in users. I claim that it is possible to maintain the old SVG rendering even without RESTbase. However, that would hinder extension of the current functionality. The currently implemented MathJax options falls back to MathML if JavaScript is disabled, so I think this could also become the default for not logged in users.
Two issues have been reported regarding the MathJax option. I have fixed one and the other one is currently waiting for code review. If I select SVG as rendering option in client side MathJax it looks very similar to the current SVG based rendering to me. This is because the MathJax codebase served as a blueprint for the native MathML implementation. Even special MathJax data such as `data-mjx-texclass` is in the generated by native MathML to help MathJax to generate correct spacing, which seems to be hardly possible from MathML input alone.
If is a majority that support that option the Wikimedia Community Group Math might want to vote on this?
typewriter based prints were a step backwards – Yes, that's precisely the point. Typewriter "manuscripts" were an alternative to hand-written manuscripts which were easier and faster to produce especially for people with sloppy handwriting. Compared to typography produced on a mathematics-specialized printing press, they looked like complete garbage, but they had the advantage of not requiring a expensive services of a professional typesetter or the expensive equipment of a press and metal type. If someone is comparing your mathematical typography to that produced by a typewriter, that is not a flattering comparison. Maybe someone could also claim that the 100 year old typesetting looks better than MathML. Yes, there are 200+ year old mathematics books with typography that looks much better than the current Wikipedia MathML output. RESTbase will be switched off regardless – the alternative is simply not acceptable at the moment, so basically you are continuing to threaten to overnight make all of technical Wikipedia look ugly, illegible, and amateur, without any backup plan. If I select SVG as rendering option in client side MathJax it looks very similar to the current SVG based rendering to me. You need to test this on an extremely wide variety of devices, and sit next to someone who is sensitive to the details of mathematical typography while you do so, and let them point out any issues. In my opinion this option is only viable if Wikipedia ships down fonts to every reader, and after that is going to require an extended period of bug fixing before it's ready. –jacobolus(t)14:08, 5 October 2024 (UTC)[reply]
"RESTbase will be switched off regardless – the alternative is simply not acceptable at the moment". Complaining here will have little effect, no one on here has the power to stop the change. You really need to take this up with the foundation. Maybe there is a chance for an alternative image cacheing service, but that would require foundation level developers, rather than a couple of volunteers.
What we can do is is make is suck less. For that identifing concrete example of when the renderer fails. I'm happy to turn these into bug report, and Physikerwelt has done a lot of work fixing reported bugs. Some of the bugs could do with input on what we really want to acheive. For example should \operatorname{foo} always have space before and after, or are there cases when this is not the desired result? T375861
You really need to take this up with the foundation. – Has anyone told the Foundation that this is a severe and urgent problem? Who is the appropriate contact / what is the appropriate venue? \operatorname{sin} needs to appear the same as \sin, etc. The appropriate spacing depends on the context, and the behavior should hopefully be identical to the current renderer, because many articles have had manual spacing workarounds for this. (Though if the current renderer differs from the behavior of standard LaTeX for some reason, then I could imagine a case for "fixing" any differences, and then editors would just have to try to check any articles that explicitly tweaked the spacing.) similar debate when server-side MathJax was introduced – yes, and the replacement had nearly identical layout and appearance, except for being a vector image instead of a bitmap. If you can accomplish the same nearly identical result to the current renderer across all readers' devices and settings, then we won't have any issue this time either, but currently that is not close to the case. –jacobolus(t)20:46, 5 October 2024 (UTC)[reply]
If comments like "RESTbase will be switched off regardless" do not provide a clear enough picture of Wikimedia having no concern for technical content on Wikipedia, and being willing to break that content for months or years, consider the sad fate of the graph extension (Help:Graph), "temporarily" disabled since April 2023 with its supposed "Charts" replacement well behind schedule and lacking updates.
It may be time to start preparing more extreme countermeasures, in the likely case that mathematics formatting becomes broken and unreadable. Something that comes to mind: a bot or script that reads a Wikipedia page, finds all of its mathematics formulas, creates bitmap or svg images using LaTeX, uploads them to Wikipedia, and uses an image as the replacement for the formula. —David Eppstein (talk) 21:02, 5 October 2024 (UTC)[reply]
Maybe we could just add a colorful banner to the top of every technical article along the lines of "The Wikimedia foundation just broke math rendering across Wikipedia. Contact XYZ if you would like to restore professional looking rendering." Trying to replace every formula with explicit images sounds like a logistical nightmare. –jacobolus(t)21:33, 5 October 2024 (UTC)[reply]
I thought of that, but I strongly suspect that the banner would be removed as an administrative action.
Incidentally, since my experience with the torture test was that going from a web browser on a computer to mobile made MathML much worse, not merely extremely ugly but totally unreadable: does anyone know if there is some way to convince the android Wikipedia app to render using MathML so I can see what that would be like? It doesn't appear to respect my user preference for that. ——David Eppstein (talk) 22:06, 5 October 2024 (UTC)[reply]
Phabricator Bugs
I've been creating a set of Phabricator bugs under the task T375318• TNative MathML mode formatting bugs and there has been progress on some of the bugs over the last week.
T375317 \align aligns fields in the centre rather that on the left in MathML mode - now resolved.
T375295 \begin{align} with font sizes specified show font size annotation 6pt in MathML mode - now resolved.
T375337 Too much space around / in MathML formatting mode - probably solvable.
T375349 \int\limits_a^b limits in incorrect position in MathML mode - probably solvable
T375340 Too much space between fences and content in MathML formatting mode
T375346 Lots of space around the cells in matrix evironments in MathML mode
The last two depend a bit on font choice, in particular the font set by browser corresponding to the font-family: math used for <mi> and <mo> elements, so I'm not sure what should be done with theses. A couple of other bugs related to client-side MathJax rendering T375241 and To T375241 have also been fixed.
@Salix Alba: I can give some examples of the most pressing issues (MathJax with SVG output):
1: \\[8mu] etc. in "align" is broken, see for example
2: \mathcal cannot be rendered and it is instead replaced by \mathscr, see for example
(this is not mathcal)
3: \operatorname is broken, see for example
4: \displaystyle\sum_{n\in\mathbb{Z}} and \displaystyle\prod_{n\in\mathbb{Z}} puts the index in an incorrect position (it should be below but it's on the right instead)
5: the symbols "!" and ":" are skewed when they shouldn't be, see for example
1. Automatic resizing of \rangle and \langle doesn't look at what is inside of the ket, but outside. This messes up almost every quantum mechanics article. Example: S. In general I think automatic resizing is a terrible idea and should never be turned on by default, instead it should be controlled with the \left and \right commands like in LaTeX.
2. The limits of integration are displayed above and below the integral sign, whereas they should be displayed to the right. Example: .
3. The pipe "|" introduces spurious spacing, which messes up conditional probabilities among other things. Example: .
MathJax bugs:
1. Automatic resizing of \rangle, \langle and | look at the largest operator in an equation. Examples: , , . Again this illustrates how automatic resizing is a terrible idea.
2. The glyph for the pipe simply does not render in the following expression: . I assume it's automatically resized, and the glyph of that size does not exist. Tercer (talk) 10:09, 27 September 2024 (UTC)[reply]
MathML #1 This is now T375959 and it looks like it will be fixed soon. An old bug T137788 adds the \middle command, which you need for a full bra-ket, is this needed?
MathML #3 Looks a similar issue to T375337 we are discusssing the desired behaviour as LaTeX and MathML have different ideas on what the spacing should be.
MathJax #1, hopefully fixed at the same time as MathML version.
MathML #1: \middle would certainly be nice to have, but I wouldn't call it necessary, as it's always possible to size it manually.
MathML #3: I don't think there's much of a choice here, if you don't follow the LaTeX standard you'll break half of Wikipedia. I found another problematic glyph: the colon introduces spacing in LaTeX, but not in MathML/MathJax. This messes up for example .
MathJax #2: Firefox 130 on Ubuntu 22.04. It's probably a font issue, because I have another machine with the same browser and OS, and they pipe does show up there. I don't know how to diagnose it, though. Tercer (talk) 11:14, 29 September 2024 (UTC)[reply]
{code|f:X \to Y} is now T375974. Colon is being treated as an identifier <mi>:</mi> rather than an operator <mo>:</mo>. There are a bunch of other symbols that should probably be treated as operators. --Salix alba (talk): 14:24, 29 September 2024 (UTC)[reply]
Found another pressing problem: in both MathML and MathJax \| is rendered as a single pipe, instead of a double pipe. This messes up the display of norms and relative entropies, among other things. Example: . Tercer (talk) 10:19, 4 October 2024 (UTC)[reply]
I've relayed some of your concerns to one foundation employee involved. At T271001 and he has given some useful bit feedback.
On timing:
We're currently waiting for the final QA round, and we have a number of early bug reports above to work through. Right now we're not yet pressed for time with inviting more users or entire pilot wikis.
There is no set deadline for Mathoid yet, and it's not enabled anywhere by default (beyond beta cluster and group0 testing). As you can see above, there is no shortage of feedback at the moment so we're not in a rush to get wider feedback or enablement yet.
On options:
if the exact interaction and styling of the current rendering is preferred, enabling the "MathJax client-side" preference. This will stay long-term.
The "SVG" option, powered by Mathoid with server-side MathJax, is planned to be removed in the future.
On communication:
We're not in a rush to get wider feedback or enablement yet. It would just waste people's time reporting duplicate/known bugs, and make it less likely for them to try again later to find other issues.
I prefer it when the Foundation does software development in public. As such, the draft is available for everyone to see.
I made the call to not announce it widely until we're more confident in it ourselves.
We generally encourage community members that are tech-savvy to do this outreach directly, exactly as you did, and liaison bug reports back to here. I don't mind doing further outreach myself as well on a handful of suggested talk pages. I speak Dutch, English, and a bit of German :)
On User Acceptance Testing:
Sure. Acceptance is based on known test cases passing without glitches, and bug reports like those above. I'd consider the following kind of bugs as blockers:
glitches where symbols appear that shouldn't.
glitches where symbols don't appear that should.
glitches where symbols appear in an obviousy incorrect place.
The goal is not pixel identical rendering to MathJax, so the exact font size and spacing may vary. This is in part a feature in that these aspects can now be customised with CSS via user styles, and are decided by individual web browsers. We do have some connections at browser vendors (Mozilla/Google/Apple) so if there are bugs caused by the HTML>screen rendering in browsers, rather than the LaTeX>MathML HTML rendering in MediaWiki, we can help escalate upstream bug reports as well. Free free to share links to https://bugs.webkit.org/, https://bugzilla.mozilla.org/ or Chromium's issue tracker.
MathML rollout page in my browser – The top and bottom of the screenshot are intended to look about the same?
"The goal is not pixel identical rendering to MathJax, so the exact font size and spacing may vary. This is in part a feature in that these aspects can now be customised with CSS via user styles, and are decided by individual web browsers." – This is a terrible idea. There are plenty of manual tweaks required to get math rendering looking good in edge cases or gaps in the default rendering, but which tweak is required differs depending on which font is used. Additionally many fonts just have bad built-in metrics, not to mention poorly distinguished symbols, etc. This entire endeavor is not going to work unless you pick a single specific set of math fonts and ship it down to every reader, so that authors are assured that readers are seeing a nearly identical result. The plan of giving every reader and every device different fonts is not an acceptable way forward for Wikipedia. –jacobolus(t)14:17, 9 October 2024 (UTC)[reply]
I'll try and translate your comment on Phabricator into individual bugs
There are many subtle spacing flaws (for example the vertical spacing is wrong in the fraction x/2)
the superscript 2 uses the wrong font (it uses a scaled-down 2 from a font intended for regular size instead of a properly optically scaled 2 intended for superscript size)
the two lines at the bottom have been smushed together
the strikethroughs of the 'y' letters are much too small (and in this font, y is not a legible character to cross out because the strikethrough overlaps the leg of the y)
the renderer does not understand the explicit alignment directions of the source markup (which asked for left-aligned, center-aligned, and right-aligned) – though this is a poor example because people should be using LaTeX \align instead of \array for this specific thing.
No 4. Is a bug. Its worse in Chrome than in Firefox as the strike is not rendered at all T376829
No 5. I've started a new bug T376838 for this, quite close to T375317 but thats for \begin{align}, rather than \begin{array}.
No 1. I can't see this. Here is a variety of fractions in SVG and MathML mode. SVG: MathML: SVG: MathML: the spacing looks right with consistent baseline and allowing space for ascenders/descenders.
No 2. I don't quite get, the SVG uses <use transform="scale(0.707)" xlink:href="#E1-MJMAIN-32" x="613" y="583"/> for the 2, so its a linear transform of the font. The MathML use a font-family: math; font-size: 11.89px; compared to a 16px font for the mc. This seems better behaviour, font designers adjust fonts for different font sizes. This is what you get from a vanilla MathJax install, recall SVG was a hack to get MathJax to work serverside.
(1) Here's what your example looks like in my browser:
In my opinion the MathML versions are utterly broken. It might look fine in a different browser, on a different device, or in a different browser version. That one main point of the criticism: MathML does not render consistently across devices, especially if the font is not standardized, which makes it effectively impossible for page authors to write markup which will render consistently (or even barely legibly) on all readers' browsers. Until the MathML version has been tested on hundreds of different configurations of devices and browsers, including 10 year old devices running 10 year old software, it's not production ready for the purposes of Wikipedia, which has an extremely wide audience including many people running old hardware/software. We shouldn't lock people out of reading technical Wikipedia articles because their laptop or phone is out of date.
Inre your other questions:
(2) Any time you have multiple sizes of symbols being used side by side, you need to use a different font for each one (or a fancy "variable font" which adjusts its proportions for each size); larger sizes need proportionally thinner strokes and narrower proportions, smaller sizes need proportionally thicker strokes and squatter proportions. See Font § Optical size. Typical LaTeX math typefaces have several different fonts intended for different sizes, including a "standard" font and also separate fonts for inline fractions, superscripts/subscripts, super-superscripts, etc. If you use the same font for symbols at multiple different sizes, the ones which have just been uniformly scaled are incorrect: they have a distractingly uneven visual weight which is both ugly and less legible. Only math fonts which have multiple different optical sizes should be used for rendering complicated typography such as mathematical notation, and any renderer used needs to be able to successfully choose the correct font for different sizes of symbols.
(3) There were apparently supposed to be two separate lines of unrelated equations, but they were smushed together onto one line without any space in between. It's not clear what's going on there.
(1) Which browser and which OS? Your screenshot clearly fails the acceptance test, but we need to be able to reproduce the error.
(2) Having the font-family: maths CSS rule should indicate to the browser that it should use a math capable font. Chrome respects this option, and you can see the choice at chrome://settings/fonts with the default maths fonts being Cambria math in Windows. Firefox does things a little differently, but it looks like it defaults to Latin Modern Math on Windows, these are both fonts that respect the OpenType math table, so should scale correctly. Again, knowing browser and OS will help. But we need concrete examples of failures to be able to make a bug report or do anything.
We need to be able to reproduce errors to fix them. But, it is unacceptable to tell Wikipedia readers that the reason they cannot read Wikipedia mathematics articles is that they have the wrong browser/OS/installed fontbase. It needs to work out of the box, for readers in very different environments, on very different platforms, and with very different levels of technical expertise. Obviously, that is not true for MathML today, and that is why I think MathML is an unacceptable option. —David Eppstein (talk) 00:51, 10 October 2024 (UTC)[reply]
This is Safari v. 15.6.1 running on MacOS 10.15.7, but the fraction bar spacing is also unacceptable on recent iPhone Safari, the appearance is mediocre but in the vague direction of correct on Firefox v. 131, and MathML doesn't render at all on Chrome v. 87. –jacobolus(t)02:47, 10 October 2024 (UTC)[reply]
As for (2), as I have said repeatedly, telling readers to bring their own math font is strictly unacceptable for production use in English Wikipedia. Wikipedia needs to ship all of the necessary fonts from a single good math typeface (there are multiple freely available ones) to every reader for either the MathML or client-side MathJax options to be remotely acceptable. It's not possible to even evaluate what is a bug in the renderer vs. what is a bug in the font fallback mechanism vs. what is a bug in every individual font without having a consistent baseline.
To be honest, I doubt continuing this conversation is a super productive use of time. My recommendation would be, if the Foundation wants to go this route, then they should pay someone to come up with a test setup with several dozen variant devices of a wide variety and hire someone with significant expertise in the details of mathematical typography to sit down next to the developer(s) of this feature and go through the current cross-device rendering in detail sitting side by side (this is going to take days of full-time work if not weeks, just to document and understand all of the current rendering bugs) From where I sit it seems like the complaint here is not being listened to or understood, and I feel like we're wasting our breath. My own estimate is that MathML support in browsers is literally years away from being consistent enough across end-user devices to be a productive render target, and Wikipedia's current MathML output is also literally years of bugfixes away from looking professional. Client-side MathJax is much more promising, but is also going to take at least months of serious work, after settling on a single typeface to ship to readers. –jacobolus(t)02:51, 10 October 2024 (UTC)[reply]
(2) Totally agree with you and David that we should not require users to install specific fonts or modify settings in any way, and that the system should render well, with no "glitches" on a nearly all conbinations of platforms and browsers. This should be the sort of thing the Web QA team will assess. We can help ensure a quality product, or delay rollout, by assembing a good corpus of problematic examples to try. We know more about the intricies of mathematical typography that the QA team will.
Your torture test in any species of Chrome/Chromium is broken. Apart from the kerning, sizing, and font issues, everything involving matrix/align/cases and over/underset is completely broken. I would post a screenshot, but I assume that someone in WMF is responsible for checking things like the most popular browser used to access Wikipedia. Tito Omburo (talk) 11:45, 10 October 2024 (UTC)[reply]
(1) Every diacritical accent renders incorrectly, e.g. \hat a renders with the accent overlapping the letter, (2) subscripts render incorrectly with wrong vertical positioning (but sometimes too high and sometimes too low), (3) \operatorname renders incorrectly, (4) \left\vert renders incorrectly, (5) \partial is too close to the letter, (6) f' is completely broken, (7) f^{(3)} has the superscript run into the letter, (8) a sqrt with a fraction inside renders with too thin a line on top, (8) arguably this is a poor way to achieve the result but \overset{\underset{\mathrm{def}}{}}{=} has the letters too widely spaced, (9) \overline{abc} renders with more or less a hyphen striking through the top of the b, (10) limits of \prod and \sum have incorrect vertical alignment and the \prod and \sum symbols themselves are too small, (11) \xrightarrow[T]{n\pm i-1} has the wrong size arrow and horrible alignment of the parts above/below, (12) \overbrace puts a normal-sized curly brace turned sideways over the middle of whatever is being braced which does not stretch and is anyway too small, (13) fraction bars are consistently not quite wide enough (aside from the vertical spacing issue), (14) \lim_{n \to \infty} has too much horizontal space around \to, (15) \int renders with a too small symbol and overlaps a following fraction, (16) x^3\, dx has too much space between parts, (17) 0.5 has too much space around the decimal point, (18) \binom{n}{k} uses parens that are too small, (19) \begin{Vmatrix} x & y \\ z & v \end{Vmatrix} has mismatched sizes for the surrounding ||, (20) \bigl( renders a normal sized paren instead of a larger one, (21) \begin{cases} ... uses a too small brace, (22) \begin{alignat} .. does not properly align at the indicated & points, (23) \begin{array}{lcl} does not respect the specified alignment directions, (24) \hline in an array does not render, and vertical lines indicated do not render at the correct widths, (25) | renders with too small a symbol not matching other brackets such as \langle, (26) kerning is poor for uppercase greek (too wide) and lowercase greek (mostly too tight, but some too wide), (27) blackboard bold symbols are too wimpy to be legibly double-lined, (28) \mathsf renders smaller than the other math fonts, (29) \pm is not vertically aligned correctly (too low), (30) parentheses sometimes overlap the content inside, (31) parentheses horizontal spacing with surrounding content is inconsistent and usually at least slightly incorrect, (32) apart from rendering the prime completely wrong in x' the spacing afterward is much too wide, (33) spacing between a regular variable and a following named function is too tight, (34) vertical positioning of lines in \begin{cases} is inconsistent, (35) spacing between numbers and a following variable is too tight, (36) spacing around \cdots is too tight, (36) spacing before ; is too wide, (37) \tfrac renders incorrectly (not small enough, vertical spacing too tight), (38) sqrts in fractions are too large and extend too far below the baseline.
Firefox does considerably better with https://en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative but there is still a long list of problems. A naively scaled font being used for inline fractions and superscripts, etc. is still a problem here. Beyond that:
(1) diacritics are not quite correctly positioned, sometimes too low, sometimes not horizontally centered relative to the visual top of the letter, (2) the \hat symbol is the wrong shape, looking like a wedge instead of a hat and \widehat uses the same symbol, (3) \lVert z \rVert has too much horizontal space around the z, (4) \operatorname{d}\!t has the two letters overlapping (\operatorname is wrong for this use which should just be \mathrm{d}, but \operatorname needs to add space, which the negative space was added as a tweak to eliminate; this kind of tweak for the previous renderer behavior will be found all across wikipedia and any new renderer needs to have close enough spacing to the previous renderer to not break them all), (5) \nabla\psi has too much space between, (6) fraction bars are too thin, (7) dy/dx has too much space around the slash, (8) dy, dx have slightly too much space between letters, (9) f' is completely broken here too, (10) \ddot y needs the dots pushed slightly to the right, (11) \shortmid uses the same symbol as \mid, which is incorrect, (12) square roots have overlines which are too thin and don't align with the √ part of the symbol, (13) \setminus and \smallsetminus use the same symbol, which is incorrect, (14) := renders with too much space between, (15) 45^\circ has too small a circle, (16) \not\operatorname{R} has a misaligned strikethrough, (17) \textstyle \prod_{i=1}^N x_i has the top limit of the sum too high, and the limits aren't consistently aligned on the left, (18) \lim_{n \to \infty}x_n has too much space around the \to, (19) \int\limits_{1}^{3}\frac{e^3/x}{x^2}\, dx has a horizontally misaligned top limit, and not enough space between integral and fraction, (20) 0.5 has too much space around the decimal point, (21) \cancel{y} has a poorly aligned strikethrough (not vertically centered), (22) vmatrix and Vmatrix don't have enough space between content and surrounding delimiters, (23) smallmatrix does not render small, (24) \begin{cases} has a brace with a disproportionately thick stroke relative to the font and too much vertical space between cases, (25) alignat doesn't get alignment correct at the indicated &, (26) \begin{array}{lcl} doesn't apply the indicated alignment directions, (27) \begin{cases} doesn't have enough horizontal space between the brace and the content, (28) \hline in an array renders but doesn't go from edge to edge, and the outside lines aren't rendered thick enough, (29) \left / renders too small around large content, (30) |\bar{z}| renders with inconsistently sized/aligned || and neither side is correctly sized or aligned.
I tried en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative on Chrome on Android (Pixel phone, default setup) and found it to be very badly rendered in many ways:
Diacritics tiny, too far above their letters
The operator font has a significantly larger x-height and heavier weight than the math variable font, and there is no space between the operators and their arguments
Greek letters are far too wide, out of scale with Roman
In differentials and derivatives, commas placed too close to the fractions they occur in, so close that they look like primes on the variables
Actual primes are placed tiny and high above the letter they modify, indistinguishable from diacritics
Ell does not look like a letter, and certainly not like an ell. Maybe it is a weird at-sign?
The radical sign is much heavier than its crossbar, with a visible gap where they should connect, and is too high and small, to the point that in the expression sqrt(x^3+y^3) it looks like the square root is only on the exponents and not on the whole expression. I assume this would only get worse for nested radicals.
In the overset alpha omega tests, the alpha is tiny compared to the omega, regardless of whether it is above or below. The gamma is also tiny.
The over-arrows, over-braces, and under-braces are sized for a single character regardless of what they are over
The "Arrows" example has gone full Zalgo (he comes). Characters all on top of each other. Totally unreadable.
In many cases the limits of the summations, products, and integrals touch the summation or product or integral sign. The summation and product signs are indistinguishable from capital sigma and pi, too small. The integral sign is also too small, looking more like a bold sans-serif text long-s. The same issue with limits touching the signs also applies to the bigcap and bigcup.
You would think rendering "0.5" would be so easy as to be non-problematic. You would be wrong. There is too much space around the decimal point.
The binomial coefficients only use text-size and text-weight parens. Even in the case of tbinom this is wrong (they look far too heavy).
The matrix left and right delimeters only use text size. This is never right. In the case where \bigl has been explicitly used, the size has not changed but now there is extra unnecessary whitespace between the delimeter and the matrix.
The cases and aligned formulas are not aligned. The cases left bracket is text size, which is never correct.
In "parenthesizing big expressions", both the "bad" and "good" examples look identical. Both are bad. All of these parenthesized expressions use only text-size delimiters, incorrect for all of them. Especially bad are the floor and ceiling functions on a vertical fraction, where the floor and ceiling delimiters are raised above the midline so they look like they are applying only to the top part of the fraction, changing the meaning. In the examples of nested parens with different size qualifiers, all render in a single size. For some reason the last of these examples, with the nested slashes, puts much more spacing around the forward slashes than the backslashes.
The examples with mathbf do not work. The result just looks like italic, at normal text weight. Boldface Greek is also identical to non-boldface Greek. Greek italic capitals are not italic (they are upright just like the default Greek).
The Roman typeface is actually displayed as sans-serif, but the sans-serif typeface is actually displayed as italic serif. The sans-serif Greek is sans-serif, but this is the same as for all other Greek; there is no change in visible appearance.
Mathcal produces the appearance that I would expect mathscr to produce (curly script letters). (See File:Mathscr-vs-mathcal.png for how these are supposed to look.)
Fraktur has no effect; it produces the same italic text that you would get by default.
In the text "an inline expression like [integral] should look good", it doesn't look good, because inline integrals should put the limits to the right but here they are placed vertically above/below, making bad line spacing.
I didn't go carefully through the individual examples at the end of the link but my general impression was one of ugliness, with many of the same problems above and some others (such as limits with infinity signs becoming too big and overpowering whatever thing they were supposed to be a limit for).
An aside re "the convention [of using HTML for inline math instead of math formatting] is really annoying": I agree, but I predict that shifting to MathML is going to increase the usage of this convention, because MathML formatting is so bad that html-formatted math will look better. —David Eppstein (talk) 20:19, 10 October 2024 (UTC)[reply]
Thanks to Jacobolus, Tito and David for these. There is going to need to be a bit of Triage here, as thats a lot of problems, and there are basically two of us working on this, and we can only really work on a few at one time.
Trying to think through prorities 1) The three glitches Krinkle mentioned: glitches where symbols appear that shouldn't; glitches where symbols don't appear that should; glitches where symbols appear in an obviousy incorrect place. 2) Problems that affect all browsers, have a higher prority, that those specific to one browser/OS. 3) For browser/OS specific one for practical reasons Windows bug are likely to addressed first as that the machine I use, I can get access to a Mac in the libary at work but progress there will be slower.
It looks like this user is in the Albert-László Barabási school of network science. He's a real researcher but also known for some rather exaggerated or pseudo-scientific claims, see e.g. [4]. A textbook on random graphs like Bollobas' will be a vastly more reliable reference than any paper of Barabási's, or most papers in the 'network science' field. When it comes to wiki articles on network science itself, it's ok to use Barabasi's work as a reference. I would avoid it otherwise. Gumshoe2 (talk) 20:17, 21 September 2024 (UTC)[reply]
That looks like a good revert. The added material was, at best, off-topic. Also, the source removed here was from 2002, pretty much the height of the "scale-free networks" hype era and before the people in that field were adequately scrupulous about things like testing whether a straight-ish line on a log-log plot really is a power law. XOR'easter (talk) 23:21, 22 September 2024 (UTC)[reply]
503 pages currently link to URLs of the form maa.org/press/maa-reviews/*. Many if not all of these appear to be broken. www.maa.org needs to be changed to old.maa.org, as for example here. And sometimes maa.org needs an old. inserted before it, as for example here. Hopefully there is an automated tool that can be deployed for this. XOR'easter (talk) 08:30, 23 September 2024 (UTC)[reply]
Seems like a lot of MAA links are broken (not just reviews), but the reviews have the feature that they are recoverable. Now slightly below 500 (although some of those the search finds already have archived versions linked, which both means that for them the situation isn't too bad and that one should be a little careful with an automated fix). --JBL (talk) 00:28, 27 September 2024 (UTC)[reply]
At least we have a simple fix for these ones. I have yet to find a working replacement for the broken American Physical Society Fellow archive, to which we have many links. —David Eppstein (talk) 01:45, 27 September 2024 (UTC)[reply]
Review of the section "Universal algebra" of the article "Algebra"
If (as I just did at File:Lattice in R2.svg) you encounter a really old svg illustration that is mysteriously missing much of its content, try looking for attributes like "xlink:href" in its source code. This attribute used to be used for referring to named objects defined elsewhere in an svg file, but it has been deprecated since 2018 or so when svg 2 was released. Some time in the last year the Wikimedia svg code was updated and stopped handling these. The fix is to replace "xlink:href" by "href". —David Eppstein (talk) 06:51, 27 September 2024 (UTC)[reply]
Hello David Eppstein. I happened to be reading Wikipedia:SVG help today, which suggests to exclusively use "xlink:href" rather than "href". This is completely outside of my area of expertise, but perhaps it would be worth updating this help page if Wikimedia has deprecated this. Kind regards, Pagliaccious (talk)22:11, 27 September 2024 (UTC)[reply]
It's the SVG standard that deprecated it; Wikimedia is belatedly following suit. xlink:href also doesn't work in Chrome and in Adobe Illustrator; I don't know how long that has been the case. —David Eppstein (talk) 22:14, 27 September 2024 (UTC)[reply]
Which things that should not be included in mathematics articles?
In the article four-dimensional space, two users were edit-warring for whether to add video games about four-dimensional objects. The first reversion was because of the WP:BALANCE, and the replying showed a short summary, followed by blanks. Two video games that were added were the Miegakure and 4D Miner.
I think it would be fine to add some content about 4D video games, but there should be secondary sourcing that puts it into context, not just a random selection of games that happen to have 4D elements. Ideally, the lead section of List of four-dimensional games should contain an introduction into the concept. A shorter version of that would then make sense in the four-dimensional space article. —Kusma (talk) 09:54, 27 September 2024 (UTC)[reply]
I don't have a problem with mentioning 4-dimensional video games in an article about 4-dimensional space, e.g. in the art section. It's probably not worth putting an extensive discussion there though; maybe more detail could fit at Fourth dimension in art or the like. Any material added to the 4-dimensional space article needs to be concise, supported by sources, and a neutral summary of the subject. –jacobolus(t)22:01, 27 September 2024 (UTC)[reply]
WikiFunctions in infobox
@Monkelogus has taken it upon themselves to add a link to the respective WikiFunctions function on {{Infobox logical connective}}. While I think this is viable in some form, I just wanted to poll for consensus as to whether we want this kind of presentation. I also have potential quibbles with how it's been placed near the top of the infobox, not consistent with how we generally link to sister sites. Remsense ‥ 论23:57, 27 September 2024 (UTC)[reply]
It's pretty true that it's kinda useless. I think I'm gonna remove them shortly. However, stuff like SHA-2 and is prime number functions might be much more helpful, when the other alternatives are some random online tools. Monkelogus (talk) 00:37, 28 September 2024 (UTC)[reply]
Monkelogus has added links to Wikifunctions at the top of several mathematical articles. IMO this must be avoided, and I reverted this, because such a link belongs to sections External links, or to a section describing the linked algorithm, if such a section exists.
Having had a look to one of these links, I found it not understandable for our common readers. IMO such links must be added only if really useful.
I added most of them at the "see also" section, but I agree that right now wikifunctions is extremely buggy and should only be added when it's needed. Monkelogus (talk) 16:29, 28 September 2024 (UTC)[reply]
I am attempting to clarify the definition and description of "indeterminate" in the article as I do in this version, however, another user seems to disagree with how my sources define the term and is enforcing the this version, and we can't seem to come to a consensus.
To be clear, I elaborated this version for resolving concerns that I have with the old stable version and, partly, for including some relevant remarks providen by Farkle Griffen, in particular the fact that some authors give a definition of an indeterminate that implies that every polynomial and the constants π and e are indeterminates. D.Lazard (talk) 15:36, 28 September 2024 (UTC)[reply]
I think Griffen's version of the lede is clarifying. I don't think the definition of an indeterminate as a transcendental over a ring is appropriate, precisely for the reason noted that this implies π is an indeterminate over the rationals, when it is clearly a *specific* element of the completion of Q at the infinite place, not an "indeterminate" one. This seems to be missing the point in a bad and confusing way that we should avoid if possible. Tito Omburo (talk) 20:05, 28 September 2024 (UTC)[reply]
@Tito Omburo, I think I see your point. But one comment I have is that I think the word "indeterminate" is a bit of a misnomer. Many authors don't see indeterminates as literally indeterminate, but rather as a kind of (unchanging) object; specifically, the indeterminate X is an element of the ring R[X], and it doesn't change within it. But one still wants to allow "substitution" of X for elements of R. Since X isn't a variable, authors get around this by defining "substitution" as a Ring homomorphism from R[X] to R. The transcendental definition just formalizes this.
"We generally reserve the expression “‘t is an ‘indeterminate’ over F’’, when we are thinking of evaluating t. Field theoretically, however, the terms transcendental and indeterminate are synonymous (so that the subfield of and the field are isomorphic)."
But, again, I digress.
I do, however, see your point. Having this definition in the lead is confusing and too technical for the average reader. But I do still believe it deserves to be mentioned in the article. How about these formalizations simply be moved to a new section further down? Farkle Griffen (talk) 20:08, 29 September 2024 (UTC)[reply]
@Farkle Griffen Some comments: (1) In general, please do not ever use more than ~3 footnotes in a row (even 3 in a row is pushing it) – it is unnecessary to bludgeon readers with footnotes, and in the lead section it's often better to have no footnotes at all if the same material is sourced from the article body. (2) It is not really that useful in my opinion to link to a bunch of course notes, whenever other sources are available; these are not usually considered "reliable sources" by Wikipedia standards, though they can sometimes be leaned on in a pinch. (3) Your lead section is in my opinion much too long and not that legible. I'd focus on getting the main point across, and elaborating about details later in the article. I think the existing lead does a decent job of giving an idea what an indeterminate is and why such a concept exists, but it would certainly be helpful if we could find some kind of historical survey better explaining the history of the word (not sure any such source exists, unfortunately). –jacobolus(t)22:57, 28 September 2024 (UTC)[reply]
(1) Is this a Wikipedia policy, or your opinion? I'm not asking to be snarky, I just don't know. Either way, yes, I will hereon take this into consideration.
(2) I'm a bit confused what you mean by this? Of the sources given, only two are course notes, Howlett and Grinberg, and the rest are textbooks; though these two can be removed if you believe they are problematic.
Although, as a bit of explanation: the only reason I've opted to include them is because of the high standard of sourcing being imposed on claims (due to the several accusations of WP:Original research). Howlett for the informal description of indeterminates in the sequence definition, noting: "X, X^2 , X^3 , . . . are nothing more than symbols written alongside the coefficients to enable us to see which is the 0th, which the 1st , which the 2nd, and so on.", and Grinberg for added support that authors do consider this definition "more formal."
(3) That's a fair point. I agree these formalizations aren't helpful in the lead. However, I do believe they are helpful to more experienced readers to know such formalizations exist. How about we move these definitions to a seperate section? Then the lead becomes much shorter, and very similar to the current one
And I don't agree about their lead. The biggest issue is "An indeterminate is a variabe" creates unnecessary confusion between indeterminates and variables. As far as I can tell, no source defines indeterminates as variables. And this is for good reason; one usually wants to use indeterminates so that, for instance, the polynomials over , x and x^5 are not equal if x is an indeterminate, even though they are equal if x is a variable within the ring. And moreover, their description "just a symbol used in a formal way" doesn't add any clarity, and is more likely to confuse readers. Farkle Griffen (talk) 18:43, 29 September 2024 (UTC)[reply]
About citations in the lead, here's the relevant part of the manual of style (which, as a guideline, is lower in the hierarchy of Wikipedia rules than a policy but much higher than one person's opinion): WP:LEADCITE --JBL (talk) 19:43, 29 September 2024 (UTC)[reply]
Articles about big lists of open problems
Does Wikipedia allow for creation of articles about big lists of open problems, such as Yau's problems or Arnold's problems? Or maybe it's better to create separate articles for each problem? These two examples of big lists of problems seem to have strong influences in mathematics research today, in geometry and dynamical systems at least. DuqueLL (talk) 19:09, 29 September 2024 (UTC)[reply]
There are certainly multiple articles about Hilbert's problems, because there are multiple in-depth secondary sources (multiple entire books!) about those problems. That's what such an article or list needs: multiple secondary sources, like anything else, per WP:GNG. —David Eppstein (talk) 19:15, 29 September 2024 (UTC)[reply]
It was also reviewed in MR and ZBL. Those don't usually contribute to notability (because their choice to review mathematics books is routine) and the MR reviewer (of the 2000 Russian version) is the same as the later Intelligencer reviewer, but they might still be useful in providing content for an article. —David Eppstein (talk) 23:09, 29 September 2024 (UTC)[reply]
I would suspect that either Yau or Arnold's problems could, on the merits, be justified as a standalone page. However they are both rather long (Yau's 1982 list has 120 problems and his separate 1993 list has 100, and there seem to be a comparable number of Arnold problems), it may not be easy to write a useful page for either. Gumshoe2 (talk) 21:01, 29 September 2024 (UTC)[reply]
Thanks to everyone! I've submitted it to review. English is not my native language, so maybe the English could be improved and I don't know, but anyways it looks like a very good start! DuqueLL (talk) 00:56, 30 September 2024 (UTC)[reply]
Should Algebra be reverted to the version of 21 Decembre 2023?
The present state of Algebra results of numerous edits done by a single editor, Phlsph7 since 21 Decembre 2023. It results that that the article presents a biased and misleading view of algebra that reduces algebra to universal algebra and the part of algebra that is taught in secondary educalion ("abstract algebra" and elementary linear algebra). This make that the article is very incomplete. I started a tentative to completing the article, without changing its structure, but it appeared soon that this is an enormous task this would require an amount of time that I am not willing to do.
Nevertheless, the article goes against the policy WP:NPOV by excluding a very large part of algebra.
@Phlsph7 This is a common problem with reviews: it is easy to examine the content that is there and judge its style, but takes deeper thought to figure out a neutral and relevant high-level scope, organization, and narrative flow for articles about broad topics. –jacobolus(t)16:27, 30 September 2024 (UTC)[reply]
Forgive me if I lack adequate understanding of all the connections here, but it seems like this sense of iniquity is at least partially based on confusions regarding use versus mention of terminology, of labels versus concepts. I hope I'm not explaining perfectly obvious and accounted-for points here, but we generally write articles about concepts, not the terms we apply to them—cf. God versus God (word)...versus God in Islam versus Allah. When you say the previous version adheres to NPOV, it seems like you view an article that covers "every distinct sense that the label algebra is applied to" as the goal, rather than an article that covers "the core, contiguous concept most commonly labeled algebra". In fact, the pseudo-disambiguation section in the old version almost forces me to hold this view. Have you accounted for this potential discrepancy in the present misunderstanding? Remsense ‥ 论15:57, 30 September 2024 (UTC)[reply]
It's not as scattered a semantic field as I implied, after a refresher reading through the previous discussions linked. I would strike my reply altogether as I don't feel like I have as much as others here to offer in terms of domain-specific analysis; but I'll risk the possibility of making further less-than-helpful remarks by trusting my generalized analysis here: the present article seems to lend itself better to expansion outward than any other course of action with the previous revision, and I can't help but see its reversion or total denaturing as counterproductive to solving what everyone seems to agree are the present issues to one degree or another. Remsense ‥ 论16:56, 30 September 2024 (UTC)[reply]
I do not see how reverting would be the right course of action here. By all means, add material about topics that are missing, and adjust the section headings for better organization if necessary. But the current version is a better point to build from than the one from last December. XOR'easter (talk) 15:58, 30 September 2024 (UTC)[reply]
I think Universal algebra is overemphasized. It is not one of the main branches of algebra. It does not even have an MSC code. The main divisions are 08 (general algebraic structures), 12 (field theory and polynomials), 13 (commutative algebra), 15 (linear algebra), 16 (associative algebras), 17 (non-associative algebras), 18 (category theory), 20 (group theory). Tito Omburo (talk) 16:15, 30 September 2024 (UTC)[reply]
A revert to a version from a full year ago when the article has already passed a GA review and is currently going through FAC makes absolutely zero sense. More information on other branches could maybe be added, but I'm not knowledgeable enough to speak to that. QuicoleJR (talk) 16:18, 30 September 2024 (UTC)[reply]
Comprehensiveness is very important at GAN, one of the six top-level criteria of WP:GACR (#3). If the reviewer failed to properly address it, then that is a problem with the GA review and maybe should be brought to GAR. —David Eppstein (talk) 18:04, 30 September 2024 (UTC)[reply]
I know you are aware, but it's worth repeating here that "comprehensive" is a word used only in the FA criteria, while GA criterion 3a only requires that an article addresses the main aspects of the topic. Remsense ‥ 论18:08, 30 September 2024 (UTC)[reply]
Yes, there's a difference between the GA "adequately broad" and the FA "comprehensive". I have a lot of bad memories about the GA processes and don't want to get into that world again, but I think it's fair to say that the former is arguably met and the latter not. XOR'easter (talk) 22:44, 30 September 2024 (UTC)[reply]
I don't think reverting is particularly helpful, but it would be good to get more experts involved in substantially expanding this article and somewhat reorganizing it (hopefully people with significant professional mathematical experience directly in algebraic topics – this does not include me). –jacobolus(t)16:21, 30 September 2024 (UTC)[reply]
I agree to oppose reversion with Remsense, XOREaster and others. I don't have the mathematical knowledge to judge the validity of the complaints raised, though many other editors do, and I note that so far we have yet to see others appearing to diagnose the same problem with the same level of seriousness, despite several stages of review. However, assuming that the problems are real and need fixing, they are very much a WP:SOFIXIT issue rather than cause to undo a great deal of hard (and excellent) work by a conscientious and skilled editor. Big articles like this will never please everybody, but equally we should be very cautious when talking about applying drastic measures to articles which, by their nature, take time, negotiation and skill to build up. UndercoverClassicistT·C17:32, 30 September 2024 (UTC)[reply]
Taking a glance at the suggested version to restore, I see little missing from the current version, except that most terms in the enlightening "Areas of mathematics with the word algebra in their name" list have been dispersed into the prose. The discussion on universal algebra should be pared down and sections reformatted, but a complete reversion is unreasonable. Pagliaccious (talk)04:16, 1 October 2024 (UTC)[reply]
I don't see a case for reverting, but I do see a major problem and a minor problem.
There is this article about one of the most famous differential geometers. The first thing one finds there is this message: "this article may require cleanup to meet Wikipedia's quality standards. The specific problem is: make it shorter, especially the "Scientific interests" section. Please help improve this article if you can.". Why should it be made shorter? What should be cut to make it meet the quality standards? PadawanDG (talk) 23:54, 2 October 2024 (UTC)[reply]
"Add references" should mean: add references by other people than Pogorelov, discussing Pogorelov's work in depth. Pogorelov's own publications are not good references for claims about his research contributions. —David Eppstein (talk) 00:41, 3 October 2024 (UTC)[reply]
It looks like a large part (and maybe all) of the "Scientific interests" section of Pogorelov's wikipage has been plagiarized from this article. Perhaps it should be deleted until something more suitable can be written? I don't know well wiki policies on this. Gumshoe2 (talk) 02:45, 3 October 2024 (UTC)[reply]
For example, with a randomly chosen paragraph, compare wiki:
The first work of A. V. Pogorelov on surfaces of bounded extrinsic curvature was published in 1953. In 1954, J. Nash published the paper on С1-isometric immersions, which was improved by N. Kuiper in 1955. It follows from these studies that a Riemannian metric defined on a two-dimensional manifold, under very general assumptions, admits a realization on a С1-smooth surface in a three-dimensional Euclidean space. Moreover, this realization is carried out as freely as a topological immersion into the space of the manifold on which the metric is given. Hence it is clear that for С1-surfaces, even with a good intrinsic metric, it is impossible to preserve the connections between the intrinsic and extrinsic curvatures. Even in case if a С1-surface carries a regular metric of positive Gaussian curvature, then this does not imply the local convexity of the surface. This emphasizes the naturalness of the class of surfaces of bounded external curvature introduced by Pogorelov.
to Borisenko–Vesnin–Ivochkina:
Pogorelov’s first paper on surfaces with bounded extrinsic curvature appeared in 1953. However, in 1954 J. Nash published a paper on C1-isometric immersion, the results in which were then improved by N. Kuiper in 1955. Their work showed that, under rather general assumptions, a Riemannian metric on a 2-manifold can be realized on a C1-smooth surface in 3-dimensional Euclidean space. Moreover, such a realization can be implemented as freely as a topological immersion of the manifold with metric in the ambient space. From this it is clear that for C1-surfaces there can be no such connection between the extrinsic and intrinsic curvatures, even with a nice intrinsic metric. And even when a C1-surface carries a regular metric with positive Gaussian curvature, this does not mean that it is locally convex. All this underscores that Pogorelov’s class of surfaces with bounded extrinsic curvature is a natural class.
I agree with Gumshoe2 judgment, the excerpts he compared are too close to each other. By the way, I'll edit your comment, if you don't mind, Gumshoe2, because as others noted, we can't show copyrighted material, even if it's only for comparison. It's safer this way. PadawanDG (talk) 03:27, 3 October 2024 (UTC)[reply]
If the plagiarized content is still up when I have more time, I will remove it. Anyway, here are some references which may be useful secondary sources for certain claims about Pogorelov's work:
Li, An-Min; Simon, Udo; Zhao, Guosong; Hu, Zejun (2015). Global affine differential geometry of hypersurfaces. De Gruyter Expositions in Mathematics. Vol. 11 (Second revised and extended edition of 1993 original ed.). Berlin: De Gruyter. doi:10.1515/9783110268898. ISBN978-3-11-026667-2. MR3382197. Zbl1330.53002.
Calabi, Eugenio (1972). Complete affine hyperspheres. I. Convegno di Geometria Differenziale (24–28 Maggio 1971); Convegno di Analisi Numerica (10–13 Gennaio 1972). Istituto Nazionale di Alta Matematica, Rome. Symposia Mathematica. Vol. X. London: Academic Press. pp. 19–38. MR0365607. Zbl0252.53008.
Just before I was about to remove the content in question, I realized that its inclusion in December 2017 predates the journal article, published in 2019. So perhaps the plagiarism is in the other direction? It would be unusual, since (some of) the 2019 authors had previously published on Pogorelov, so there would not be any apparent need for them to take material from wikipedia. I haven't been able to find any writing previous to 2017 that the material could be taken from. So I won't remove any material for now. Gumshoe2 (talk) 16:58, 5 October 2024 (UTC)[reply]
The journal article is itself a translation by N. Kruzhilin from a Russian-language original published in a parallel Russian-language journal. One possibility I could imagine is that the Russian language version was actually completed and circulated considerably before the 2019 dual English-Russian issue dating, and that our article text is a separate close translation of the same Russian text. Felix QW (talk) 16:28, 9 October 2024 (UTC)[reply]
I believe that much of the content in the 2019 article is itself taken from an older 2006 article by Borisenko: Борисенко, Александр Андреевич (2006). "Алексей Васильевич Погорелов—математик удивительной силы". Журнал математической фи��ики, анализа, геометрии. Фізико-технічний інститут низьких температур ім. БІ Вєркіна НАН України. In particular, the paragraph used as an example above is repeated verbatim (in Russian). An English translation can be found here on arXiv. Pagliaccious (talk)18:03, 9 October 2024 (UTC)[reply]
It's equivalent 1 was almost simultaneously promoted to GA :) There were some distasteful comments about my work at 1, prior to my final push, which I hope now can be seen for what they were and that project members can be nicer to one another. Polyamorph (talk) 07:57, 3 October 2024 (UTC)[reply]
There are two remaining tagged issues with 0.999...: a {{citation needed}} and a warning about potential synthesis (the Negative zero is another redundant feature of many ways of writing numbers paragraph reads like something that somebody thought sounded analogous). If anyone wants to address either or both of those, please do; this article has exhausted me. XOR'easter (talk) 20:25, 3 October 2024 (UTC)[reply]
Oops, I overlooked a tag about a statement needing a non-primary source, on the Blizzard Entertainment bit (which looks rather like a remnant of 2004-vintage "in popular culture" Wikipedia). A quick search did not find a suitable reference. XOR'easter (talk) 00:52, 7 October 2024 (UTC)[reply]
Thanks for taking out the negative zero thing. It was definitely "original synthesis" and I think it's a nonsense comparison: negative zero represents underflow, i.e. all negative numbers between zero and half of the smallest representable negative number. This is not at all an analogous situation to 0.999999..., in my opinion. –jacobolus(t)04:06, 7 October 2024 (UTC)[reply]
Removed the Blizzard Entertainment bit. Couldn't find a suitable non-primary source and I'm not convinced of the long term significance of a 2004 April Fools joke on an online gamer forum.Polyamorph (talk) 10:37, 7 October 2024 (UTC)[reply]
Hello all,
There are a few MoS questions in Wikipedia talk:Manual of Style/Mathematics, including one that I started related to function notation and screen readers, and another that another user started about Laurentian notation.
If the good people of this WikiProject could head over there and provide some guidance, that would be great.
in the literature. It's not unusual for conventions to differ between Mathematics and Physics, or to change over time. I haven't seen it for co- vs contra-, but I have seen cases where at text uses one convention for most of the book but the opposite convention in a specific chapter. In the case of wikipedia, what matters is that the convention be explicitly stated and used consistently, or at least that deviations be explicitly justified.
I'm not challenging the edit, it's just that it reminded me that there are two conventions.
This is one of several conventions for which I am trying to locate online examples, e.g., sign conventions. Ideally, for each type I would like a single source that states which convention is used when, as opposed to two sources for opposite conventions. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:08, 4 October 2024 (UTC)[reply]
Both articles Archimedean solid and Catalan solid have similar properties and relatable topics: they are dual to each other, so they have the same symmetry; two of them have the property of chirality, so their dual are also chiral. Yet, this reason is not strong enough to keep them merged, unless there are more backgrounds in some sources. Anyhow, I guess some of the members of this project do not consent to this idea. Dedhert.Jr (talk) 12:28, 6 October 2024 (UTC)[reply]
Also see various sources in Talk:Laguerre transformations § List of references. Laguerre's word for an oriented line was "semi-droite" (literally "semi-straight"; in Euclid the Greek equivalent of "line" means curve and straight lines need a qualifier, but in English we eventually abbreviated "straight line" as "line"; in French "straight line" was instead abbreviated as "straight"). Later in German and English the names "spear" and "ray" were used. For English Wikipedia's purposes, I think a term such as "oriented line" (or perhaps "directed line") is the most explicit and unambiguous. –jacobolus(t)04:07, 8 October 2024 (UTC)[reply]
I have still not gotten a straight answer for how an oriented ray is supposed to be a different thing than just, you know, a ray. fgnievinski has been pushing paragraphs full of technicality on this that convey no information to me.
Now that you're here, fgnievinski, perhaps this question would focus on what is confusing me about your edits. Do you allow rays to be directed only towards their apex, only away from their apex, or do you imagine that there are two kinds of rays, one towards and one away? If there is only one orientation possible for any ray, then there is no point in choosing an orientation of a line and then using it to orient the ray, because there is no choice in how to orient the ray. On the other hand, if you imagine that there are two different kinds of oriented rays, then you should say that more clearly (with a source that says that clearly) instead of all this bafflegab about oriented lines. —David Eppstein (talk) 04:32, 8 October 2024 (UTC)[reply]
A point and an orientation of a line define a ray. Conversely, a ray defines an oriented line with a specific point. So, the phrase "oriented ray" is at best a pleonasm and at worst confusing (see David's post). It must not be used in Wikipedia, unless there are (I doubt) reliable sources discussing it. D.Lazard (talk) 10:08, 8 October 2024 (UTC)[reply]
Is it possible that the problem is the same as for DAG (which, when parsed literally, should mean “oriented forest”, but actually means “directed graph with no cycles”)? Like, maybe some people use the phrase “oriented half-line” not with the literal parsing but instead to mean the construction D.Lazard mentions (start with an oriented line, then take half of it)? I don’t see where fgnievinski has used the phrase “oriented ray”. 100.36.106.199 (talk) 10:06, 9 October 2024 (UTC)[reply]
EoM's definition of "half-line" and PM's first definition, cited above, say nothing about orientation, it just defines a locus. Similarly, Pedoe (1988) defines "half-line" as a set of points, not implying any orientation, and calling point A an "endpoint" instead of "initial point". Wylie (1964) doesn't mention "half-line", it defines a "ray" and initially it doesn't say anything about orientation: point A splits a line in two and point B selects one of the two halves. Orientation only appears later in the discussion, when it says the other half has the opposite direction. It'd benefit the reader to make it more explicit, stating a direction (from A to B) is often implied, although strictly it's not required. For example, the definition of plane angle doesn't require the sides to be orientated, only to be concurrent (meeting at a vertex).
I started assuming "half-line" was unoriented:
Orientation
Unoriented
Oriented
Size
Infinite
Line
Oriented line
Semi-
infinite
Half-line or
unoriented half-line
Oriented half-line
(also: ray)
Finite
Line segment
Oriented line segment
Now I realize "half-line" is often assumed to be oriented:
the concept of "one half of an unoriented line" exists, – yes, this is called a "half-line" or "ray", and is typically defined as a locus of points. It only has an implicit orientation. I don't think a separate concept of "one half of an oriented line" is very useful / widely used, and we shouldn't imply that this is how the word "ray" is defined. To adopt your table method:
Orientation
Unoriented
Oriented
Size
Infinite
Line (Or more explicitly, straight line)
Oriented line (sometimes called a half-line, ray, or spear)
Semi-
infinite
Half-line or ray (note: has an implicit orientation)
N/A – not a commonly used concept
Finite
Line segment
N/A – inconsistently defined and needs care to describe. More commonly used concepts include ordered pairs of points, or the translation vectors formed from their difference.
Also, an important distinction between objects like rays, lines, and segments as usually defined vs. oriented lines is that the former types objects are considered to be loci of points, whereas oriented lines are considered to be primary objects in themselves. I think we should probably have a separate article titled Oriented line and eventually another one titled Laguerre geometry describing the resulting geometry when oriented lines are taken to be the fundamental objects rather than points.
Instead of "A semi-infinite oriented line is called a ray", it would be more supportable to say something along the lines of "A ray is half of a line which has been divided by a point, which is infinite in one direction, and is thus similar to an oriented line insofar as it has an implicit orientation." –jacobolus(t)17:01, 8 October 2024 (UTC)[reply]
I think it's also pretty common in some other flavors of geometry such as projective geometry to think of points and lines as primary objects with an incidence relation, rather than lines as subsets of points. The difference is that the subset conceptualization still works, while in oriented geometry you need the lines to be objects so you can attach orientations to them. —David Eppstein (talk) 17:51, 8 October 2024 (UTC)[reply]
Invitation
The Wikipedia:WikiProject Council is a group that talks about how to organize and support WikiProjects. If you are interested in helping WikiProjects or learning more about them, please put that page on your watchlist and join the discussions there. Thanks, WhatamIdoing (talk) 18:42, 8 October 2024 (UTC)[reply]
This (WikiProject Mathematics) is one of the most active WikiProjects, as measured by the number of editors who check this talk page. The WikiProject Council is a place for people to talk about WikiProjects: when to create or merge them, how to recruit new participants, where to find help with templates, etc. If you care about working together and want your group to do better at it, or to help other groups learn from your experiences and successes, then come and join us! WhatamIdoing (talk) 02:15, 9 October 2024 (UTC)[reply]
much better than in the Torture Test.
![{\displaystyle {\begin{aligned}\varpi &=[2,1,1,1,1,1,4,1,2,\ldots ],\\[8mu]2\varpi &=[5,4,10,2,1,2,3,29,\ldots ],\\[5mu]{\frac {\varpi }{2}}&=[1,3,4,1,1,1,5,2,\ldots ],\\[2mu]{\frac {\varpi }{\pi }}&=[0,1,5,21,3,4,14,\ldots ].\end{aligned}}}](https://cdn.statically.io/img/wikimedia.org/api/rest_v1/media/math/render/svg/77b83715e21dc69253b7047b2045b6e482802fdd)
The redirect Isometry (mathematics) has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 October 9 § Isometry (mathematics) until a consensus is reached. This discussion would particularly benefit from contributions from those familiar with the subject. Thryduulf (talk) 10:36, 9 October 2024 (UTC)