Talk:Main Page

Welcome to the general discussion page of $\mathsf{Pr} \infty \mathsf{fWiki}$.
Please add any new discussion topics at the bottom of this page.

Alternative axiomatic systems

I've been considering doing some work on axiomatic geometries such as Axiom:Hilbert's Axioms or Axiom:Birkhoff's Axioms. However, I've been undecided on how to structure the pages for this. We already have a lot of geometry results from Euclid, and I'm hesitant to put these in as "alternative proofs," when they use subtly different definitions, etc. Sometimes, the proof is only even applicable to the single system.

My working idea is to a convention such as:

etc. I've noticed similar "use the page name while changing the namespace" tricks is a few places on this site, so this has precedent. It would also help ensure that we don't accidentally reference a result that hasn't been proven for this particular system. If it becomes desirable, we can of course transclude or link to them from the "main" page.

Any thoughts on implementing this convention? Any other options to consider? --CircuitCraft (talk) 03:40, 15 December 2023 (UTC)

No, do it like

and transcluded into the master page. --prime mover (talk) 06:51, 15 December 2023 (UTC)

Quotient: Page naming and distinctive terminology

Currently battling with how to name and categorise pages concerning the concept of quotient and its related concept partial quotient.

I have moved the existing "partial quotient" page to partial denominator as that's what it's named in the context of continued fractions. Then there is a disambiguation page Definition:Partial Quotient.

It remains to uniquely and generically come up with ways to differentiate the concept of a quotient as a result of division in the context of a field, in which the division is complete, and that as a result of an application of the Division Theorem in all its various applications: integers, polynomials, general Euclidean domains, etc.

