Wikipedia talk:WikiProject Mathematics

Main pageDiscussionContentAssessmentParticipantsResources

Big traffic spike to Triangle

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.

(I added {{talk page header}} to Talk:Triangle hoping it would forestall some of the graffiti being directed there. Are there other good ways to deal with giant traffic spikes like this?) –jacobolus (t) 22:49, 11 August 2024 (UTC)

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

To be honest I don't care much about GA or FA, but it would be nice if the article were better sourced and more complete. –jacobolus (t) 01:01, 12 August 2024 (UTC)

Okay. I have made it on my sandbox, and the progress is on the way. For someone who would like to give comments or advice for improvement only, ask me on my talk page. Dedhert.Jr (talk) 03:56, 12 August 2024 (UTC)

I have some problems while expanding the article. In the case of non-planar triangles, I found out that there are other triangles as in hyperbolic triangle and spherical triangle. However, I also found out that hyperbolic triangles can be constructed by a so-called Thurston triangle [1]. It also contains the area of a hyperbolic triangle by using Gauss–Bonnet theorem, but according to which it is a geodesic triangle. Dedhert.Jr (talk) 11:38, 14 August 2024 (UTC)

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)

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)

Another problem: The article Triangulation (geometry) is somewhat short and unsourced in some areas. Do you think this article should be expanded, or rather redirected to the section of the article Triangle? Dedhert.Jr (talk) 05:43, 15 August 2024 (UTC)

Triangulation (geometry) should definitely be its own article, and does not make sense to redirect. But feel free to dramatically expand it. It's a large topic about which whole books have been written. –jacobolus (t) 16:03, 15 August 2024 (UTC)

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)

"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.

There should probably separately be a discussion of the use of triangles as common decorative elements etc. –jacobolus (t) 16:02, 15 August 2024 (UTC)

Triangles are definitely not the unique basis for rigid linkages; see Laman graph. The utility graph $K_{3,3}$ is I think the simplest triangle-free rigid graph (in 2d). —David Eppstein (talk) 18:04, 15 August 2024 (UTC)

That's an interesting subject well worth discussing in Laman graph or structural rigidity, but the utilities graph isn't a polygon, and isn't really relevant to the point that the triangle's rigidity is the reason for many of its practical applications. Edit: Maybe Triangle § Rigidity would be a good top-level heading for Triangle. –jacobolus (t) 19:56, 15 August 2024 (UTC)

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

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)

Thanks for putting in the time and energy. XOR'easter (talk) 21:18, 19 August 2024 (UTC)

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)

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)

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)

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

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)

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

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

@David Eppstein Sorry but that source is already linked as a reference or works cited in the Isosceles triangle, see the references:

• Heath, Thomas L. (1956) [1925]. The Thirteen Books of Euclid's Elements. Vol. 1 (2nd ed.). New York: Dover Publications. ISBN 0-486-60088-2.

Dedhert.Jr (talk) 10:16, 20 August 2024 (UTC)

Apparently the incorrect link is the fault of User:InternetArchiveBot: [3]. Reported: T372925. —David Eppstein (talk) 17:25, 20 August 2024 (UTC)

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)

What we need in this case is vol.1. —David Eppstein (talk) 17:31, 20 August 2024 (UTC)

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)

Yes. And the page number matches, answering Dedhert.Jr's question. —David Eppstein (talk) 18:00, 20 August 2024 (UTC)

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)

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)

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)

Yes, it would be entirely reasonable to add such material to triangle, if you want to. It would also be reasonable to discuss topics involving a bunch of triangles stuck together as in Delaunay triangulation, Triangulated irregular network, and Triangle mesh. And there are plenty of other triangle-related topics that are currently unmentioned or barely mentioned that could be discussed. –jacobolus (t) 19:47, 12 September 2024 (UTC)

Okay. Let me think about that. Dedhert.Jr (talk) 14:10, 14 September 2024 (UTC)

