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

## Archives

Archive 1 |

## Archive

I have created Archive $18$.

Steady as she goes, Mister Shoeless. --prime mover (talk) 15:19, 2 January 2024 (UTC)

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

- Thank you to Usagiop who had identified a workround: you can fix it by removing the

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

- Please when you do this, please start a new line and

- 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
*)$*

- $(\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)

- What would be good would be to have a macro, say

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

- There appears to be two naming conventions in use. One that calls the adjoints

- 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}`

.

- The $\LaTeX$ code for \(\upperadjoint {\mathbf J}\) is

- or:

- The $\LaTeX$ code for \(\upperadjoint f\) is
`\upperadjoint f`

. - The $\LaTeX$ code for \(\loweradjoint f\) is
`\loweradjoint f`

.

- The $\LaTeX$ code for \(\upperadjoint f\) is

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

- Of course, a simple answer is to add an extra \\ in there. Duh.

- $\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}$

- --prime mover (talk) 22:28, 16 May 2024 (UTC)

## nowiki tags for $\LaTeX$ by default?

Can we add something to the renderer so it's the default policy to nowiki everything between math delimiters?

Otherwise I can add nowiki by default to the eqn template without any trouble, on the condition that somebody alert us immediately they see something wrong.

In the meantime, there are two favoured techniques for fixing this stuff:

- Remove the leading indenting colon from a complex multiline expression (cases, matrix, array etc.) and putting \quad as the first thing in the code to indent it there instead

- Writing it all on one line by removing line breaks. This is good for simple cases, but for more complicated stuff the formatting on the page is important for comprehension.
- If this is the preferred method of improvement, please leave spaces between each "morpheme" so to speak (see examples of recent changes to see what is meant). Consistency and simplicity of visual presentation are of profound importance in its ability to teach.

- If the problem is two adjacent apostrophe characters (MediaWiki seeks to interpret this as a command to start rendering in italics), the quickest and easiest thing to do is insert a space between each '' in all your $\LaTeX$. Or use
`\prime`

which unfortunately can bloat the code.

- We do now have a
`<nowiki></nowiki>`

edit tool: just select the code you want nowikied and press that tag. Hey presto. This should cure everything but alert me (or I'll find it) if anything goes wrong. --prime mover (talk) 22:20, 16 May 2024 (UTC)

## Bot attacks are back

Please see the Special:ConfirmAccounts page where the bots are active again. --prime mover (talk) 00:59, 19 May 2024 (UTC)

## Location of the $\LaTeX$ definitions

I see in the discussion about the upper and lower adjoint commands that the definitions for them were visible, with the edited page appearing in Special:RecentChanges. It has been too long, however, so I can no longer see the edit in question. Was that in reference to Symbols:LaTeX_Commands? If so, are the actual definitions, as passed to MathJax, available anywhere? (Also, the link to the MathJax documentation in Symbols:LaTeX_Commands appears to be dead.) --Thuna (talk) 09:03, 24 May 2024 (UTC)

- I'm not sure I understand the question. Symbols:LaTeX Commands/ProofWiki Specific available from the menu on the left includes the documentation on how to use
`\upperadjoint`

and`\loweradjoint`

. Beyond that, what do you need to know?

- I take the point about the dead link. We will need to address that at some stage. --prime mover (talk) 11:09, 24 May 2024 (UTC)

- I write my own notes using the proofwiki notations so I was looking for a quick way to keep my
`sty`

files in sync with proofwiki. I am aware that all the in-house definitions are specified in Symbols:LaTeX_Commands/ProofWiki_Specific but as far as I can see there is no non-laborious way to convert that into something actually usable locally. --Thuna (talk) 11:25, 24 May 2024 (UTC)

- I write my own notes using the proofwiki notations so I was looking for a quick way to keep my

- This is where they are defined: MediaWiki:MathJax.js -- is that what you are after? --prime mover (talk) 12:09, 24 May 2024 (UTC)

- In case anyone's interested, here's some naive elisp code to extract the source of MatchJax.js into $\TeX$ definitions, the comments included. This is the resulting file (with the triple-backslash fixed). --Thuna (talk) 23:03, 24 May 2024 (UTC)

- Good job. --prime mover (talk) 08:48, 25 May 2024 (UTC)

- So it is. Don't know what happened there. That has worked in the past. --prime mover (talk) 23:40, 24 May 2024 (UTC)

## Amusingly anagrammatic

## Proposed changes to Template:TFAENocat and Template:TFAE

I am proposing that the Template:TFAE is enhanced to allow the 'equivalence' to be changed to something other than logical equivalence. For example, topological equivalence.

I will be adding two more parameters:

**equiv**to specify the equivalence page that will be linked**equivview**to specify how the link will appear

The default of course will be logical equivalence if the parameter **equiv** is not specified.

You can view the proposed changes on these pages:

Various uses of the changed template can be seen here: User:Leigh.Samphier/Template Testing and an example of the template in actual use can be seen here: User:Leigh.Samphier/Topology/Topological Equivalence of Definitions of Spectrum of Locale

My only concern is whether it is desirable to have non-logical equivalences added to [[Category:Definition Equivalences]]? --Leigh.Samphier (talk) 10:21, 30 July 2024 (UTC)

- I like the strategy, but like you I have problems with the category going into [[Category:Definition Equivalences]]. Suggest another (optional) parameter which allows variations of this, i.e. in this case the proof going into [[Category:Topological Equivalence]] or whatever the relevant category name is. We can always rename and/or restructure categories for $\mathsf{Pr} \infty \mathsf{fWiki}$ style and content consistency as need be. --prime mover (talk) 13:48, 30 July 2024 (UTC)

- Ok, i'll add another parameter
**cat**to allow the cateogory in Template:TFAE to be something other than [[Category:Definition Equivalences]], defaulting to [[Category:Definition Equivalences]] if not specified.

- Ok, i'll add another parameter

- It will be independent of the other parameters, allowing the category to be changed on any use of the template. --Leigh.Samphier (talk) 22:14, 30 July 2024 (UTC)

- This looks good, as in: it's how I would have done it. :-) --prime mover (talk) 09:46, 31 July 2024 (UTC)

- I've now applied the changes, If anyone notices a problem with the templates, let me know and I'll back out the changes and sort out the issue. --Leigh.Samphier (talk) 11:02, 31 July 2024 (UTC)

- Late to the party, but if you want to change it all, should there not be a simple alternative template name, like TFAETop? — Lord_Farin (talk) 21:21, 9 August 2024 (UTC)

- Point taken. --Leigh.Samphier (talk) 13:53, 15 August 2024 (UTC)

- I've backed out the changes after checking that there were no uses of the new features other than those in my unpublished pages. --Leigh.Samphier (talk) 14:17, 15 August 2024 (UTC)

## New macro

Would be great to get something like $\operatorname{EssRng}$ (analogous to $\Rng \cdot$) for Definition:Essential Range/Resolution of the Identity. Cheers. Caliburn (talk) 23:21, 14 August 2024 (UTC)

- Seems a bit specialised. How much do you anticipate it being needed? --prime mover (talk) 14:51, 15 August 2024 (UTC)

- We'd do well to come down a bit closer to Earth and put in those basic definitions that at the moment only have their definitions for a rather more specialised context than that rather more general concept.

- While it is probably the case that you are concentrating on a particular branch of whatever it is you are involved on, it may be better to try to establish that more general context first, then it may turn out that the more specialised definitions are no longer needed as such, because the definition is "the same" as it is in the more general context. This has happened before in a different context.

- Hence the results may become more accessible and easier to get one's head round. --prime mover (talk) 15:57, 15 August 2024 (UTC)

- I can definitely put up a page for the scalar case. The problem is that while "resolutions of the identity" (I'll just call them projection-valued measures) are entirely analogous to scalar-valued measures, they are not really the same. While I can say that $E \subseteq E'$ implies that $\map \EE E \le \map \EE {E'}$ for a projection-valued measure $\EE$ as well, what $\le$ means here is completely different, being in the sense of Definition:Canonical Preordering of C*-Algebra which just happens (well, it's basically because of Gelfand-Naimark) to behave a lot like ordinary inequality of $\R$. E.g. if $\map \EE A \le 0$, you still have $\map \EE A = 0$ and etc. So what's going to end up happening is that we'll have sometimes very similar looking pages for the scalar and projection cases, but when you go and click through the definitions and justifications you'll find that they are actually meaningfully different. Don't see a way around it and no undergrad will need to look at the projection-valued case basically. Caliburn (talk) 16:18, 15 August 2024 (UTC)

- Question 2: considering we have deprecated the term "range" on $\mathsf{Pr} \infty \mathsf{fWiki}$ on the grounds that it's ambiguous as to whether it's supposed to mean "image" or "codomain", it might be better to go with the Wikipedia convention and call it the "essential image", along with the appropriate "also known as" sections as per standard. We will of course obviously need to correlate this with the literature. --prime mover (talk) 17:18, 15 August 2024 (UTC)

## Multiple proofs

I've had this question for a while. Sometimes I know one way to prove the forward direction of an implication, and two ways to prove the other. Our current format of having Proof 1, Proof 2, etc. would see us reprove say, the Necessary Condition but then substitute an alternative proof of the Sufficient Condition. For example, on this page Characterization of Positive Bounded Linear Operator on Hilbert Space, the way I prove the necessary condition is basically the canonical way, but for the sufficient condition there's a few different ways you can approach it. How should I implement that? Let me know if this needs clarification. Caliburn (talk) 19:25, 16 August 2024 (UTC)

- Oh I can just do separate subpages for necessary and sufficient condition... right? Caliburn (talk) 20:04, 16 August 2024 (UTC)
- That's how I've tended to do it. Fiddly to get the structure workable, but there are multiple examples to use as paradigms. --prime mover (talk) 20:30, 16 August 2024 (UTC)

## Further improvement to proof structure

I have added a new template `{{Recall}}`

.

It can be seen in action (so far) in Uniform Prism is Uniform Polyhedron and Platonic Solid is Uniform Polyhedron.

It can be hoped that this technique may streamline a lot of the boilerplate, and make it easier for us to implement proofs to a standard pattern.

Comments? --prime mover (talk) 08:07, 17 August 2024 (UTC)

- I like the idea, saves you some time clicking back through the definitions yourself. My question is, should old proofs that essentially used this template "manually" be changed to using the template? I'm asking because I just came across this Norms on Finite-Dimensional Real Vector Space are Equivalent, which begins with such a recall. --Ilithios (talk) 14:15, 19 September 2024 (UTC)

## Graphics

What is the house-style/wiki policy on using graphics in proofs? Only when absolutely necessary/dedicated graphics article? When useful/desired?

(Apologies if this has been asked before. Is there a way to search the main page talk archives?) Tule-hog (talk) 20:00, 2 September 2024 (UTC)

- The archives are at /Archives. I think any and all graphics/diagrams that aid the understanding of the theorem statement, definition or proof are welcome if not encouraged. I would say we probably don't have enough. Just be careful not to add diagram dependence (drawing the diagram in a particular way which causes loss of generality) or similarly handwave details as "obvious by diagram", we wouldn't want either of those things. Caliburn (talk) 20:11, 2 September 2024 (UTC)
- I recommend GeoGebra for basic stuff. It allows for a more uniform look and feel. Graphics done using different tools tend not to look anywhere near as good. --prime mover (talk) 20:46, 2 September 2024 (UTC)

## Currently pending account request

Would it be classified as spam? Advice needed. --prime mover (talk) 19:37, 19 September 2024 (UTC)

- Seems legit to me. --Joe (talk) 19:39, 19 September 2024 (UTC)
- Let's bring him on board then --prime mover (talk) 19:44, 19 September 2024 (UTC)

- That remeinds me. I added one of those CloudFlare "are you a bot" checks when someone goes to the registration page a few days ago. Hopefully it will help cut down on spam. --Joe (talk) 19:43, 19 September 2024 (UTC)
- TBH it's not been too bad recently. --prime mover (talk) 19:44, 19 September 2024 (UTC)