User talk:Barto

Splitting Theorem and Definition
Thanks for your work on Definition:Z-Module Associated with Abelian Group, it was long overdue.

In the future, please take care to duplicate any sources listed on the original integrated page on both resultants, and flag them with Template:SourceReview. This way, we can ensure to continue representing the content of said sources as faithfully as possible.

If applicable, please also attend to any links to the page via "Tools -> What links here" in the sidebar menu. They might have to be updated to the new definition. &mdash; Lord_Farin (talk) 16:46, 5 December 2016 (EST)


 * I'll keep it in mind.--barto (talk) 03:24, 6 December 2016 (EST)


 * Also please note the wording of the SourceReview template, with particular reference to the word "following". It is how we distinguish between sources which have been reviewed and those we have not. --prime mover (talk) 06:56, 6 December 2016 (EST)

Consistent naming
Thank you for taking the time and effort to improve the structure of this area -- it is long overdue.

The reason for inconsistent naming between e.g. direct product of groups and direct sum of rings is purely as a result of the source works that the material came from.

The definition namespace of was conceived more or less as a dictionary of existing usage, and as such we make the effort to stick to what is found in the source works which are plundered to provide material. If it just so happens that the source work used uses "sum", then that, by default, is what was taken.

So I don't think there are problems with renaming Ring Direct Sum to Ring Direct Product, and I don't think there are many pages that would need to be changed to accommodate it. As is our usual technique, we can of course use "Also known as" to explain the differences in terminology.

As for removing "external" from all "external direct product" pages -- again, I think that should be okay. I was specifically using "external" as opposed to "internal" as I had trouble with this when first studying group theory and I needed to make sure I was very sure what was being discussed -- particularly when I was battling with the Internal Direct Product Theorem -- but now I look back on it, I think we would be okay to just use "Direct Product" for what is now "External Direct Product", using an "also known as" section to explain the alternative terms. --prime mover (talk) 06:53, 17 December 2016 (EST)


 * Thank you for your assistance! Indeed, because for finite families they coincide, different authors may (rightfully!) use different names if they do not consider the infinite case. As for External: While I do prefer "Direct Product" over "External Direct Product"; I would not mind if page names include "External" as long as there are appropriate redirects to them. As for Internal Sum vs. Internal Product: Both are used and mean the same (at least for groups, rings, modules). Naturally, sum is reserved for the commutative case; that is, for modules (and vector spaces), while product is used in the non-commutative case (so more fitting for groups and rings). The reason we do not make a distinction between internal direct sum and internal direct product is that within a structure, we cannot take infinite sums/products --barto (talk) 07:07, 17 December 2016 (EST)


 * You seem to have a far better handle on this than me, who, since my MMath, my entire knowledge is self-learned and haphazard. Feel free to go ahead, as you know where the devils are in the details. --prime mover (talk) 07:10, 17 December 2016 (EST)


 * Before we start renaming pages: do we go for X Direct Product (as in Definition:Module Direct Product and many others) or Direct Product of X'es (as in Definition:External Direct Sum of Rings and Product of Vector Spaces )? Are there cons of Direct Product of X'es besides alphabetic ordering? --barto (talk) 08:12, 17 December 2016 (EST)


 * I believe that "Group Direct Product" is a standard term used commonly in AbAlg and Group Theory as I have seen it a few times in source works. I don't know about modules. My gut tells me to go with whatever is most "standard" and if that means naming is inconsistent, then that is of less importance than intellectual accessibility, but it is not a point I feel strongly about. If you feel it would be an improvement to be consistent, then DP of Xs works better for me as a general standard than XDP. Others may differ, but it is up to them to express an opinion, and if they don't it is assumed they may not be strongly concerned either way. --prime mover (talk) 08:23, 17 December 2016 (EST)

I vote DP of Xs. Looking at your ambitious plans, one point of attention is the approach of universal properties. Because there is always the open point of integrating all this with the category-theoretic perspective one day, where of course the universal property is the defining concept, and the abstract-algebraic definition is a means of fulfilling this definition.

But maybe it's not a thing that realistically can be incorporated at this point. Feel free to proceed even if you're not able to come up with a universal approach (heh ;)). &mdash; Lord_Farin (talk) 15:53, 18 December 2016 (EST)

Making the definitions more complicated
We have a specific policy on to put only definitions in a definition page, and not clutter it up with justifications for the validity of the definition. If there is a genuine need to justify the existence of an object because it is non-intuitive, then we add it as a separate proof page.