Page move to Piecewise function

After some discussion at Talk:Piecewise_function#Requested_move_20_July_2024, the page Piecewise was moved to Piecewise function. I still consider this decision nonsensical, and the new title highly confusing. For this reason, I'd like to draw your attention to the move. If nobody else has a problem with it, I'll shut up. - Jochen Burghardt (talk) 18:05, 25 August 2024 (UTC)

In addition, a separate(!) DAB page Piecewise property has been created, which links most of its entries (like "Piecewise continuous") back to Piecewise function, where they are explained more or less satisfactorily. According to Piecewise_function#See_also, "Piecewise property" is a generalization of "Piecewise function"! - Jochen Burghardt (talk) 18:05, 25 August 2024 (UTC)

According to WP:NOUN the title should be a noun. For example, instead of "French", articles are titled "French language" or "French people". — Rgdboer (talk) 20:08, 25 August 2024 (UTC)

Or "piecewise property". The problem with "piecewise function" is not grammatical; it is that many of the things defined piecewise are not exactly functions. See e.g. piecewise linear manifold. —David Eppstein (talk) 20:27, 25 August 2024 (UTC)

I'd move Piecewise property to Piecewise, which if someone wants could be upgraded to a "broad-concept article", and leave a separate article at piecewise function, which should ideally contain quite a bit more discussion of piecewise polynomial "splines", piecewise parametric curves as used in CAD/CAM, and so on. –jacobolus (t) –jacobolus (t) 21:33, 25 August 2024 (UTC)

My point is that there is no such thing as a piecewise function. Every function can be defined using if . then . else . endif (linearizing 2dim math terminology), and every function can be defined without it. This is stated correctly in the 2nd lead sentence. In order to subsume also e.g. piecewise linear manifold, what about "Piecewise definition"? - Jochen Burghardt (talk) 21:52, 25 August 2024 (UTC)

every function can be defined without it While this is maybe true in a very narrow pedantic sense, the concept of a "piecewise function" has a clear, obvious, and useful meaning (which is why it is used in practice), and there are valuable things to say about it as a concept which would not be relevant to an article about "every function". –jacobolus (t) 09:27, 26 August 2024 (UTC)

Given a function by its domain, range, and graph, you can check whether it is piecewise linear, piecewise continuous, etc. (provided additional restrictions to domain and range are met). However, I doubt that you can check whether it is piecewise (without any property); I even don't know what that could mean. Moreover, different properties can require different domain decompositions, e.g. $f:\mathbb {R} \to \mathbb {R} ,x\mapsto \min\{1,x^{2}\}$ is piecewise differentiable (use $(-\infty ,1]$, $(-1,+1)$, $[1,+\infty )$) and piecewise monotonic (use $(-\infty ,0]$, $(0,+\infty )$). Also note the absence of any case distinction from this definition.

What we can say, however, is what a piecewise definition is (one that has an outermost case distinction on a domain decomposition into finitely many intervals). Based on this, we can define a function to be piecewise xxx if is has some piecewise definition such that each piece satisfies xxx (this is what the article does). Possible, this can also be generalized from total to partial orders to subsume also David Eppstein's piecewise linear manifold example. - Jochen Burghardt (talk) 13:22, 28 August 2024 (UTC)

Okay, but "take a function and determine whether it is 'piecewise'" is not really something anyone cares much about. Instead, people are interested in proving properties about functions defined or known to be definable in pieces (usually each piece of some specific type, such as constant, polynomial, rational, a linear combination of given basis functions, continuous with bounded derivative, ...), because such functions are extremely common in all sorts of practical applications. Calling these "piecewise functions" is common and well understood (Google scholar turns up 37k results for that phrase – much more common than alternatives I can find, so a good title following WP:COMMONNAME). Deciding that "there is no such thing as a piecewise function" is in my view a semantic quibble that kind of misses the point. –jacobolus (t) 15:54, 28 August 2024 (UTC)

