Wikipedia talk:WikiProject Mathematics/Archive/2004/Sep-Dec

Links to surnames of mathematicians are often very bad things

Just as the untutored lay person knows who is being referred to when one mentions Shakespeare or Einstein by surname only, so mathematicians know who is being referred to when one mentions Abel by surname in the context of a math article. But a link to Abel is (of course) a link to the son of Adam and Eve who was killed by his brother in the book of Genesis. And how could anyone expect a link to Study to be a link to an article about the mathematician Eduard Study? Sometimes a math article, or substantial parts of one, are intended to be read by people who know little about mathematics, and in such cases linking to "Euler" does not inform the reader as well as if one links to Leonhard Euler. Consequently I think in most cases first and last names should be used. Michael Hardy 02:04, 1 Aug 2004 (UTC)

There appear to be two points about this:

(a) that surname-only links may be ambiguous to the reader or require disambiguation as wikilinks;

(b) that fuller names in links carry more information to the reader anyway, in the absence of the problems noted under (a).

I'm sympathetic to the first point, as I imagine most people are. I find the second point less convincing, really; if there were no link then surname-only does offer much less, but the point is weakened when there is a page to refer to. It is partly a generation and background thing, but I'm happy with Swinnerton-Dyer, just as much as with Peter Swinnerton-Dyer who is really Professor Emeritus Sir Peter Swinnerton-Dyer, Bart. when it comes down to it.

Charles Matthews 16:47, 3 Aug 2004 (UTC)

The main reasons that it became standard to use only surnames for references in published text, have been for considerations of space, and the tediousness of typesetting. That is, they were publisher-centric. However, since, Wikipedia is (essentially) free from such constraints, we can afford to be more reader-centric. Thus, more use of full names is a good thing. The presence of a link lessens but does not eliminate the benefit to the reader of fuller names. Of course, judgment is required to know when more information is too much information. Paul August 15:48, Aug 24, 2004 (UTC)

I don't think it's just a matter of publisher-friendliness. Readers take additional time to read long names too, and there becomes a time when "Leonhard Euler" looks uselessly long to them. So perhaps in introductory articles, the first appearance of Euler could be written "Leonhard Euler", and the next ones can be just "Euler". Otherwise really-big-names like "Euler" could stay as surname only. (Surname-only links like [[Study]] or [[Abel]] are another matter and should always be avoided, indeed, IMO.) --FvdP 19:18, 29 Oct 2004 (UTC)

Note that according to policy, a link is only given when a name is first mentioned or when it is used in a new context. Thus, asking that every link use the full name isn't inappropriate — the ones that aren't links, which is most of them, can go right ahead and use just the surname. Link redundancy and first-name-redundancy coincide.

That said, an advanced article is justified in excluding the first name of well-known mathematicians, even from links, since it can reasonably expect a more experienced reader. Derrick Coetzee 23:18, 29 Oct 2004 (UTC)

The case for LaTeX

In recent days, I have been adding <math>...</math> to every inline math expression I have encountered, starting with articles in Category:Curves and category:Bundles (mathematics). At the time, I thought that the HTML wikitext markup for equations was provisional, and that by TeXifying expressions, I was improving the articles. I didn't know about the existence of the Wikiproject Mathematics page. I'd like to offer my apologies for breaking convention.

That said, I'm perfectly astonished that HTML wikitext markup for inline equations and variables is an official recommendation (not truly "official," but you know what I mean.) I think it's a bad idea, so allow me to flesh out my case here. My proposal is that we should use <math>...</math> markup for any and every expression related to math, including formulae, single-letter variable names, and all inline expressions. Here's why:

1. Content != presentation. The entire reason that XHTML and CSS were created from the ashes of HTML 3.0 was to separate presentation from content. We can see the effectiveness of that design decision right here in the Wikipedia: I can change the "skin" of the site (which is just a CSS file) and the look of the site changes automatically, in spite of the fact that the content of every page remains the same.
   Doing this required tags that were solely devoted to presentation, like <i>...</i>, <b>...</b>, and <u>...</u> to be removed from the standard. They force presentation and content to mix. So why do we require mathematical expressions to be represented in the exact same manner? Why should a variable name be "italic?" What, precisely, does that indicate to the user?
