Talk:Main Page

Extending ProofWiki to "derivations" and visual explanations?
I'm proposing the extension of ProofWiki to "derivations" and visual explanations of mathematical concepts and expressions. Examples would include the convolution integral or e.g. the Hilbert transform.

An example explanation is how the convolution integral is presented here: https://en.wikipedia.org/wiki/Convolution#Visual_explanation

What do you think?


 * No reason why not. We already have plenty of visual enhancements of proofs. The only thing limiting us has been the ingenuity of the people putting such visuals in place.


 * If you have particular skills and interests in this area, then please feel free to contribute. Your work will be very welcome. --prime mover (talk) 07:47, 24 December 2015 (UTC)


 * I'm willing to contribute, but I don't understand how to edit the Wiki (if I even have the rights to set up those pages). --Mviljamaa (talk) 09:18, 24 December 2015 (UTC)


 * You should have sufficient rights to edit pages. You also have all sorts of Help and FAQ pages to read. Feel free to study these. You have links on your home Talk page, and you also have various links down the left hand side to explore. --prime mover (talk) 13:56, 24 December 2015 (UTC)

Joke namespace
Since it is of course of the utmost and pressing importance that we ensure that we have documented all the mathematical jokes in the world, we are going to need a namespace for them.

Can we therefore have a "Joke" namespace, the same way we have a "Mathematician" and "Book" namespace?

What does anyone else think? --prime mover (talk) 08:29, 3 January 2016 (UTC)


 * Meh. Use subpages until it becomes too unwieldy. It's better that they're all in one place, to be read in a single run. &mdash; Lord_Farin (talk) 22:02, 3 January 2016 (UTC)

Style problem
Something gone wrong with this page Category:Definitions/Fundamental Dimensions

Anyone able to sort it out? --prime mover (talk) 18:42, 23 January 2016 (UTC)


 * no worries, flushed my browser cache, all OK --prime mover (talk) 19:02, 23 January 2016 (UTC)

Problem with MathJax?
Is anyone else seeing this problem?


 * [[File:MathJaxProblem.png]]

All the $\LaTeX$ strings are appearing with a following vertical line.

I first noticed this yesterday on a different machine from my usual one (Windows 7 vintage), but now I notice it on this (my trusty old Vista). On both machines I am using Google Chrome.

I just tried it on Firefux and it's fine (I don't fancy getting IE out this morning to check that too) -- so it appears it may be a problem with Google Chrome. --prime mover (talk) 07:28, 30 January 2016 (UTC)


 * I can't reproduce it. &mdash; Lord_Farin (talk) 09:14, 30 January 2016 (UTC)


 * Very odd. As I say, it exhibits this problem on both of the machines I have access to: work and home, and on Google Chrome only. I can't get IE to connect to it (but then I can't get IE to connect to anything, I never use it). --prime mover (talk) 10:12, 30 January 2016 (UTC)


 * This has been happing to me for the past few months on the Canary version of Chrome. I assumed it was a bug that would be fixed. I guess it has made its way into the stable branch. --Joe (talk) 16:56, 30 January 2016 (UTC)
 * According to Stack Overflow this has been fixed in MathJax. --Joe (talk) 16:58, 30 January 2016 (UTC)
 * Updated MathJax, should be fixed now. --Joe (talk) 16:59, 30 January 2016 (UTC)


 * Yep, after a page refresh, this is now looking okay. Although I may stick with Firefox, the version I currently have (and have been using all day) seems to run more easily than Google Chrome ... the only thing I don't like about it is the tab management paradigm. --prime mover (talk) 20:28, 30 January 2016 (UTC)

Template:BookReference
Some recent pages brought the need to support more authors in the BookReference template. I've expanded it to 6, and also included a whitespaced sample of the (for display reasons necessarily) cluttered wiki code producing it. This should help in making such templates more maintenance friendly. &mdash; Lord_Farin (talk) 14:52, 21 March 2016 (UTC)
 * I think something might have gone wrong with it -- check out the Book:Books page. Also, Template:Book needs a similar expansion.  I'd work on it myself but I lack the patience tonight :-) --prime mover (talk) 20:49, 21 March 2016 (UTC)
 * Done. (And this time, I did check that it works on existing stuff ;).) &mdash; Lord_Farin (talk) 11:45, 25 March 2016 (UTC)
 * Nice one. Might not have been good in all browsers, though -- I found you have to use  instead of a space at the start of any string after a pipe delimiter that is being used as an "else", otherwise the space is not interpreted. --prime mover (talk) 12:30, 25 March 2016 (UTC)

Invitation for suggestions on improvements to presentation of oscillatory systems
There's a lot of new material that's been added in the Mechanics section, all of which is working towards a treatment of (so far as I've reached) resonance. The overall plan is that the general second order ODEs defining the underlying mathematics be established separately from the applications (whether they be moving carts attached to walls by springs or L-R-C circuits, or whatever) and hence to decouple the mathematics from the physics.

I'd welcome suggestions as to how to assemble the various categories, and also how to structure the pages and even to name the pages if they appear to be inadequate. Also, any definitions which appear loose or inaccurate (and there are plenty) I definitely want to improve.

I may well be changing direction after this, as I'm getting tired. --prime mover (talk) 13:01, 27 March 2016 (UTC)


 * Good work. Personally I find physical applications of ODEs boring, so I'll refrain from having an opinion on that front. As to the particular ODEs, I would probably go with the following scheme:
 * ODE LHS (basically TeX without backslashes and braces)
 * /Homogeneous
 * /Inhomogeneous
 * /Instance
 * Furthermore I think there is a need for clear overview pages of the calibre Trigonometric Identities (e.g. Linear Second-Order ODEs). As much as possible, these should have TeX'ed click-throughs. Naming convention close to TeX will help searchability.
 * If all becomes too much to maintain, we will eventually end up introducing the Example namespace we've kept out thus far. For now, however, subpages will be fine. (We might even consider sub-wikis or other cross-wiki collaborations, but this is at present unrealistic.) &mdash; Lord_Farin (talk) 18:00, 28 March 2016 (UTC)


 * Overview pages was something I started, but they got a little unwieldy and I reckoned it would be easier to go back to them, but I never did.


 * Another thought I had was to subcategorise the 2nd order ones further into the three categories: over-, critically and underdamped, and then resonant, but at the "pure" level rather than at the application level, but that came to me late as I got into the thread with the oscillating cart. And there is a lot in there which need to be pulled back into the abstract, but that also needs work which I'm not prepared to do at the moment, I'm going to need to let it rest a little before I can see it from a fresh angle.


 * All contributions welcome here. I've not seen an example before of such a structured categorised approach to arranging DE's into categories before, so as to exactly what it is we're trying to achieve, I confess I'm not sure where it's going. --prime mover (talk) 19:28, 28 March 2016 (UTC)


 * I think one reason why there is no good categorisation for ODEs is because unlike e.g. finite simple groups there is provable failure in classification: we cannot solve them all in "elementary" form. This also makes me less eager to attempt such a thing.
 * But then, admittedly I have been out of the theory of DEs and everything that goes with them for a long time, so maybe I'm not in a position to comment on this. &mdash; Lord_Farin (talk) 19:13, 30 March 2016 (UTC)

Template:explain spans too many lines. It makes bad reading experience.
Example to illustrate that template:explain is bad.

Two solutions:

1. Use template:clarify.

2. Remove redundant sentences in template:explain.

Golopot (talk) 03:28, 7 April 2016 (UTC)


 * I disagree. --prime mover (talk) 05:43, 7 April 2016 (UTC)


 * I like the template as it is, but that page is a an eye sore. What I'd prefer to see is the explain template used once there and either it lists all the problems in one section like a summary, or to have the explain not mention any specifics and have a smaller cleaner template like clarify to each specific. Whatever the case, those template shouldn't exist on the page, so this really is a nit pick. --Ybab321 (talk) 11:27, 7 April 2016 (UTC)


 * My take on this is that "explain" templates should not be there in the first place. They are supposed to make the page ugly, so as to inspire people who know what they are talking about to put in whatever fixes are necessary so as to allow that invocation of that template to be removed. --prime mover (talk) 12:19, 7 April 2016 (UTC)

First of all, thanks for the feedback. This helps to improve the site. (NB. Naturally you are encouraged to make changes yourself -- it's a wiki after all.) However I feel a third option didn't receive sufficient attention:

3. Resolve the calls to explain by improving the article.

That's what really ought to be done. I agree that the page is ugly and tough to read now, but the solution lies not with prettifying the maintenance template(s). That being said, I think Template:Explain could say everything in need of being said on three lines. I'll see what I can do about both. &mdash; Lord_Farin (talk) 14:33, 7 April 2016 (UTC)


 * Here goes: Fundamental Theorem of Algebra. &mdash; Lord_Farin (talk) 15:09, 7 April 2016 (UTC)

Problem loading WebFonts
After I have freshly booted up my (elderly Vista) machine (running Google Chrome), when I open certain pages I get a message in the bottom left corner of the screen saying: "Loading web-font TeX/Math/Italic" and the page just sits there, taking some time to finish. Then it puts the message up (same place): "Web-Fonts not available - using image fonts instead".

Take for example Area under Arc of Cycloid.

Examining the generated html, it looks, for example, something like this: 

Take as a contrast, for example, an element of a page Brachistochrone is Cycloid which does not show this error message: sin α

... which shows the Math-italic font being used as per normal.

The appearance of the mathematical text is different as well -- the one using images is heavier and slightly fuzzy.

Has anyone else noticed this, or does it look as though it is a problem with my machine? --prime mover (talk) 06:09, 13 April 2016 (UTC)


 * ... but now get this.


 * I have just made a no-change edit ("Edit" then "Save page") on the troublesome page Area under Arc of Cycloid in question, and now it is behaving correctly.


 * But now it has suddenly started doing it on Brachistochrone is Cycloid.


 * Ugh. And now Brachistochrone is Cycloid is working fine again. WTF? --prime mover (talk) 06:15, 13 April 2016 (UTC)

Prioritising stub and refactor-requiring pages
There are 993 pages that are marked as stubs, there are 853 pages that are marked as currently being refactored (refactor required or does this mean that someone is on the job?). This number is huge. Also Definition:Thermodynamics (for example) isn't marked as a stub, but looks like a stub. Surely there's more that can be said about thermodynamics!


 * Just a quick point: is intended to be more of a dictionary than an encyclopedia, hence its intention is to contain definitions rather than expositions (with the possible exception of the "Mathematician" namespace, where I confess to getting carried away sometimes). There is ample room for discursion on e.g. Wikipedia, with whom we are not and never will be in competition.  Our intention is to state the facts of a definition and that is all.


 * Hence although it "looks like a stub", to the extent that it fulfils its purpose: it defines what thermodynamics is. Such pages (those that define a branch of mathematics or other science) are not intended to be large. --prime mover (talk) 06:31, 22 April 2016 (UTC)

Anyway! I (the newest of the current newbies) would like to propose a grading system for stubs and a change to the refactoring system, and have a grade for each which denotes "low hanging fruit" to make it easier for newcomers to get started and learn. I'd rather (for example) have a proof for "equivalence relations partition a set" rejected on style grounds than pour time and effort into a longer, much more involved proof and have that declined.


 * Pages don't get "approved" or "declined" -- if their style does not come up to scratch they get a "tidy" template appended to them and then get brought up to style by one of the admins (er, yeah, that's me) who (irony alert) delights in such work.


 * So it should be no big deal. Paste up what you see fit; once it's in (if it's not a repeat of something already there, or is wildly incorrect) it stays -- and the only changes are those of, for example, stylistic improvement, correction of grammar/spelling or expansion of the argument, or rewording for clarity and/or linguistic consistency. --prime mover (talk) 06:42, 22 April 2016 (UTC)