Somewhere in there we will also need to establish the concept of a partial quotient in the concept of a long division, the main page of which still needs to be written. (This is of course an instance of the Division Theorem process, but still needs to be thought through.

Complicating this is that the term "partial quotient" only applies to the Division Theorem technique if there is a remainder. If the remainder is zero, it's not called a partial quotient.

Any ideas? --prime mover (talk) 15:28, 2 January 2024 (UTC)

We currently have Definition:Quotient (Arithmetic) and Definition:Quotient (Algebra) which as names are not all that useful.

The two contexts appear to be Definition:Field Theory and Division Theorem, so Definition:Quotient (Field Theory) and Definition:Quotient (Division Theorem) would provide greater clarity than Definition:Quotient (Arithmetic) and Definition:Quotient (Algebra) in my opinion. --Leigh.Samphier (talk) 22:48, 17 January 2024 (UTC)

I have a problem with Definition:Quotient (Field Theory) in that it is the definition used for basic real division which you do in school. Nobody in school knows what "field theory" is, so we run into the same issue we do on a regular basis, that is: losing the pre-University readers who will mistakenly think that they are out of their depth. --prime mover (talk) 22:14, 18 January 2024 (UTC)

How about Definition:Quotient (Division) and Definition:Quotient (Integer Division) for Definition:Quotient (Arithmetic) and Definition:Quotient (Algebra) respectively? --Leigh.Samphier (talk) 22:38, 18 January 2024 (UTC)

The simple and obvious answer is once again the best! Will take this on in due course. --prime mover (talk) 00:56, 19 January 2024 (UTC)

Server Offline Yesterday

Anomaly? Scheduled? Hacked? --Robkahn131 (talk) 00:06, 6 January 2024 (UTC)

Yes, it was out all this morning from at least 07:00 till about 13:30 GMT on 05-01-2024, and the same happened yesterday 04-01-2024 from about 10:00 to 13:45 GMT.

I sent an email to the admin asking if there was anything going on, but had no reply.

Has someone been taking an xml dump? --prime mover (talk) 00:14, 6 January 2024 (UTC)

Interesting date

For the first time in a year or two the digits are all even in the date.

Such dates form a Cantor dust.

Discuss. --prime mover (talk) 18:00, 2 February 2024 (UTC)

Page quality standards

Sorry, it's cropped up again. What's the general consensus, those who are around and active, on source code quality and maintainability?

Is the current regime too harsh, or is there a serious method to my insistence on a regular pattern?

I maintain that consistency and accuracy of pattern helps crystallise an idea in mind. The more structured the pattern, the easier the mastery. --prime mover (talk) 17:33, 23 March 2024 (UTC)

I don't find the current approach harsh. The expectations around structure are well thought out and are more flexible than you might first think. But you do have to overcome a natural resistance to creating pages. And you need to develop a way of working that means that you don't lose sight of what pages you have created / are working on.

Documenting maths proofs in the detail required is more onerous than what might be presented in a maths course or book, but thats the nature of what is being attempted. Every page on $\mathsf{Pr} \infty \mathsf{fWiki}$ can be an entry point to some maths topic for someone, and so this places a huge burden on every page. Its unavoidable.

I guess my question back to you, is what is being asked to be relaxed and why would we want to relax it? What is to be gained? --Leigh.Samphier (talk) 18:29, 23 March 2024 (UTC)

The consistently high quality of contributions from most regular contributors is testament to the fact that it is possible to learn the $\mathsf{Pr} \infty \mathsf{fWiki}$ presentation style and source code convention quite quickly. As mathematicians, it is expected that contributors (particularly younger ones) should have no trouble learning new stuff, and hence should be able to commit to this.

Either contributors cannot learn new stuff, which would be dismaying and regrettable, or they just don't want to, and believe that they are special enough and important enough for the house rules not to apply to them. My personal opinion on this matter is that while the first would be regrettable, the second is unacceptable. --prime mover (talk) 12:42, 24 March 2024 (UTC)

The quality of contributions of new users, (self included back in 2020), is not where it needs to be. We are all trying to co-create something valuable here. I would prefer we hold each other accountable. I am a fan of the current regime - call it like you see it. Some of us take some small measure of joy in reading the commentary. --Robkahn131 (talk) 18:57, 23 March 2024 (UTC)

Endorsed. --prime mover (talk) 12:42, 24 March 2024 (UTC)

CPU intensive operations

Twice this week at around 07:00 or 08:00 UDT, $\mathsf{Pr} \infty \mathsf{fWiki}$ has been failing to connect with a 502 or a 504.

Investigation shows that at this time the CPU was running at 100%.

Not sure what's causing this, but if anybody out there has been running a task which has been taking several hours to complete, like, for example, "Export Pages", or anything else along those lines, can you please fess up? --prime mover (talk) 11:28, 12 April 2024 (UTC)

I think it's a general issue with server capcaity, which I've now increased. Hopefully this should fix your issues. --Joe (talk) 19:13, 12 April 2024 (UTC)

Troubleshooting in progress

You may notice rendering problems with expressions whose source code spreads over multiple lines, as in Modulo Multiplication/Cayley Table/Modulo 6:

$\quad \begin{array} {r|rrrrrr} \struct {\Z_6, \times_6} & \eqclass 0 6 & \eqclass 1 6 & \eqclass 2 6 & \eqclass 3 6 & \eqclass 4 6 & \eqclass 5 6 \\ \hline \eqclass 0 6 & \eqclass 0 6 & \eqclass 0 6 & \eqclass 0 6 & \eqclass 0 6 & \eqclass 0 6 & \eqclass 0 6 \\ \eqclass 1 6 & \eqclass 0 6 & \eqclass 1 6 & \eqclass 2 6 & \eqclass 3 6 & \eqclass 4 6 & \eqclass 5 6 \\ \eqclass 2 6 & \eqclass 0 6 & \eqclass 2 6 & \eqclass 4 6 & \eqclass 0 6 & \eqclass 2 6 & \eqclass 4 6 \\ \eqclass 3 6 & \eqclass 0 6 & \eqclass 3 6 & \eqclass 0 6 & \eqclass 3 6 & \eqclass 0 6 & \eqclass 3 6 \\ \eqclass 4 6 & \eqclass 0 6 & \eqclass 4 6 & \eqclass 2 6 & \eqclass 0 6 & \eqclass 4 6 & \eqclass 2 6 \\ \eqclass 5 6 & \eqclass 0 6 & \eqclass 5 6 & \eqclass 4 6 & \eqclass 3 6 & \eqclass 2 6 & \eqclass 1 6 \end{array}$

This is currently being worked on (presumably). --prime mover (talk) 09:13, 13 April 2024 (UTC)

There have been no software changes recently. This is a new issue, presumably? --Joe (talk) 13:28, 13 April 2024 (UTC)

A while back (think it's in archive 18) there was a discussion about strange behaviour after a version change. Multiline $\LaTeX$ expressions ailed to render -- line breaks in the middle of an expression broked the parser, or something, so all multiline source code expressions had to be written with no line breaks.

When that was fixed, the menu headers broke when they contained $\LaTeX$ which compromised the rendering of lots of pages.

Now we are back in the same position we were where multiline $\LaTeX$ breaks, but $\LaTeX$ in headers now renders properly in the contents menu at the top of the page. --prime mover (talk) 22:28, 13 April 2024 (UTC)

Found it: Talk:Main Page/Archive 18#MediaWiki LTS Upgrade --prime mover (talk) 22:31, 13 April 2024 (UTC)

Thank you to Usagiop who had identified a workround: you can fix it by removing the : at the start of an offending line.

Please when you do this, please start a new line and \quad the beginning of the line? May have need of a template. Let me know of suggestions. --prime mover (talk) 14:12, 14 April 2024 (UTC)

A line that starts with a space within the latex fragment seems to break rendering as well. A template would be nice (although the ideal solution would be to keep the original syntax). --Thuna (talk) 16:31, 14 April 2024 (UTC)

We may surround LaTeX with <nowiki> tag, for example: Pullback Lemma --Hbghlyj (talk) 17:23, 17 April 2024 (UTC)

Whichever method you like. Many thanks to all who have been working on this. It's a dirty job but someone's gotta do it. --prime mover (talk) 17:40, 17 April 2024 (UTC)

At some stage soon I'm going to experiment with adding nowiki tags to the eqn template so as to fix a lot of things in one stroke. Not tonight, I'm about to go out. Sometime over the weekend, maybe. --prime mover (talk) 18:06, 17 April 2024 (UTC)

Also double prime breaks $\LaTeX$ expressions irrespective of whether they are on a single line or multiple lines.

The expression $(\text C 3'')$ renders as, e.g.:

$(\text C 3)$

rather than:

$(\text C 3'')$

Correct rendering can be achieved by surrounding the double primes with <nowiki> tag:

$(\text C 3<nowiki>''</nowiki>)$

Not sure if this is desirable, but it works. --Leigh.Samphier (talk) 09:05, 19 April 2024 (UTC)

Lower Adjoint and Upper Adjoint

Given a Galois connection $f$ the notation for the upper adjoint (or right adjoint) and the lower adjoint (or left adjoint) in the literature is $f_*$ and $f^*$ respectively.

So a Galois connection is the tuple $\tuple{f_*, f^*}$ where:

$f_*$ denotes the upper adjoint (or right adjoint)

$f^*$ denotes the lower adjoint (or left adjoint)

This notation:

(1) overuses '*' which is not preferred on $\mathsf{Pr} \infty \mathsf{fWiki}$

(2) is not at all suggestive of the names given to the adjoints

I was wondering if someone could create a couple of $\LaTeX$ macros for the notation of the upper adjoint and lower adjoint.

I haven't found anyone using an alternative notation, so I can't offer something else that isn't an invention of mine. But having macros would allow the notation to be changed in one place if that is ever is desired, and also it would be easier to get the notation correct given the lack of suggestivity. --Leigh.Samphier (talk) 10:50, 17 April 2024 (UTC)

I am not aware of better notation available for this problem. I do agree that we are at the distinct risk here to introduce a notation that will be idiosyncratic and will confuse even more than the asterisk would.

The issue for me is that the notation is not at all suggestive of the roles performed by the adjoints. I can only assume that there is some badge of honour amoungst those that are well-versed in the subject.

What would be good would be to have a macro, say \upperadjoint or something similar, when invoked as \upperadjoint f produced $f_*$. And a similar macro, say \loweradjoint, when invoked as \loweradjoint f produced $f^*$. This would go a long way to reducing the double checking I'm doing to ensure I have used the correct notation. --Leigh.Samphier (talk) 22:39, 17 April 2024 (UTC)

Although I don't posess that particular badge, it does seem fine to use the Galois-specific terms upper and lower adjoint, and use them in macros. Then there is minimal risk of confusion and we leave the road open for the category-theoretic concept in the future. — Lord_Farin (talk) 10:02, 18 April 2024 (UTC)

Somewhat related but relevant: category theory also has a specific meaning for adjoints, compare Definition:Adjunction. In some sense the Galois connection will be an example of this although I haven't studied the concept specifically.

It might therefore be relevant in due time to consider to refer to the Galois concepts as "lower Galois adjoint" instead of simply "lower adjoint". — Lord_Farin (talk) 13:23, 17 April 2024 (UTC)

I'm going to defer to those who know more about this than me. I probably have loads about it in the various books I have, but I haven't studied. --prime mover (talk) 17:35, 17 April 2024 (UTC)

This is not the can of worms I was looking to open. It may be an issue, I'm not sufficiently knowledgeable to comment.

There appears to be two naming conventions in use. One that calls the adjoints upper adjoint and lower adjoint and those that use right adjoint and left adjoint. The latter appears to be the convention used by those steeped in Definition:Category Theory because a Galois connection is an Definition:Adjunction when the ordered sets are viewed as categories, and is what is used by the two sources that I have. It's not clear to me which of the naming conventions is the more favoured.

I'm not looking to change the naming convention in place on $\mathsf{Pr} \infty \mathsf{fWiki}$ as it will take me even further away from my goal of completing the Stone-Cech Compactification Theorem. --Leigh.Samphier (talk) 22:39, 17 April 2024 (UTC)

I know that was not the aim, but we should not take a decision that ends up having adverse effects down the line; therefore I wanted to mention it. With the suggestion above we will be fine. — Lord_Farin (talk) 10:02, 18 April 2024 (UTC)

These are the macros I want to create:

\def \upperadjoint #1{#1_*}$\def \upperadjoint #1{#1_*}$

\def \loweradjoint #1{#1^*}$\def \loweradjoint #1{#1^*}$

How do I get these added? Is there somewhere that I can add them? --Leigh.Samphier (talk) 08:25, 19 April 2024 (UTC)

I've added them. Please see recent edits for details of what I did.

The $\LaTeX$ code for $\upperadjoint {\mathbf J}$ is \upperadjoint {\mathbf J} .

The $\LaTeX$ code for $\loweradjoint {\mathbf J}$ is \loweradjoint {\mathbf J} .

or:

The $\LaTeX$ code for $\upperadjoint f$ is \upperadjoint f .

The $\LaTeX$ code for $\loweradjoint f$ is \loweradjoint f .

Feel free to study the file in question. The syntax is straightforward but may need to be thought about. I believe you have the appropriate access rights to play with it. --prime mover (talk) 08:56, 19 April 2024 (UTC)

Thanks, I'll look at your changes. --Leigh.Samphier (talk) 09:07, 19 April 2024 (UTC)

For some reason I can't get $\upperadjoint f$ or $\loweradjoint {\mathbf J}$ and so on to render properly in the wild. I need to revisit it. --prime mover (talk) 09:12, 19 April 2024 (UTC)

... ah, got it. --prime mover (talk) 09:14, 19 April 2024 (UTC)

I can edit Symbols:LaTeX Commands and subpages, but not MediaWiki:MathJax.js --Leigh.Samphier (talk) 09:54, 19 April 2024 (UTC)

Okay, thanks. At the moment I'm going to leave things as they are. The danger of overloading the list of macros is something I need to be aware of. --prime mover (talk) 11:37, 19 April 2024 (UTC)

Good job well done. --prime mover (talk) 11:37, 19 April 2024 (UTC)

Improvement of presentation of "cases" environment

The construct \begin {cases} ... \end {cases} is part of the $\LaTeX$ package. However, when rendering displaystyle entities, e.g. $\dfrac a b$, the lines could do with being separated out a little.

This can be done manually, by adding a spacer in between them (I think either Usagiop or Hbghlyj did this recently, can't remember which).

We don't want to have to do this by hand, though, we want to amend the rendering of the existing \begin {cases} ... \end {cases} code to automatically add a small gap between them, so as to space it out in accordance with the way we do this in the {{eqn}} template. (Wider spacing makes things easier on the eye, in general).

Any of you boffins know how this would be done?

Here is an example of what I mean:

$\ds \int_0^\infty \frac {\sin p x \sin q x} {x^2} \rd x = \begin {cases} \dfrac {\pi p} 2 & : 0 < p \le q \\ \dfrac {\pi q} 2 & : p \ge q > 0 \end {cases}$

from Integral to Infinity of Sine p x Sine q x over x Squared.

A larger vertical gap would improve its rendering greatly. --prime mover (talk) 09:26, 19 April 2024 (UTC)

Talk:Main Page

Contents

Archives

Archive

Alternative axiomatic systems

Quotient: Page naming and distinctive terminology

Server Offline Yesterday

Interesting date

Page quality standards

CPU intensive operations

Troubleshooting in progress

Lower Adjoint and Upper Adjoint

Improvement of presentation of "cases" environment

Navigation menu

Talk:Main Page

Archives

Archive

Alternative axiomatic systems

Quotient: Page naming and distinctive terminology

Server Offline Yesterday

Interesting date

Page quality standards

CPU intensive operations

Troubleshooting in progress

Lower Adjoint and Upper Adjoint

Improvement of presentation of "cases" environment

Navigation menu

Search