2. Consistency. TeX is capable of creating beautiful PNG representations of math expressions, but the fonts and styles it uses for PNG do not match the fonts and styles used for the present "wikitext math" style. TeXifying everything will make all variables and equations look consistent. We won't be able to avoid TeX for more complex formulae anyway; we might as well let TeX choose the font for us.
3. TeX allows the user to decide. If we put all math expressions (including inline expressions and even variable names) in the <math>...</math>, any user will be able to change the look of all math-related pages with a single tweak to their preferences. They can view everything as HTML unless absolutely necessary, or they can view everything as PNG for maximum clarity. That all users' default preferences are not set to the latter is no reason to avoid LaTeX markup.
4. TeX allows the admins to decide. If, in the future, some brave developer decides to replace our LaTeX engine with MathML or some other more fitting standard, they can write a bot that automatically converts all LaTeX expressions on every page. Alternately, they may decide to change the default fonts for TeX (I don't know if this is possible, but I assume that it is), and again, all math expressions in the Wikipedia will respond to the change. Neither scenario is possible with "wikitext math," which would have to be changed by hand.
5. PNG images are small. That's the entire point of PNG, and why we use it in the Wikipedias in preference to GIF files. An expression like $\int _{0}^{\infty }e^{-x^{2}}\,dx$ only takes up 680 bytes; this post I am typing is much larger. It would be difficult to achieve better compression without throwing away image quality! In a giant page full of these types of expressions, the bandwidth "wasted" downloading the PNGs is negligible compared to the bandwidth required for (1) the article text, and (2) the Wikipedia logo in the upper left corner.
   Now, if you're using a graphical browser, right-click on the previous image and view its file name. Then compare that file name to the one on the WikiProject Mathematics page (where I got it from.) The filenames are exactly the same--5aa3fbdb28e2859859317b8a9d316fa9.png. So server space is not wasted for common expressions like variable names, either, even if they are forced to render as PNGs. There will be only one copy of the PNG file for $\,\!\theta$, and anyone viewing our math articles will have it cached.
6. TeX can emulate inline HTML, anyway. One objection to the use of LaTeX markup (and, in my opinion, the most legitimate one) is that some browsers cannot view inline PNG, and the resulting alt-text is incomprehensible. This is true; however, the MediaWiki LaTeX engine creates inline HTML already! Compare:
   • HTML style: f(x) = a₀x² + (a₁x)cos θ
   • TeX inline HTML: $f(x)=a_{0}x^{2}+(a_{1}x)\cos \theta$
   • TeX with forced PNG rendering (with \left, \right, and \!\,): $\!\,f(x)=a_{0}x^{2}+\left(a_{1}x\right)\cos \theta$

But it is true that mixing inline PNGs with ordinary article text can have a somewhat jarring effect; this is unavoidable, and I happen to not mind it at all (I have seen textbooks that have odd line spacing due to inline math expressions; they still sell well.) One possible compromise is to avoid forced PNG rendering unless absolutely necessary (that is, do not use "\!\," or other "artificial" spaces if you can possibly help it), so the user will see the maximum amount of inline HTML. They can still use their preferences to turn PNG rendering on, so we should expect that PNG versions of all of our expressions, equations, and variable names will exist.

I admit that such a proposal will require us to avoid the more traditional style; $x\cos \phi$ renders as "squashed" inline HTML, and would require parentheses if we did not allow artificial spaces: $x(\cos \phi )$ or $(x)\cos \phi$ or $x*\cos \phi$, etc. It's easier to simply allow PNG rendering for unsatisfactory expressions, but nevertheless, this proposal does address the inline objection.

I'm not surprised that my sentiments have been expressed before: Wikipedia talk:WikiProject Mathematics/Archive1#Moved_from_Village_Pump (see comments by User:Pascalromon.) I echo his/her sentiments, but I don't think we need changes as drastic as those that he/she proposed. So how about it, everyone?

Ardonik 19:26, 2004 Aug 3 (UTC)

You write I happen to not mind it at all. If most people agreed, we wouldn't be having the discussion, though. Wiki tends to look provisional, and there's a reason (it is). Now, work on format is constructive; but I don't know enough TeX to be happy with it. We have a kind of compromise at present. I expect it to remain until there is a clear technical shift in rendering, making inline TeX the obviously right way to go. Charles Matthews 21:52, 3 Aug 2004 (UTC)

The beauty of TeX is that we can avoid inline PNGs (which I am not opposed to avoiding) and still reap the other benefits of TeX mentioned above by keeping inline expressions in <math> tags. As for not knowing TeX, you don't have to! You add a lot of useful math content to the Wikipedia, Charles, and I figure that the job of less math-literate people like me is to follow in your footsteps, tweaking things here and there. TeXifying equations is one way to do that.
Perhaps it would be to everyone's benefit to mark the "old style" as provisional, so as to encourage intrepid Wikipedians to update it at their convenience to the "new format" without shunning the old style completely? --Ardonik 22:28, 2004 Aug 3 (UTC)

I think inline PNGs are ugly. I don't mind the use of <math> tags if they are properly translated in inline HTML; in fact, I prefer to type <math>f(x)</math>, rendering as $f(x)$, to ''f''(''x''), rendering as f(x) [side remark: I am surprised to see that both expressions render differently; on my display, I prefer the latter]. Unfortunately, not all mathematical expressions are translated into HTML, and I think that these expressions should be either translated by hand to HTML, or put on a separate line. -- Jitse Niesen 20:19, 4 Aug 2004 (UTC)

I will admit that it often takes some degree of coaxing to convince TeX to leave some simple expressions as HTML (for instance, using \(space) seems to invariably cause PNG conversion.) TeX isn't perfect, but I still think the advantages of keeping expressions TeXified more than outweigh the disadvantages.

If the community consensus is to avoid inline PNGs, then the next step is to discuss strategies for keeping TeX from PNG conversion. I am assuming that the conversion program ultimately responsible is latex2html. As seen from this page in the official manual, there are any number of ways to induce image conversion, but there appears to be no option by which one can force HTML output. (Can someone who is more familiar with the world of TeX correct me on this point?) That rules out convincing the developers to change program parameters; I think we'll just have to come up with a list of TeX features to avoid or replace in order to ensure inline HTML generation. But now is the right time to discuss such things, and this is the right place to do it.

Ardonik 07:39, 2004 Aug 5 (UTC)

Use of \mbox

We can use \mbox{ } to force spaces without inducing PNG conversion. Compare:

	Appearance	Markup
HTML	a2b cos x	''a''<sup>2</sup>''b'' cos ''x''
TeX (PNG rendered)	${a^{2}}b\cos x\,\!$	<math>{a^2} b \cos x\,\!</math>
TeX (without \mbox)	${a^{2}}b\cos x$	<math>{a^2} b \cos x</math>
TeX (with \mbox)	${a^{2}}b{\mbox{ }}\cos {\mbox{ }}x$	<math>{a^2} b \mbox{ } \cos \mbox{ } x</math>

Can anyone think of any other HTML syntax that TeX can't handle without PNGs?

Ardonik 11:21, 2004 Aug 5 (UTC)

TeX/HTML currently incompatible

On line bundle, I attempted to view the article using all possible choices of user preferences, and none of them were able to convert things like the "Z/2Z", "RP2", "CP2", etc. (blackboard bold, fractions, etc.) to inline HTML. When strict HTML was selected, of course it returned tex code. The point is that there is no way to use inline math mode while avoiding PNGs. TeX and HTML simply "evolved" from different origins and haven't quite become compatible. I expect this problem will be solved in time. In any case, there's no telling that the solution won't require detailed combing over and editing in the future, anyway. So, I agree completely with you in principle, but think it's too early to work in practice. And I don't think it's that big a deal...it will be a lot of work to make the switch when HTML and TeX become compatible, but with enough people working on it, shouldn't be a problem. Revolver 21:02, 5 Aug 2004 (UTC)

If the \frac notation cannot be used inline, then we should employ a forward slash instead. TeX understands it; see http://turing.une.edu.au/~amth247/Lectures_2003/Lecture_03/lecture/, and in particular the section of fractions and roots. It recommends that the slash notation be used in favor of \frac wherever it would make an equation easier to read; thus "Z/2Z" would become $Z/{2Z}$. In order to prevent the "RP" and "CP" in line bundle from rendering inline as PNGs, it suffices to avoid switching to fonts like \blackbb (and it makes perfect sense that HTML would not be able to handle those.) Again, we can reap the benefits of TeX without generating PNG files. --Ardonik 02:33, 2004 Aug 6 (UTC)

If the community consensus is to avoid inline PNGs, then the next step is to discuss strategies for keeping TeX from PNG conversion....That rules out convincing the developers to change program parameters; I think we'll just have to come up with a list of TeX features to avoid or replace in order to ensure inline HTML generation. But now is the right time to discuss such things, and this is the right place to do it.

Maybe so. I don't know, maybe this comes from seeing articles evolve over months or a couple years, but I don't think this is a urgent problem in any case. Try to avoid the most obvious problems (e.g. I think blackboard bold should be entered as bold for the moment) but it's nothing to get too uncomfortable over. For now, it's probably enough to sit back and wait for the inevitable HTML/TeX compatibility to happen, and then let things sort out. None of these articles are really going to look like they do at present in 2-3 years, anyway. Adding good content and improving some of the weaker "elementary" articles (fundamental thm of calculus, etc.) seems far more important. (BTW, why is FTC listed first in the "calculus" box, before derivatives even?) Revolver 21:15, 5 Aug 2004 (UTC)

It's not urgent (what is urgent in this Wikipedia?) but I feel that we do need to address it. LaTeX is not some relatively new technology waiting for extra features to be added by enterprising programmers. It is mature and fully featured; latex2html itself was around before 1993. There is nothing to wait for. The TeX tools were designed to empower those who love math, and now that they have been enabled in the MediaWiki projects, they are at our disposal. They do everything we want. What reason do we have to avoid them?
Of course I agree with you that adding content is more important than worrying about style, but by formalizing a system now, we ensure that future Wikipedians will know what guidelines to turn to when creating new math and science articles, and that people like me will know how to TeXify articles without ruining them. A thousand times over do I prefer consensus to inaction. --Ardonik 02:33, 2004 Aug 6 (UTC)

P.S. FTC? Calculus box? --Ardonik 02:33, 2004 Aug 6 (UTC)

Fundamental theorem of calculus. Look at the "topics" box on the right. FTC is the first topic. Revolver 19:55, 6 Aug 2004 (UTC)

I agree that <math>f(x)</math> is more logical than ''f''(''x''), and that content is more important than format, but I also agree that the HTML version looks better. Supposedly this will all be resolved when mathml is working. Should we just wait until then? (and how long will that be, anyway?) - Omegatron 02:47, Aug 6, 2004 (UTC)

Well, we have "experimental" MathML support right now, but as for how long we'll have to wait before MathML becomes a widespread standard, the answer is perhaps indefinitely. How could a company that failed to correctly support even CSS 1 be bothered with adding MathML support? Sure, Mozilla might get it eventually (or someone might develop a fork of Mozilla that supports it), but until aforesaid company makes Mozilla or Firefox the default desktop browser, few people will be able to view MathML. Additionally, when MathML support is fully enabled, we won't be able to take advantage of it without putting our expressions in <math> tags first, so we will be better off TeXifying our expressions now than continuing to use raw HTML and piling up the amount of conversion that will need to be done later.
Honestly, what do we stand to gain by waiting? --Ardonik 03:37, 2004 Aug 6 (UTC)

A few points. (1) Actually there is a free plug-in for Explorer available and Mozilla et al. have already a reasonable support for MathML (but you need to download some fonts). (2) What happens to <math> is determined by a home-grown transformation that might be changed if desired. (3) MathML is not really functional right now. I think the last point is important. There should be at least one way to see the ideal end-result. -- Jan Hidders 11:22, 6 Aug 2004 (UTC)

Yeah, I used the MathML player when I was still in IE. It seemed to work fine, and is free. MathML is probably the ideal future solution, but ideals are commonly nonviable.

Maybe we can make some sort of compromise? add an attribute "inline" to the math tags ( <math style="inline">, etc. )to make it format as HTML if at all possible, or in small-lettered, center-aligned TeX if not? And when converting to HTML, change the span.texhtml { font-family: serif; } to something that renders prettier? Perhaps just leave it in the default font? - Omegatron 13:36, Aug 6, 2004 (UTC)

From what I can gather, TeX's chief weakness is its inability to guarantee the generation of inline HTML (by default, of course; user preferences would always be able to force PNG generation.) I am convinced that this can be worked around, but I openly admit that the solutions (like using \mbox{ } instead of a space) are cumbersome. Another weakness is that the inline HTML is rendered in a different font than the HTML that surrounds it. Only the developers can fix this problem, as they control the MediaWiki CSS.

At the same time, responders seem to generally agree that there are tangible benefits to preferring the <math> markup to ordinary HTML.

I see the workings here of a possible compromise:

1. Content and accuracy are more important than anything else. Compared to these, the beauty of a page's math should be an afterthought.

(I'm afraid I can't agree that considerations of beauty "should be an afterthought". Of course content and accuracy are of paramount importance, but if an article is so off-putting, that it isn't read, well … Paul August 16:34, Aug 24, 2004 (UTC))

1. Allow people to continue creating and formatting equations in the "wikitext math style" currently described on the WikiProject Mathematics page, but recommend use of the <math> tag for future entries.
2. When using LaTeX, the "house style" will be to avoid generating PNG images for inline equations and variables. Anyone TeXifying wikitext math must be careful to preserve the HTML format for all inline expressions and variables; when this cannot be done, they should leave the expressions and variables as they are. Conversely, if the TeXification of a page's math expressions is done correctly, there should be no reason to remove it.
3. The WikiProject Mathematics page will feature a tutorial on how to keep LaTeX from generating images so that Wikipedians can share tricks like \mbox{ } with others. I can help to write this.
4. Expressions on their own line may freely be converted to PNG, so house style will be to prefer that complex expressions remain on their own line whenever possible.
5. Convince the developers to use a prettier font-family, font-weight, font-style and font-size for inline HTML conversion (what specific settings would be ideal I do not know.)

Does this sound like a reasonable set of guidelines? Would anyone be opposed to them, and if so, what can I do to improve them? --Ardonik 19:10, 2004 Aug 6 (UTC)

"Well, the ideal solution would be …"

Well, the ideal solution would be to just have any and all articles that use mathematical expression to jettison HTML entirely and have the whole thing be a LaTeX file. This would eliminate all the problems. (I'm being facetious, of course...but also trying to indirectly point out what the problems are short of doing this.)

From what I can gather, TeX's chief weakness is its inability to guarantee the generation of inline HTML.

It's a bit more than that. For people who dislike the ugly "discontinuity" of alignment between HTML and PNG, and find it personally disruptive, solving this problem would still these people to choose "always HTML" and so give up inline PNG images altogether. But why should they have to do that?

The guidelines sound alright. I still believe that for relatively simple things, it's best to leave in HTML as we've always done. I'm talking about the greek letter "π", for instance. Or, single variables, like "x" or "y". Nothing gets me more than seeing a variables that stands out nearly TWICE AS TALL as the text size I'm reading. For more complicated inline expressions, I have a lot more tolerance and understanding. But, even something like Z/2Z, doesn't seem to need texifying. Of course, I'm sure I draw the line much farther than most other people.

Revolver 19:50, 6 Aug 2004 (UTC)

Here is where you and I disagree--I think anything related to math should be TeXified, so as to indicate that the information being marked up is math and not prose. I've already outlined my reasons for preferring this, so I'll have to accept that we will differ on this point. But remember that with inline HTML generation, the user should not see any drastic difference between &pi; (π) and <math>\pi</math> ($\pi$). The only real difference to the user will be that they can change the look of the second one on the fly with a single change to their preferences. --Ardonik 20:48, 2004 Aug 6 (UTC)

Your assertion is just not true. Obviously, you have never attempted to do this on IE personally, or you wouldn't claim this. Here's the problem: too many math expressions are not changeable (or won't change) to HTML. So, even after changing preferences, the user is STILL bombarded with a ton of inline math expressions, esp. at articles like curve and a lot of the category and algebraic topology articles. These things can't be changed to HTML, and given that there will always be a wide variability in the size people choose for their fonts, someone will be left looking at disruptive text. Revolver 17:45, 24 Aug 2004 (UTC)

Crazy idea

This may seem like a crazy idea, but it would be something I would be willing to contribute time toward. There is a company which makes a semantic interface onto LaTeX (Scientific Works), which you can enter into directly (not WYSIWYG, but logical interface). It takes very little time to enter stuff, about as fast as using a word processor. Then, there is a viewer that comes with it which is free for anyone to download on the internet. So, once you make a file, you just direct someone to download the viewer and view the file with the viewer. There is absolutely no TeX code involved at all.

While this is clearly not workable for the wiki pages that people work on, it might be possible to do periodically for some of the more important math and technical pages, I'm thinking of Wikipedia 1.0 in particular and its updates. The number of articles here wouldn't be too much, it would be much better visually, and both the wiki-HTML-PNG version as well as the Works version could be available for people to choose.

Otherwise, I'm just starting to think, while the CD-ROM viewers of 1.0 will have the option of which way to see it, the people reading the paper version will not.

Revolver 20:10, 6 Aug 2004 (UTC)

The best way to integrate any document-viewing plugin is with XHTML's <object> tag; say, something like

 <object data="proof.tex" type="text/plain" width="400" height="200">
   alternative text (i.e. inline HTML for the proof)
 </object>

sort of like an "applet" for math pages.

Yet I would still prefer the current system of integrated LaTeX to this--the user doesn't have to know that we're using a LaTeX back-end, and we can swap it out with something more effective (read: MathML) at any time. It's definitely not as easy to use as a WYSIWYG editor, though.

Ardonik 20:57, 2004 Aug 6 (UTC)

My own two cents: In principal, I completely agree with the idea of writing all math code in TeX. That being said, I must object to actually doing this at present. I personally think that all inline TeX—whether rendered as HTML or PNG's—looks terrible. More than once I've avoiding reading a math article (let alone bothering to edit it) simply because I don't want to get a headache trying to wade through the changes in font sizes. In principal, the TeX->HTML shouldn't look bad, but it does. Yes, I know this can be fixed by a simple change to the wiki CSS file, but no one seems to be doing this. In the meantime, I'd much rather have a article that I can read rather than one which is semantically "correct".

Point 2: I think the real push should not be towards getting everyone to TeXify everything, but rather towards getting the wiki developers to implement MathML output. I believe that MathML is a viable solution now! Not some distant future. MathML looks reasonable in Mozilla browsers and plugins are available for other 'less competent browsers'. If you ask yourself why there isn't better browser support for MathML, the answer is pretty obvious: there just isn't much demand for it. What's needed is a site like Wikipedia, with its large quantity and quality of math content, to start outputing things in MathML to increase demand. Who should we be talking to, to push this matter?

In the meantime, I will continue to use pure HTML for everything inline simply so I can read it. I will starting inputing TeX as soon as wiki starts outputing MathML. As to having to rewrite all the articles when this happens, I don't think it's such a big deal. It's not like it has to be done all at once. Articles are getting edited all the time, they can be converted piece by piece. And until they are, it's not like they're going to be unreadable.

Fropuff 04:08, 2004 Aug 8 (UTC)

For changes to the CSS file you could do a request at the wikitech-l mailing list [1]. I suspect that if you make clear that this is a common complaint in the math community there will be a quick response. I'm not really an expert on CSS matters, so I cannot do this myself. As far as real support of MathML goes, see the discussion on this in this newsgroup last week (in August 2004) with subject "Status of MathML support". -- Jan Hidders 09:51, 8 Aug 2004 (UTC)

Fropuff, you think that neither TeX's PNG rendering NOR its inline HTML look good? Honestly, is the serif font on your browser that ugly?

I've performed an experiment in the interest of furthering this conversation. I have just TeXified the entirety of the determinant article, trying as much as I could to keep inline statements from rendering as PNGs. I will disclose now that in four areas, I failed to accomplish this task, though not for lack of trying:

1. The \approx symbol in TeX apparently forces PNG output, in spite of the existence of the &asymp; entity in HTML. I could not find a suitable replacement for this.
2. I was unable to specify a bold font for the "R" characters in ${\textbf {R}}^{n}$ without generating PNGs. From the documentation I read today, it seems that the command to do this is \textbf, but it apparently has the same effect as \mathbf in the MediaWiki.
3. The correct way to prevent $|A|$ from looking spaced out is to use the \left and \right commands, but for reasons unknown to me, <math>\left| A \right|</math> displays as a PNG: $\left|A\right|$.
4. I couldn't find an inline sqrt or a square root symbol. Using \sqrt{} guarantees PNG output.

Anyway, here are links to the old version and the current version. Compare the way they look. Except for the places I mentioned above, how similar are the two articles? Do those of you who dislike TeX's HTML output still dislike the text that you see?

It took me several hours of browsing through manuals and latex files to fully TeXify the article (I'm still learning TeX, too), but if any of you feel that I've mangled it or inserted something contrary to fact, please revert my changes.

Ardonik 11:33, Aug 8, 2004 (UTC)

Determinant#Derivative is somewhat messed up. The first two expression render differently of the last two... IMO major, i.e. long, expressions should (be allowed to) render as PNG and be placed in a new line, for clarity; there should be no "tricks" when writing <math> so that it is easy to edit and convert to some later format; expressions and/or single letters/symbols inline with text should be <math> also, although uglyer it is more clear.--Nabla 12:40, 2004 Aug 8 (UTC)

I honestly think the old version of the determinant article looks far better. If there isn't a whole lot of inline TeX, the effect isn't too bad, but take a different example with a higher density: compare the current version of Representable functor to the last unTeXified version [2]. Again, I think the old version is far more readable.

"Honestly, is it the serif font on your browser that's ugly?" No, I actually approve of the serif font. It's the size that bothers me. PNG's are too large, the text of the TeX/HTML is too small (hard to read in fact). When the two are used side by side its just a mess. I know this may sound nitpicky, but I honestly get a headache trying to read that stuff.

Fropuff 14:26, 2004 Aug 8 (UTC)

I agree with Fropuff that the inline PNGs are very ugly and with Ardonik that it would be preferable to use <math> tags to deliminate maths expressions. The discussion that Jan pointed to shows that we will probably not have MathML output in the near future. The only satisfactory resolution, as far as I can see. is to improve the translation of <math> environments to HTML, so that for instance <math>|A|</math> automatically renders as |A|. -- Jitse Niesen 18:19, 8 Aug 2004 (UTC)

Is it just me, or do the HTML sup constructs show up really low? Compare x² to $x^{2}$. This makes articles that contain many superscripts very hard to read because the superscripts are hard to distinguish from regular text. TeX/HTML renders the superscripts much better in my opinion. Gadykozma 14:14, 27 Aug 2004 (UTC)

The both 2's look to be at the same height for me - the bottem of each "2" just below the top of the "x". Paul August 16:33, Aug 27, 2004 (UTC)

The TeX version looks awful -- the x of x^2 protrudes far below the "baseline" of text. The HTML version is balanced in height and more readable. Revolver 09:00, 31 Aug 2004 (UTC)

Maybe it was a linux problem, or the specific version of Mozilla/Galeon I usually use. Now I'm on windows and both look fine. Gadykozma 18:59, 1 Sep 2004 (UTC)

A clarification

A Clarification -- one more reason I prefer HTML. Besides lots of things not being able to render in HTML, there is another big problem. Many people urge me to change my preferences. But then a lot of expressions I wish were KEPT in TeX get changed to HTML when I don't want them to!! This happens for example at the article pi. Long, single-line expressions get chopped up and rendered often in a silly manner. Besides, for single-line, I WANT TeX. Why should I be force to give it up?? Revolver 09:04, 31 Aug 2004 (UTC)

Good point. The preference "HTML if possible or else PNG" renders fractions as HTML, which looks terrible (at least in my browser). A possible solution is to change the software so that all single-line expressions are rendered as PNG, even if they could be rendered as HTML. With single-line expressions, I mean lines that contain only a <math>...</math> construct, and possibly white space. I do not know how feasible this is technically. What do people think of this idea? -- Jitse Niesen 10:22, 31 Aug 2004 (UTC)

Its strange nobody seems to have mentioned the project for a paper version of wikipedia, meta:Paper Wikipedia. This seems very relevant to the question whether LaTeX or html markup is to be preferred. Gadykozma 18:23, 5 Sep 2004 (UTC)

Editing the articles on set theory.

Although I've been editing for about a month, I've just discovered this page.

I've been doing more and more edits to the articles on set theory, and I'm contemplating rewriting the article Set. I posted some discussion concerning my proposed changes at Talk:set and Talk:naive set theory but so far no one has responded. Perhaps no one is watching these pages, or has nothing to say regarding my posts ;-) However, at the risk of being accused of not being bold, I'm reposting them here, just in case anyone cares. If not I will go on blissfully editing to my hearts content - until someone objects.

(The following comments and proposal is now pretty much moot, as I've made the changes I proposed below. Paul August 21:00, Aug 27, 2004 (UTC))

I think there is too much overlap between the articles Set and Naive set theory.

In reviewing the change history for Set, I find that the earliest versions of this article (can anyone tell me how to find the original version, the earliest I can find is as of 08:46, Sep 30, 2001) contained the following language prominently placed in the opening paragraph:

"For a discussion of the properties and axioms concerning the construction of sets, see Basic Set Theory and Set theory. Here we give only a brief overview of the concept." (The articles referred to have since been renamed as Naive set theory and Axiomatic set theory resp.)

As subsequent editors, added new information to the beginning of the article, the placement of this "brief overview" language, gradually moved further into the article, until now it is "buried" as the last sentence of the "Definitions of sets" section. Consequently I suspect that some new editors are unaware that some of the material being added to this article is already in, or should be added to Naive set theory or even Axiomatic set theory (e.g. Well foundedness? Hypersets?).

If it is agreed that, Set is supposed to be a "brief overview" of the idea of a set, while Naive set theory and Axiomatic set theory give more detail, I propose two things:

1. Add something like: "This article gives only a brief overview of sets, for a more detailed discussion see Naive set theory and Axiomatic set theory." to the opening section of the article Set.
2. Move much of what is in the article Set to Naive set theory or Axiomatic set theory.

Comments?

Paul August 20:23, Aug 16, 2004 (UTC)

I have moved the sections on "Well-foundedness" and "Hypersets" to Axiomatic set theory, which I think is a more appropriate place for them - based on the idea expressed above that the Set article shold be a "brief overview". Paul August 07:34, Aug 18, 2004 (UTC)

I should have added a third item to my proposal:

3. Rewrite the remaining parts of Set in a more elementary style. (The idea being that Set would be at the elementary/high school level, Naive set theory would be at a high school/college level and Axiomatic set theory at a college/graduate school level)

If you want to look at a first draft of a rewrite of Set, see: Paul August/Set.

I've now completed my rewrite of set Paul August 21:00, Aug 27, 2004 (UTC)

lastly, a couple of questions about notation. Why is "{}" preferred over ∅ for the empty set? "{}" looks kinda ugly to my jaundiced eye. Also is A\B preferred over A - B for set theoretic difference?

Actually I've got lots more questions, (especially about markup - are there any standards?) but that's enough for now. If this is not really the right place for all this, then my apologies. Paul August 03:47, Aug 19, 2004 (UTC)

Have at it. Your changes sound good to me. I think ∅ is far more common than {}. I've always preferred A - B to A \ B, but the latter seems more common and is used (presently) in the article Complement (set theory) — Fropuff 05:03, 2004 Aug 19 (UTC)

(Note: I've taken the liberty of moving the disccussion on "{}" versus ∅ which used follow here to the following new section below. Hope that's koser ;-) Paul August 18:14, Aug 24, 2004 (UTC))

A friend of mine recently pointed out to me another article that should be considered in a revision of our set theory coverage: Language of set theory. It's a poor article currently, but you might be able to take it somewhere. I was thinking perhaps that it should highlight how other mathematics can be built using set theoretic language (for example, how relations, functions, and ordered pairs are expressed as sets.) Isomorphic 18:05, 19 Aug 2004 (UTC)

Yes this article needs some help. I'll see what I can do. Paul August 21:00, Aug 27, 2004 (UTC)

Notation for the empty set: "{}" vs. ∅

(Note: I've taken the liberty of moving the disccussion on "{}" versus ∅ from the previous section to here. Paul August 18:14, Aug 24, 2004 (UTC))

Why is "{}" preferred over ∅ for the empty set? "{}" looks kinda ugly to my jaundiced eye. Paul August 03:47, Aug 19, 2004 (UTC)

… I think ∅ is far more common than {}. Fropuff 05:03, 2004 Aug 19 (UTC)

The reason that some prefer {} over ∅ is that many popular browsers such as explorer and konqueror cannot display ∅. -- Jan Hidders 08:46, 19 Aug 2004 (UTC)

hmmm all my browsers Safari, OmniWeb, IE (all on Mac OSX) display it fine. Paul August 12:29, Aug 19, 2004 (UTC)

My IE under Windows XP doesn't and neither does Konqueror (on Mandrake Linux). For the record: IMO we should use ∅ anway. In fact, I think that if looks are important there is no problem as long as there is a free, open source browser that can be easily installed on several platforms, is standards-compliant and displays the article as it is suppposed to look. But that's just me. :-) -- Jan Hidders 13:06, 19 Aug 2004 (UTC)

Based on the above It looks like there might be an emerging consensus that &empty is better than {}. any objections? I wouldn't mind going around and changing {} to &empty. But it's a little work, and I don't want to do it if anyone is just going to change them all back. Paul August 20:17, Aug 22, 2004 (UTC)

You have my vote. But we/you should probably first try to formulate a policy on the project page. That gives you something to point to when watchers of articles who didn't follow this discussion start complaining. Formulating such a policy and trying to make it sound sensible is IMHO a good sanity check to see if this change is ad-hoc or can be fitted in the broader picture. -- Jan Hidders 21:46, 23 Aug 2004 (UTC)

Jan makes a good point. I've frequently included HTML entities for various symbols in my posts, and sooner or later someone will come along and change them because they don't display in browser X (almost always IE). A few of the named entities that won't display in IE (with default fonts on my Windows 2000 system) include

&empty; (∅), &notin; (∉), &lowast; (∗), &otimes; (⊗), &lang; (⟨), &rang; (⟩), and &alefsym; (ℵ)

The unnamed symbols that I most frequent want are U+210F (ℏ) and U+21A6 (↦). These I've avoided using altogether as I think support for them is probably worse (although they both dispaly fine in my default browser). My personal vote is to say anything in Unicode is fair game (it's valid HTML after all), but I may be in a small camp on this one. -- Fropuff 23:04, 2004 Aug 23 (UTC)

It's very annoying that on some browers I use (I use multiple computers and multiple browsers) many of the set theory articles or just articles with lots of HTML set theory notation are completely unintelligible, because they read as "A (BOX) (B (BOX) C) = (A (BOX) B) (BOX) (A (BOX C)), unless A = (BOX) or B = (BOX).", or worse "(BOX) (BOX) A = A if and only if A = (BOX)". With many of these, I don't even bother to read them, I just leave. I suspect lots of other readers do as well. Revolver 17:29, 24 Aug 2004 (UTC)

Having said this, there are some symbols that are impossible to render HTML (intersection?) and so I often end up using it anyway. Revolver

So Revolver, does this mean you prefer we stick to using "{}"? Paul August 18:14, Aug 24, 2004 (UTC)

For now, yes. It's not as good as << empty set >>, but it's better than << (BOX) >>. Revolver 07:32, 26 Aug 2004 (UTC)

I'd say it is better to use the TeX version ($\varnothing$) than {}. This is, at least, both standard notation and universally visible, if somewhat ugly when set inline with normal text. -- Fropuff 21:48, 2004 Aug 27 (UTC)

Well I also like $\varnothing$ better than {}, just about anything would be. Should this be the preferred way? Paul August 23:56, Aug 27, 2004 (UTC)

I make a very strong vote against &empty;. Why? Almost all our readers use IE, which doesn't support it! I like <math>\varnothing</math>, because the software can render it according to user preferences and HTTP browser information, which is the best solution for everyone (if it doesn't do this now, at least the potential is there). Derrick Coetzee 01:39, 28 Aug 2004 (UTC)

Agreed. I'm only wondering if there is a difference for you between $\varnothing$ (<math>\varnothing</math>) and $\emptyset$ (<math>\emptyset</math>). On my Mozilla (under the pref. "HTML when possible" for math) the latter renders better. -- Jan Hidders 01:56, 28 Aug 2004 (UTC)

The same difference there is between $\epsilon \!\,$ and $\varepsilon$, between $\phi$ and $\varphi$ and between $\sigma$ and $\varsigma$. — Miguel 23:21, 2004 Dec 3 (UTC)

Oh, yikes, Firefox's math HTML rendering is inconsistent with TeX! — Miguel

Depend's on what you're preferences are. When they both render as PNG's I like the \varnothing one better. But certain preferences will convert \emptyset to the HTML &empty;. So maybe that's the better one to use. -- Fropuff 02:17, 2004 Aug 28 (UTC)

For me, under Safari for any math rendering preference setting:

• ∅ (&empty) looks like a circle with slash - my preference
• $\varnothing$ (<math>\varnothing</math>) looks like a circle with a slash- a little bigger circle, slightly more horizontal slash - my second preference.

With either "recommended for modern browser" (not sure what this pref means exactly) or "Always render PNG", then

• $\emptyset$ (<math>\emptyset</math>) looks like a rather ugly oval taller than wide with slash. - don't like this one much, but better than "{}"

While with "HTML if possible or else PNG"

• $\emptyset$ (<math>\emptyset</math>) looks the same as &empty.

How does IE render <math>\emptyset</math> ? Paul August 04:18, Aug 28, 2004 (UTC)

IE, with default preferences renders both <math>\emptyset</math> and <math>\varnothing</math> as PNG's. The former looks like a tall, skinny oval with a slash through it, and the latter as a circle with a slash through it. -- Fropuff 04:33, 2004 Aug 28 (UTC)

Given all this, I vote for $\emptyset$, because it yields HTML where settings allow it and works in IE. It's also very common in LaTeX documents. Do we have consent? Derrick Coetzee 04:38, 28 Aug 2004 (UTC)

I support a <math>...</math> based solution. Personally, I would prefer \varnothing over \emptyset, but if the majority style here is \emptyset, I can stick with that, too. FWIW, in my LaTeX documents I usually have a global redef in the global preamble, as in \def\emptyset{\varnothing}, and then use \emptyset later on. BACbKA 23:25, 3 Dec 2004 (UTC)

I think the notation {} is too confusing. We should use some variation on the slashed O sign, even if it doesn't render properly everywhere. Gadykozma 05:03, 28 Aug 2004 (UTC)

In my opinion {} or { } is better because it still has a connection to the set notation due to the braces. whereas $\emptyset$ is a completely new symbol and the connection with emtpy set has to learned and cannot be inferred. MathMartin 22:28, 3 Sep 2004 (UTC)

If by "completely new" you mean "widely used in papers for decades"... keep in mind this is the default LaTeX empty set symbol. Derrick Coetzee 23:12, 29 Oct 2004 (UTC)

This was my personal opinion (I should have said so). Of course we should use the symbol which is most common, if this is $\emptyset$ so be it. MathMartin 21:41, 22 Nov 2004 (UTC)

I would say that {} is the empty set, while $\emptyset$ is a symbol for it. Which notation to use should depend on the context. — Miguel 18:01, 2004 Nov 26 (UTC)

Out of curiousity could you provide an example where it is better to use $\emptyset$ than {} ? MathMartin 22:00, 3 Dec 2004 (UTC)

Sure: $\{\emptyset \}$ is more readable than $\{\{\}\}$. — Miguel 23:06, 2004 Dec 3 (UTC)

Avoid notational conventions! Sometimes "{}" works better, sometimes "∅" works better; sometimes TeXvc works better, sometimes it doesn't. There are special circumstances; if a common browser cannot render a version, then it's justified to warn writers against that version. Still, the only basis for debate in that case is to determine whether the special circumstance obtains, and the only conclusion to draw is that the number of options is lowered by one. Of course, people that are interested in æsthetics are free to discuss their personal preferences as much as they like; I have my own opinion on this matter, which I'd be happy to chat about on my talk page or even by email. But Wikipedia does not need a standard for every notational debate. -- Toby Bartels 23:55, 3 Dec 2004 (UTC)

∪ symbol displays as box?

Someone edited the set article, changing each set union symbol "∪" (i.e &cup) to an uppercase U, because they were displaying as boxes. Is there a problem with rendering ∪? It looks ok for me (Safari, IE, OmniWeb on MAC OSX). Does anybody else have problems with this? Paul August 19:48, Aug 31, 2004 (UTC)

The right thing to do if your browser does not display "& cup ;" is to use <math>\cup</math>, never to replace it with "U". — Miguel 23:41, 2004 Dec 3 (UTC)

Schaun MacPherson

At User_talk:ShaunMacPherson, I have invited that person to discuss on this page his implicit decision to move hundreds of articles titled ABCD's theorem to ABCD's Theorem with a capital T, and similarly for conjectures, lemmas, axioms, etc. In case anyone can be more effective in persuading him that I can, I mention that here. (If you are Schaun MacPherson and do not wish to pursue the matter, please feel free to delete this section.) Michael Hardy 20:40, 31 Aug 2004 (UTC)

Personally, I don't think the word theorem, lemma etc. should be capitalized in this context. But it's a minority view. A number of editors threw out my preferences and capitalized them. Gadykozma 23:51, 3 Sep 2004 (UTC)

New Article: The algebra of sets - request for comment.

I've just created a new "set theory" article: The algebra of sets I'd be interested if anyone has any comments. In a sense it's an expanded version of Simple theorems in the algebra of sets the latter being primarily just a list. One could argue that consequently the latter article is no longer necessary. But I can see the possible use of an article which simply lists results. Comments? Paul August 03:53, Sep 6, 2004 (UTC)

Hmmm - a few questions relative to the integration with the rest of WP. What you mean mostly is 'here is some explicit information about the Boolean algebra of sets'. Which might be useful to some people, indeed. Since the 'set of all sets' is chimerical, your 'algebra' is not precisely a Boolean algebra; the subsets of a given set X would give a Boolean algebra. I think this kind of placing would be helpful; and probably renaming the page. Charles Matthews 08:07, 6 Sep 2004 (UTC)

Charles, thank you for your comments. As to the title, I took my lead from Simple theorems in the algebra of sets. The word "algebra" here is not being used as a technical term, as say in "Boolean algebra" or "linear algebra" but rather as a descriptive term, for this collection of facts concerning "the basic properties and laws of sets, the set-theoretic operations of union, intersection, and complementation and the relations of set equality and set inclusion." The motivation for using the word "algebra" beyond it's descriptiveness, is to help the reader make the connection to the perhaps more familiar notion of algebra of numbers. It is a relatively common way of describing this material. For example Robert R. Stoll in Set Theory and Logic has a section titled "The Algebra of Sets", as does Seymore Lipschutz in his Set Theory and Related Topics (Schaum's Outline Series). Having said that I'm not opposed to finding a better name for the article. I had also considered simply "Set algebra" as an alternative name. What name are you proposing? As you say, and as is pointed out in the article, the power set of a given set is a Boolean algebra. As to your other suggestion of "this kind of placing would be helpful" I'm not sure what this means, could you please be more specific? Thank you again. Paul August 16:41, Sep 6, 2004 (UTC)

I would like to see even more analogies with usual algebra. A) You never say explicitly which operation is the analog of addition and which of multiplication (does this make sense? If not, the article should explain that too). B) Analogs of (a <= b) => (a+c <= b+c) should be highlighted. C) perhaps to put to the right of every inequality the anaolg (if it exists) in usual algebra? Arrange everything in comparison tables? I feel I'm starting to float. Think about these. Gadykozma 12:13, 6 Sep 2004 (UTC)