I agree that the term “piecewise property” seems problematic since, unlike continuity or differentiability, it’s not something a function can have or not. “Piecewise-linear” is a property that a space or a function, etc. can have but that’s different. Since other editors have made the same point, I have started a move proposal: “piecewise property” -> “piecewise” at talk:Piecewise_property#Requested_move_26_August_2024. —- Taku (talk) 08:16, 26 August 2024 (UTC)

What about Piecewise-defined property? Surely we agree that a given definition of a property can be piecewise (or not)? The piecewise functions of calculus are perhaps piecewise elementary functions, for example. 100.36.106.199 (talk) 10:37, 28 August 2024 (UTC)

I've been an advocate of piecewise-defined, as grammatically preferable to the other options. Tito Omburo (talk) 10:57, 28 August 2024 (UTC)

Or, if it must be a noun, piecewise definition. —David Eppstein (talk) 17:49, 28 August 2024 (UTC)

+1 for piecewise definition; that seems to get best at the correct concept. Piecewiseness is not a property of functions, but it is a property of definitions. --Trovatore (talk) 19:26, 28 August 2024 (UTC)

Sounds good to me, for the general concept article. Tito Omburo (talk) 19:42, 28 August 2024 (UTC)

Piecewise definition sounds good to me, too. XOR'easter (talk) 02:19, 29 August 2024 (UTC)

Sounds good to me, too. - Jochen Burghardt (talk) 11:52, 29 August 2024 (UTC)

Sure, let's do it. 100.36.106.199 (talk) 16:15, 29 August 2024 (UTC)

Definitely piecewise definition should be the title, and I'm surprised it isn't already. It is the definition, rather than the function itself, that is piecwise. Michael Hardy (talk) 05:50, 13 September 2024 (UTC)

Eigenmode vs. eigenmodes (redirects)

Currently,

• eigenmode redirects to Eigenvalues and eigenvectors, and
• eigenmodes redirects to Normal mode.

This is obviously confusing, because eigenmodes ([[eigenmode]]s) and eigenmodes ([[eigenmodes]]) are different link destinations.

Suggestion: the plural redirect [[eigenmodes]] should point to Eigenvalues and eigenvectors, just like the singular version. Thoughts?  — sbb (talk) 03:30, 5 September 2024 (UTC)

The word “mode” (with or with prefix) does not appear at Eigenvalues and eigenvectors; should it? 100.36.106.199 (talk) 10:36, 5 September 2024 (UTC)

I believe that the best way forwards is to look at all of the articles on eigenfunction, eigenmode, eigenstate, eigenvector and normal mode collectively, then discuss what to merge and what to redirect. As part of this, the redirects for singular and plural should be brought into alignment with each other after looking at what links to what.

My first take is that eigenfunctions and eigenvectors should be in the same article, but I could make a case for keeping them separate. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:52, 5 September 2024 (UTC)

Clearly the target of any of these links should not depend on whether it is plural or not. That's easy to fix.

I think Eigenfunction should be kept separate from Eigenvalues and eigenvectors, since the latter article is necessarily focused on linear endomorphisms in general, whereas the former should be focused on the specific application to function spaces. It's fine to leave a summary in Eigenvalues and eigenvectors § Eigenvalues and eigenfunctions of differential operators pointing to Eigenfunction as a main article. –jacobolus (t) 17:25, 5 September 2024 (UTC)

A mode is a standing wave. See eg https://www.feynmanlectures.caltech.edu/I_49.html#Ch49-S5

In mathematical models of wave systems these standing waves appear as "eigenfunctions", also called "eigenvectors" in some representations. A mode, a wave concept, is not a synonym for "eigenfunction", a mathematical concept.

