Wikipedia talk:WikiProject Mathematics/Archive/2017/Jun

MathJax?

This has probably come up before: why don't we have MathJax on Wikipedia? Jakob.scholbach (talk) 01:12, 4 June 2017 (UTC)

We used to, but the developers ripped it out, partly because their implementation was big and crufty for reasons I don't understand (when I use it in my own web pages it is very very simple) and partly because they want to promote failed-web-standard MathML instead. —David Eppstein (talk) 02:37, 4 June 2017 (UTC)

In places like stackexchange and other web pages where MathJax is used, it seems to do work very well at doing things that are done badly in Wikipedia articles. For example, in expressions like $e^{x^{2}+2}\,$ the e should be at the same elevation as the letters in the surrounding sentence and the superscript should be above that, but that's not what happens here. In in things like $A+B+C\,$ the letters A, B, C appear more than twice as large as the corresponding letters in this sentence.

So MathJax would be a good thing if the developers can get it working. Michael Hardy (talk) 15:06, 4 June 2017 (UTC)

I agree wholeheartedly! For example, I was reading cubic function recently. A well-done article, but the (necessary) usage of different markups makes it just painful to read.

Are there any drawbacks (other than implementation-related details) of MathJax on Wikipedia? If not, I suggest we should just lobby more strongly? After all, as Michael points out, the latex markup looks ugly and disconnected to the text. The {{math|...}} template looks a bit better, but is painful to type. Moreover, like the usual ''...'' markup, it only works for basic formulas. Jakob.scholbach (talk) 18:15, 4 June 2017 (UTC)

{{math}} also doesn't work well on mobile. —David Eppstein (talk) 18:17, 4 June 2017 (UTC)

@Michael Hardy: "appear more than twice as large as the corresponding letters in this sentence." That's weird btw.. The dimensions and positioning with these SVG images is based on the height of your surrounding font (using ex units, similarly to em units). The difference should not be that big (They are the same units as the SVG mode of mathjax uses). Unless the font your browser is using has a broken font specification or broken SVG renderer or something... —TheDJ (talk • contribs) 13:10, 7 June 2017 (UTC)

@TheDJ: I've seen this on a considerable variety of computers, in a number of different public libraries, in a number of different university libraries on different campuses, in faculty offices on university campuses, on the Lenovo Thinkpad on which I'm typing this now, on a desktop computer in my home, and others. Michael Hardy (talk) 18:00, 7 June 2017 (UTC)

Another issue with the {{math|...}} template is that it may not work on other language wikipedias, which is really a bit of a pain if you work across several wikipedias. Actually I rather much have universal syntax for formulas (the <math> tag + Latex) throughout all Wikipedias and within all articles than a perfectly optimized display that comes at the cost of additional syntax and a lack of interoperability.--Kmhkmh (talk) 23:06, 4 June 2017 (UTC)

OK, another drawback of {{math|...}}. David Eppstein, you participated in this discussion, where some developers seem to maintain that introducing MathJax would have some drawbacks. Can you or anyone else explain these? I am not very much into these different paradigms of math rendering. What are the "political" reasons for not adopting MathJax? Jakob.scholbach (talk) 09:06, 5 June 2017 (UTC)

There used to be a version maintained by Nageh, here, but he has retired and no longer supports it. There is much less need for it now, with the MathML support in particular doing the same job much more efficiently (MathJax had painfully long page loading times). I don’t recall it fixing alignment problems either which probably have more to do with the style sheets and markup WP uses for text paragraphs. StackExchange and other technical web sites can probably afford to have a more formula-centric design.--JohnBlackburne^words_deeds 09:32, 5 June 2017 (UTC)

I am not sure I understand your comment "there is much less need for it now". We keep having the same crappy-looking (in relation to the surrounding text) <math>...</math> formulas for years. Can you clarify how MathML helps in this regard?

My personal point of view is this: judging from its wide-spread adoption on other sites, from its overall superior aesthetic performance, and judging from its apparent simplicity of implementation, I don't see why WP does not use MathJax as a default.