Gadykozma, thanks for your comments. As far as the analogy holds, union is the analog of addition (in fact the union of two sets has been sometimes called their "sum") and Intersection is the analog of multiplication. The article used the order of their mention to try to make this clear (perhaps a well placed "respectively" is needed.) As I partially said above, the use of this analogy is to help motivate these ideas for the reader, and to help place these facts concerning set theory in an appropriate setting. Including the fact that A ⊆ B ⇒ (A ∪ C) ⊆ (B ∪ C) is probably good in it's own right, that it continues the analogy is also nice. But I think we should be careful about relying too heavily on the analogy. It is not meant (by me at least ;-)) to be an article about the analogy. Paul August 16:41, Sep 6, 2004 (UTC)

cdot and times

In LaTeX markup, does \cdot equal \times?, that is do they represent the same mathmetical function or is it just a center-aligned dot? -- Ævar Arnfjörð Bjarmason 13:08, 2004 Sep 12 (UTC)

\times: $5\times 5=25$ ; \cdot: $5\cdot 5=25$ -- Ævar Arnfjörð Bjarmason 13:08, 2004 Sep 12 (UTC)

Yes, they are both multiplication. \cdot is more appropriate for advanced texts and \times for beginner level texts. Also \times is used in advanced text to denote "special" kinds of multiplication like vector product or Cartesian product. Gadykozma 14:49, 12 Sep 2004 (UTC)