Absent a significant reliable reference, "eigenmode" should be deleted. The word is redundant by repeating itself. Similarly "eigenmodes". Without a reference having these pages is misinformation. Johnjbarton (talk) 15:34, 5 September 2024 (UTC)

According to Eigenmode expansion, eigenmode is a specific term-of-art for solutions of the Maxwell equation along a waveguide. This usage seems to be consistent with many of the hits in a cursory Google scholar search. Tito Omburo (talk) 17:19, 5 September 2024 (UTC)

Thanks, but I disagree with your characterization based on the three sources in that page. None of these references define "eigenmode" and as far as I can tell they only use the word as a modifier as in "eigenmode propagation algorithm".

The solutions to Maxwell's equations along a waveguide seems to be just "modes". Jackson discusses "wave guides" in section 8.3 and says:

• "There will be a spectrum of eigenvalues and corresponding solutions which form an orthonormal set. These different solutions are called the modes of the waveguide.

Here is a review of quantum optics that uses the word 'mode' many times, but 'eigenmode' rarely and inconsistently.

• Fabre, Claude, and Nicolas Treps. "Modes and states in quantum optics." Reviews of Modern Physics 92.3 (2020): 035005.

My guess is that "eigenmode" has a specific technical meaning like you say. But what meaning?

Based on what we know so far, "eigenmode" should redirect to Eigenmode expansion since at least the word is used there. Johnjbarton (talk) 19:38, 5 September 2024 (UTC)

Ok I think I found a review that sorts this out at least for radio waves:

• Huang, Shaode, Jin Pan, and Yuyue Luo. "Study on the relationships between eigenmodes, natural modes, and characteristic modes of perfectly electric conducting bodies." International Journal of Antennas and Propagation 2018.1 (2018): 8735635.
  • Eigenmode expansion method (EEM) [3], singularity expansion method (SEM) [4], and characteristic mode analysis (CMA) [5] are three common modal analysis methods in electromagnetic engineering. The three modal analysis methods result in three different kinds of modes generally, that is, eigenmodes, natural modes, and characteristic modes, respectively.

Based on this reference (and thus restricted to the corresponding field), "eigenmode" is not a synonym for "eigenvector" or "normal mode", but a specialized term related to the "eigenmode expansion method". Johnjbarton (talk) 19:57, 5 September 2024 (UTC)

The edit history for the eigenmode redirect shows that it used to point to Normal mode, but the latest (Oct 2022) edit by Constant314 (talk · contribs) states "Eigenmode is much more general that normal mode. When modes are mapped onto a vector space, a mode becomes a vector. Hence, eigenmode and eigenvector are nearly the same thing", and was changed to point to Eigenvalues and eigenvectors.

I can't comment on whether or not the edit comment is correct, but that was the rationale/statement.  — sbb (talk) 23:22, 5 September 2024 (UTC)

Just some random , unauthoritative thoughts.

• An eigenmode is a mode (whatever that is) that can be mapped onto an eigenvector. More specifically, the numbers that describe the mode can be the components of an eigenvector. Doing that allows the machinery of linear transformations to be used to analyze the mode. Casually speaking, we may say that an eigenmode is a type of eigenvector. Of course, speaking more formally, we mean that the numbers that describe the eigenmode are treated as components of eigenvectors. Again, speaking casually, we say that an eigenmode is an eigenvector, but we do not say that (all) eigenvectors are eigenmodes.

• An electromagnetic field mode is any configuration of the electromagnetic field that satisfies Maxwell’s equations, the constitutive equations, and the boundary values. Solution and mode are used interchangeably. I have not heard the term eigen-solution.

• Mode is not restricted to mean an electromagnetic field mode.

• The voltages and currents of multi-conductor transmission lines are analyzed by the use of eigenmodes.

• It is not an eigenvector unless it is associated with a linear transformation which has an input vector and an output vector.