Lastly (to keep this short) grades can convey urgency, for example Carathéodory's Theorem (Measure Theory) is extremely important in Measure Theory where as Book:Christopher Clapham/The Concise Oxford Dictionary of Mathematics, lets be honest, it isn't that urgent. Alec (talk) 19:51, 21 April 2016 (UTC)


 * Actually, I quite like that idea (particularly for stubs, anyway). I can see room for the Stub template to be expanded to take a new optional parameter "importance", or however the parameter may be named (let's be jocular and call it "defcon") to take a value of e.g. 1 to 5, where 1 is "goodness, this needs to be fixed urgently, it's embarrassing" and where 5 is "meh", and thence to automatically assign such pages into an appropriately-configured subcategory of the unwieldy and overflowing "stubs" category.


 * This is an area of development where "he who smelt it dealt it", so I'd be happy enough for you to take that on, if you so desire.


 * I am not so concerned about the "refactor" category, and (as I say to all new contributors) I would prefer to have this category left well alone except to old hands. --prime mover (talk) 06:38, 22 April 2016 (UTC)


 * These lakes of stubs/refactor pages/etc. are one of the biggest pain points this site has to deal with. Any ideas to break these categories into manageable chunks are most welcome.


 * One of the templates that might be (and at times, has been) used for this purpose is Template:Finish which signifies that while the mathematical content isn't too exciting, it's still some work to complete the page.


 * As to grading I'm not convinced yet it would work because of the inherent subjectivity involved. But there might be a case for something in between Template:Stub and Wanted proofs list.


 * Do you have concrete suggestions on how to introduce such sifting? &mdash; Lord_Farin (talk) 22:31, 21 April 2016 (UTC)


 * Just so as to get a handle on the quantity of work here, I have cleared 6 refactor flags over the last couple of days. It took all day to restructure the Definition:Polygonal Number refactor flag. The work is ongoing, and it gets picked up as and when the thread of what I am studying passes through one such.


 * As for the stubs, they are always available for someone coming into to see whether they want to try their hand. --prime mover (talk) 20:33, 27 April 2016 (UTC)

This old rubbish again
It has been once more pointed out that it is extremely bad form to name one's results after oneself. I understand that it displays an arrogance and egotism that have no place in the field of mathematics.

Once more there have been calls to take this result down again, on the grounds that it makes look bad.

While I completely take on board the philosophy behind this (there should be zero tolerance for self-aggrandisement in mathematics), for various reasons I am reluctant. So I will hold off purging it from the database if I get enough (? five or ten) well-argued posts to the contrary.


 * Just leave it there. It's not hurting anyone. &mdash; Lord_Farin (talk) 16:06, 26 April 2016 (UTC)

Original research
Can I add topics from my original research book? (note, that it is currently published only on the Web, not peer reviewed) --VictorPorton (talk) 07:25, 3 July 2016 (UTC)


 * Yeah sure. Bear in mind they will get editied a lot to fit them into house style. Be welcome. --prime mover (talk) 07:37, 3 July 2016 (UTC)


 * But what if my proof refers to a theorem present only in my book? --VictorPorton (talk) 08:02, 3 July 2016 (UTC)


 * Then you will need to add to that theorem which is present only in your book, at which point it becomes public domain under the CC-by-SA 3.0 licence and the GNU Free Documentation Licence. See Copyrights. --prime mover (talk) 09:09, 3 July 2016 (UTC)

can't do it any more
I'm staring at it and staring at it but I can't motivate myself to get any work done. It's all I can do to just post up links. Can someone take over because I'm tired. --prime mover (talk) 15:56, 6 July 2016 (UTC)
 * Hm, sad to hear that, although I've been in similar situations in the past. Just take some time off and give yourself a rest. You've earned it. &mdash; Lord_Farin (talk) 21:48, 7 July 2016 (UTC)

sorry i completely lost the plot
I went and changed all those results on $a^x$ from discussing them as exponentials to referring to them as powers. Now i realise this was all wrong. Sorry, i've broken everything. Someone is going to have to mend it. Not going to be me because I don't want to, it's too much like hard work. --prime mover (talk) 12:32, 7 July 2016 (UTC)


 * I felt a little too timid to mention. I'll fix up, once I've brought up my existing pages in the category to house style :) --Keith.U (talk) 14:25, 13 July 2016 (UTC)

New wave of spammers
In order to penetrate our spam blocker, prospective spammers need to send us a CV.

Here are a couple of recent CVs which have proven to be bogus:


 * Hey, I am Neal Wrangler , working with Synopsis LLC as a Senior Project Consultant

and:
 * Neal is Director, Software Architect, and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. Before joining ThoughtWorks, Neal was the Chief Technology Officer at The DSW Group, Ltd., a nationally recognized training and development firm.


 * Neal has a degree in Computer Science from Georgia State University specializing in languages and compilers and a minor in mathematics specializing in statistical analysis. He is also the designer and developer of applications, instructional materials, magazine articles, and video presentations. He is also the author of 6 books, including the most recent Presentation Patterns and Functional Thinking. Given his degree, Neal is a bit of a language geek, with affections including but not limited to Ruby, Clojure, Java, Groovy, JavaScript, Scala and C#/.NET. His primary consulting focus is the design and construction of large-scale enterprise applications. Neal is an internationally acclaimed speaker, having spoken at over 300 developer conferences worldwide, delivering more than 2000 presentations. If you have an insatiable curiosity about Neal, visit his web site at nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.

I'm also pretty suspect of this guy:
 * My name is Zachary Kniebel and I am a full-stack Web Application Developer and Software Developer, currently living in Philadelphia, PA. I have a Bachelor of Science in Computer Science from Northeastern University, and my primary focus and inspiration for my studies is Web Development. In my free time, I study human computer interface and the psychology of human computer interaction. I am both driven and self-motivated, and I am constantly experimenting with new technologies and techniques. I am very passionate about Web Development, and strive to better myself as a developer, and the development community as a whole.

... although as the latter hasn't contributed yet it is impossible to say with any certainty.

The thing in common with all these CVs is that they say nothing about the user's commitment to mathematics as such.

I did specifically reject one user's application to join recently (I was in a bad mood) as he presented a similar CV. We will never know whether I was correct in my assessment. --prime mover (talk) 07:30, 12 July 2016 (UTC)


 * Some people take any text box on the internet as a potential job application form, apparently. I say, no mercy. &mdash; Lord_Farin (talk) 15:44, 12 July 2016 (UTC)


 * Can someone take a second opinion on a bunch of 3 job applications currently sitting in our intray? Dismiss them out of hand, accept them with a view that they may be potential spammers, or reject with a polite email saying "Get lost, spammer!"? I tend towards the first. --prime mover (talk) 09:12, 24 July 2016 (UTC)


 * I rejected them all. I'm thinking it might be a good idea to tweak the account request form somewhat so as to make it less daunting (without a CV upload button, which I somehow suspect to be the cause of the problems we've been having). I'll ask Joe to update it. &mdash; Lord_Farin (talk) 10:08, 24 July 2016 (UTC)


 * Something like: "Please tell us what your interest is in mathematics, then (no less than 5 words)" should do it. Adding an apologetic note about how this is how we filter out the obvious spambots may also be a good idea. Apparently this aspect of  has been discussed not-completely-positively on e.g. Reddit (suggestions of elitism, and so on), although when I explained the spam problem to someone who subsequently joined us, the reaction was completely understanding and supportive. --prime mover (talk) 10:22, 24 July 2016 (UTC)


 * I've simplified the account request form. Now it's just username, email, and notes. We'll want to update the system messages to tweak some of the wording. --Joe (talk) 13:06, 24 July 2016 (UTC)


 * I've made some minor text edits, someone else may want improve them. --Joe (talk) 13:12, 24 July 2016 (UTC)


 * How easy would it be to get it to automatically email to the user: "Welcome to ProofWiki!" rather than making it so you have to type it in every time we press the "Accept" button? Apart from that, it looks fine. --prime mover (talk) 13:22, 24 July 2016 (UTC)

... Further research: in the "Confirm account requests " page, the "Biography" field is empty. Can we replace this with the contents of the "Additional Notes" field which is what the user has to type something into now? This could then also go into the user's home page. Maybe. --prime mover (talk) 17:33, 24 July 2016 (UTC)


 * I could change the field back to "Biography", however I wonder that will just deter people from signing up? --Joe (talk) 13:20, 25 July 2016 (UTC)


 * Well yes, that -- and besides, we don't want it to be a "biography", that's the whole point, people just post up their boring CV, and that makes it difficult to screen out the spambots. But an answer to "Why do you like mathematics?" demands something more creative and bot-proof. Till they get wind of it (here cometh the Singularity). --prime mover (talk) 18:42, 25 July 2016 (UTC)

How to cite ProofWiki?
How to cite a ProofWiki article in my work? Should I cite at all? --VictorPorton (talk) 18:10, 21 July 2016 (UTC)


 * Depends on the citation style you're using. I'd imagine you can cite it as you would any encyclopedia entry. Perhaps we could add a "Cite this" link at the bottom of each page one day? One that autoformats citations for MLA, APA, etc. Chandra (talk) 19:02, 21 July 2016 (UTC)


 * Never thought about it, never dreamed anybody would want to, we never thought we'd be citeworthy.


 * If anyone wishes to design and specify a citation style, the world is yours. --prime mover (talk) 20:40, 22 July 2016 (UTC)

Changing the "ProofWiki" first name use
When you share the ProofWiki main page anywhere, the LateX markup shows up for the first instance of "ProofWiki" on the page. Makes sharing it on Facebook, for example, rather ugly. I move to change the first instance of the site name with the lemniscate in it to just "ProofWiki" Chandra (talk) 19:02, 21 July 2016 (UTC)


 * Perhaps we could replace it with a graphic. --prime mover (talk) 19:05, 21 July 2016 (UTC)


 * How does that work? --prime mover (talk) 10:30, 24 July 2016 (UTC)


 * ... no, I see it does not. Anyone care to have a better try? I'm limited as to what FakeBook will allow me to do, I've compromised the usability of my account by being rude to Brexit scoundrels. --prime mover (talk) 10:37, 24 July 2016 (UTC)


 * We already have a graphic right next to the text. We could just put "ProofWiki" in bold Chandra (talk) 12:47, 25 July 2016 (UTC)


 * Do we really even even to make it look special. I say we just replace the markup with "plaintext". --Joe (talk) 13:24, 25 July 2016 (UTC)


 * I think the bold would make it look nice when on the main site without making the shared page ugly. And not just for the first paragraph, but also for the header bar above it. Chandra (talk) 17:22, 25 July 2016 (UTC)