variable letters

Probably doesn't matter, but is there any standard for variable letters? For instance, most people use i for the imaginary number and f(t) for a function vs time, but I am used to engineering convention, which uses j for the imaginary number (because i is current), and x(t), since f is frequency in fourier transforms, etc. should we just use whatever variables are conventional in each specific topic? and what about a topic like fourier transforms which are used in contexts with i for current but also used in unrelated contexts where the majority of people would be used to i for imaginary number? - Omegatron 01:34, Sep 19, 2004 (UTC)

• Don't use j for the square root of -1, unless the article has a strong engineering flavor, and in this case warn in the beginning.
• Other issues you raised are pretty free. Not that I like x(t), but I don't see it as very distracting to understanding. Gadykozma 02:11, 19 Sep 2004 (UTC)

ok. should you mention this on the wikiproject page? yeah, and x(t) is confusing because of f(x). but then it would be confusing when you transform to X(f), etc. etc. - Omegatron 02:21, Sep 19, 2004 (UTC)

In some cases, x(t) is the most appropriate, e.g. the vector-valued function of time x(t) = (x(t), y(t), z(t)). Revolver 05:48, 24 Sep 2004 (UTC)

Simple formulas

Some of what you say just isn't true: "If you enter a very simple formula...this will not be displayed using pgn but html, like this:", but this does display as a PGN for me. If you ask me to change my preferences, then many legitimate LaTeX formulas will becomes emasculated (see pi.) To see what I mean, you say the L^infin is "horrid", but it looks exactly the same as the L^p above to me! Why is one horrid and the other not?? Revolver 20:43, 22 Sep 2004 (UTC) (Moved from project page 23:15, September 22, 2004 by Gadykozma)