Hence I reversed out your additions to Ceiling and Floor definitions. --prime mover (talk) 01:11, 29 January 2017 (EST)


 * Okay. What about adding just one sentence to the definition, just to link to a page where it is shown that the definition is valid? --barto (talk) 03:38, 29 January 2017 (EST)


 * See the "Also see" section. --prime mover (talk) 04:31, 29 January 2017 (EST)

Continued good work
I appreciate the way you've got the general "feel" of and you're generating some seriously worthwhile content.

Please do not feel offended if I (or others) spontaneously amend (or even reverse out) some of your changes, or change the notation, presentational style and even source code style in ways which may look arbitrary. It's all working towards completely consistency of content and structure. --prime mover (talk) 16:23, 23 April 2017 (EDT)


 * No problem. I'm happy to contribute, especially if it's things you most likely won't find anywhere else (because nobody has made the effort to write out a proof). Of all the small amendments I can think of only one I dislike, which is the use of  for every pair of brackets. It creates additional spacing before the brackets, which I don't find aesthetic: $f\left(x\right)$ vs. $f(x)$, or worse: $\gcd\left(a,b\right)$ vs $\gcd(a,b)$. It's as if the $\gcd$ has nothing to do with $(a,b)$.  --barto (talk) 16:31, 23 April 2017 (EDT)


 * You're not alone, nobody likes the \left...\right. :-) OTOH I personally do prefer the extra gap before the brackets. This is one area where not everybody is going to be happy.


 * Oh yeah -- I was actually taught $\gcd \left\{ {a, b}\right\}$ because "it doesn't matter what order the operands go in". There are (generally unresolved) debates about the general wisdom of using set notation for such argument lists throughout the talk pages of . --prime mover (talk) 16:38, 23 April 2017 (EDT)


 * I imagine. What was the motivation to begin to use set notation, except the fact that we can? Does a certain author use this? I don't like it neither, because it hides things like $\gcd(a,b,b,a,b)=\gcd(a,b)$ (and not only $\gcd(a,b)=\gcd(b,a)$). Also, in general rings (that are not $\Z$ or polynomial rings over fields), $\gcd(a,b)$ becomes the ideal $(a,b)$, and then we use round brackets and not set notation for obvious reasons. --barto (talk) 16:50, 23 April 2017 (EDT)


 * I think it came from my M203 course in my MMath (OTOH might have been the Number Theory module). Didn't much like it, but thought that was the way it should be done. That was the same course that liked $]a, b[$ for an open interval, which I really didn't like.


 * In general we are trying to use the most up-to-date notation we can find which is not too specialised, trying at the same time to pick notation which is as unambiguous as possible, even if this means not using the most conventional notation. Hence the need to define the notation when it is being used: "where $a \mathrel \backslash b$ denotes that $a$ is a divisor of $b$" and so on. --prime mover (talk) 16:58, 23 April 2017 (EDT)


 * I think $\gcd\{a,b\}$ is more ambiguous than $\gcd(a,b)$. --barto (talk) 08:40, 28 April 2017 (EDT)


 * As long as we're consistent don't care what we use. We are already using $\gcd \left({a, b}\right)$, so. --prime mover (talk) 11:27, 28 April 2017 (EDT)


 * Okay. I try to make it a priority to create new content and not to discuss tangential issues too much, but sometimes I can't resist :) Part of the job is making proofwiki user-friendly and attractive. --barto (talk) 11:50, 28 April 2017 (EDT)


 * It's more like this: we have already evolved a style and a structure which has proved to work. We have evolved a notational convention which we believe is as good as any other, which has proved adequate. If there is a choice of notations to use, some will prefer one style, some will prefer another. A colossal amount of the time spent on this site is in refactoring and rework, and we really, really, really don't want to spend a lot of time doing an unnecessary package of work purely because a different way looks as though it is "better" without a solid reason to believe that it will be better.


 * My belief is that it is user-friendly and attractive. --prime mover (talk) 12:43, 28 April 2017 (EDT)


 * I hesitated between writing 'make' or 'keep' user-friendly, should have taken the other one :) As regards page lay-out, conciseness, coverage and especially the self-containedness of the pages and the omnipresence of links you've certainly done a great job so far. I mainly see room for improvement in the search function. --barto (talk) 12:56, 28 April 2017 (EDT)