Math on my wiki
I have started a new wiki site:

https://conference.portonvictor.org

Please explain which MediaWiki extension and which configuration should I use for displaying math on my wiki.


 * We use MathJax, via this MediaWiki extension. I don't know all the details, but it shouldn't be too hard.
 * NB. Please sign your posts so we know who said what and when. &mdash; Lord_Farin (talk) 19:48, 22 July 2016 (UTC)


 * I've installed MathJax on my site but rendering of math formulas is horribly slow: https://conference.portonvictor.org/wiki/Project:Sandbox Please help to investigate. --VictorPorton (talk) 20:38, 22 July 2016 (UTC)


 * For a start, you may find you need to use dollar sign delimiters in a MathJax installation on a MediaWiki site, as "math" delimiters do not always render properly. When we moved to MathJax from MediaWiki $\LaTeX$ we had to go through every single page and change them all. Kept us busy for a week or two. --prime mover (talk) 20:43, 22 July 2016 (UTC)


 * With dollar signs https://conference.portonvictor.org/wiki/Project:Sandbox has the same problem (renders too slowly, about 20 secs) --VictorPorton (talk) 20:45, 22 July 2016 (UTC)

It would appear that there is some built-in delay configured for MathJax; Chrome measurements show that after ~20 secs, the render command is triggered and subsequently completes in ~100ms. So please check if there's any configuration parameter which you have inadvertently set. Otherwise I don't know; you might try the MathJax mailing list or some other dedicated channel for further help. &mdash; Lord_Farin (talk) 20:55, 22 July 2016 (UTC)

Idea for categories/maintenance templates in user namespace
I just cleared out some user pages from Category:Tidy by putting the template calls in nowiki tags. But on second thought it might make more sense to enhance the various maintenance templates to exclude the User namespace (see this).

This will then exclude those pages from showing up in the categories, so they won't hamper us, but if e.g. a page is moved live from a sandbox (I've done this numerous times) it will automatically be included in the proper maintenance categories.

Thoughts? &mdash; Lord_Farin (talk) 11:19, 30 July 2016 (UTC)


 * Never realised how bad Category:Tidy had got again. Suppose I'd better get working on it. --prime mover (talk) 05:15, 1 August 2016 (UTC)


 * Seems like a good idea! --Joe (talk) 13:18, 1 August 2016 (UTC)


 * 't Has been done, and it was quite easy in the end. There might be various caching mechanisms in place which persist the User and Talk pages in the respective categories, but over time, or given a null edit, I expect them to disappear. In any case, the inflow has stopped. &mdash; Lord_Farin (talk) 19:30, 1 August 2016 (UTC)


 * I'm trying to reduce the number of pages in the maintenance categories but I still have so much more to do. But I just get so tired nowadays. I'm doing my best but it's just not good enough. --prime mover (talk) 20:10, 1 August 2016 (UTC)

Recent maintenance upgrade -- problems
Ever since the maintenance upgrade of a couple of days ago, I've been having sporadic trouble where the response time is such that it causes the browser to time out (it's a few seconds or so). Two things here:
 * a) It used to be a lot longer than that
 * b) The result of this is that the page is lost.

It never used to do this. The timeout situation lasts a few minutes, but when you're doing work it can interrupt the flow. The last time it did this was at about 08:45 British Summer Time 13th Aug 2016, and it came back soon after that. It did it about an hour before that as well, and I had to abandon what I was doing and do something else instead.

Is there something systematic that may be going wrong, or is it just me being impatient? --prime mover (talk) 03:52, 13 August 2016 (EDT)


 * I've worked out what it is.
 * Whenever you type anything into the "Search" field at the top right of the page, which does a text match on the stuff you are typing in, it crashes. This is seriously going to compromise my productivity because I use this all the time.  Is there any way this can be fixed, or is this just the way it works now? --prime mover (talk) 08:39, 13 August 2016 (EDT)


 * I'm not seeing this. What exactly crashes, the browser tab, the search box results list? --Joe (talk) 09:59, 15 August 2016 (EDT)


 * When I type something in the search box, it usually puts up an autoselector which populates itself with all the options that match what you type in. After you're typed in a few characters, and specially if you hesitate for a while and let it sit for a few seconds, and then continue, you notice that it has stopped updating the autoselector with your latest keypresses.  And a few seconds after that (you may or may not have actually selected a page by this time), the entire tab goes blank, leaving you with: "This site can’t be reached", "proofwiki.org took too long to respond." "ERR_CONNECTION_TIMED_OUT".


 * Other ProofWiki tabs that you have open then behave the same way (i.e. if select another page, any page, e.g. from a link on the left hand side menu bar, the same thing happens in that tab too). But only ProofWiki tabs. Although one of my tabs put the ProofWiki favicon on it. This page won't save, I'll cut and paste this text into a copy buffer and wait for it to recover. It usually does after a couple of minutes. --prime mover (talk) 13:25, 15 August 2016 (EDT)


 * What browser and version are you running? --Joe (talk) 15:07, 15 August 2016 (EDT)


 * I think you were being caught up in an overly aggressive firewall rate limiter. I've made some firewall changes, let know if this still persists. --Joe (talk) 16:43, 15 August 2016 (EDT)

Latency is appalling
Even after you purge your cache and press F5 on your keyboard on all relevant pages, it still takes quite some time before redlinks turn to blue, pages appear in their correct categories and "What links here" reflects an accurate account of what links there.

I noticed this getting worse after the latest software upgrade. Maybe MediaWiki designers need to be made aware of this. --prime mover (talk) 03:10, 4 September 2016 (EDT)


 * I experienced this a few times as well. Somehow the updates of the database seem to be delayed. Since it's intermittent (at least for me), I'll try to discover a pattern. &mdash; Lord_Farin (talk) 04:58, 4 September 2016 (EDT)


 * It's as if the database updates are batched, and only sent to update the database intermittently. --prime mover (talk) 17:59, 4 September 2016 (EDT)


 * I suspect the issue maybe be caused by some overly aggressive caching from the web server. I'll temporarily disable it to see if it is indeed the cause. --Joe (talk) 21:24, 4 September 2016 (EDT)
 * Change made, let me know if you're still seeing this issue. --Joe (talk) 21:27, 4 September 2016 (EDT)


 * There is still a noticeable delay between committing -- and purging -- and seeing the page appear in its appropriate category. I haven't tested how quickly "what links here" reacts to changes. --prime mover (talk) 01:22, 5 September 2016 (EDT)


 * The other thing I can think of is the job queue. It runs about once a minute. --Joe (talk) 10:34, 5 September 2016 (EDT)


 * That's sort of what it feels like. The odd thing is: how come it has never been noticed before? --prime mover (talk) 14:31, 5 September 2016 (EDT)


 * The MediaWiki job queue has changed in the latest update (we actually jumped two major versions). We're now doing the recommended thing and running the job queue via cron, previously we were running on user requests. Running on user requests is not recommended as it can be quite slow sometimes. Is one minute too unbarable? --Joe (talk) 10:02, 8 September 2016 (EDT)


 * When doing a refactoring job, and I move a page (with redirect) and then I do a "what links here" on one of the pages, and I get "No links", it's too easy to say "that's all right then" and delete the page before it's had a chance to update itself. And then there are so many links broken.


 * Just means I'm going to have to change my working style and leave big gaps between each operation I do. --prime mover (talk) 11:05, 8 September 2016 (EDT)

"Recent changes" does not completely work
I added a page "Definition:Conditional Preference" earlier today, but for some reason the "Recent changes" link does not pick up on it. --prime mover (talk) 07:18, 27 September 2016 (EDT)
 * Did it resolve itself after? --Joe (talk) 11:58, 30 September 2016 (EDT)


 * When I edited it subsequently, the change was registered -- but the original creation of that file never actually did appear on the Recent Changes log. It doesn't matter in itself, just an indication of things not going quite right when the fabric of space and time was tearing itself apart the other day. --prime mover (talk) 17:15, 30 September 2016 (EDT)

A general shout out to contributors
While it is accepted that not all results are perfect, and some need to be improved, it would be nice if contributors were to spend some time creating new pages in areas where we have so far made little progress (perhaps even to attack our colossal backlog of stubs) rather than to spend their time continually reworking existing material. Just a suggestion. --prime mover (talk) 03:08, 13 November 2016 (EST)

Examples
Once upon a time there was discussion about adding examples. For example, how to use Theorem X in solving a certain kind of problem. Did that idea come to fruition? --GFauxPas (talk) 12:41, 14 November 2016 (EST)


 * Plenty. Search for "Examples" and see what comes up. --prime mover (talk) 14:20, 14 November 2016 (EST)