It depends on your preferences, browser rendering of HTML, etc. I have tentatively converted to the "everything in math tags no regular text in italics" camp, and even switched my preferences to "render everything in PNG". It takes a couple articles to get used to but then I liked it. Most math websites look like that anyway. - Omegatron 20:46, Sep 22, 2004 (UTC) (Moved from project page 23:15, September 22, 2004 by Gadykozma)

That's what I have now!! I've had it for weeks or months that way and still hate it. Perhaps it's my HTML text size relative to PNG. The PNG's are just TWICE as tall and FOUR times as big as HTML. This is what he meant above by "horrid". Revolver 21:16, 22 Sep 2004 (UTC) (Moved from project page 23:15, September 22, 2004 by Gadykozma)

Actually, I think they were showing that the HTML rendering of TeX (not the PNGs) and the plain old HTML letters look different. The TeX rendered into HTML is in a serif font and kind of weird sizes, so it doesn't match with the rest of the text. I guess some people like it like that. You can change it in your user css if you really want, although you, Revolver, have always PNG, so it doesn't matter. - Omegatron 23:56, Sep 22, 2004 (UTC)

Also, does it do this for you?: do the PNG's go below the bottom justification of the HTML text? It does for me. It's just the size of them, it's that they protrude below the line of text, so that e.g. the "p" in L^p is no longer a superscript, it reads horizontally on the same level as an HTML "p" (or very close). Revolver 21:19, 22 Sep 2004 (UTC) (Moved from project page 23:15, September 22, 2004 by Gadykozma)