• The Eigenmode expansion article seems underdeveloped and focused on waveguides. There are no in-line citations in the body of the article. Of the three citations, two are used to establish the name and the other establishes that the method is useful. The external link leads to a not found page. The term eigenmode has been in use since the 1950’s and predats any of the references. I hesitate to redirect anything to this article.

• The Eigenvalues and eigenvectors article is more fully developed. It does not contain the word “eigenmode”, but it does contain “vibrational modes” and maps them to eigenvectors. I have no problem with redirecting eigenmode to Eigenvalues and eigenvectors. Eigenmode is a much broader subject than is covered by the Eigenmode expansion article.

Constant314 (talk) 17:00, 6 September 2024 (UTC)

As far as I know, the level of development of an article is not a criteria for redirects nor are unauthoritative thoughts. My unauthoratative take is that 'eigenmode' is used in different ways in different subfields and mostly as an informal synonym for 'mode' because that does not sound fancy enough.

I have provided a reference that identifies "eigenmode" as a type of "mode". This particular type of mode is discussed in sources listed in eigenmode expansion. So far these are the only source we have that discusses "eigenmode" directly. (Many sources use 'eigenmode' in the sense of 'eigenmode expansion'.) Asserting that 'eigenmode' is a much broader subject and predates the 1950s doesn't really help us here. We can't verify you ;-).

Even with a source that shows 'eigenmode' is an 'eigenvector' representation of a mode, I still do not agree that this redirect to eigenvalues and eigenvectors makes sense. A specialized, modified noun should redirect to the noun, not the adjective. Moreover, all the sources indicate that 'eigenmode' is associated with physics and engineering, not mathematics as topic.

A reasonable alternative to eigenmode expansion could be a redirect to normal mode. Johnjbarton (talk) 17:32, 6 September 2024 (UTC)

I don't think normal mode is a candidate. It is clearly talking about resonances at a fixed frequency. The eigenmodes of a waveguide have a continuous frequency spectrum. Further, it describes a mode as a standing wave. The eigenmodes of waveguides are traveling waves. Constant314 (talk) 21:37, 6 September 2024 (UTC)

Yes, I agree. I think normal mode should be renamed "Mechanical mode" or similar. What if we merge transverse mode and longitudinal mode into eg "Waveguide modes" and add a short section on "eigenmodes"? Johnjbarton (talk) 23:14, 6 September 2024 (UTC)

Of course! We also have Mode (electromagnetism). Bah. Johnjbarton (talk) 23:32, 6 September 2024 (UTC)

I share your frustration. Wikipedia has never been accused of being overly organized. I did not take part in the seminal conversations that established Wikipedia culture, but it seems to have settled to this: verifiability takes priority over completeness which takes priority over avoiding redundancy. You are welcome to reorganize, but don't lose anything. Sound also has longitudinal modes, transverse modes (in solids), and waveguides. You cannot just absorb those into Mode (electromagnetism) or Waveguide modes. However, both of those could use an expanded section on transverse and longitudinal modes. Constant314 (talk) 03:22, 7 September 2024 (UTC)

Redundancy is totally fine in my opinion (and by Wikipedia convention), as long as (1) each subject is encyclopedic ("notable"), (2) the scope of each article is reasonably clear and not entirely overlapping, and the article is reasonably complete and balanced within that scope without putting undue weight on minor aspects of the topic or fringe viewpoints, (3) each article is moderately self-contained and accessible, not dependent on text in other articles, (4) related articles are each correct, don't contradict each-other, reflect the consensus of reliable sources, (5) related articles link to each-other so that readers can find the information they are looking for, and maybe some others I'm not thinking of. With that said though, also feel free to reorganize material by moving it from one article to another, merging articles together, splitting them apart, etc. if a different high-level inter-article organization seems clearer. –jacobolus (t) 04:07, 7 September 2024 (UTC)

I updated Mode (electromagnetism) and included a sentence about eigenmode with the two refs I found. Johnjbarton (talk) 00:51, 8 September 2024 (UTC)

