User:Barto

From ProofWiki
Jump to: navigation, search

Random

caveat. Any perceived negative feelings in my communication are misinterpreted enthusiasm, partly due to poor word choice from a limited vocabulary. I try not to let my mind trick me into making the same mistake!:)

Heading

My mission at ProofWiki: Introducing rigor where it's missing, choosing better page names, looking for ways to expand the community, refactoring, connecting pages with relevant links in the also see section, or by organizing pages using transclusion.

(talk | contribs | sandbox | iw map | common.css | common.js)


My philosophy:

  • Transparency. Every proof of more than ~ 20 lines should probably be preceded by an Outline of Proof. The level of detail at ProofWiki is otherwise way too high to quickly understand what's going on. Just a very simple overview may make it 10 times as easy to read the proof, no exaggeration. $\mathsf{Pr} \infty \mathsf{fWiki}$ can be a very qualitative and even more unique source with both outlines and fully detailed proofs.
  • Coherence. When writing a proof, look if part of it has already been proved elsewhere. If there are two proofs doing the same reasoning to arrive at an intermediate result; consider placing that result in a separate page (either as Theorem or Lemma). Long proofs are difficult to read, especially in the style they are presented at ProofWiki. Linking to other articles allows, if this makes the proof shorter, for a global view and quicker understanding.
If a proof is too long, it needs more lemma's.
  • Connecting pages. Aside from the usual links, I try to add at least one link in the Also See section. This allows us to guide visitors to related or more interesting results. -- Just don't go too mad. Try to make it so that "Also see" contains only items that are immediately relevant. We already have a "What links here" option, and at least one Category. The danger is that this section can soon become bloated and distracting. -- Yes, true. Of course if I don't find any relevant pages, I don't add any. Thanks for the feedback.


Ideas for the ProofWiki community

  • Make proofwiki popular and more known using some kind of blog (e.g. put the facebook page to use)
I tried to set up a blog but I was told I wasn't allowed to. So I stopped.

Ideas to improve structure and appearance

  • A namespace for algorithms
  • (bad idea) An idea to make pages more neat and appealing: Add a templates to include hidden notes containing material such as:
    • Links to definitions (instead of cluttering the page with things like "Where $\cup$ denotes union" The "clutter", as you call it, is essential. Leaving the concepts undefined is not acceptable. So until someone designs some "hidden notes" template, we must include the links to the appropriate definitions. Until that time, the fact that this may be unappealing to you is regrettable but unavoidable.
    • Links to more trivial results being used (to avoid cluttering the page of a more advanced proof with links to elementary results that are still worth mentioning, but not worth taking space).
Those hidden notes would show upon clicking and disappear when clicking again. Or when hovering, and disappear when moving the mouse away.
  • (Improvement of the above idea) When you ask something to WolframAlpha, such as solve sin(x)=2 it will show a note on the right for any new symbol appearing in the solution. This made me think we can do something similar: placing notation explanations in a column somewhere on the right. This could be achieved using some sort of {{Notation}} template, as in {{Notation| $\sin(x)$ is the [[Definition:Sine Function|]]}}, instead of adding a line where $\sin(x)$ is the [[Definition:Sine Function|]]. It may be argued that one of those makes the page look more neat. It's hard to say which, as I don't know what the new suggestion looks like. I'll try an example someday.
2 immediate reasons why I'd be wary about doing this:
a) It would be a lot of work to go through the existing page and implement this style -- in the meantime the site would look inconsistent
b) If we add a column on the right, we lose considerable real estate on a page with such a right-hand column. Some of the pages are already quite wide, and splitting them down so as to make room for a bit of stylistic flam may compromise it. Then again, if we are then to hide that column and make it available on a click, you lose the flow of the argument of what you are reading.
So I remain to be convinced, me, but feel free to try something out if you think it could work. I am still a big fan of a linear flow down the page of a train of thought. If you have to keep referring to boxes elsewhere on the page, you end up with something like those infuriatingly irritating books which put boxes of text on the page in the middle of the flow of text, which is the worst ever design mistake which, I suppose, is supposed to try and make a work more accessible for submorons who have an attention span of a brain-damaged butterfly. --prime mover (talk) 04:46, 27 August 2017 (EDT)
An extra reason why I think it's important to be cautious with this: around 30% (and growing) of our traffic consists of mobile users. Admittedly these users would probably also profit from changes in other parts, but relying on left-right split is probably not a good idea... But maybe a separate setting for mobile and desktop is feasible. — Lord_Farin (talk) 05:59, 27 August 2017 (EDT)
Mobile users are certainly something to take into account. I also agree that it should not break the argument, which is why I think it should only be used for defining notations, as does W/A. For example, in proofs about more advanced topics, users may be bothered by having to read definitions for every symbol such as $\gcd$, divisibility, $\Vert\cdot\Vert$, Euler $\phi$, ... It makes proofs look longer than they are and, ironically, can be argued to break the flow of the argument as well. Either way, it's still unclear what it would look like (small/large font, ugliness) and how much space it will take up. I will leave the idea here so it can be revisited someday, and try some examples in my sandbox. --barto (talk) 06:40, 27 August 2017 (EDT)
Notations should usually be defined upfront, as it would be usual to encounter them in the statement of the theorem. There may be exceptions, where a notation is encountered in the middle of a proof, but they will be rare. and anyway, defining 5 things as they are encountered adds 5 lines to a proof, which does not bulk it out that much. I wonder if you may be trying to solve a problem that isn't there -- unless there is a specific example which you can point to which needs to be improved. --prime mover (talk) 06:48, 27 August 2017 (EDT)