They look centered in the middle of the line to me. I used Firefox. Bigger than the rest of the text, but I am used to it, and it looks better than the TeX rendered as HTML. You see it like that on webpages all the time. - Omegatron 23:56, Sep 22, 2004 (UTC)

OK, I guess I didn't write it quite as well as I intended. What I had in mind was to convey two points:

• How Wikipedia displays simple formulas with the default parameters, which is what most users use (this need to be said!)
• That people don't like when you change their text from one to the other (the only thing that everyone agreed on in the very very very very very very very long discussion).

Anyone has a better idea how to convey this information? Gadykozma 23:31, 22 Sep 2004 (UTC)

Upright differential operators

I was extraordinary happy when I saw that subscripts that are not variables should be upright Far from everyone has understood that. Another thing people, even here at Wikipedia, don't put uphright is the differential operator, and I dislike it from the bottom of my heart! ;-) Wouldn't it be a good idea to advocate such "d":s, in integrals and derivatives, too be put upright rather than in italics? - Jolson 17:40, 2 Oct 2004 (UTC)

In my experience, the "d" is upright in England but italicised in the United States. Being a United Stateser myself (my own personal conventions notwithstanding), I've seen quite a few examples of italics in the US and no exceptions. (More precisely, every time that I've ever noticed an upright "d" in published material, it turned out that the material was published in a foreign country.) Speaking more broadly, I'm against instituting unnecessary conventions on Wikipedia, and caution you (to avoid upsetting some people) against editing articles to fit your conventions. But by all means make your own "d"s upright when you write a new article (or rewrite an old one), if you wish. -- Toby Bartels 01:10, 4 Dec 2004 (UTC)