I just made an enquiry at the Teahouse about subpages. Seems that it is not allowed. I was referred to Wikipedia:Splitting. Noit sure if that helps. It looks like your main interest is the eigenmode redirect. Perhaps he should create an eigenmode stub which could point the reader to all the appropriate targets along with some commentary. Does that sound like a good idea? Or, even simple, create an eigenmode dab page. I may go ahead and do that.Constant314 (talk) 18:32, 8 September 2024 (UTC)

I essentially used the page Mode (electromagnetism) for the disambiguation purpose. I think that should be the target for the redirect unless we find a lot more sources and content. We could add an anchor to the paragraph. Johnjbarton (talk) 18:55, 8 September 2024 (UTC)

I am good with that. Eigenmodes is probably a little more general than that, but Mode (electromagnetism) is a probably a good redirect target. You have my support to make the change. I presume that include both eigenmode and eigenmodes. Constant314 (talk) 19:18, 8 September 2024 (UTC)

Thanks,  Done Johnjbarton (talk) 19:39, 8 September 2024 (UTC)

 Courtesy link: Wikipedia:Teahouse § Adding a subpage to an existing article—  jlwoodwa (talk) 20:46, 8 September 2024 (UTC)

Help needed on several elementary articles

Farkle Griffen made many edits on several elementary articles including Variable (mathematics), Mathematical object, Indeterminate (variable) and several others. Generally, these article are of low quality, but IMO, most of their edits are disimprovements, as consisting generally of misinterpretations of randomly chosen sources. One of their typical edit is to change the first sentence of Variable (mathematics) from "In mathematics, a variable is a symbol, typically a letter that is used for naming a mathematical object, often a number" to "In mathematics, a variable is a symbol, typically a letter, that holds a place for constants, often numbers".

I must stop to revert them, because WP:3RR, and because of the lack of third party input, I cannot open an ANI thread for disruptive editing (this appears as content dispure).

So, I need some help. D.Lazard (talk) 18:36, 5 September 2024 (UTC)

Mathematical object seems broadly improved. Variable and indeterminate seem tricky to me. There's at least one way these are different, in that variables usually have a domain, while indeterminates are purely formal symbols. (E.g., random variable, real variable, etc.) But many people in casual discourse make no such distinction. Tito Omburo (talk) 18:53, 5 September 2024 (UTC)

Derivative article, again

Sorry, but can someone explain what does the IP say about the numerous references? The IP is known as the former professor, said by itself. Dedhert.Jr (talk) 00:45, 8 September 2024 (UTC)

Just looks like a rant to me, not a real edit request -- there is no concrete proposal to change any particular text to any other particular text that I can see. --JBL (talk) 00:57, 8 September 2024 (UTC)

They do have a point that the Gonnick source is wildly inappropriate. Tito Omburo (talk) 01:30, 8 September 2024 (UTC)

What's inappropriate about it? (Maybe, this discussion should be happening over there.) --JBL (talk) 17:48, 8 September 2024 (UTC)

Wikipedia articles should be based on scholarly sources, not comic books. Tito Omburo (talk) 19:40, 8 September 2024 (UTC)

It's a scholarly source in the format of a comic book. Gonick's three volumes on algebra, geometry, and calculus are each serious about what they cover and don't shy away from hard material; any one of them could be a course textbook. Sure, it makes sense to have multiple citations when a point has been addressed at multiple levels, but I don't see the point of removing citations just because the books they point to are less turgid than average. XOR'easter (talk) 20:58, 8 September 2024 (UTC)

We should probably round out our comic-book references by also citing Prof. E. McSquared's Calculus Primer: Expanded Intergalactic Version. –jacobolus (t) 21:04, 8 September 2024 (UTC)

Tangentially, that seems like a book it might be possible to write an article about, though the reviews I've found so far have been on the short side. XOR'easter (talk) 21:22, 8 September 2024 (UTC)