Projects in Analysis

Asymptotic notations

See the project page User:Barto/Asymptotic Notation

Properties

Infinite Products

  • Convergence and analyticity of analytic products $\checkmark$
  • Logarithmic derivatives and analyticity $\checkmark$
  • Goal: A treatment of Factorization of Analytic functions, including full versions of Weierstrass and Hadamard factorization. Apply this to e.g. the Gamma Function and deduce Stirling's Formula for complex arguments.
  • Difficulty: this needs a proper set of definitions of asymptotic notations (see corresponding project)

Clean-up Projects in Abstract Algebra

Modules

Direct Product and Direct Sum

  • Make sure that the definition pages for direct products include a definition for arbitrary families. Ideally, there should be:
    • A definition for two components
    • A definition for a finite number of components
    • A definition for general families
    • (Optionally: a definition for countable families)

and the naming of those subdefinitions should be consistent: Finite Case, General Case or something like that.

  • For direct sums, the definition for general families should suffice.
  • Be consistent in naming pages:
    • product vs. sum: product is the primary notion, sum is derived from it. It is thus impossible to define the direct sum without defining the direct product; unless when they coincide and allow for ambiguous naming.
    • External vs. internal: If nothing is specified, external has to be understood. IMO external can be removed from titles; it's unnecessarily pedantic; though I could live with it if it stays.
    • Word order: (less important) Direct Product of X's vs. X Direct Product? I'm in favor of Direct Product of X's, and accordingly for sum, internal or not internal.
    • The following table shows the jolly inconsistencies (no, I didn't misplace the entries):
General Group Ring Module Vector Space
External Product Definition:External Direct Product Definition:Group Direct Product Definition:Ring Direct Product Definition:Module Direct Product
Definition:Module of All Mappings
Module on Cartesian Product
Definition:Direct Product of Vector Spaces
Vector Space of All Mappings
Vector Space on Cartesian Product
Sum Finite Submodule of Function Space Definition:Module Direct Sum
Internal Product=Sum Definition:Internal Direct Product Definition:Internal Group Direct Product Definition:Ring Direct Sum

Please, feel free to add missing entries. These are the only definitions I found so far (not including transclusions). Some definitions are still to be extracted from a theorem that's being refactored.

Dimension

Support

Actual Projects in Abstract Algebra

Modules

Separability

Multiple roots in a ring

Let $R$ be a commutative ring with unity and $P\in R[X]$ TFAE:

Separable Polynomial

TFAE:

etc..

Interesting selection:

to be continued

Wanted Theorems

Definition-level

Actual theorems

Wanted Definitions

Spaces of Morphisms

Other useful notions

Long Term Projects

  • Disambiguate between left and right modules. Does this mean that every occurrence of "module" should be amended? Very probably. The coverage of this is inadequate, as will be seen when we come to tensors.


Enhancing the Help Section

One of the things I like to do is expanding the Help Section. This is to avoid questions being brought up over and over, and discussions to be lost in the talk pages.

Do I think every single minor discussion point should be addressed in the Help Section? Yes.