Pages for review

Hi guys. Could you review my page Marcinkiewitz theorem for correctness, fullness and especially readability? I tried to write it so that it will be readable (enjoyable?) by any graduate student or equivalent. Thanks Gadykozma 15:09, 8 Oct 2004 (UTC)

I'm pretty sure the name is usually Anglicized as Józef Marcinkiewicz. I've changed the links accordingly. Terry 06:01, 2 Nov 2004 (UTC)

Yes, sorry. Gadykozma 14:01, 2 Nov 2004 (UTC)

Here is another one I'd love input on, especially since I have no clue about the topic: Hearing the shape of a drum Gadykozma 14:24, 16 Oct 2004 (UTC)

OK, you want research pages here is one loop erased random walk. Tell me what you think. Gady 19:00, 7 Nov 2004 (UTC)

Another to review, if you please, for completeness and especially accuracy: Small set.—msh210 22 Nov 2004

And another: Modulo. —msh210 21:32, 7 Dec 2004 (UTC)

Wikipedia:Math 1.0

I found Wikipedia:Math 1.0 in a dusty corner. I think the goals and information needs to be merged with this WikiProject. Please take a look and salvage what you can. -- Netoholic @ 19:45, 2004 Oct 26 (UTC)

Well, it's kind of optimistic. It would be great to have the mathematics of the 1990s, and the twenty-noughties even, properly covered here. In many cases that would involve just writing articles with 'long words' in them: red links to concepts that we don't have. So, sometimes it looks like we should just expand coverage of 'core areas', with the long-term goals of getting to the frontier of research. Sometimes I add surveys of topics, to move things ahead; or add isolated (at present) theorems or conjectures. What really does need to happen is that the coverage as a whole stays balanced, even if it's a bit humiliating that the Atiyah-Singer index theorem is 40 years old, and we really still can't state it exactly, yet. Charles Matthews 19:57, 26 Oct 2004 (UTC)