Signatures
There is no button to add signatures on sandbox pages, like on User:GFauxPas/Sandbox and User:Lord Farin/Sandbox and Sandbox. --GFauxPas (talk) 09:28, 20 November 2016 (EST)


 * You can use 4 tildes (~), which on US keyboard layout can be typed as Shift-backtick (`). But it's strange nonetheless. &mdash; Lord_Farin (talk) 10:36, 20 November 2016 (EST)

Images
After I upload new versions of images, the old images sometimes still show on the page invoking. Unless you click the image and go to the appropriate   page. .. except when this doesn't work, either. But if you click on the image on the  space and open the image in its full resolution, then the updated image is there. Is this a known issue of MediaWiki? How does one fix it? --GFauxPas (talk) 17:25, 29 December 2016 (EST)
 * Purge. --prime mover (talk) 17:43, 29 December 2016 (EST)
 * I suspect this is a caching issue. Does the issue go away when you purge the page as Prime.move suggested? --Joe (talk) 19:05, 29 December 2016 (EST)


 * Purging didn't seem to have helped. --GFauxPas (talk) 19:36, 29 December 2016 (EST)


 * Purge the file page *and* the page it's included on. Works for me. --prime mover (talk) 01:30, 30 December 2016 (EST)


 * I did that and it still didn't work. Then I found the problem: I needed to clear the cache of my browser (Chrome) as well. All good, thanks. --GFauxPas (talk) 10:25, 30 December 2016 (EST)

Recent visits
Would it be possible to show some statistics of this website? A simple as daily visits would add some motivation, while other numbers like the quantity of proofs would be interesting, which I have not been able to find except for those announced by administrators. Also, other stats like most popular categories, proofs, definitions or other articles in general would help to define new goals, a success thereof would again be reflected on daily visits' part. Or, maybe, there are third party tools that are being used for this purpose? Julius (talk) 14:08, 17 January 2017 (EST)


 * There is Google Analytics, which shows that we have ~8000 daily visits, a number that is quite stable the past three years, modulated mostly by academic year and weekdays. There used to be an overview of the number of proofs and the number of definitions. However, showing this metric every time is quite resource-intensive and was harming page load times, so we removed it from the main page. &mdash; Lord_Farin (talk) 05:07, 29 January 2017 (EST)

Literature coverage progress
What do you think of explicitly showing the progress on literature coverage. By coverage I mean all theorems, lemmas, corollaries and problems which exist in a given book should be presented here without any missing steps with sufficient rigour. For example, this could be done for each section separately, say in the personal page of each book next to the corresponding section or chapter (percentage, or ratio of completed/total). This information could be exploited even further. One could make an invitation on the main page for a visitor, who, say, is confused by what is being said in a given book, to check if we have covered that book. Then there would be an increased chance for him to understand what was said in the aforementioned book. Maybe this could reduce the bounce ration of this webpage. Of course, this would require some micromanagement, and there are more important things missing, like whole branches of mathematics not having any related articles. Julius (talk) 09:07, 20 January 2017 (EST)


 * At this stage of ProofWiki's mathematics coverage, I feel like investing in this would be a waste compared to writing more definitions and proofs. Also, what is to be covered and what not is surprisingly hard to decide sometimes -- do you want this parenthetical example covered or not? &mdash; Lord_Farin (talk) 05:07, 29 January 2017 (EST)


 * I am making more of an attempt to be completist than I used to be, although I am finding it hard to make a case for the inclusion of the following exercise from : "Let $A$ be the set of words occurring in the first sentence of Chapter 1, $B$ the set of words occurring in the first sentence of the second paragraph of Chapter 1. What is $A \cup B$? $A \cap B$? $A - B$? $B - A$?" I find it difficult imagining a universe in which somebody can have thought this was an appropriate question for a graduate-level textbook. --prime mover (talk) 05:31, 29 January 2017 (EST)

Redirects
Some time ago we enforced a policy whereby we removed a large number of redirects, on some grounds that I can't remember now, I expect someone will remind me.

Now it seems that we have re-implemented that policy of having lots of redirects.

Can somebody clarify our position here? I'm really confused. --prime mover (talk) 03:16, 2 February 2017 (EST)


 * Some observations: As the search function does not recognize wrongly spelled words, it is easy to search for a page and not find it; e.g. because you wrote "Real Numbers" instead of "Real Number". I'm certainly not in favor of adding redirects for wrongly spelled words, but for names of mathematicians with accents I think exceptions can be made. Also, searching for a theorem can be tricky: if the title of the page uses a synonym of a word you used in your search query, chances are you won't find the page. --barto (talk) 12:16, 2 February 2017 (EST)

Name space for algorithms?
Has it ever been considered to use a separate namespace for algorithms? If yes, what were the pros and cons? Currently they're put in the Theorem (main) namespace, but as they require a particular treatment (algorithm statement, followed by proof of finiteness etc., a section/theorem addressing its complexity), and as they often make for long articles, I thought it might be worth to work out a framework for them. --barto (talk) 13:20, 3 February 2017 (EST)


 * I have no problem with the concept. I have not been happy with the way we present algorithms so far. But it would need Joe to set it up as I believe I do not have the authorisation. --prime mover (talk) 15:10, 3 February 2017 (EST)


 * I see one problem: how to name those pages? Do we go for the verbose Algorithm:Prim's Algorithm or the weird Algorithm:Prim's :s ? --barto (talk) 16:17, 3 February 2017 (EST)


 * The former, unless someone has better ideas. It is only by accident of evolution that we don't have "Theorem:Cauchy's Theorem". THe clumsiness is regrettable but I fear unavoidable if we are to continue with the stylistic design of this site.


 * Better suggestions are invited. --prime mover (talk) 17:18, 3 February 2017 (EST)


 * Two possibilities are either including part of context in the title, say "Prim's minimum spanning tree determination" (or similar) such that it provides with enough details to separate from others, or to leave out algorithm, but mention the relevant field in parentheses like "Prim's (Graph Theory)", so it does not end abruptly. Julius (talk) 18:51, 3 February 2017 (EST)


 * Not a fan of the first idea for the simple reason that this is inconsistent with the rest of the naming philosophy: we don't do for example "Fermat's result that there is no integer greater than 2 such that the sum of two numbers to that power equals another number to that power". Can lead to unaesthetic verbal circumlocutions. One of the advantages of preferring named theorems is their brevity. --prime mover (talk) 19:11, 3 February 2017 (EST)


 * I'm with prime mover. Actually I think Algorithm:Prim's Algorithm isn't so bad. --barto (talk) 01:38, 4 February 2017 (EST)


 * I do not see a problem with that as long as that's the only item under the name of the author. However, as more items appear under a given person's name, some additional information should reside in titles to make a clear distinction between them. Hopefully we will never get to the point where a situation like the one above becomes real and necessary, but one could speculate about making an abbreviation of a given equation or lemma just for this website, and then refer to it whenever needed. --Julius (talk) 07:53, 4 February 2017 (EST)


 * You may wish to familiarise yourself with how things have been done so far on this website.

Hello!
Hi. I just joined and I added a proof for the double angle of sin (proof 3). This is my first try and I will like to get some feed back - I know it's not perfect.

Also, I will like to help adding more proofs in geoemtry. Is there any one already working on this?

Thanks, ElyashivH (talk) 09:32, 28 February 2017 (EST)


 * Welcome. It is a pleasure to see our team growing. I am curious how you found this website.


 * The presentation of your proof is not far from the required form. One thing that is a bit visible is spelling. Anybody can make such mistakes, but usually they become marked in red on the code editor of this page. That should help you with spelling. Another aspect is formality of the proof. It would be better to start with "Let" or "Consider" instead of "look". A neutral language is preferred over a personalised invitation. Finally, it would be great if you could add a source of this proof. This is not always possible, but if there is a possibility, that would be welcome.


 * I do not think that anyone is working just on geometry. In the recent past it does not seem to be the main focus of anyone, although some members have lots of experience in this field already. It can be that you will work in geometry completely on your own. Could you be more specific on which areas of geometry you would like to write about? --Julius (talk) 13:27, 28 February 2017 (EST)


 * Sorry about the spelling - I worked from a computer in the library that doesn't have the dictionary installed.
 * I don't know a source for this proof - I just tried to calculate the sin of a double angle and did it this way. The proof isn't complete - It doesn't handle cases where the angle is more than 180.


 * I know just Euclidean geometry, so I guess I will need to stick to this.
 * ElyashivH (talk) 15:21, 28 February 2017 (EST)


 * Very well. If you feel that the proof is incomplete, use one of the templates used on this website, like Stub or WIP to denote it as an unfinished problem. Also, if you have any more questions regarding that exact proof, it would be better to use the talk page on the page of the proof ( or any other article). --Julius (talk) 15:56, 28 February 2017 (EST)

Problem with images
Hi,

I had a problem with the image  which throws a complicated message when generating a thumbnail:
 * Error creating thumbnail: /usr/bin/timeout: the monitored command dumped core /var/www/proofwiki/web/w/includes/limit.sh: line 101: 15784 Aborted /usr/bin/timeout MW_WALL_CLOCK_LIMIT /bin/bash -c "1" 3>&- Error code: 134

Any chance to look at this? I am trying to create a new template for "Proof Wanted". --prime mover (talk) 05:54, 5 March 2017 (EST)


 * A quick search shows that it could be memory limitation for such processes. Then one of the suggestions, except for faulty commands, is to increase that limit, like it is explained in . --Julius (talk) 15:52, 5 March 2017 (EST)


 * I'll let someone else do that. --prime mover (talk) 18:32, 5 March 2017 (EST)
 * Can you confirm that this is still happening? --Joe (talk) 10:43, 7 March 2017 (EST)


 * It sure does. See Numbers whose Cyclic Permutations of 3-Digit Multiples are Multiples for an example. --prime mover (talk) 12:06, 7 March 2017 (EST)

Help needed with Template
I am trying to fix the SubjectCategory template to allow a "context" parameter to be passed in, which will be passed through into the SubjectCategoryNodef template to be displayed as "in the context of (link to definition page of subject)". There is an example of it invoked on Category:Baire Spaces. But for some reason I can't get it to work and I can't see what I am doing wrong. All I want to do is pass the "context" parameter as and when it is not blank.

Anybody care to have a go to see what I'm missing? --prime mover (talk) 07:01, 12 March 2017 (EDT)


 * I think you were thinking too complex. I removed the #if construct, now it works. &mdash; Lord_Farin (talk) 13:38, 13 March 2017 (EDT)


 * There is now a subtlety I've learned: the technique of adding a pipe into a parameter. Now I know how to simplify several templates. Thanks. --prime mover (talk) 14:46, 13 March 2017 (EDT)

Progress on Problem with Images
Did we get anywhere with this?


 * I had a problem with the image  which throws a complicated message when generating a thumbnail:
 * Error creating thumbnail: /usr/bin/timeout: the monitored command dumped core /var/www/proofwiki/web/w/includes/limit.sh: line 101: 15784 Aborted /usr/bin/timeout MW_WALL_CLOCK_LIMIT /bin/bash -c "1" 3>&- Error code: 134

See above. --prime mover (talk) 02:17, 3 April 2017 (EDT)
 * Does this happen with all uploads or just this one in particular. --Joe (talk) 09:58, 3 April 2017 (EDT)


 * It just did it also with File:PascalsTriangle.gif when I put |left|100px against it just now on Definition:Pascal's Triangle. So no, it's not just Thinker.gif. --prime mover (talk) 10:09, 3 April 2017 (EDT)

This should be fixed now. Please let me know if it's not. --Joe (talk) 11:06, 3 April 2017 (EDT)


 * Yes indeed, that's all good. Good job. Cheers --prime mover (talk) 15:54, 3 April 2017 (EDT)

Policy on keeping categories small
So if I understand well, the goal is to have ~ max. 100 pages per category. I'm guessing that the correct way to tag e.g. the subpages of Definition:Connected (Topology) is: only the main page in the category Topology, all subpages under Connectedness? What about Definition:Connected Component (Topology): in the main category as well? --barto (talk) 09:52, 27 April 2017 (EDT)

Defining new MathJax commands
This has probably been discussed before, but I don't know how to search talk pages. Is it possible to define new commands, such as  so they can be used everywhere? Would this slow down page loading or not make any difference? Note: I don't want to push through my own set of commands, just talking about some very common ones, such as, about which there is no discussion how they should be named. This way we don't have to use  every time --barto (talk) 08:53, 28 April 2017 (EDT)


 * Yes we have had this conversation before, it crops up regularly -- but we haven't found anyone both committed and knowledgeable enough, and with sufficient privileges and authorisations to be able to do it. We did have some considerable discussion on what those abbreviations would be, and there was also some juicy disagreements as to whether a 2-letter command was better than a 2-word command or not. So it all got left up in the air, as usually happens. --prime mover (talk) 11:24, 28 April 2017 (EDT)


 * Technically, I should be able to make this happen. --Joe (talk) 11:27, 28 April 2017 (EDT)


 * Well what I propose is (if possible) to create commands that are literally what the output should be, like  (and not  ) for $\operatorname{Hom}$, so there can be no discussion or obscurity. (So not   or   but   for $\operatorname{Dom}$ and   for $\operatorname{dom}$, just to give another example.) --barto (talk) 12:02, 28 April 2017 (EDT)


 * I don't want both  and   -- we use one or the other. Consistency. --prime mover (talk) 12:27, 28 April 2017 (EDT)


 * Of course, I was just giving an example. --barto (talk) 12:46, 28 April 2017 (EDT)


 * Also no things like  for whatever notation we use to express divisibility. --barto (talk) 12:05, 28 April 2017 (EDT)


 * is a good example. We want that. We can't use  unfortunately because that is already in use for $\div$.


 * ... and because  would have been perfect for $\operatorname{div}$ (used for divergence of vector fields and divisors in algebraic geometry). One has to be very careful when creating abbreviations (not to say avoid them), which is also why I want to focus on 'literal text commands'. While   may be an arguably useful command, I suggest not to focus on such commands now. It's much less standard and may prevent us from getting this project off the ground. --barto (talk) 12:46, 28 April 2017 (EDT)


 * We could then have a page where new commands can be requested and discussed. --barto (talk) 12:10, 28 April 2017 (EDT)


 * But  for $\mathsf{Pr} \infty \mathsf{fWiki}$ seems acceptable :) --barto (talk) 12:15, 28 April 2017 (EDT)


 * We already have -- I would discourage unnecessary proliferation of such things when we already have a shortcut like this. --prime mover (talk) 12:27, 28 April 2017 (EDT)


 * Incidentally, I have just remembered a good reason why we have not used "\def" in the past to define commands -- and that is when the page is transcluded, the "\def" is not carried over into the transclusion. We need to make sure we don't fall foul of this. --prime mover (talk) 12:30, 28 April 2017 (EDT)


 * Never mind about  --barto (talk) 13:02, 28 April 2017 (EDT)

Joe, would you mind experimenting a bit, say to try to implement  as a start? --barto (talk) 04:35, 30 April 2017 (EDT)
 * Will do! --Joe (talk) 10:45, 4 May 2017 (EDT)
 * Done. --Joe (talk) 11:24, 4 May 2017 (EDT)
 * Can confirm that $\lcm$ works well, and also in transcluded pages (where this technique was under suspicion). --prime mover (talk) 15:46, 4 May 2017 (EDT)
 * Awesome! What about creating a separate page where we create our list of newly introduced commands, aside from Symbols:LaTeX Commands? We could then discuss them there and have a nice overview of what is new versus what is standard included in MathJax. --barto (talk) 16:19, 4 May 2017 (EDT)


 * Don't know about "separate from" -- "transcluded into" I am up for: Symbols:LaTeX Commands/ProofWiki Specific is where we start. --prime mover (talk) 16:36, 4 May 2017 (EDT)

MathJax CDN discontinuation
I just noticed that MathJax will permanently shut down its CDN services on April 30 (tomorrow): https://www.mathjax.org/cdn-shutting-down/ Is ProofWiki hosting its own MathJax or does it use their CDN? --barto (talk) 12:11, 29 April 2017 (EDT)


 * Thanks for the heads up. We were aware of the CDN shutdown, but we have a local instance running (as you noticed the past days). &mdash; Lord_Farin (talk) 11:31, 2 May 2017 (EDT)

Restricting the Rename tool
Does anyone know if it is possible to restrict the "Move" tool (which effectively renames a page) to "Admin" users or other suitably authorised editors? It is so easy to just change page names according to whim and personal preference, and completely compromise the linking structure. --prime mover (talk) 02:35, 2 May 2017 (EDT)


 * Joe should be able to manage this; it's internal MediaWiki configuration. I think it makes sense, given that we nowadays have the "Trusted user" group in between. &mdash; Lord_Farin (talk) 11:31, 2 May 2017 (EDT)


 * I'll take care of this. --Joe (talk)
 * Should be limited to the "Trused user" group and above now. --Joe (talk) 11:21, 4 May 2017 (EDT)


 * Jep, confirmed :) --barto (talk) 16:20, 4 May 2017 (EDT)

Strange behaviour with editor
Has anyone else noticed the following strange (but inconsistent) behaviour of the wiki page editor?

You place the cursor at the place in the page where you want to add a macro-generated construct, e.g. the MediaWiki function from below the edit screen.

But instead of appearing on the screen where you put your cursor, it appears on the line (or 2 line, or 3 lines, ...) above.

This not only affects the macros below the screen, but I have also noticed it on the "add header" button (the big uppercase A on the list of edit helper buttons above the edit page). However, it is inconsistent -- it does not always happen, and I have been unable to identify the conditions under which it does happen.

Note that I am using Google Chrome (I don't have the patience for any other) on a Windoze 10 machine (yes I know, how brain-dead is that).

It has only started doing it for the past week or so (I can't recall when it started). I first wondered whether it was a glitch, but now I wonder if it is more general than just my machine. --prime mover (talk) 02:40, 4 May 2017 (EDT)

Error on protected featured proof.
I find it odd that the proof 3 in this featured proof (Complex numbers cannot be totally ordered) would have a typo. Near the beginning it states.

Aiming for a contradiction, suppose suppose that (C,+,×) can be ordered.

Suppose, suppose... Feels philosophical to me.


 * The person responsible is to be fired. --prime mover (talk) 14:01, 7 June 2017 (EDT)

On the begging of forgiveness
(It's better than asking permission.)

As some time ago we lost sight of the number of proofs (for some reason it got removed), we haven't been able to get a quick count of the number of theorems.

To make up for this, I have added the category Category:Proven Results, invoked automatically when the template is included at the bottom of any proof. This category is populating itself as I type. --prime mover (talk) 02:34, 9 June 2017 (EDT)


 * It seems cleaner to add Category:Proven Results to Category:Hidden categories. Nobody will ever look at that category anyway; it serves just to count the proofs. --barto (talk) 02:46, 5 August 2017 (EDT)


 * You're sure of that why? --prime mover (talk) 05:30, 5 August 2017 (EDT)


 * Because Category:Proven Results is too large to scroll through. You're much more likely to find what you're looking for with a normal search. But I won't insist. --barto (talk) 05:42, 5 August 2017 (EDT)


 * It can be fun. Offering the opportunity for someone to browse through it in all its manic colossalness is better than not doing so. I do it myself sometimes. --prime mover (talk) 14:14, 5 August 2017 (EDT)

The following are equivalent
What about a template "TFAE" for The following are equivalent:
 * ? --barto (talk) 05:43, 30 July 2017 (EDT)
 * ? --barto (talk) 05:43, 30 July 2017 (EDT)


 * Yeah, why not? On it ... --prime mover (talk) 05:46, 30 July 2017 (EDT)


 * Cool. Just that sentence or also some functionality to include the equivalent statements, with  etc? Maybe that makes it too complicated to use. Not sure. May aso clash with some LaTeX symbols then. --barto (talk) 05:51, 30 July 2017 (EDT)


 * How's that? See it in use on the page Equivalence of Definitions of Abelian Group. --prime mover (talk) 05:59, 30 July 2017 (EDT)


 * It's fine. The clashing I was talking about was in the hypothetical situation where the TFAE template would include parameters for the equivalent statements, similar to the Equation templates. But the way it's now is good. I like it. --barto (talk) 06:08, 30 July 2017 (EDT)


 * I considered adding the stuff to populate the rest of the page, i.e. by automatically transcluding the definitions, or indeed the statements themselves, but deciding how to pass in the number of such equivalences is non-trivial (as far as I know there is no easy way of setting it up to handle varying numbers of things to be defined without going down the complicated route we went through with the Citation template etc. --prime mover (talk) 06:21, 30 July 2017 (EDT)

Does this mean we can now sort the pages in Category:Definition Equivalences using  in the template? --barto (talk) 10:11, 1 August 2017 (EDT)

Yes, it seems :) --barto (talk) 16:58, 1 August 2017 (EDT)


 * I don't understand the question. All pages are sorted alphabetically. --prime mover (talk) 17:20, 1 August 2017 (EDT)


 * I mean, to ignore "Equivalence of Definitions of" in the alphabetic sorting, so that the pages will be organized in sections according to the starting letter. We talked about this at Category talk:Definition Equivalences once. --barto (talk) 17:25, 1 August 2017 (EDT)

Expanding the Help Section
Many things are not yet addressed in the Help Section, leading to discussions being brought up over and over, while a consensus has already been reached. To make more attractive to contributors, I decided to expand the Help Section (which has not been done for years, it seems).

Topics include:


 * When to Redirect - partially addressed at Help:Redirects
 * Which categories to add - partially addressed at Help:Categories
 * The balance between accessibility and generalizations of elementary results.
 * When to enumerate definitions and when to separate them into sections.
 * How to treat pages with multiple definitions
 * New LaTeX commands
 * Requests for moving pages
 * Commutative Diagrams
 * etc...

There are many such things, and the discussions are scattered on talk pages. I've recently started writing, but only with the input of many users can the Help Section become really great. --barto (talk) 09:33, 30 July 2017 (EDT)

More topics: informal definitions, proof outlines, proof outlines in the case of multiple proofs, what to put in the also see section and what not, (over)using the AoC Template, stubs and similar templates, requesting new categories, example categories. --barto (talk) 10:08, 30 July 2017 (EDT)

More: Named theorems, named theorems and disambiguation, Template:Languages. --barto (talk) 13:25, 30 July 2017 (EDT)


 * Sounds good to me. --Joe (talk) 10:38, 31 July 2017 (EDT)


 * I've started by creating a skeleton for the missing topics. Fleshing it out now. You're welcome to change the wording or give me some advice if you're not happy with it. There are some sections I can't complete, because they have not yet been discussed, or I because can't find the discussions. When I find one (e.g. on the archives of the main talk), I copy the consensus to the Help Section. --barto (talk) 16:47, 1 August 2017 (EDT)

Commutative diagrams using AMScd
Next to XyJax, which I learned is no longer maintained, some commutative diagrams can be written using the AMScd package, using  for every CD. According to the MathJax Documentation, we can make a small change in the MathJax configuration to avoid using  every time. --barto (talk) 09:57, 2 August 2017 (EDT)
 * I can add this to our configuration later today or tomorrow. We should also need to remove/replace anything that's using XyJax. --Joe (talk) 10:00, 2 August 2017 (EDT)


 * Thanks. As long as XyJax works and there is no good alternative, I'd rather not remove the existing diagrams though. A TikZcd extension would be ideal, but all I could find is an ordinary PGFTikZ Extension: It creates images, not MathJax, has a cumbersome syntax and will not be compatible with our new LaTeX commands. --barto (talk) 06:41, 24 August 2017 (EDT)

CirrusSearch
Can we implement the CirrusSearch Extension? It makes searching more comfortable because it does spelling correction, among other improvements. --barto (talk) 06:35, 24 August 2017 (EDT)
 * It does seem to require an effort to install, but it is worth it. --barto (talk) 08:50, 31 August 2017 (EDT)

Gadget Extension to see links to disambiguation pages
The Gadget Extension (which Wikipedia has) makes it possible for a user to display links to disambiguation pages in orange instead of blue. (Among other things.) This makes it possible to spot lazy links and fix them. --barto (talk) 15:44, 24 August 2017 (EDT)


 * Possibly, but there are rarely many. I go through them every so often and tidy them up. --prime mover (talk) 16:37, 24 August 2017 (EDT)

On whitespace before headings
I do support the increased whitespace before section headings, for the exact reason as explained in the FAQ. But the way in which it is added has some drawbacks, and in fact MediaWiki:common.css exists precisely for this purpose. I have tested the css-based solution by writing some code at user:barto/common.css so that, for me, the amount of whitespace is now always right. Here are some advantages and disadvantages of using css, after which I discuss alternative solutions and what css can and cannot do. I hope I'm not missing any important aspects. Any thoughts are welcome. (Please comment at the very end only.)

Tl;Dr: Replace all rules about blank lines around section headings by one simple rule, together with some other advantages including section editing, but at the cost of removing double blank lines before headings in the source text, possibly reducing its readability?

Advantages:


 * Easier to contribute. The less conventions (new) users have to keep in mind, the happier they will be to contribute.
 * Less discussions. If whitespace is fixed automatically, users are less likely to express their opinions about it, or to notice the increased whitespace in the first place.
 * Semantics. It is semantically wrong to use  (which is what happens now) to increase top margin.
 * Customizability. A coded solution is customizable, as opposed to relying on specific Wikitext usage on every page.
 * Section editing. Section editing could be allowed again. (See alternative solutions below for why it is not.) It has multiple advantages; some that come to mind are: Less need to scroll when editing Wikitext, more descriptive edit summaries, faster page load when editing/previewing (I've had problems with this when I was editing at places with slower connection than I have at home).
 * One may argue that this is not such an advantage because pages at ProofWiki are, generally, small. Still, even relatively short proofs take quite some space in the Wikitext. Either way it's more elegant to only edit a section, especially if you want to correct a typo, add some extra explanation, add a link in the Also see section, add a source, ... There are other philosophical arguments in favor, such as the idea that unrelated edits should not be done at once.

Doubts you may have:


 * What with existing pages? Increasing the top margin using css, combined with the existing line break on those pages creates too much whitespace.
 * Indeed. That's were jQuery comes to aid: it can remove those empty paragraphs, without affecting anything else.
 * But then the page content jumps when the page is loaded.
 * I don't know how to avoid that. But consider that it will always jump a bit due to MathJax.
 * There are currently about 50000 pages. They would all have to be brought up to the new standard.
 * Unfortunately, yes. I would never punish anyone by having them fix that manually. Except a bot. As long as the job isn't finished, jQuery can take care of them. Remember that it won't have to be done ever again, because the styling of all headings will be automatized.
 * Wikitext readability. Blank lines in the Wikitext make it easier to spot section headings. Especially considering that there are many single blank lines in the source text already, because statements are separated by a blank line.
 * I agree. On the other hand, with section editing there's less need for it. It will be mostly useful for refactoring and restructuring tasks, or when creating a page.
 * Still...
 * To some extent, it's a matter of habit. Consider that the extra blank lines in source text are specific to ProofWiki, and are not used on e.g. Groupprops or Wikipedia, so not everyone will find the extra blank line needed for readability. I discussed this further at Alternative solutions below.
 * I don't think pages in [insert namespace] should be affected.
 * No problem. Common.css can take care of that. See code details below.
 * Not all section headings need more whitespace. For example subsections that come immediately after a section heading, or transcluded definitions at equivalence proofs of multiple definitions.
 * Again, this is no problem for css. Even better: css can be used here to make sure they all follow the same format, and any changes in style will be applied to them all at once.
 * Some templates create section headings, and should not be accessible through section editing.
 * An administrator can lock them.

In summary, the only lasting disadvantage I see is readability of the source text. It has to be decided whether this outweighs the advantages above. Consider also that we could replace all rules about blank lines around headings by just one simple rule:
 * One blank line before a heading, one blank line after.

See also Alternative solutions below.

Alternative solutions


 * 1) Change the default number of blank lines at the end of a section when section editing.
 * When submitting a section edit (or any edit), what the MediaWiki parser does is:
 * Trimming
 * Adding "\n\n" at the end
 * It would be nice to make the parser add "\n\n\n" at the end instead. This would allow section editing while maintaining the right amount of whitespace. It does however not solve other things such as customizability, semantics and special cases like definitions at definition equivalences and perhaps others.
 * Unfortunately, this is not configurable, or at least not without hacking into internal MediaWiki files.
 * 1) Change the way Wikitext is interpreted. Keep the double blank lines before headings, but don't let MediaWiki create empty paragraphs. Add the whitespace using css instead.
 * This would allow multiple blank lines in the source text for readability, without affecting the result. A disadvantage is that section editing removes those blank lines again. Also, it still involves different source code rules on blank lines (though they won't affect the output anymore).
 * I could not find anything about whether it's possible to customize wikitext interpretation (will update when I do) but it's very likely that it is not, again, at least not legally and free from danger.
 * 1) Keep it the way it is.

It must be noted that (unless we resort to more hacking) 1 and 2 would affect all pages, including user pages.

Code details

There are some things to be taken into account in common.css (and common.js for the temporary jQuery script):


 * Headings following headings. We probably don't want as much whitespace as usual between two headings if there's no text between them. No problem for css.
 * Definitions at definition equivalences. It appears that the current policy is to reduce whitespace between them. No problem for css, but requires some more code. Also does not depend on there being a blank line between them in the source code or not.
 * (In general: 2n blank lines in source text = 2n+1 blank lines in source text = n empty paragraphs in output.)
 * Restricting to namespaces. There are some namespaces like Category:, User:, talk pages, that perhaps we don't want to affect. That's no problem, in fact MediaWiki has cues in the source code that are created specifically to distinguish between them when using common.css.
 * Browser compatibility. The css I wrote at user:barto/common.css uses some features of css3, but the most recent versions of all major browsers support them.

For the jQuery paragraph removing script: only empty paragraphs right before headings must be removed, but this is no problem. The following must be taken care of:


 * Empty paragraphs created by blank lines between list items; see e.g. Definition:Open.

The following cannot be affected, because they don't involve empty paragraphs:


 * Double blank lines before "then" in theorem statements or, similarly, in definitions. Or anywhere else between two paragraphs.

Thoughts? --barto (talk) 06:41, 4 September 2017 (EDT)


 * Whatever we need to do that:
 * a) gives me least work to do, I would rebel against a regime that made me do a lot of rework;
 * b) leaves it looking stylistically exactly the same as it is now.
 * Apart from that, I'm okay with whatever is decided. --prime mover (talk) 09:52, 4 September 2017 (EDT)


 * A lot of your points focus on enabling section editing. I consider section editing a flawed means of editing, and I know by experience that the MediaWiki parser code generating it is buggy and unpredictable, especially in combination with transclusion. That right, in combination with what is the single most used MW feature on ProofWiki.
 * Additionally there are very many cases where I would rather avoid that someone changes one part of the page (say, the proof), and accidentally uses different notation from the theorem statement. No thank you.
 * Those qualms regarding section editing (which makes up a good portion of the aims you seem to have with this change) having been mentioned, I think it can only add to the ease of contributing. Not a lot, admittedly, but a bit. And it helps to reduce frustration from header distance not behaving as wanted. So I would be in favour of experiments and a good style sheet.
 * Last point I want to mention here is the behaviour of transclusion. Because of the logical way this technique's tags are placed, we get extra line breaks for free. I would like to see a plan to address this. &mdash; Lord_Farin (talk) 15:11, 4 September 2017 (EDT)


 * On section editing : I'd personally like there to be an option to disallow editing transcluded sections (without having to use html tags for those headers). With the suggestion on transclusion below, I think it is possible.
 * I agree that section editing would slighty increase the possiblity that someone uses different notation than in the theorem statement. On the other hand, experienced users won't, and the bold unexperienced who are not informed about our policies on notations will probably do it anyway. Something we can already do now, is adding a line in ProofWanted as a reminder to use the same notation. --barto (talk) 12:28, 7 September 2017 (EDT)


 * On transclusion : It is infortunate that the placement of the onlyinclude tags matters so much. What would be ideal are tags that trim the text when transcluded.
 * Solution? There is no hope that the behaviour of onlyinclude will ever be changed because many wikis rely on it. However, what should be possible is to create a variant of the tag that does trim. (Alternatively, we could maybe combinine onlyinclude with a trimming template (I'm not sure, because of 's in the source code), but the transcluding syntax will become inelegant.)
 * If it's possible, a key question (but not something to focus on now) will be: should the text be trimmed always, or only when transcluded?
 * Lastly, an advantage of our own onlyinclude tags is that (I think) we could disallow section editing of transcluded sections (by placing everything in a  or something, + common.css) --barto (talk) 12:28, 7 September 2017 (EDT)


 * Editing sections is easy, I'm editing one now. You just right click on the subheading.


 * I've said it before, I'll say it again, and I will continue to say it over and over again until the apocalypse: it ain't broke, don't fix it. If you feel the need for a programming exercise to keep you occupied, bend some thought to how we may be able to add some structure to Category:Specific Numbers.


 * All the dreaming aside, here is a realistic, practical suggestion: From now on, place the onlyinclude tags such that there are no additional linebreaks inside. This does not affect anything, again by mediawiki's whitespace handling. (It's how onlyinclude is supposed to be used.) --barto (talk) 05:40, 8 September 2017 (EDT)


 * "Improving" the MW transclusion mechanism is something that I have been looking into with regard to the ProofWiki extension (having options to increase heading levels and multiple transcludable sections, among other things). However, it turns out to be a pain because the parser code generating the table of contents is an absolute mess and by default will omit sections transcluded that way. While I would encourage such a mechanism to work (because as said, it enables more features than just whitespace control) I think it presupposes work on the table of content generation in MediaWiki. If you are interested I have some discussions on the MediaWiki issues board that should provide a good introduction.


 * Changing the placement of onlyinclude will introduce a major inconcistency in the source code formatting, and make it much harder to find the places where it starts and ends (due to the tags not being on their own line). I don't think this will improve things over time. Maybe we can rely on the jQuery to save us when it comes to transclusion.


 * In summary, I conclude that there is currently nothing in the source code conventions that can be suitably improved at this moment. However I still support the CSS/jQuery experiment to see if we can make steps towards achieving this layout with the proper technical tool. &mdash; Lord_Farin (talk) 05:14, 9 September 2017 (EDT)

css/jQuery proposal
There seems to be some support for testing out the css/jQuery approach. Shall we try it? It can always be limited to specific namespaces. --barto (talk) (contribs) 18:01, 30 October 2017 (EDT)

Hosting and ads
Below is a discussion I moved from user:barto to here.

Some people tell me they don't want to use or contribute to just because it has ads. That's sad. I think it is not hard to find a university or something that's willing to host the site for free. They tend to have huge servers anyway, so hosting won't make a big difference for them. --barto (talk)


 * I use Adblock so I don't get ads. I'm wary about this site being hosted by a university because I don't go to university and you can bet bullets to bullshit that they'll disallow anyone not an alumnus from contributing. If that happens I'm going on another killing spree, but this time I won't stop when I've reached my age in weeks.


 * Many people don't use adblock, but that doesn't matter. The success of ProofWiki should not rely on Adblock. Whether it's a university or some mathematical society, we still decide what happens to the site. The idea is simply that someone would pay for ProofWiki as an act of generosity. --barto (talk) 17:11, 24 August 2017 (EDT)


 * Nobody ever does anything as an act of generosity. Universities are businesses out to make money, and they do that by charging people for the use of their facilities, and they do that by blocking everybody who isn't a fee-paying student.


 * But I'm just one person, and my opinion bears no more weight than that of everyone else, I just won't be around when it happens. No worries.

Another option is to become part of wikimedia. Reading their criteria it does seem that ProofWiki has a good chance of meeting them. Our goals and style do differ from Wikipedia:WikiProject Mathematics (we're not an encyclopedia but more a dictionary, quite the opposite and complementary to it), any Wikibooks on mathematics (we do not focus on one topic, dictionary style) and Wikiversity (not a collection of courses, nothing is done twice, dictionary style, nonlinear) --barto (talk) 17:05, 4 September 2017 (EDT)
 * If we're to preserve the current structure of requesting an account, the site would have to be independent of SUL. The problems that this site has faced in the past with spambots doesn't make opening up the site to anyone with a Wikipedia account an attractive proposition in my opinion. I'm unsure how open to compromise the sysadmins would be on this, as SUL is deemed to be a relatively important feature. There would be no harm in one of us creating a proposal on meta, however. I could always start drafting one in userspace. Caliburn (talk) 17:20, 4 September 2017 (EDT)


 * IF we were to merge with metawikipedia, then I am afraid that is where and I would part ways. --prime mover (talk) 18:27, 4 September 2017 (EDT)


 * That would be very unfortunate, you are an exceptionally valuable contributor. Again, I do forsee problems involving SUL, and independence also. While we would not lose control of the project, we would most likely have to allow Wikimedia stewards and sysadmins reasonably escalated access. Thank god the WMF is nothing like Wikia, and do keep the interest of the community in mind in their actions. The migration would of course welcome a stream of new, inexperienced users, which is a monumental positive in some senses, and a significant negative in others. I quite like the status quo in terms of the editing environment, so I'm not sure how I'd feel about it, though I've only been here for a few weeks. Caliburn (talk) 18:47, 4 September 2017 (EDT)


 * Yeah well, I've not been here that long myself, I don't think I'd be missed. --prime mover (talk) 01:16, 5 September 2017 (EDT)


 * Good point. I don't know how spam-proof wikimedia is. There are surely other things I haven't thought about. Either way, everyone here would have to agree.
 * Quote from About: The more people we have supporting the project, the bigger and better it will become. --barto (talk) 09:39, 5 September 2017 (EDT)
 * While there's no doubt that an influx of unexperienced editors requires more tidying and explaining policies (which can frustrate you if you let it), it is the only way in which a community can truly become great. It will be impossible for one user to patrol everything, and that's a good thing: there exists more than a lifetime of mathematics to read. --barto (talk) 10:07, 5 September 2017 (EDT)

Just to make clear why I think getting rid of ads is beneficial: And for finding a generous hosting provider: in particular, wikimedia: --barto (talk) 09:39, 5 September 2017 (EDT)
 * Makes the site more attractive
 * Less distraction for those who learn by reading ProofWiki
 * No more need for ads
 * The future of ProofWiki is secured: when one day the current administrators retire, the site will continue to exist
 * Currently people might refuse to contribute because they don't know who owns ProofWiki (a person or a (non-profit) organization?). (Or whether someone is able to shut the site down and take advantage of their contributions for personal gain. I know it sounds paranoid, but it wouldn't surprise me if some people think like that.)
 * Likely to attract many contributors
 * (conjectured) Higher page rank in search engines
 * Technical support as much as we want

I'm currently preparing for Hurricane Irma. I'll try to address this stuff as well once I get some time. --Joe (talk) 10:41, 6 September 2017 (EDT)

Caching problem
Suppose you have a picture which you have uploaded, and included in a page, with a size, for example:

Suppose you then upload a new version of that file, using "Upload file".

However much you refresh the cache, purge, whatever you have to do, it will not update the page to show this new version.

If, instead, you change the size of the image on the page:

... the new version appears.

But then if you go back to the old size:

... you once more get the old version back.

Is there a way of purging these old views of the files, so you don't have to change it size to see the new version? --prime mover (talk) 07:40, 1 October 2017 (EDT)


 * Hm, strange. I checked today and all seemed to be fine when reverting to 400px. It must be caching somewhere, but I cannot determine now if it is server-side or client-side. Also couldn't find any similar cases online. We'll have to keep looking if it reoccurs. &mdash; Lord_Farin (talk) 17:48, 4 October 2017 (EDT)


 * Local caching problem. Sorted. I hate my new machine. --prime mover (talk) 18:27, 4 October 2017 (EDT)

Symbolic Evolution
I have come up against the difference in notational preferences for a sequence or a series: $\left\langle{a_n}\right\rangle$ or $\left({a_n}\right)$ or even $\left\{ {a_n}\right\}$?

For and against:


 * $\left\langle{a_n}\right\rangle$ is also used for the generator of a group, and so can be confused with it. The reason it has been settled on for this site is because it's what I learned in uni, and what I have in certain of my source works, and that is where it settled.


 * $\left\{ {a_n}\right\}$ can be conflated with the set notation, and so carries the subtext "order does not matter, uniqueness does" which are both fundamentally not the case for sequences. No takers for this, I hope.


 * $\left({a_n}\right)$ is what Barto, for one, uses by preference. I have been routinely changing them to $\left\langle{a_n}\right\rangle$ in my ongoing drive for consistency, but I have been minded that it may be "the most sensible" notation -- because it is the same sort of notation as the "ordered tuple", it brings its own subtext that "order matters, and terms may not be unique".

So, a big suggestion for a major refactoring task: should we settle on $\left({a_n}\right)$ for the standard notation on for sequences and series? My vote is: yes, but we don't need to do the change all in one go please. --prime mover (talk) 08:29, 22 October 2017 (EDT)


 * Hmmm... I tend to use $(a_n)$ indeed, I guess because it's what I grew up with or what's easiest to write down (pen & paper, I mean). Regardless of that, I do see some objective reasons to prefer them: $\langle\cdot\rangle$ is sometimes used for generated substructures (e.g. linear span), and $\{\cdot\}$ makes it look like a set (without ordering). I'd like to hear other arguments I'm overlooking. --barto (talk) (contribs) 18:51, 25 October 2017 (EDT)


 * Well, $\langle\cdot\rangle$ can be confused with a generator just as much as $(\cdot)$ can be confused with an ideal... and with the general ubiquity of parentheses in mathematics (both in text, like here, and for order explication, and for function invocation, and ideals as mentioned, and probably for more things), it hardly seems that we need more things using parentheses.
 * Rather, it seems to me that sequences are one of the places where there is a reasonably common alternative with $\langle\cdot\rangle$. I see no harm using it and even less a need to refactor all of them away.
 * But I could live with the compromise that both are allowed (although consistency will suffer). &mdash; Lord_Farin (talk) 11:23, 29 October 2017 (EDT)

Proof count on main page
What about something like currently has about proofs. at the main page? Or does this slow down page loading? --barto (talk) 10:02, 25 October 2017 (EDT)
 * We had this for a long time, I forget why we removed it (anyone remember?). Would be nice to overhaul the main page in general. I'm cool with adding it back if you have a proposal. --Joe (talk) 10:05, 25 October 2017 (EDT)


 * I think you removed it so as to de-clutter the front page a couple of years ago. We used to use it to keep an idea of the count of the proofs so we could add "landmark" proofs: "This is the "n"th proof on ProofWiki!" It would be good to have it back.


 * A count on the "Proven Results" category will in general be an overestimate, because parent pages which are the container for Proof 1, Proof 2, etc. are also counted, because they transclude the qed. But it would be a start. --prime mover (talk) 10:35, 25 October 2017 (EDT)


 * True. But there's no harm in exaggerating a bit, especially if we put "about" before the number. --barto (talk) (contribs) 19:09, 25 October 2017 (EDT)


 * Is there a better way we could estimate? I could add something to our extension. Eg. all pages that contain and don't contain any todos, etc. --Joe (talk) 11:20, 26 October 2017 (EDT)


 * If we could count pages with qed on them and not include the pages they are transcluded into, that would probably be the best technique, to my mind. I would say: keep it simple, and don't exclude pages with todos on them because they shouldn't have a qed on them in the first place. --prime mover (talk) 12:24, 26 October 2017 (EDT)


 * I have this implemented locally. Can anyone think of a good way to likewise count definitions? --Joe (talk) 14:56, 3 November 2017 (EDT)


 * Is it possible to count the contents of a category and all its subcategories? And exclude redirects in the process? --prime mover (talk) 16:05, 3 November 2017 (EDT)


 * The issue is that definition pages sometimes have several subpages including examples. How accurate do we want to be. Consider Definition:Rational_Number, it has several subpages, are these to be counted as more than 1. If so how do we ignore the "note" subpage. One idea I had was count the number of links to unique definitions from proofs. That total is around around 3,500 unique pages. All unique definition links from all namespaces is almost 10,000 (about the same as counting all pages in the definition namespace). Which of these feels more accurate? --Joe (talk) 16:15, 3 November 2017 (EDT)

Subpages and the horror of refactoring
I've been working on an alternative for subpages: User:Barto/Sandbox/navigation. At least, for subpages except things like multiple (numbered) definitions, historical notes, multiple (numbered) proofs, ... Basically it's meant for the type of subpages that are commonly linked to (definitions, mostly).

Pros: Prevents using direct links to subpages, Page titles become neater, Refactoring easier (hierarchy is easily changed, we can even go to much deeper levels just by adding links)

Cons: The absence of slashes in the title makes the hierarchy less clear, despite the "navigation bar". In some cases the structure of the title (e.g. "Continuous Real Function at Point") still reflects the hierarchy: "Continuous/Real Function/at Point"


 * Another con: having to learn yet another page structure template, and one which is horribly non-intuitive, for no benefit. --prime mover (talk) 13:34, 27 October 2017 (EDT)

Thoughts? Probably some stylistic improvements can be made. --barto (talk) (contribs) 18:41, 25 October 2017 (EDT)


 * How's that for a big suggestion for a major refactoring task? :) Might be the last of its kind though. --barto (talk) (contribs) 19:00, 25 October 2017 (EDT)


 * I'm going to need a lot of convincing. There are going to be some pages with a big ugly blue box on them which looks shit, and it's going to mean a colossal amount of work to get it into that shape in the first place. So, I'm out. --prime mover (talk) 01:42, 26 October 2017 (EDT)


 * Some examples: Definition:O Notation/Big-O Notation/Real/Point could become Definition:Big-O Estimate of Real Function at Point and we could easily add another level "Asymptotic Notation" in the hierarchy, without making the page title longer. The theorems transcluded at Triangle Inequality (e.g. the reverse) could link back to that page, improving navigation.


 * We've already got Definition:Big-O Estimate for Real Function at Point so I really don't see what the point is. --prime mover (talk) 12:30, 26 October 2017 (EDT)


 * I don't mind doing the work. Style of the box can be changed to your liking.
 * If you want, I can test out an actual example, e.g. Triangle Inequality. --barto (talk) (contribs) 02:55, 26 October 2017 (EDT)

Made some stylistic changes, looks more intuitive now and fits within the color scheme: User:Barto/Sandbox/navigation. --barto (talk) (contribs) 05:54, 26 October 2017 (EDT)


 * Actually this is exactly how subpages work, and how the buildup of the backlink structure of subpages is set up. I don't see a need to improve upon this. Although the argument regarding the page titles is a fair one. (But who cares about the title anyway if there is a redirect? What we actually want is that the search functionality improves so that it becomes easier to find pages.)


 * As to refactoring, you are still going to transclude the subpages, and whether you do that with the redirect as the main page or not, the fact remains that they need to be changed. I am assuming here that a rename will also affect any and all subpages (which is ideally the case to ensure consistency). Therefore I struggle to see the benefit from this scheme.


 * It could be decided that we can improve upon the backlink structure by making it customisable, but then I would say we should invest into getting this a MediaWiki extension proper and not develop some hand-written workaround that sits beside the MediaWiki solution.


 * As to the labeled section transclusion extension mentioned, we had a look into it and it was deemed insufficient. Our own extension is supposed to fix this better but is not finished yet (the major problems with section headings and nested tags continue to exist; we might try to steal the syntax of LST, if it works them I'm all for it (although it is of course a bit against XML standards)).


 * But I'm open for hearing more arguments, and want to thank you for looking into it in any case! &mdash; Lord_Farin (talk) 06:54, 26 October 2017 (EDT)


 * Thanks for the feedback. Still, while there are redirects, it takes a few clicks to find them, which, apparently (and understandably), is too cumbersome for the average contributor.
 * As for refactoring, I don't think I understand "I am assuming here that a rename will also affect any and all subpages [...]" - the idea is to not use subpages anymore (except
 * I don't expect MediaWiki to create an extension for such navigation, as it is already possible with LST, I believe. I'd like to learn more about our own extension, although I don't think it is needed here. --barto (talk) (contribs) 07:24, 26 October 2017 (EDT)
 * Confirmed, LST suffices for the improved version: User:Barto/Sandbox/nav/2. --barto (talk) (contribs) 08:21, 26 October 2017 (EDT)


 * Well, regardless of whether it is a subpage or not, if we are transcluding onto Definition:Continuous Real Function the page Definition:Continuous Real Function at Point, then I assume that any rename of the former will naturally lead to a rename of the latter (by application of the same principle). Moreover, dropping this principle would open us up to losing consistency in naming (because the rename need not be consistently applied). But maybe you see this differently; if so I would like to hear an example.
 * As to LST, I was referring to its functionality as a whole, which makes the transclusion mechanism more flexible. We very much have a need for this with our deep transclusion practices (which can sometimes call for distinct subsections of pages to need transclusion, e.g. when transcluding to overview pages). This is where the need for our own, more versatile extension sprouted, see Help:ProofWiki Extension for how it works.
 * With regard to the extension I was mentioning, please be aware that it is perfectly possible to create a MediaWiki extension of your own. We don't have any dependency on MW here, I just imagined that it would help us if something like this would be included in the backli nk structure of subpages, instead of relying on a specific cumbersome application of LST, with the MW version sitting besides it to confuse the reader.
 * From a practical perspective, since the PW extension and LST both use the  tag, I fear there is a breaking incompatibility at work. &mdash; Lord_Farin (talk) 12:03, 26 October 2017 (EDT)


 * About the renaming: that's true, and the renaming job would be less efficient. But. :) It seems to me that most of the times such a page is renamed, it's either because (*) it has an ambiguous title or (*) something is wrong with the subpage hierarchy. What I want to say is, and I may be naive, I think a page with a title like Definition:Continuous Real Function at Point will never have to be renamed, with the hierarchy being independent of titles. (Okay, yes, there's always the possibility that someday a majority will prefer "Continuity of Real Function [...]". But hey, if we're talking about aesthetics, "Continuous Mapping/Real Function[/...]" isn't better :) In any case, "never" can safely be replaced by "much less often".) --barto (talk) (contribs) 13:52, 26 October 2017 (EDT)


 * It's only when someone decides to stride in and rename everything for reasons not completely understood that we have these renaming exercises in the first place.


 * As was established early on in the life of, there are multiple names for concepts, and different approaches that can be made. Having settled on one approach, and decided on a particular direction to come from, it was expected that this would be what it would be. It makes no sense at all just to arbitrarily rename and restructure everything. Yes, arbitrarily. --prime mover (talk) 16:12, 26 October 2017 (EDT)
 * I have worked out an example here to let you taste: Definition:N-Ary Operation Induced by Binary Operation.
 * It uses the ProofWiki transclude extension. You only have to give the title of the parent page.
 * Makes it very comfortable to restructure. No danger for links to subpages. --barto (talk) (contribs) 07:41, 27 October 2017 (EDT)

Okay so I've looked at Definition:Indexed Iterated Binary Operation, and I need to ask: do we really need to add all that stuff at the top of the page complete with all those "includeonly" and "noinclude" tabs and two "section" sections? Nope, no way.

Can you explain again why this is better than making Definition:Indexed Iterated Binary Operation a redirect to a structured hierarchical page in the manner fully supported by the MediaWiki software itself? --prime mover (talk) 09:46, 27 October 2017 (EDT)


 * I refer you to "Pros" in the beginning of the section, or the last line just above your comment. No need to repeat it. --barto (talk) (contribs) 10:01, 27 October 2017 (EDT)


 * Are those really pros?
 * "Prevents using direct links to subpages" -- that's not necessarily a pro, sometimes you might want to make a direct link to a subpage.
 * "Page titles become neater" -- what do you mean, "neater"? Clarity is always to be preferred over neatness -- and slash-separated page names make it completely clear what the hierarchy of page names is.
 * "hierarchy is easily changed" -- there's only one person here insistent on changing the hierarchy, and I for one do not want to make this easy, under any circumstances, for blindingly obvious reasons.


 * Now, can you find me some pros?


 * As for the heavy syntax, that's indeed unfortunate, and is probably the best reason not to implement it now. I'm planning to file a request at Phabricator to improve the functionality of LST, in a way that would allow to do this with a single template, as in  --barto (talk) (contribs) 10:06, 27 October 2017 (EDT)
 * Fun fact: the aspired version of LST would also allow to automatically populate, for each book, a page with links to all pages on ProofWiki where it is cited, in the same order as the results appear in the book. Without any changes to the wikitext (thanks to prev & next)). I.e. a detailed online version of it. --barto (talk) (contribs) 10:35, 27 October 2017 (EDT)

Nope, I can't live with it. Not at all. --prime mover (talk) 12:35, 27 October 2017 (EDT)


 * Some more cents: I agree with PM that the redirects take adequate care of the cry for "readable" page titles. I was thinking that the only thing that could sway me in favour of this mountain of work would be a solution to the issue that we might want the same page to be transcluded on more than one page (one of the things our extension addresses). But then if the hierarchy is still defined to have a single parent, we have no benefit over using the built-in subpage hierarchy.
 * If you manage to find a way to address that, then we might have something worthwhile that I would call a real "pro". Until then, I would call the suggested solution unpractical -- it would be more efficient to extend MW so that the displayed title can be one of the redirects to the page; such would solve the problem the same way, but without having to tamper with our existing pages in any way.
 * Again, thanks for your investigation, but it would just be too much work, and actually additional idiosyncrasy in the PW approach to MW as opposed to using the standard redirect functionality. I doubt this will increase usability for people... &mdash; Lord_Farin (talk) 12:58, 27 October 2017 (EDT)


 * "If you manage to find a way to address that" - I'm not sure here what you mean by "that", is it pages with multiple parents? The navigation template could allow that, yes (it could make recognize common ancestors and merge subtrees in one tree or whatever; design is not the problem).
 * It is already possible to change the displayed page title to whatever you want, see &#36;wgRestrictDisplayTitle. Note also "[...] it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it.", a convention that PW already violates by disrecommending direct links to subpages. --barto (talk) (contribs) 13:37, 27 October 2017 (EDT)
 * Allthough I do think &#36;wgRestrictDisplayTitle=false is a good start. --barto (talk) (contribs) 13:41, 27 October 2017 (EDT)


 * I'm done arguing. --prime mover (talk) 13:40, 27 October 2017 (EDT)
 * arguing? brainstorming :) --barto (talk) (contribs) 13:48, 27 October 2017 (EDT)

The end of MathJax?
I just saw that the MathJax extension at MediaWiki has been archived: mediawikiwiki:extension:MathJax. Not sure what it implies. Are we using that extension or an independent one? --barto (talk) (contribs) 04:41, 27 October 2017 (EDT)
 * We're using that one with a few fixes. See https://github.com/ProofWiki/mediawiki-mathjax --Joe (talk) 12:19, 30 October 2017 (EDT)

Presenting generalizations, special cases
Hi, I've been experimenting a bit with how to mention generalizations and special cases on a page (definition page, mostly). See for example Definition:Summation/Finite Set: I created subsections in the "Also see" section, presenting a generalization as It is a somewhat terse style, but I like it, as it tells you everything you need to know, and I think it fits the general writing style on ProofWiki. Same for the reverse phenomenon, with links in both directions. Comments? Should the headings be level 4 instead of 3? --barto (talk) (contribs) 04:44, 31 October 2017 (EDT)
 * Definition:Generalization, as shown at Proof that it is a Generalization