Here is a table that aims to help objectivize the discussion. Please feel free to correct any judgement I have made so far, also feel free to refine or add to the criteria that came to my mind. Just edit right in the table if there is no likely controversy. Likewise, if there are other options that I am not aware of, just add a column. Jakob.scholbach (talk) 11:17, 5 June 2017 (UTC)

	"Naive markup"	{{math|...}} markup	<math>...</math>	MathJax
Example	a2 is the square of a.	a2 is the square of a.	$a^{2}$ is the square of $a$.	[please add screenshot]
brief explanation of how the technique works	[please add]	[please add]	[please add]	[please add]
Appearance of font (size, position) in relation to surrounding text	very good	very good	poor	OK (judging from other sites
can be typed easily for simple formulas such as a^2	18 bytes: a2	27 bytes: a2	17 bytes: $a^{2}$	17 bytes: $a^{2}$
can be typed easily for medium formulas such as the fundamental theorem of calculus	87 bytes: ∫ba f(x) = F(b) − F(a)	98 bytes: ∫ba f(x) = F(b) − F(a)	45 bytes: $\int _{a}^{b}f(x)\,dx=F(b)-F(a)$	45 bytes
can be typed easily for advanced formulas	no	no	yes	yes
can be served quickly (download times etc.)	yes	yes	[please add]	[please add]
can be customized relative to WP skins	yes	[please add]	[please add]	[please add]

Two reasons MathJax not being the default that at least were in effect a year ago:

• WP MathJax is (was?) just incredibly slow.
• WP MathJax is (was?) full of bugs.

This is not saying we shouldn't move to MathJax in the future. But changing from something bad to something equally bad is just pointless. YohanN7 (talk) 11:46, 5 June 2017 (UTC)

The table above omits the "dx" in a couple of places but includes it in another whose number of bytes is contrasted with the numbers of bytes in the examples that omit it. Michael Hardy (talk) 00:20, 6 June 2017 (UTC)

In some sense, we do have mathjax, just on the server side rather than the client side. When the engine was overhauled the backend was changed to use a latex to mathml/svg rendered which written with input from the MathJax people. I believe the whole reason MathJax has an svg mode might have a lot to do with Wikipedias needs.

The technical problems for client side mathjax for wikipedia is the range of devices being targeted. It needs to work well on old hardware in developing countries and increasingly phones and tablets. Asking such devices to do a lot of javascript rendering is not ideal.

It is possible to have client side mathjax. I think including User:Salix alba/MathJax.js in your vector.js will do it.

mw.loader.load( '/w/index.php?title=User:Salix_alba/MathJax.js&action=raw&ctype=text/javascript' );

ght

You also need to set the rendering mode in your preferences to "LaTeX source (for text browsers)". I've not tested it lately, I think it works with the latest MathJax. It would not be possible to give such a script a wide rollout as it would put too great a load on the CDN server.

The is also a chrome extension Wikipedia with MathJax which esentially acheives the same as the above script.

Personally I'm relatively pleased with the current scheme. Rendering problems are much reduced from the old PNG days. I'm sure there was a bug related to baselines, possibly T34694, its still not quite right. --Salix alba (talk): 17:07, 5 June 2017 (UTC)

re I am not sure I understand your comment "there is much less need for it now" , before MathJax the only rendering was PNG graphics, which were and still are crude, and were more expensive to load as every one has to be fetched individually. Now though we have Math ML/SVG, which produces much higher quality output, more suited for high resolution screens and printing. Math ML also uses less bandwidth, though this is less of a concern as bandwidth costs have come down exponentially. So there are no big quality benefits to be had from MathJax now: the quality of what we have is at least as good.--JohnBlackburne^words_deeds 09:59, 6 June 2017 (UTC)

Actually I disagree somewhat here, in practice in certain scenarios the Math ML/SVG is much slower than the old png solution. That is when a client calls a page for first Math ML/SVG is still horribly slow, in fact if a page is formula heavy it doesn't render completely if you don't hit reload. Now for the subsequent calls to the same page the rendering is fast, until the cache gets purged presumably. If you return to the same page after a longer time the first rendering is horribly slow/incomplete again.--Kmhkmh (talk) 12:47, 6 June 2017 (UTC)

I’ve not noticed that, or tried comparing it to PNG rendering. Maybe I’m just used to pages taking a long time to regenerate, usually due to scripts and/or length. The problem with MathJax though was that it was slow every time the page loaded, because of the way it worked, rendering the mathematics after the rest of the page was loaded, using Javascript. Pages could take several seconds to render the mathematics every time the page was viewed. This was dependent on the viewer’s browser, so might be faster now, at least on desktop – though more and more viewing is done on mobile where performance is much slower.--JohnBlackburne^words_deeds 13:30, 6 June 2017 (UTC)

Well I'm not arguing for MathJax. In fact personally I don't care really much for the underlying technology (as long as it does the job done) and I'm not really familiar with their details anyhow. I just wanted to point out that from user's perspective as editor/reader the current Math ML/SVG solution still has significant issues in practice as far as it's speed is concerned.--Kmhkmh (talk) 13:56, 6 June 2017 (UTC)

It might be worth doing a bug report for the speed issue. With images, there are ways of packaging up all the images in a single download. There might well be a way to speed up the download of svg's using modern html features.--Salix alba (talk): 21:58, 6 June 2017 (UTC)

@JohnBlackburne: here we go again with the advocacy of MathML (a failure for web display, as it is only supported by a tiny minority of browsers) over anything that actually works in the real world. Your argument that it uses less bandwidth is both pointless (who cares how much bandwidth it uses when it doesn't work) and false (once the one-time cost for loading the libraries and fonts has been paid, MathJax is more concise). SVG, your preferred fallback to MathML, is better than the old bitmaps, but still has big issues with font sizing, baseline alignment, fuzzier rendering (antialiasing vs subpixel-resolution text display in browsers), etc. It is simply false that what we have now renders as well as MathJax. —David Eppstein (talk) 22:33, 6 June 2017 (UTC)

It is a bit fuzzy now, but as I recall MathJax had all those problems, or at least many similar ones. Some of them would be as it was different from PNG rendering, and as PNG rendering was the standard and what most editors had used when assembling articles, so they looked bad in MathJax, but it had its own bugs and problems. I tried enabling it a couple of times but removed it as worse than PNG rendering. I have no such problems with the MathML/SVG option and have had that on by default for as long as I can remember.

On the particular issue of baseline alignment, I imagine this is deliberate, for consistency with the PNG renderer. If formulae are too complex to inline well then probably no automatic solution can work, and the content might be better rewritten so the formulae are in their own paragraph(s). If it really needs fixing it should be fixed for all forms of math rendering, for consistency.--JohnBlackburne^words_deeds 11:56, 7 June 2017 (UTC)

I can only hope this font-sizing and alignment is not deliberately wrong. More importantly, MathJax does manage to align & size the formulas just fine in relation to surrounding text. (Look at any example, including the one linked in the above table.) This is one of the reasons I personally would prefer MathJax. Jakob.scholbach (talk) 13:38, 7 June 2017 (UTC)

The one link is to a secure, as in password protected site. But we cannot go by what other sites are like. Other sites, especially mathematically focussed ones, might make different decisions about how to combine text and formulae, with different configurations for their equivalent of the math extension and different CSS and javascript to specify how it appears in the page. If you think it is wrong here then you could submit a bug report, but I cannot believe this has not been looked at before; the way it works now must be by design.--JohnBlackburne^words_deeds 14:10, 7 June 2017 (UTC)

Just as a point of order.. Even though the name of the option includes MathML, unlike earlier envisioned, it does not actually use MathML anywhere to render math. It only uses SVG (generated serverside by MathJax) or PNG. Additionally, there is a non-visible MathML snippet for machine readability and accessibility purposes. The SVG is sized relatively to the surrounding font. —TheDJ (talk • contribs) 13:16, 7 June 2017 (UTC)

TheDJ: Is it correct that simply changing (or optionally changing) the way MathJax formats the output (i.e., replacing svg output by html+javascript output) on the backend of WP would in effect amount to introducing MathJax? (I.e., how much work is it for WP developers to change to (or offer an option to change to) the "usual" MathJax output seen on many other websites?) Jakob.scholbach (talk) 13:42, 7 June 2017 (UTC)

No, MathJax as you all talk about it, requires client side javascript (also for the HTML/CSS mode). It wouldn't be as easy as just generating another format. —TheDJ (talk • contribs) 14:34, 7 June 2017 (UTC)

@YohanN7: you mentioned that MathJax is full of bugs. Can you specifically name or explain some of these? Jakob.scholbach (talk) 13:38, 7 June 2017 (UTC)

I said WP MathJax was full of bugs some time ago, because you asked for reasons it isn't presently default. I don't know of the current status. One example I remember was nesting commands like \overline. I'd also consider extremely slow performance being a bug. Face it, on a machine able to numerically solving for ten simultaneously colliding black holes in a split second (maybe exaggerating a bit here, just making a point), rendering a little screen output should take no measurable time at all. CPU and network speed is nowadays measured, not by astronomical numbers, but by economical numbers. These are big numbers indeed Again, I don't know the present status, but from what I read here, performance issues are still there. If they are, they are of more serious nature than anything else like isolated bugs referring to a specific feature, since they indicate that the implementation may be rotten throughout, and beyond repair. Handing a large chunk of code to someone, saying "make this fast" isn't an easy assignment. I am not taking sides here, since I don't know the current status of WP MathJax. YohanN7 (talk) 14:15, 7 June 2017 (UTC)

I also remember reporting errors (to presumably the correct place), the \overline bug and another one I don't recall the details of. But nothing happened in a long time, and that is also problematic. YohanN7 (talk) 14:21, 7 June 2017 (UTC)

1. The biggest problem is that it causes reflows (size changes of content) and repaints (re-rendering of the page) in the entire page. This is VERY slow, killing on performance. If you have intensive pages, like on Wikipedia, reflows are the worst thing you can have. In pages the size of Barack Obama, one mathjax formula 'enhancement' can be disruptive.
2. The second problem is the huge payload sizes of mathjax, which are problematic for mobile and low speed connections. As well as just being complex and taking a lot of CPU to execute the MathJax rendering (not everyone has high performance computers).
3. Additionally, is the problem that we already run a LOT of scripts on Wikipedia. And these all have to compete with eachother about when then can go and start to do their job. Much of that is invisible (other than superscripts). but again, mathjax causes reflows, so this would lead to content jumping around at unpredictable times after the page has loaded.

That's 3 problems, each and everyone of them a reason for developers to not like MathJax. And it's also not something that can easily be fixed, because it's what 'makes it work' in that mode. —TheDJ (talk • contribs) 14:34, 7 June 2017 (UTC)

I don't think we should care what the developers like or don't like. What we deploy should be what is best for our readers and editors, not our developers. Otherwise we'd be stuck writing plain unformatted ascii text. —David Eppstein (talk) 18:10, 7 June 2017 (UTC)

All of those though affect users. In fact my 'slow loading' comment above is much better described in TheDJ’s first point. It was not that page was slow to load. It loaded, then MathJax spent several seconds doing its thing, reflowing the page again and again as it did, causing it to redraw and so making it impossible to read. This is unlike e.g. any delay as images are loaded because the pages knows how much space they will occupy, so can generate the page with spaces for images to load into. And this was on a modern desktop PC. It would be an order of magnitude worse on many mobile devices.--JohnBlackburne^words_deeds 18:31, 7 June 2017 (UTC)

Screenshots of above table comparing the two rendering modes the default SVG and client-side svg using my javascript

Server side (SVG) rendering

Client side MathJax rendering

The biggest difference is the fuzzyness of the text in the SVG mode. Neither actually get the baseline quite right. The SVG does not seem to have used the inline formatting for the integral. Which can be forced with <math display="inline"> to give ${\textstyle \int _{a}^{b}f(x)\,dx=F(b)-F(a)}$.--Salix alba (talk): 20:11, 7 June 2017 (UTC)

WP:Citation overkill RfC

Opinions are needed on the following matter: Wikipedia talk:Citation overkill#Should this essay be changed to encourage more citations?. A WP:Permalink for it is here. Flyer22 Reborn (talk) 01:31, 9 June 2017 (UTC)

\iddots

Our system for mathematical notation of course has \ddots:

${\begin{pmatrix}a_{11}&\cdots &a_{1n}\\\vdots &\ddots &\vdots \\a_{m1}&\cdots &a_{mn}\end{pmatrix}}$

Does it have have any kind of rising diagonal dots? This is plainly needed in some fragments of Pascal's triangle:

${\begin{array}{cccccccccc}&&&&1\\&&&1&&1\\&&1&&2&&1\\&1&&3&&3&&1\\\vdots &&&&&&&&\ddots \end{array}}$

Clearly where the two sets of \vdots appear below and where the \vdots appear above, one should have rising diagonal dots.

${\begin{array}{cccccccccccccc}&&&&\vdots \\&&&1&&8&&28&&56&&70&&\cdots \\&&1&&9&&36&&84&&126&&\cdots \\&1&&10&&45&&120&&210&&\cdots \\\vdots \end{array}}$

Michael Hardy (talk) 01:21, 9 June 2017 (UTC)

And while we're at it, how would I draw a hexagon around the six entries that surround one entry? Michael Hardy (talk) 01:22, 9 June 2017 (UTC)

Not perfect, but unicode has 22F0 utdot, rising dots: ⋰ --Mark viking (talk) 03:35, 9 June 2017 (UTC)

Collatz conjecture or 3x + 1 problem

The article formerly titled Collatz conjecture was recently moved to the new title 3x + 1 problem, seemingly without any discussion. I am a little skeptical of this move; what do others think? --JBL (talk) 22:15, 7 June 2017 (UTC)

The problem has a lot of valid names, so it's hard to pick just one. 3x+1 at least has the advantage of being descriptive. But I don't feel very strongly either way. —David Eppstein (talk) 22:44, 7 June 2017 (UTC)

A recent bibliography of papers about the conjecture The 3x + 1 Problem: An Annotated Bibliography, II (2000-2009) seems to show both names being used fairly often. As long as redirects for the alternative names, like the Collatz problem, are in place, the 3x + 1 problem seems a reasonable title. --Mark viking (talk) 05:07, 8 June 2017 (UTC)

I personally would prefer "3n + 1 problem" to "3x + 1 problem"; x is usually used for real-valued variables, and this is a question of arithmetic. There also seem to be several instances of "3n + 1" or "3N + 1" in that bibliography. I think I like "Collatz" better than "3x + 1"; the x just kind of bugs me, even though obviously you can call a variable whatever you want.

In any case, procedurally, the move should probably be reverted pending discussion, if anyone cares enough to discuss it. I'm not fond of the x title but I probably don't care enough to make a big stink about it. --Trovatore (talk) 09:59, 8 June 2017 (UTC)

I prefer "Collatz conjecture" as this is the more common term for the conjecture, as evidenced by Google scholar, which shows about twice as many hits for this as for the combined total of "3x+1 conjecture" and "3n+1 conjecture". I agree with Trovatore that the "x" is a bit jarring, but this does seem to be standard in the literature and so for this reason would be preferable to using "n". Sławomir Biały (talk) 11:58, 8 June 2017 (UTC)

I agree 3x+1 seems to be the worst of all three principally valid options. Another things is, that unilaterally moving articles from one valid name to another is something that should be avoided. As such moves can have side effects (for instance potentially breaking internal and external links and/or the handling of large number of redirects), they should only be done after careful consideration and checking for feedback/consent first.--Kmhkmh (talk) 12:18, 8 June 2017 (UTC)

Let me ping Ylevental who did the move, in case he or she wants to weigh in. For what it's worth, I agree with the comments that "3n + 1" or "3x + 1" is more descriptive, that "Collatz conjecture" strikes me as the thing I've heard the most (but maybe this is just the Wikipedia effect?), and that "x" is jarring relative to "n". If it stays at "3x + 1" or "3n + 1", I hope that someone can do the thing that has been done to e (mathematical constant) so that the title appears correctly formatted, with the variable in italics. --JBL (talk) 15:28, 8 June 2017 (UTC)

I have moved the page back to Collatz conjecture. Using "3x + 1" is IMO wrong. GeoffreyT2000 (talk) 22:23, 8 June 2017 (UTC)

It's clearly a name that some people use for the conjecture; what could it mean to say that it's "wrong"? --JBL (talk) 22:47, 8 June 2017 (UTC)

If a name is used in authoritative/reputable external it is usually considered "right" from the WP (policy) perspective. So in that sense all 3 names are valid or "right". However that does not mean that all 3 are equally good choices as there are other things to consider, such as which name is more common or which name fits the problem better and more.--Kmhkmh (talk) 01:06, 9 June 2017 (UTC)

Ylevental here. User:Sławomir Biały made a good point when he mentioned Google scholar. But it seems that at least for me, the "3x + 1 problem" term has the most highly cited papers, by a wide margin. The "3n + 1 problem" term is hardly used, and Collatz conjecture does have more papers, but they are not as highly cited. Additionally, Jeffrey Lagarias, one of the top experts on the problem, calls it the 3x + 1 problem and wrote an entire book on it called The Ultimate Challenge: The 3x+1 Problem There is no corresponding book with the name Collatz in the title. Ylevental (talk) 01:46, 9 June 2017 (UTC)

There is however The Dynamical System Generated by the 3n+1 Function (Springer 2006). Also doing a Google books search for "3x+1" problem collatz produces only 9 hits whereas "3n+1" problem collatz produces 84. "collatz conjecture" on its own yields 824 hits. Btw. I didn't consider "3n+1" problem or "3x+1" problem as those seem to produce an extremely large number of false hits.--Kmhkmh (talk) 02:32, 9 June 2017 (UTC)

That's true, but the more well-known books use 3x + 1 in the title. I see your point, however. I now am fine with either 3x + 1 problem or Collatz conjecture as the title. Ylevental (talk) 10:21, 9 June 2017 (UTC)

I don't necessarily disagree, but "more well known" seems to be bit in the eye of the beholder. As I said before imho all 3 names are valid as such and you probably can make a case for each of them being "the best" option. I don't have strong preference towards any, but I really dislike the moving from one valid name to another without checking for consent first.--Kmhkmh (talk) 13:43, 9 June 2017 (UTC)

Requested move: Quasi-category → ∞-category

I have made a request for the move Quasi-category → ∞-category at Talk:Quasi-category. Participation to the discussion is very welcome. -- Taku (talk) 01:49, 10 June 2017 (UTC)

Master theorem

Ninjagecko and I have been disagreeing over whether Ninjagecko's recent edits to master theorem actually constitute improvements. Additional opinions would be helpful. Please participate in the discussion at Talk:Master theorem#Proposed changes June 11th, not here. —David Eppstein (talk) 06:19, 12 June 2017 (UTC)

List of solution strategies for differential equations

List of solution strategies for differential equations has been proposed for deletion, in case anyone cares to try to save it. —David Eppstein (talk) 03:23, 13 June 2017 (UTC)

I disagree with the rationale for deletion (WP:NOTMANUAL). But I don't feel strongly enough about the article to contest the prod. I think any standard undergraduate textbook on differential equations could easily serve as a general reference for a list article like this. Sławomir Biały (talk) 12:12, 15 June 2017 (UTC)

Non-mainstream terminology in several algebra-related articles

Could someone review/revert Pbierre's edits? They consist in self-promotion and inserting non-standard terminology and notation. Said editor has enganged in edit warring in the past (see his talk-page) and apparently edited as an IP editor. --Omnipaedista (talk) 23:01, 14 June 2017 (UTC)

The editorial work of this editor during this year consists in 8 (eight) edits, 2 of which are outside the scope of mathematics (EOE). The importance of these articles, as well as of these contributions is marginal to my scales. He reverted one single edit twice before retreating. I do not deny him citing his book, the quality (obviously on elementary level) of which I cannot judge. Summoning to review/revert this editor's edits is -to me- nuking possibly biting midges. A witch hunt? Purgy (talk) 06:16, 15 June 2017 (UTC)

An editor citing themselves is definitely not a problem as long as they cite work published via reputable outlets. Said editor keeps citing Pierre Bierre, Flexing the Power of Algorithmic Geometry; this a self-published work (published by Spatial Thoughtware; absolutely no further details about this publisher are known) and the single published work by a non-professional mathematician (a self-professed "smart product inventor"). These edits are in violation of WP:RS and WP:SYNTH. I just reverted his last four mathematics-related edits (1, 2, 3, 4). --Omnipaedista (talk) 16:53, 16 June 2017 (UTC)

counter broken - "31444"

The counter on the project page has been stuck at 31444 for a long time. Can someone explain how the counter works and suggest how we might get it started working again? Arided (talk) 12:37, 21 June 2017 (UTC)

Euler–Boole summation

Euler–Boole summation could use work if it's worth keeping.

Summation method redirects to Divergent series. But Euler–Boole summation says that that is a "summation method", but it seems to end up being about a series with only finitely many terms. Michael Hardy (talk) 05:51, 26 June 2017 (UTC)

Proposed deletion of Lueroth constant

Back in May, the community decided that our page on the "Alladi–Grinstead constant" ought to go. In the discussion there, I noted that if the decision was to delete, then Lueroth constant should go as well. I've now PRODed it accordingly. XOR'easter (talk) 01:01, 27 June 2017 (UTC)

Non-technical summary of Wiles' proof of FLT. Review requested.

The page has long lacked a summary that someone lacking group theory and beyond can grasp. Based on several descriptions of the proof, I've summarized it in a manner that would probably scandalize a pedant :) but should be roughly right and quite helpful to very many readers. As it's a huge proof, this is about the level of detail needed to make the basic approach accessible to those lacking advanced mathematics and to educate on it.

Due to its technical nature, I'd really appreciate eyeballs and review to check the technical accuracy, and see if there's areas it can be improved while remaining widely accessible.

Thank you.

Link: Wiles's proof of Fermat's Last Theorem#Non-technical summary of Wiles'_proof.

FT2 ^{(Talk | email)} 01:51, 27 June 2017 (UTC)

I'd quibble with the use of the word "Non-technical" in the section heading; a curious reader who just dropped in after watching an old NOVA special on YouTube or the like would still find it pretty heavy going. I think calling the section just "Summary of Wiles' proof" (or "Outline of Wiles' proof", etc.) would be fine. XOR'easter (talk) 02:58, 27 June 2017 (UTC)

Group orders of ${\mathbb {Z}}^{n}$

The section title above, Group orders of $\mathbb {Z} ^{n}$, appears in the article titled Lexicographic order. My experience has been that TeX in section headings fails to appear in the article's table of contents. But this on appeared. Is this a recent software improvement? Does it depend on how the user's preferences are set, or on which browser is used? Michael Hardy (talk) 21:13, 27 June 2017 (UTC)

. . . and now I see a part of the answer: This appears in the table of contents when I'm logged out, but not when I'm logged in. Michael Hardy (talk) 21:16, 27 June 2017 (UTC)

. . . also links to such a section do not work properly (for example, the link to this thread in my watchlist). In fact, this behaviour is very similar to what is described in MOS:HEAD for misplaced invisible comments. IMO, MOS:HEAD must be expanded for warning about this. D.Lazard (talk) 08:39, 28 June 2017 (UTC)