I'm quite happy with people making the topic entertaining if they're reasonably accurate. But some people think maths has to be po-faced and turgid so I guess another source should be provided as well to cater for them or this complaint will come up again. NadVolum (talk) 20:34, 8 September 2024 (UTC)

This footnote in Kelley comes to mind as an example of humor in a textbook. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:34, 9 September 2024 (UTC)

The sidenotes in Concrete Mathematics are a hoot. note: "What is a proof? 'One half of one percent pure alcohol.'" // "The ∑ sign occurs more than 1000 times in this book, so we should be sure that we know exactly what it means." note: "That's nothing. You should see how many times ∑ appears in The Illiad." // "... now [mathematicians] also have both floor and ceiling [notations]." note: "Next week we're getting walls." // "And the intervals [α..β) and (α..β], which contain just one endpoint, are defined similarly and called half-open." note: "(Or, by pessimists, half-closed.)" // etc. –jacobolus (t) 05:17, 10 September 2024 (UTC)

Not a textbook, but there's also the famous quip about Gauss

References

Unicode mathematical letters block

Hi. Unicode has a Mathematical Alphanumeric Symbols block. For purposes of editing Wiktionary, I'm wondering which of these have set meanings that require their own entries, and which are simply letter variants. For example, using bold letters for vectors is a generic convention, but bold "𝐚" is just a variable without any set meaning, and it can therefore be made a redirect either to 'a' or to a page defining bold variables as vectors. However, ℋ is specifically the Hamiltonian and ℍ (and maybe 𝐇?) are the quaternions, so those should be defined individually.

The Unicode block is too large for me to expect a detailed answer here, but do you know of a reference that might guide me?

I understand that some of the mathematical symbols in Unicode are spurious, or are ad hoc conventions from some source that aren't followed by the mathematical community in general, but it would be nice to define the ones where there is some consensus. (And if there are conflicting consensuses, that's fine, we can always have multiple definitions.)

Again, this is for Wiktionary, but I thought here would be the place to ask. — kwami (talk) 06:54, 12 September 2024 (UTC)

You should definitely not use the unicode ℍ. Use <math>\mathbb{H}</math> instead, giving $\mathbb {H}$. See MOS:BBB. I suspect the same guidance should apply to many of the special unicode mathematics characters. For instance, if it's going to appear in a mathematical equation, the Hamiltonian symbol should probably be <math>\mathcal{H}</math>, ${\mathcal {H}}$, which looks nothing like the unicode to me, so if you mixed the two readers would likely be very confused. —David Eppstein (talk) 07:53, 12 September 2024 (UTC)

For WP, sure, but this is for the purpose of defining the Unicode character.

If the Unicode character doesn't match the <math> display that's supposed to be the same thing, that's presumably an issue with the fonts you have installed: the font called by your browser for a specific Unicode character is different from the font/style called by <math> function. Ideally they should look the same, but there's generally going to be some discrepancy between what we would like the text to look like and what the reader will actually see, unless we post PDF's. Regardless, the underlying data structure will have a use that we would like to define, and AFAIK we can't use <math> to generate entries for Wiktionary. — kwami (talk) 08:19, 12 September 2024 (UTC)

@Kwamikagami Are you sure this is a valuable project? In actual practice, professional mathematicians never use Unicode for mathematical symbols. They almost universally use a variant of Tex/Latex when formatting symbols and equations, corresponding to the <math> tags in wikipedia. PatrickR2 (talk) 19:25, 14 September 2024 (UTC)

Unicode is widely used in mathematical programming, e.g., Lean. And also in domains like industrial mathematics. Tito Omburo (talk) 19:34, 14 September 2024 (UTC)

It seems that in some cases \mathscr is used to display the Hamiltonian symbol. SilverMatsu (talk) 05:47, 15 September 2024 (UTC)