Redirects
Seriously how many redirects to Definition:Infimum of Set/Real Numbers do we need? We already have one: "Definition:Infimum of Subset of Real Numbers" which should be adequate. One of the things that another contributor to this site is keen on is not proliferating redirects (don't know why but he's the boss). So unless you have a really good reason for having them, we might want to rethink this latest strategy. --prime mover (talk) 18:03, 24 April 2017 (EDT)


 * Okay, I admit that was exaggerated. I'm curious though as to what the reason is to not like redirects. I can think of one reason, which is that it clutters search results. Redirects may become less needed if the search function recognizes spelling mistakes/variants, as on Wikipedia. Not sure what it takes to allow that. --barto (talk) 18:17, 24 April 2017 (EDT)


 * In this context "Definition:Infimum" takes you to the master page, and in this context you are then able to navigate with little difficulty to Definition:Infimum of Set/Real Numbers. Then one does "What links here" and finds the go-to redirect, which one can then use, and it is a specifically stated title: it's the infimum of a subset of the real numbers.


 * I contend that Infimum (Real Numbers) and Infimum (Real Analysis) are not specific enough. There exists an infimum of a real function and/or real-valued function (I can't remember without checking) and it is not immediately obvious whether, for example, Infimum (Real Analysis) refers to Definition:Infimum of Set/Real Numbers or (ah, here we are) Definition:Infimum of Mapping/Real-Valued Function.


 * In all cases, unambiguity takes first place on the podium, understandability second, and consistency 3rd. --prime mover (talk) 18:58, 24 April 2017 (EDT)

Beware renaming
I see you renamed "Vector Space has Basis" to "Vector Space has Basis between Linearly Independent Set and Spanning Set" (sorry, I renamed it from "Between" to "between" better to reflect our house style), and then renamed the corollary to "Vector Space has Basis" -- but please beware of doing this, because of the danger of links to the original "Vector Space has Basis" now pointing towards the one you renamed it to.

Also note that the general structure of a MediaWiki page is such that pages whose name is of the form "(pagename)/(subpage)" then get a link on the page at the top to the parent page. This allows a convenient link, and an immediate way of referring back to the page which is its parent. So the old "Vector Space has Basis/Corollary" used to have a link to "Vector Space has Basis" at the top. This new "Vector Space has Basis" page no longer has this link back to "Vector Space has Basis between Linearly Independent Set and Spanning Set", which can be seen as being a subtle nuance that has now been lost.

I understand you have a vision for this site which is wider, more comprehensive and richer than that of those who first put this site together, but please beware that implementing that vision may compromise some of the carefully-thought-out decisions of the past. Yes I know this stuff is not all documented in the various help pages and instructions on how to build this site. This is something that stupidly I and colleagues had failed to anticipate when we wrote that stuff. --prime mover (talk) 02:11, 2 May 2017 (EDT)


 * Also, when you do rename, please update the links to the renamed page. You can find what they are by the "What links here" link at the left hand side on the menu -- but you need to wait a short while (a minute or so) for the internal MediaWiki database to update itself to show those links. --prime mover (talk) 02:15, 2 May 2017 (EDT)


 * ... and finally, please remember to add that extra gap between sections so as to preserve consistency. An extra gap between sections improves the look. --prime mover (talk) 02:22, 2 May 2017 (EDT)

And another very important thing: you renamed "Linearly Independent Subset of Finitely Generated Vector Space" to "Size of Linearly Independent Subset is at Most Size of Finite Generator" without renaming its "/Proof n" subpages. Please please please, when you rename such a page, please tick the box to rename the subpages as well -- and then amend all links to all such subpages. This, I admit, is a pain in the arse, but if you really want the page renamed, please can you do the work to make sure everything remains consistent? I had plans to do other stuff this morning which I am no longer going to be able to do because I have to clear all this up. --prime mover (talk) 02:29, 2 May 2017 (EDT)


 * Yes, I understand completely. Apart from updating the links to the renamed pages, those things you mentioned, I didn't notice them, so I'm sorry. Normally I would tick that box to rename subpages, but this time I didn't notice there were any. Next time, you can just post on my talk page and leave the dirty work to me. I'm aware of all the work that has to be done, except this time I procrastinated it a bit and there were some things I just overlooked. --barto (talk) 07:55, 2 May 2017 (EDT)


 * No worries, I have gone through and done the updating (or at least, as much as I had time to this morning, I'm back to the day job now).
 * A suggestion (which I learned the hard way) is to rename pages one at a time. Rename one, clean it up, redirects and all, and only then go through and rename another one. --prime mover (talk) 08:17, 2 May 2017 (EDT)


 * Yes, makes sense. I was too enthusiastic. --barto (talk) 08:31, 2 May 2017 (EDT)

hang on a minute
Look I'm working on it, I said in the page for Baire Space that I'm working on it, please give me a minute fragment of a microsecond before jumping in, please? --prime mover (talk) 06:01, 5 August 2017 (EDT)


 * Sorry about that, but I was right in the middle of code development there, and we had an edit conflict.


 * Okay, I've finished now, feel free to tidy up the spacing if you can improve it. --prime mover (talk) 06:13, 5 August 2017 (EDT)