CZ Talk:Mathematics Workgroup: Difference between revisions
imported>Michael Hardy (Capitalization conventions) |
imported>Aleksander Stos |
||
Line 288: | Line 288: | ||
I created a redirect from [[fundamental theorem of algebra]] to [[Fundamental Theorem of Algebra]] and found FOUR existing articles already linking to the redirect before I created it. [[User:Michael Hardy|Michael Hardy]] 21:11, 21 May 2007 (CDT) | I created a redirect from [[fundamental theorem of algebra]] to [[Fundamental Theorem of Algebra]] and found FOUR existing articles already linking to the redirect before I created it. [[User:Michael Hardy|Michael Hardy]] 21:11, 21 May 2007 (CDT) | ||
:You might be interested in looking at [[CZ:Formatting_mathematics#Capitalizing_theorem_names]]. There is a comment on the related talk page. I believe, however, that the discussion should be centralized on [[CZ:Formatting mathematics/Theorem capitalization]] (and the related talk, of course) --[[User:Aleksander Stos|Aleksander Stos]] 02:09, 22 May 2007 (CDT) |
Revision as of 02:09, 22 May 2007
Suggested Plan of attack
I think that the current status of mathematics workgroup is not good. there are two major problems:
- we don't have a plan.
- we don't have enough editors, writers or readers/reviewers
Regarding the first problem. The crop we had from "random suggestions", which is currently on the workgroup wiki, is IMHO total crap. Since I believe it is very important to start with a good "skeleton", I suggest we starts with MSC or ZMATH (which are very similar), and fill all the nodes on the classification tree. Indeed the classification tree does not mention explicitly some classical topics which certainly deserve an article - we just add them in the correct place ( e.g. hyperelliptic curves, Kummer surface, SU(2)->SO)(3) fibration to name some of my personal favorites). I estimate that if we stay close to tree we are talking about 2000 articles. (I know I ignore elementary math, there isn't so much of it).
Regarding the second problem, let us start with the number of writers: It took me about a week to get the hyperelliptic curve article to be more or less ok (it still needs editing, but the content I want is there). I think that this is an average length article. I know that I'll work faster in time, but on the other hand some of the excitement will fade of. Let's assume 20 articles per author per year. If we want to get this thing done in a year we need at least 100 authors. Which means that we need at least 5 editors, and at least 500 readers.
comments ? --dlehavi 22:28, 28 February 2007 (CST)
- Good questions. Concerning the number of editors -- it is not up to us. The best we can do is to create a friendly working environment (e.g. to attract new authors). Concerning the "plan of attack" -- I'not sure what I shall think about it. I use WP often as a reference manual to find concrete definitions (or, given the WP's reliability, some hints where to look up). It proves to be extremely useful in this regard. I think I have never read Mathematics article, nor Algebra, Harmonic Analysis etc. These are surely parts of the core skeleton, and of course of the highest importance for an encyclopedia, but I found them hardly of my (selfish) interest. These are also difficult articles to write, aren't they. Besides, while I am all for team working, on wiki it is not easy to make the members do exactly what you want... a kind of anarchy is here, like it or not. A more concrete proposal could attract more brains, however. Consequently, I have the following suggestions/remarks:
- why not move this discussion to the forum (link in the header is for a reason!) and try to design something you proposed. I think it concerns also an approximate structure of envisaged sub-workgroups (someone already posted a proposition). In this regard, we may also benefit from concrete experience of our most active workgroups (Bio, Healing sciences).
- meanwhile, let's continue producing articles dealing with basic --and not so basic-- concrete notions; brand new articles, maybe not exhaustive at the beginning -- but reliable (=let's approve them). More precicely, I think about a "semi-approval" meant for articles that are "not very elaborated", but clearly "containing basic useful informations". Let's imagine a header "This atricle has been revised by an expert (link to the name) who found it correct and containing the most important informations. Still, the article needs to be expanded (link to the draft page)."
- This could give us a quick start and make CZ become in not so distant future a useful and reliable source of reference. As far as I can see such "semi-approval" is well adapted for math. The question is whether expanding such "semi-approved" article (instead of writing a complete one from the beginning) would give us much of additional work. Any thoughs? Let's continue on the forum.
- --Alex S. 09:32, 1 March 2007 (CST)
- PS. I think that Mathematics could be rewritten from scratch. at the moment it is just borrowed from WP (practically untouched) and formally qualifies for BigSpeedyDelete. The only reason to "tolerate" it for a while to have the blue link in the workGroup header...
(Straight) line
Hello. We have an article at line (geometry) and another one at straight line (geometry). However, in elementary geometry, all lines are by definition straight; curved lines are called curves. It may be the case that in some specialized areas, the concept "straight line" is being used and that the articles need to be clarified (I'm not a geometer). However, it seems that the articles are misguided and that straight line (geometry) needs to be deleted. Unfortunately, I've no idea who to do this. Any assistance would be greatly appreciated. Cheers, Jitse Niesen 23:16, 26 March 2007 (CDT)
- Agreed. --AlekStos 06:50, 27 March 2007 (CDT)
List of mathematical topics
Is this a worthwhile list or is it redundant to the workgroup page?
If it is good; shouldn't there be a easy-to-find link to it, on the workgroup page?
--David W Gillette 20:15, 30 March 2007 (CDT)
- Now I see a link to this list under 00 XX General. --David W Gillette 00:03, 1 April 2007 (CDT)
Level of the introductions in our articles
Judging from my experience, the vast majority of people in the world are very satisfied with keeping their mathematical knowledge at the precalculus level. I also assume that most of those who will be accessing our work in CZ will look to clarify or expand only moderately, their knowledge at this level. In articles that have aspects of both precalculus and advanced math, can we meet this audience where they expect to be, by introducing and beginning these articles on a low level, and then in later sections cover the ‘good’ stuff?
- --David W Gillette 17:01, 3 April 2007 (CDT)
I am certainly in favor of writing accessible introductions. Hey, I'm a big fan of the Science Channel, and I think developing accessible accounts of difficult ideas is a real art form. But these are articles about mathematics, after all, and it seems to me that some people have been a little overzealous in "dumbing down" articles, even to the point that they seem condescending (and become factually inaccurate). We need to be a bit careful here, and show respect for the reader. Another question: Is the average reader of Citizendium the average reader of mathematics articles? Greg Woodhouse 17:29, 3 April 2007 (CDT)
- More thoughts:
- Those articles with titles that sound like something covered in a precalculus class, should not overwhelm our seekers until the basic information that they are looking for is found.
Here is an idea for some upper layer headings
== Introductory material == === Basic notation === === Basic properties === === Basic operations === == Formal coverage == === - - - === == Advanced topics == === - - - ===
- I would envision a collaborative writing. Some of us are more familiar with how the topics are covered in a precalculus class, and others of you are more familiar with how the topics are covered in a more advanced setting.
- I would think that this approach would be used in some more advanced levels as well. There are topics covered in a calculus class at one level, and then in more depth in an analysis class.
- In answer to Greg’s question, Obviously not. But if we can put together a useful product for the man on the street, the high school student or the non-math major, we can supply a needed resource.
- --David W Gillette 18:41, 3 April 2007 (CDT)
I think it is a very interesting proposition. Concerning the proposed headings, I guess it does not have to be the formal heading structure of every article, since sometimes the notation or operation sections would be _very_ short or empty. But it does express the general idea of the global structure of an 'average' article. So I would propose to put it on the main workgroup's page. Eventually, we could develop there some "author's guide" in math.
My two cents to this end. Introductory part could also mention the general meaning ("where and why is it important"), some historical context ("who, when, what for") and general interactions with other parts of mathematics and/or other sciences applications. All of this is accessible to a wider audience. I do not know the Science Channel, but I agree it is good to begin articles with an intuitive/informal discussion of the subject (yes, it is fun and maybe a form of art too!). --AlekStos 04:06, 4 April 2007 (CDT)
I suppose I look at things a little differently. What makes an encyclopedia different from a dictionary (or in the case of mathematics, a compendium of definitions and theorems). Writing an article for Citizendium ought to be expository writing. But this is really orthogonal to the issue of level or depth. It's pssible to write a good expository article on how to add integers with pen and paper. It's also possible to write a good expository article on, say, the Atiyah-Singer index theorem, or the Langlands program. But a special difficulty with mathematics is that supposedly elementary topics (like prime numbers or map coloring) often lead to very difficult mathematics. (After all, isn't that why mathematicians spend so much time studying "difficult" things? Abstract concepts are generally introduced because they are amenable to analysis!) So, while an article on Artin reciprocity is likely to attract readers with the necessary mathematical background and maturity, articles on arithmetic essentially have to do double duty. They need to provide an accessible introduction for non-experts, but they need to establish a foundation for the introduction of more abstract ideas. Otherwise, we'll end up with a two tiered system: one group of articles will be both understandable and boring, while the other will be technical, sterile, and ultimately unenlightening. Greg Woodhouse 17:01, 4 April 2007 (CDT)
Math notation style
mathematical notation syle
- Don't use \Sigma instead of \sum . Please note:
-
-
- The former uses \Sigma ; the latter uses \sum . The latter is generally considered correct usage of TeX.
- Note this difference:
-
-
-
- I think the last should be adopted as standard, and the lower dots in the second display above should be used between commas.
- I don't know about anyone else, but the use of centered dots with sums (not products) looks very wrong to me. consider the following (more or less random) example from Wolfram Mathworld [1]. Greg Woodhouse 04:12, 12 April 2007 (CDT)
- I always use centred dots in sums. I looked in some books on my shelf and found that seven use centred dots in sums and only one (on quantum physics) lower dots. Donald Knuth write in the TeXbook (p. 172) that "in general, it is best to use \cdots between + and − and × signs, and also between = signs or ≤ signs or ⊂ signs or other similar relations. Low dots are used between commas, and when things are juxtaposed with no signs between them at all." -- Jitse Niesen 04:31, 12 April 2007 (CDT)
- The American Mathematical Monthly's style manual precribes \cdots between two occurrences of "+", if I'm not mistaken. Michael Hardy 16:00, 20 April 2007 (CDT)
- Hmm...Well, I don't have TeXbook handy, so I looked in Guide to LaTeX (Kopka and Daly). They, too, use \cdots, but add (p. 125) "The command \ldots is available in normal text mode, whereas the other three are only available in math mode. In text mode, the command \dots may be used in place of \ldots to the same effect." So, I'm sure you're right here, it just looks wrong to me. Greg Woodhouse 04:53, 12 April 2007 (CDT)
- a + b = c
- a+b=c
- I think the first style above should be adopted as standard in non-TeX mathematical notation.
Does Citizendium have a manual of style for mathematical notation? Michael Hardy 14:46, 11 April 2007 (CDT)
- Also note that you can add "\textstyle": . There's no such manual of style yet; I suppose that for the moment we could just follow the Wikipedia manual of style. Nice to see you here, Michael. Fredrik Johansson 02:06, 12 April 2007 (CDT)
Formatting
Right:
- <math>\int_0^\infty \frac{dx}{x}.</math>
Wrong:
- <math>\int_0^\infty \frac{dx}{x}</math>.
I.e. I propose this convention. When TeX is used in the NORMAL way, this wouldn't matter, but when it's used the way it's used HERE, it does. Putting the period or comma OUTSIDE of TeX causes bad misalignments and sometimes may cause the period to appear at the beginning of the next line.
Also, it is lunacy to write anything like this (Wrong):
- <math>\begin{cases} blah blah \end{cases}. </math>
or this (Wrong):
- <math>\begin{cases} blah blah \end{cases} </math>.
The periods or commas need to go at the ends of the appropriate lines WITHIN the "cases" environment. Michael Hardy 16:39, 17 April 2007 (CDT)
Another proposal:
Right:
- <math> \int f(x) \, dx </math>
- <math> \int \int f(x,y) \, dx \, dy </math>
Wrong:
- <math> \int f(x) dx </math>
- <math> \int \int f(x) dx dy </math>
Compare and contrast the two:
Right:
Wrong:
Michael Hardy 16:50, 17 April 2007 (CDT)
- I always use \iint for double integral signs, as in <math> \iint f(x,y) \, dx \, dy </math> which renders as
- The symbol \iint was introduced for this purpose. -- Jitse Niesen 21:24, 17 April 2007 (CDT)
If your talking about a double integral over a region D in the plane, then certainly I'd use \iint, thus:
But what about iterated integrals, thus:
Michael Hardy 16:03, 20 April 2007 (CDT)
<math> or no <math>
I know WP has a very strong anti-<math> sentiment, and there are some good reasons for it. I was wondering what the CZ policy on the matter has been discussed. For example, at group theory, I originally typed up x * (y * z) and this was edited by another editor to . I used around the * in order to ensure no line-breaking, but that comes for free with the math markup. The math-markup is much cleaner and looks better personally, but the WP-way makes sense too... anyone wanna chime in? - Jared Grubb 22:29, 3 May 2007 (CDT)
- How about x·y·z or x · y · z? Michael Hardy 15:30, 9 May 2007 (CDT)
- It has been pointed out that markup has its advantages, see Talk:Complex number#Comments (and also this post, the bottom line). We've just started and no 'policy' is defined. I think it is time to begin to transform isolated remarks emerging here and there into a more coherent 'editor's guide' or 'manual style'. To this end, we may want to discuss issues like this on the forum.--Aleksander Stos 02:13, 4 May 2007 (CDT)
OK, I've made some remarks at user talk:Catherine Woodgold that are relevant here; I'm going to paste them below:
copied from the aforementioned talk page:
TeX versus non-TeX mathematical notation
Hello. I don't think it's a good idea to indiscriminately convert non-TeX mathematical notation to TeX. Unlike the way TeX is NORMALLY used, the way it's used here causes material that's in TeX to appear in a different font from surrounding text, often comically gigantic, and often improperly aligned.
For example: . On the browser I'm using, the e in the preceeding expression is not aligned with the surround text but instead looks like a subscript.
"Displayed" TeX, as opposed to "inline" TeX, looks good:
Michael Hardy 22:22, 5 May 2007 (CDT)
- There's no easy answer to this. However, I'm impressed by the arguments at [2] (TeX versus HTML section). If <math></math> is put around things, it's meaningful, and can later be translated by "the server" or "the browser" into other formats or display methods. For example, a blind person might have a program that translates math formulas into something they can perceive, such as speech sounds. In contrast, formulas in html are very much dependent on a specific behaviour of the server and browser, and later versions (or current, different browsers) might display them in a way that means something different from what the writer intended. The browser might not recognize that it's a math formula at all.
- In the example you give, the e is the base and the rest of the formula is an exponent. It looks to me that the formula is displayed correctly except that the whole formula is too low down in the text. That is not necessarily a defect; it allows the line of text to be more compact with the other lines of text. It may not be ideal. But it doesn't look very bad to me.
- Basically, as I see it, it's the responsibility of the writer to indicate that something is a math formula, and it's the responsibility of the browser to display it correctly. If a browser doesn't display it very well, then complaints can be sent to the writer of the browser (or if it's open-source perhaps one can fix up the browser oneself) and then the browser will be improved and there will be less of a problem with other formulas in the future. Catering to the idiosyncracies of current browsers is not a reliable method: it can give unpredictable results both with other current browsers and with future browsers, and takes away some of the incentive to improve the browsers.
- So, my opinion is that it's best to put math tags around all math symbols. Perhaps more people could be brought into this discussion (on the math forum perhaps), and some consensus can be worked out.
- It's good to see more than one active mathematics editor, by the way. Even if I disagree, I think the point you bring up is valid (there's no one easy answer) and that by discussing among a number of people seeing different sides of the issue, a better final decision is usually reached. --Catherine Woodgold 08:32, 6 May 2007 (CDT)
Since this very issue has been discussed at great length in various Wikipedia discussion forums without anybody improving the browser software in the ways you suggest, I'm not going to hold my breath waiting. In some cases, "inline" (as opposed to "displayed") TeX looks truly hideous. In at least one way, citizendium has done better than Wikipedia: (let's try this....) (OK, on this browser, these characters don't look unduly big, so score one point for citizendium. But the lower-case pi looks like a small capital pi, and that's plainly wrong.) Now lets try some other things:
- a2+b+c=3 (wrong)
- a2 + b + c = 3 (wrong, but better)
- a2+b+c=3 (wrong)
- a2 + b + c = 3 (right)
- a2 + b + c = 3 (wrong)
- (right in some contexts, wrong in others according to some respectable authorities)
- blah blah blah blah blah (if there's anyone who doesn't find this one hideous, I'm tempted to prescribe euthanasia)
blah blah blah blah blah (this one is also hideous—apparently as soon as you put in a superscript this happens).
- blah blah blah blah blah blah
- blah blah blah blah blah blah
blah blah blah blah blah blah (this one looks bad despite the fact that the same thing in the paragraph above looks good; but this time the lower-case pi looks right)
blah blah blah blah blah blah
Do you have any rough estimate of the number of hundreds of times you've pointed out these differences to newbie wiki editors? In my own case I lost track long ago.
Are you impressed by ALL of the arguments on the page you cite, including the ones about the advantages of html over TeX? Michael Hardy 17:49, 6 May 2007 (CDT)
- (end of copy-and-paste)
Further discussion
I would like to clarify one thing. The web browsers are working perfectly fine. The reason those things look "broken" is because we are asking the browser to display them that way. It's our HTML and CSS that is broken, not the browser. One thing that would be very easy to change is to align the bottom of the math images to the baseline of the text. Currently (the default in monobook.css), the image gets vertically-centered with the text. The problem with aligning the bottom of the image is that subscripts or hanging letters (like "g") become the bottom of the image. So, the would look beautiful, but would be a bit raised because of the hanging gamma and the / on the right. I still think it would look better bottom-aligned than centered. - Jared Grubb 00:02, 7 May 2007 (CDT)
- This suggestion has already been discussed to death at Wikipedia, three or four years ago, and I think it was universally agreed that centering (which is done now) is FAR better than bottom-aligning (which was done initially when Wikipedia acquired TeX capabilities at about the begining of 2003). And I agree, even though center-aligning is, as we see, a bad thing; bottom-aligning is worse. Think of how an expression like would look if bottom-aligned.
- Those wishing to be fully informed on the issues should avail themselves of Wikipedia's vast experience with this. I.e. go over there at dig out the ancient discussions. (More generally, Citizendium of course owes an immense debt of gratitude to Wikipedia. One should take opportunities to learn from one's elders and forebears.) Michael Hardy 19:05, 7 May 2007 (CDT)
- Ideally, the TeX to PNG converter could return some info on where the baseline in the image is -- If the math markup was in a line of text, the TeX renderer would certainly know this information, and this could be returned to the mediawiki php code.... in theory. I can't imagine that I'm the first one to think of this in the years this issue has been discussed over at WP, so I'm sure there's a reason this doesn't work. So, do we just adopt WP policy then? I personally think is much nicer to read than x. If the font-size disparity wasn't so great (like in your example), I think the minor alignment issues would be easy to overlook. - Jared Grubb 02:24, 8 May 2007 (CDT)
That's a good point. I certainly do not mean to disparage the work done in this area by those working on Wikipedia, and am sorry if I have in any way suggested otherwise. Greg Woodhouse 19:25, 7 May 2007 (CDT)
- I agree that the solution would be calculating the baseline (just do not believe it can be done in a predictable future).
- If the font-size disparity wasn't so great... What about \scriptstyle then? E.g. vs or vs You may be interested in looking at a discussion on our forum as well.
- BTW, if I had to code 'inline' sum, I'd put something like this: But 'bigger' formulas always look bad 'inline', even with the perfect TeX. For example, many (all?) professional math journals encourage or even force slash notation for 'inline' fractions. We can follow these guidelines. --Aleksander Stos 04:47, 8 May 2007 (CDT)
- In reply to Jared's suggestion to calculate the baseline: The information is computed when you run latex, but I doubt it will be easy to get this information out of latex. One trick is to use the latex preview package, which can be used to find the depth of the image (depth is the distance between the bottom of the image and the baseline). I never looked into it, but it is used in the blahtex test page. Try it out and look at the "PNG rendering". You'll see (hopefully) that the image lines up correctly with the text.
- In reply to Aleksander's suggestion to use scriptstyle: One problem with scriptstyle is that it does more than making everything smaller. Compare for instance (\scriptstyle 3^{2^2}) with (the same without \scriptstyle). With scriptstyle, the twos have the same size (they're both scriptscriptstyle, in TeX-speak); without, they're different (they're scriptstyle and scriptscriptstyle, respectively).
- As I said in the forums, if the sole goal is to shrink the picture, that's easy to do. I just checked and it's a single number that has to be changed. We have to agree what to change the number to, but we can try out some values and see what works best in a variety of environments. We need some help from the technical people at CZ, but with luck it can be done in one or two weeks. It will change all formulas though, also those that appear on a line by itself. It may be possible to change the MediaWiki software to distinguish between maths used inline and maths used by itself, but that requires a lot of work, I think (a lot of work = not in the predictable future). An easier solution, mirroring TeX, is to introduce one tag for maths used inline and one for maths used as a display (easier = a few months). To continue with my estimates (which are little more than guesses), the baseline thing that Jared suggested would also take a few months. -- Jitse Niesen 05:59, 8 May 2007 (CDT)
- If 'general' resizing could be relatively easy I'd be all for it (and I'd give up \scriptstyle, of course). In fact, it is much more proper solution and the example above clearly shows that 'manual' formatting with \scriptstyle does not always look so good. I see no problem with the aside effect of resizing the displayed formulas, considering that the TeX displayed formulas are generally of the same size as 'inline' ones. As for the size to be agreed on, I'd propose something in the middle between what is rendered by \scriptstyle and what we have without it. Having two separate tags for inline and displayed math would be better yet (just like tex) --Aleksander Stos 07:30, 8 May 2007 (CDT)
- I like the output of \scriptstyle, but would suggest that it (or something like it, per Alexander above) becomes the default. I think we will use inline TeX much more frequently than stand-alone (think about the last LaTeX document you wrote... it's almost all inline). - Jared Grubb 12:07, 8 May 2007 (CDT)
- Regarding the Blahtex page... I just checked it out. The inline samples in this page look WONDERFUL. I personally dont like the MathML examples (but that's probably my browser's fault), but the PNG's are all perfectly aligned, and though the font sizes can be a bit large, they don't look as nasty as our current inline PNGs look. How hard would it be to borrow those features? - Jared Grubb 12:17, 8 May 2007 (CDT)
This may be a dumb idea, but after articles are approved and reasonably stable, could/should they just be converted to LaTeX and then to PDF? Wikis are great for collaboration, and I'm not suggesting we shouldn't use Wiki markup for drafts and articles under active development, but if our goal is the best possible presentation, why not just use TeX? Or, to gtake the idea to its logical conclusion: Do you suppose we can all handle editing math articles in TeX form? Greg Woodhouse 07:13, 8 May 2007 (CDT)
- Well, why not? Translating wikicode into LaTeX, then PDF, should not be too difficult (and I hope I could help). But our articles are interlinked and it's a big advantage. Could it be preserved within PDF? How do we present our PDF's: as complementary to or just replacing what we have now? (BTW, where is the Biology article PDF version?). I'd love to edit directly in LaTeX, but I guess the software is far from being ready for that. --Aleksander Stos 07:46, 8 May 2007 (CDT)
You can have hyperlinks in PDF, but I have no idea how to generate them from TeX. I can look into it, I suppose. My thought was that we'd continue to use Wiki markup for drafts of approved articles and for articles still under development, since we are all comfortable using Wikis for collaboration. Greg Woodhouse 08:27, 8 May 2007 (CDT)
CZ:Formatting mathematics
I've been bold and started an article called CZ:Formatting_mathematics, the purpose of which is to gather together all debates and policies related to formatting mathematics in Citizendium articles. I've put enough content there to suggest the format I have in mind: one main article with the statements of policies, proposed policies, and issues under discussion; and for each item, a subsidiary article with a detailed discussion of the issue, so that people will know why the policies that are (eventually) decided upon are the way they are (I fleshed out one such discussion article to give a sense of what I have in mind). I hope that this creation has value for our workgroup! If so, please feel free to develop the skeleton I put there. - Greg Martin 16:26, 10 May 2007 (CDT)
Math editors -- look at these math pages (Logarithm and Lambert W function)
I would appreciate it if an editor would look at Logarithm and comment on what's needed to bring it up to approval level, and whether the couple of things I mentioned on the talk page that I might add would be a good idea.
I think Lambert W function by User:Fredrik Johansson is a very nice article, too, and that it deserves attention from math editors. --Catherine Woodgold 14:02, 12 May 2007 (CDT)
- I left some comments on Talk:Logarithm. Sorry if I sounded negative. I actually think that the article is actually pretty close to approval as all the raw material is there. It just needs some strategic edits. The problem is to find these strategic edits. -- Jitse Niesen 07:27, 18 May 2007 (CDT)
- The article on the Lambert W function is very nice. Unfortunately, it's too far out of my sphere of knowledge (more properly called: the stuff of which I incorrectly think that I have a vague idea of what is going on). I don't feel comfortable approving it.
- I do intend to read it carefully and see whether I can make some comments. -- Jitse Niesen 07:45, 18 May 2007 (CDT)
Capitalization conventions
Should an article be titled
with capital initial letters, or
(the first letter is case-insensitive in links; the later letters are case-sensitive)?
Notice that Lambert W function has a lower-case initial f.
I created a redirect from fundamental theorem of algebra to Fundamental Theorem of Algebra and found FOUR existing articles already linking to the redirect before I created it. Michael Hardy 21:11, 21 May 2007 (CDT)
- You might be interested in looking at CZ:Formatting_mathematics#Capitalizing_theorem_names. There is a comment on the related talk page. I believe, however, that the discussion should be centralized on CZ:Formatting mathematics/Theorem capitalization (and the related talk, of course) --Aleksander Stos 02:09, 22 May 2007 (CDT)