From that thread, if there's a demonstrable contrast between script and calligraphic letters, let me know and we can see about getting them into Unicode. But that may be resolved now - as described at Mathematical Alphanumeric Symbols, there are roundhand and chancery variants of the script letters, which might cover what that thread was calling script vs calligraphic variants. — kwami (talk) 06:34, 15 September 2024 (UTC)

mathscr does not work in the lobotomized version of LaTeX provided by Wikimedia. —David Eppstein (talk) 07:06, 15 September 2024 (UTC)

Category:Pyramids (geometry)

Sorry, but are icosahedral pyramids and gyroelongated square pyramid considered to be part of Category:Pyramids (geometry)? The pyramids are supposed to be a polyhedron in which triangular faces meet their common apex and connect the polygonal base in three dimensions. How are these both supposed to get along with the category, just because they are relatedly constructed by pyramids? I hope someone can explain me before the next edit warring happens again. Dedhert.Jr (talk) 13:01, 12 September 2024 (UTC)

Balinese numerals

The page for Balinese numerals lacks and graphical representation of the numerals so if someone could find some it would be appreciated. Legendarycool (talk) 23:17, 14 September 2024 (UTC)

(Mac Lane's) coherence theorem vs. Coherence condition

What is the difference between these two articles? Also, the contents of the Coherence theorem were merged into the Coherence condition, and then redirected to Coherency (homotopy theory). SilverMatsu (talk) 05:59, 15 September 2024 (UTC)

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)

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

So it seems the appropriate time to mention it here. Salix alba (talk): 07:51, 18 September 2024 (UTC)

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)

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)

The lemniscate constant is denoted by a varpi, fwiw. Tito Omburo (talk) 09:40, 18 September 2024 (UTC)

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.

It might be worth trying to encode the rest of the Torture Test, which lacks corresponding LaTeX so we get a true comparision. --Salix alba (talk): 15:49, 18 September 2024 (UTC)

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.

Anyone is welcome to type more tests there. Tercer (talk) 20:15, 18 September 2024 (UTC)

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)

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)

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 ${\sqrt {5}}$ 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 $\pi /2$ has unusually wide spacing around the division sign. Under "Realizability", there is too much space between the two symbols in $\mathbb {R} ^{3}$. More problems with sqrt5: the bottom of the sqrt sign sits above the baseline when it should be below. In $-{\tfrac {1}{3}}$, 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.

When I view math using SVG I don't see these problems. —David Eppstein (talk) 21:02, 18 September 2024 (UTC)

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)

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)

@TakuyaMurata: Disclaimer: I started as volunteer. Now, I am working at FIZ Karlsruhe which operates zbMATH Open. This brings me in regular contact with International Mathematics Union and local representatives of the mathematical community.

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

• MathML is now supported by all major browsers
• 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)

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)

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)

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

old:${\sqrt {5}}$ vs new: $\sqrt{5}$

Thus this is a very good (minimal) example to define wrong. At least on my screen I don't see "narrower thickness" or "visible gaps." Physikerwelt (talk) 17:39, 19 September 2024 (UTC)

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)

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.

As an aside Help:Formula renders quickly with client-side MathJax but there are several Math Input Errors and Math Output Errors. Probably worth a bug report. --Salix alba (talk): 18:21, 19 September 2024 (UTC)

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)

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)

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)

Updated MathML torture test

The torture test page linked above is several decades old and includes errors in the translation to MathML. The modern update that I got from igalia looks much better. Dicklyon (talk) 22:28, 19 September 2024 (UTC)

And if someone wants to collect a page of examples that don't render satisfactorally, I bet they'd be happy to see it. Dicklyon (talk) 22:29, 19 September 2024 (UTC)

wow, that's shockingly bad. Developers are really going to push this? Tito Omburo (talk) 22:36, 19 September 2024 (UTC)

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)

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)

—David Eppstein (talk) 23:09, 19 September 2024 (UTC)