Thue-Siegel-Roth theorem

Looks like the math formula need some work in this article - Thue-Siegel-Roth theorem, figured someone here could fix them. -- Netoholic @ 04:41, 2004 Nov 2 (UTC)

Yes, the second had an inequality reversed, thanks. Charles Matthews 07:51, 2 Nov 2004 (UTC)

Computability logic

As I have been editing a lot of articles in theoretical computer science lately, I noticed many references to computability logic on the pages. The ones I checked were inserted by User:Kntg. He is also the main editor of the computability logic article. My guess is the real name of the user is Giorgi Japaridze and he is hyping his own stuff [3]. I am unable to decide whether his ideas should be included in wikipedia or not, they seem to be relatively new. What do you think ? MathMartin 18:06, 14 Nov 2004 (UTC)

Since nobody responded, I looked into the matter though I do not know that much of either theoretical computer science or Wikipedia policies. As the article on computability logic explains, it is a new theory proposed by Japaridze in 2003 (MathSciNet lists only two papers on computability logic, both by Japaridze and published in 2003 and 2004; I've found no other references). User:Kntg has inserted a lot of references to Japaridze's work: they may be the same person or related (academically). I think there is no harm in having the computability logic article, though the status of the theory should probably be explained better. In my opinion, some links to the computability logic article are over the top (for instance, those at algorithm and computer science). Can somebody please give some further guidance to MathMartin? -- Jitse Niesen 13:22, 16 Nov 2004 (UTC)

I've had my eye on this for a while. The papers (or at least the one(s) in Annals of Mathematical Logic) are respectable. The links are not worth the prominence they are sometimes given; but I haven't done much about it except to tone down the coverage a little. At the moment it falls into the category of being a little bit annoying. We do have at least one active logician (User:Chalst) who could be consulted. Charles Matthews 13:38, 16 Nov 2004 (UTC)

My main objection are the links he inserted in many computer science articles not directly related to the computability logic article. I will remove them where necessary. I will leave the computability logic article as is, althought I do not think recent research material (2003, 2004) is appropiate for wikipedia inclusion. MathMartin 14:03, 16 Nov 2004 (UTC)

Japaridze and Computability Logic

I only just noticed this discussion. I had seen the disproportionately high profile the topic has taken, and wondered if maybe Japaridze was promoting his own material. A few points:

1. While I'm sure that whoever did these edits has some investment, careerwise and/or emotional, in the topic, there are reasons to doubt it is Japaridze, namely whoever it is hasn't done a terribly good job of summarising the topic; I would normally expect a researcher to do a better job than this;
2. I don't follow the detail of Japaridze's work myself, but a close colleague of mine does, and it is the real thing: solid research work that is well-motivated and perhaps has the potential to make a real impact;
3. The edits are gung-ho and lack perspective but they were not abusive and they have stopped. Take care when reintroducing appropriate perspective not to throw away perfectly good content: that cure would be worse than the disease. ---- Charles Stewart 21:55, 9 Dec 2004 (UTC)

PS. A point about the "no research" rule: the interpretation given at the authoritative Wikipedia:What Wikipedia is not says:

Primary research such as proposing theories and solutions, original ideas, defining terms, coining words, etc. If you have done primary research on a topic, publish your results in normal peer-reviewed journals. Wikipedia will report about your work once it becomes part of accepted human knowledge. But of course you don't have to get all of your information on entries from peer-reviewed journals. See Wikipedia:No original research.

which I understand as saying that once ideas have passed the test of peer review, they are fair game for summarisation on Wikipedia. So Japaridze's work passes that test. ---- Charles Stewart 22:01, 9 Dec 2004 (UTC)

Thanks for your input. I think the business has been handled adequately, so far; the edits have been 'POV', obviously, but the WP response has been 'professional', i.e. proportionate, patient, and not too reactive. Charles Matthews 08:32, 10 Dec 2004 (UTC)

Trace

I'm wondering if we have an article on trace as it pertains to my understanding of it in crypto. That is, if $\beta \in GF(2^{m})$ then $\operatorname {Tr} (\beta )=\sum _{i=0}^{m-1}\beta ^{p^{i}}$ (forgive the crappy LaTeX, this isn't an article, just trying to get my point across ;)). I see trace (matrix) and field trace, but neither seem to be a good fit. If someone who understands these trace articles better can confirm that neither is what I'm speaking of, let me know and I can write up an article about the trace and its properties. Thanks. CryptoDerk 00:09, Nov 17, 2004 (UTC)

It's the special case of the field trace appropriate in a finite field of characteristic two (notation here: I think you mean that with p = 2, or GF(p^m). That's because any trace map is the sum of images of an element when you apply all elements of the Galois group to it; and here the Galois group is cyclic, generated by the p-th power map. Charles Matthews 08:45, 17 Nov 2004 (UTC)

Thanks. CryptoDerk 15:46, Nov 17, 2004 (UTC)

Zech?

Does anyone know who Zech's logarithms are named after? I tried various google searches and the only thing I can find is that there's some guy Boris Zech who published something in 2004 (although since the title is in German, I don't know what it's about), but MacTutor doesn't seem to have any info on anyone named Zech. Mainly, I'm just curious but it'd also be nice to have that info in the article. CryptoDerk 20:26, Nov 17, 2004 (UTC)

Category:Topological spaces and List of manifolds

It seems to me that Category:Topological spaces and List of manifolds largely duplicate one anoher. (More accurately: they would duplicate one another if they were full.) Seems like an unnecessary redundancy. Perhaps we can do as follows: Add Category:Manifolds as a subcategory of Category:Topological spaces; list manifolds only there (not in the parent category, per WP:CG), and get rid of List of manifolds. What say you all? —msh210 15:00, 26 Nov 2004 (UTC)

No. We have had a similar discussion. Lists are in general more useful and flexible than categories. I don't understand the argument, actually. Redundancy is not a criticism on a wiki. Charles Matthews 17:02, 26 Nov 2004 (UTC)

SKI combinator calculus

I just created the beginning of this article and would like to invite my fellow mathematicians to contribute and edit. I've just started to learn Wiki LaTeX, but I think I did a pretty good job with things. --L33tminion | (talk) 04:01, Dec 2, 2004 (UTC)

I'm sorry to break the news, but it doesn't seem that there's anything in SKI combinator calculus that wasn't already in the article on combinatory logic. Perhaps SKI combinator calculus (and SKI calculus) should redirect to combinatory logic, and anything in SKI combinator calculus not already in combinatory logic should be merged there. -- Dominus 18:03, 2 Dec 2004 (UTC)

Looking at the two articles, I'm not sure that they are redundant, even though they do cover some of the same information. If a merger is necessary, I don't know where to begin. However, I think that an article on the SKI system could exist independently from the article on combinatory logic in general. --L33tminion | (talk) 15:41, Dec 3, 2004 (UTC)