User:Barto

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


 * Discussion on hosting moved to talk:Main Page --barto (talk)

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  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   template, as in , instead of adding a line  . 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. &mdash; 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)

Asymptotic notations
See the project page User:Barto/Asymptotic Notation

Properties

 * $O$ and Taylor-expansion of (real) analytic functions
 * Substitution of estimates:
 * Substitution in Big-O Estimate
 * Integration of $O$ and $o$-estimates
 * Mention uniform-$O$ conventions:
 * Definition:Uniform Big-O Estimate
 * Differentiation of $O$-estimates

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)

Modules

 * Make a page (or at least a transclusion) for Definition:Module Homomorphism. Note that there is Definition:Linear Transformation, Definition:R-Algebraic Structure Homomorphism and Definition:Isomorphism (Abstract Algebra)/R-Algebraic Structure Isomorphism where module isomorphisms are defined.

Direct Product and Direct Sum
and the naming of those subdefinitions should be consistent: Finite Case, General Case or something like that.
 * 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)


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

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

 * Definition:Basis (Linear Algebra): refactor definitions; show equivalence; add definition using Definition:Free Module on Set
 * Definition:Dimension (Linear Algebra): mention that it is well-defined, with reference $\checkmark$
 * Definition:Ordered Basis
 * Unitary R-Modules with n-Element Bases Isomorphic
 * Isomorphism from R^n via n-Term Sequence
 * Unique Representation by Ordered Basis

Support

 * Elements with Support in Ideal form Submagma of Direct Product: fix notion of ideal and link
 * Elements of Finite Support form Submagma of Direct Product same
 * Support of Product is Contained in Union of Supports How to organize?

Modules

 * Address the cardinality of a basis of a module $\checkmark$ see Bases of Free Module have Equal Cardinality
 * Define modules and unitary modules using Definition:Endomorphism Ring of Abelian Group, see Morphism to Endomorphism Ring Defines Module
 * Determining Definition:Multilinear Mapping using basises, use this in Definition:Monoid Ring
 * Correspondence between Definition:Multilinear Mapping and linear maps to Definition:Module of Multilinear Mappings.

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


 * $P$ has no multiple roots in $R$.
 * $P$ and $P'$ have no common roots in $R$.

Separable Polynomial
TFAE:


 * $P$ has distinct roots in some algebraic closure.
 * $P$ has at least $n$ distinct roots in some algebraic closure.
 * $P$ has at exactly $n$ distinct roots in some algebraic closure.
 * $P$ has no multiple roots in some algebraic closure.


 * $P$ has distinct roots in some field extension where $P$ splits
 * $P$ has $n$ distinct roots in some field extension where $P$ splits
 * $P$ has no multiple roots in some field extension where $P$ splits


 * $P$ has distinct roots in every field extension where $P$ splits
 * $P$ has $n$ distinct roots in every field extension where $P$ splits
 * $P$ has no multiple roots in every field extension where $P$ splits


 * $P$ has distinct roots in every field extension
 * $P$ has no multiple roots in every field extension

etc..

Interesting selection:


 * $P$ has at least $n$ distinct roots in some field extension.
 * $P$ has exactly $n$ distinct roots in every field extension where $P$ splits
 * $P$ has no multiple roots in every field extension
 * $\gcd(P,P')=1$ in $K[X]$.

to be continued

Definition-level

 * Support of Product is Contained in Union of Supports


 * Free Module Indexed by Set is Free
 * Canonical Basis of Free Module Indexed by Set is Basis
 * Endomorphism Ring of Abelian Group is Ring with Unity $\checkmark$
 * Module of Homomorphisms between Modules is Module
 * Monoid Ring is Ring


 * Universal Property of Free Modules
 * Universal Property of Direct Product of Modules
 * Universal Property of Direct Sum of Modules
 * Universal Property of Monoid Ring

Spaces of Morphisms

 * Definition:Dual Module
 * Definition:Group of Homomorphisms Between Abelian Groups
 * Definition:Endomorphism Ring of Abelian Group
 * Definition:Module of Homomorphisms Between Modules
 * Definition:Module of Multilinear Mappings
 * Definition:Endomorphism Ring of Module
 * Note that there is already a general Definition:Group of Automorphisms for algebraic structures with one operation.

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.