:For the time being, I'm [[gerrit:q/project:mediawiki/extensions/Math+is:open+-is:wip+owner:wiki@physikerwelt.de|waiting for code review]] for the reported bugs. Once this is merged, I will look at the next bugs. [[User:Physikerwelt|Physikerwelt]] ([[User talk:Physikerwelt|talk]]) 13:42, 5 October 2024 (UTC)
:For the time being, I'm [[gerrit:q/project:mediawiki/extensions/Math+is:open+-is:wip+owner:wiki@physikerwelt.de|waiting for code review]] for the reported bugs. Once this is merged, I will look at the next bugs. [[User:Physikerwelt|Physikerwelt]] ([[User talk:Physikerwelt|talk]]) 13:42, 5 October 2024 (UTC)
::{{tq|i=yes| 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. {{pb}} {{tq|i=yes|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. {{pb}} {{tq|i=yes| 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. {{pb}} {{tq|i=yes| 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. –[[user:jacobolus|jacobolus]] [[user_talk:jacobolus|(t)]] 14:08, 5 October 2024 (UTC)
::{{tq|i=yes| 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. {{pb}} {{tq|i=yes|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. {{pb}} {{tq|i=yes| 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. {{pb}} {{tq|i=yes| 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. –[[user:jacobolus|jacobolus]] [[user_talk:jacobolus|(t)]] 14:08, 5 October 2024 (UTC)
:::"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 <nowiki>\operatorname{foo}</nowiki> always have space before and after, or are there cases when this is not the desired result? {{phab|T375861}}
:::We had a similar debate when server-side MathJax was introduced, aka SVG and somehow managed to get an acceptable rendered. --[[User:Salix alba|Salix alba]] ([[User talk:Salix alba|talk]]): 19:58, 5 October 2024 (UTC)
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]
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
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]
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]
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]
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]
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)
