User talk:Cburnett/Math

May 5, 2005 archive start

Cramér-Rao inequality

Did I misunderstand or were you using both lower-case n and capital N for the same variable? (I've changed them all to lower-case.) Also, I have some qualms about writing "n samples" rather than "a sample of n observations". Michael Hardy 00:51, 13 Mar 2005 (UTC)

I believe I had it correct. If you put the observations into a vector then it's size N, but n is an arbitrary sample on [0, N-1] (or [1, N] depending on what your starting index preference is). Cburnett 17:06, 14 Mar 2005 (UTC)

period and math tags

Thanks for your comment about period at the end of formula. There is one think I would like to remark. You see, if you put the period after </math>, what can happen is that sometimes the browser separates the formula and the period, with the latter showing up on a new line. Try to make an experiment by resizing your browser window so that the formula is at the edge and you will see.

That said, my next project would be to put all periods before </math> rather than after. If you do not agree, probably now is the time to settle this matter. Cheers, Oleg Alexandrov 03:45, 19 Mar 2005 (UTC)

I'm vehemently opposed to having to make an article work around bugs or unexpected behavior (see discussion above to see what I mean). I did get my browser to wrap periods to the next line with equations (images really). However, I don't readily see this as a WP issue but rather a browser issue. Either way, whatever is decided on the wikiproject page I'll go with. Just can't promise I'll always remember. :) Cburnett 04:04, 19 Mar 2005 (UTC)

Probability distribution plots

Hi - MarkSweep said that you and he were generating all new plots for the probability distributions for use in the template. I was talking to him about the specifications for the plots, because I think I can do some also. I have generated plots for Poisson distribution and Levy distribution as examples of discrete and continuous PDF's. I need to know if these are acceptable before I continue, because I don't want to waste a lot of time on work that will be replaced. I have not been able to get hold of him, can you let me know if these are ok, or if any changes need to be made? Thanks for any help you can give me - PAR 18:34, 5 Apr 2005 (UTC)

Some quick comments:

• Should upload them to the commons instead
• I'm not sure what to think about the discrete cases...whether they should be continuous plots with marks (like what you did) or more like impulse graphs or just marks. I think your Poisson graph will probably be the easiest to read, but I'm still wary of people misunderstanding it to be continuous... maybe hashed lines or something?
• Please upload your gnuplot source as well under GPL or PD (otherwise I'll eventually replace it with my own and provide gnuplot source)
• Need matching cdf's for those graphs
• I don't think MarkSweep's images follow this, but I think it's helpful to do what I did here Image:Exponential distribution pdf.png
  • State the gnuplot source is at the commons
  • Link to the distribution, pdf/pmf, and cdf on each image
  • Add to Category:Probability distributions images

Otherwise, everything else looks great. Cburnett 18:47, Apr 5, 2005 (UTC)

With regard to the Poisson plot, check out the Skellam distribution where I put an explanation in the caption saying the lines did not imply continuity. I think hashed lines and dots is maybe too busy, and for impulses the multiple plots may be hard to separate. I'll go slow on the discrete ones, maybe we'll get a better idea. I did the plots with IDL, not gnuplot, etc. so should I leave the documentation up to you? The rest I will take care of. Thanks - PAR 19:49, 5 Apr 2005 (UTC)

I'm not too keen with Skellam pmf since it takes up a lot of space. Perhaps just simply "Only valid at integers" or something....or remove it entirely and put it in the text around the pmf equation.

In that case, would you mind making a list of distributions on the template talk page that need gnuplot source? If it will generate the same plots as you make then that's fine with me. Cburnett 20:40, Apr 5, 2005 (UTC)

Does that mean a list of distributions whose PDF and/or CDF images do not contain gnuplot source code on their respective pages? Because the Exponential distribution PDF only has a message "See the image on the commons for gnuplot source" which I don't get, because it leads to a rather general page. PAR 21:00, 5 Apr 2005 (UTC)

Yeah, those that do not have gnuplot code with them. Re: expo, you clicked the wrong link — you have to click the "description page" link to get to the image at the commons. Cburnett 21:02, Apr 5, 2005 (UTC)

With regard to images not in the commmons, do they have to be downloaded then uploaded to the commons, or can I simply replace the "PD-self" with "GDFL" in their respective pages? Or is there another way to avoid the upload/download? Thanks - PAR 19:04, 7 Apr 2005 (UTC)

No, you'll have to go to commons:Special:Upload and reupload it (probably want to create an account at commons as well). The commons is essentially a different wiki (so different upload and login pages) but setup to allow image usage as if it were on wikipedia. That help? Cburnett 19:08, Apr 7, 2005 (UTC)

I notice that some probability distribution images have Category:probability distributions and some have Category:probability distributions images. It seems to me the second should be in all, but what about the first? PAR 00:42, 10 Apr 2005 (UTC)

Hi guys, pardon my meddling, but I just noticed that we're all working on the same things and it might perhaps be easier to explicitly coordinate, so as to avoid duplication of effort. Second, our current practice for creating plots is documented on several talk pages, and it's hard even for me to stay informed about further developments, like the suggestions on how to handle discrete distributions above. How about we document the current practice on Template talk:Probability distribution and also add our names there to let everyone else know who's working on what? If Template talk:Probability distribution is not the best place, perhaps we could start a separate project, or move over to Wikipedia:WikiProject Probability? Cheers, --MarkSweep 01:31, 10 Apr 2005 (UTC)

I'm in favor of Template talk:Probability distribution. I'll direct comments there from now on. Let me know if there's a better place. PAR 04:21, 10 Apr 2005 (UTC)

WP:FICT

I am troubled by the fact that you readily declaim WP:FICT as POV-pushing, and the allegations to several users that I am using it to harm Wikipedia. Check your sources, as you haven't read the links on there. WP:FICT is not policy, and I never claimed that it was, but it does have a large consensus behind it on a recent public discussion page that was up for several weeks. Plus, WP:FICT only gives guidelines for the long-established idea of be bold. Merging is not deletion. Radiant_* 14:30, Apr 6, 2005 (UTC)

Well, I find something purported to be semi-policy with one author and no talk page, then I find you're the only one quoting and in a way that makes it look like policy. I already admitted that I somehow glazed over the discussion link, but if I had seen it then I would have left it alone. And I won't hide that I contacted some people I saw replying to your "as per WP:FICT" on VFD.

That said, when did I ever say it was "POV-pushing" and "harm[ing] Wikipedia". I am troubled that you're putting words in my mouth. Cburnett 14:34, Apr 6, 2005 (UTC)

You didn't use those exact words, but you have made thinly-veiled accusations of me unilaterally creating a policy (that would be POV-pushing) and then using it on VfD (that easily sounds harmful to WP). I don't know if this was intended or not, but your words are easily interpreted as such. Let me just state that nobody here has deleted, or is intending to delete, any of the Star Wars wikiarticles. This is, however, just meant as an explanation and I would prefer if we dropped the matter. Radiant_* 18:04, Apr 6, 2005 (UTC)

Yes I did make those accusations, which I implicitly retracted when pointed out that I missed the link to the discussion. There were no thinly-veiled accusations, I made them pretty directly. Rephrasing anything I said or did is your preroggative and open to your interpretations.

Without that discussion link, you did exactly what I said (from WP:FICT talk) you:

• did the bulk of editting on WP:FICT

• No, I didn't. WP:FICT was formed in the discussion Wikipedia:Deletion_policy/Minor_characters, where I am only one of many editors. I created WP:FICT because the title, 'deletion policy' makes it sound like policy, which it is not.

• seem to be the only one using it on VFD

• That may seem so, but it is simply not true. I am the major user so far, but other people are also using it. Go to WP:FICT and click on 'what links here' to find out. Plus there are some people using it without linking to it.

If you want to interpret that as POV-pushing and harming WP, then I'm not going to stop you.

In the end, all this stems from me glazing over the discussion link and interpretting what I saw: a user creating a policy and using it. Other than triple-checking for a discussion link, I'd do the same thing again and I'd take the blame for being stupid again. So what exactly do you want me to say? That I was wrong and you weren't the only editor of WP:FICT (which you did) and that you seem to be the only one using it on VFD (I chose numerous from "what links here" and you were the linker). So the two accusations are true. I'll gladly risk making a mistake to stop someone from making their own policy and acting on it. Cburnett 18:57, Apr 6, 2005 (UTC)

See above. Radiant_* 08:11, Apr 7, 2005 (UTC)

You aren't understanding me, you did the bulk of editting on WP:FICT: [1]. Cburnett 17:22, Apr 7, 2005 (UTC)

Noise and covariance

Thanks for your help with the Kalman filter article. I hope you don't mind my asking - given Q, how would one go about generating a sample from N(0, Q)? Thanks! — ciphergoth 11:00, 2005 Apr 17 (UTC)

Generally, you have to generate a vector of white noise with each element is independent from each other (as if the covariance matrix were identity). Getting access to a white noise generator is dependent upon your language, but almost all should be able to give you a uniform(0,1) generator which can be used with the Box-Muller transform to give you standard normal samples. (You can convert a standard normal to any other normal by multiplying by the desired standard deviation and add the mean.)

Once you have your normal samples, you have to do a process I can't recall of the top of my head. It involves taking the Cholesky decomposition of the covariance matrix and such. You'll probably have to search online or in a text for "pre-whitening", which does the opposite: whitens colored noise. Cburnett 16:59, Apr 17, 2005 (UTC)

Many thanks! Cholesky decomposition was the key phrase I needed, and once you have Q = AA^T it's simple. Let g be a random vector of values drawn from a standard normal distribution, and w = Ag. Then E[ww^T] = E[Ag(Ag)^T)] = A E[gg^T] A^T = AA^T = Q. Fantastic - thanks again!

Now the question is where to put that since it'd be worth putting on WP. Definitely on Cholesky decomposition and perhaps a pointer from colors of noise and Multivariate normal distribution to that section on Cholesky decomposition page? Cburnett 17:27, Apr 17, 2005 (UTC)

I would say detail it on Multivariate normal distribution and link to it on Cholesky decomposition rather than vice versa. — ciphergoth 20:06, 2005 Apr 17 (UTC)

Except it applies to any distribution...not just MV normal. Cburnett 00:10, Apr 18, 2005 (UTC)

I'm surprised by that - I had convinced myself that because normal distributions are the only ones preserved by summation, they were the only ones you could do this matrix trickery with. Could you give an example? — ciphergoth 08:31, 2005 Apr 18 (UTC)

Anything really, I guess. If you had a MV uniform(0,1) then E(g*g^T) = I*var(uniform(0,1)) = I*(1/12) then E(ww^T) = E(Ag(Ag)^T) = A * E(gg^T) * A^T = AA^T/12 = Q/12. The non-unity variance is taken care of by multiplying by the inverse of E(g*g^T), which is I think a missing part of w=Ag and should be w=AgR^-1 where R=E(g*g^T) or something. I'd have to sit down and double check that (might be off by a half) though.

Really though, stacking independent samples into a vector is essentially the same thing as if you had an MV normal. Cburnett 14:01, Apr 18, 2005 (UTC)

The covariance matrix for an independent MV standard normal vector is an identity matrix, that's what's so convenient. The thing is that an MV normal is characterised by μ and Q, and it stays MV normal when you apply a matrix to it. I guess what you say about an MV uniform is true, but it's less interesting because the resulting covariance matrix doesn't tell you everything you need to know about the resulting vector's distribution... — ciphergoth 16:53, 2005 Apr 18 (UTC)

Interestingness aside :), coloring/correlating random data is a "function" of the Cholesky decomposition. I'd be perfectly happy with a general method to coloring noise in the Cholesky decomp article and then a specific method for MV normal. Maybe even a note on probability distribution or something as well. At least so if someone's curious how to color noise, they can find it at Cholesky decomposition, a link on probability distribution, or at multivariate normal distribution where they're most likely going to color (since there's a prevalence of using WGN or AWGN). Cburnett 18:13, Apr 18, 2005 (UTC)

June 17, 2005 archive start

TeX versus non-TeX mathematical notation

Are you totally opposed to the use of non-TeX mathematical notation on Wikipedia? Obviously, if one uses TeX in the normal way, instead of the way it works on Wikipedia, then TeX is superior. But on Wikipedia, TeX gets badly misaligned and mis-sized when it is embedded in lines of text. When "displayed", on the other hand, TeX looks good. Michael Hardy 00:50, 4 Mar 2005 (UTC)

I guess you could put it that way. My preference is to have everything rendered as PNG and I can't think of a good excuse to not put everything equation related in tex. Compared to my browser, the HTML character set and tex character set do not match (italicizing is ok, but my browser won't render greek letters as italicized) and it looks horrible. If someone chooses to have their preference set to "render HTML when possible" (or whatever the option is) then most of the trivial tex changes should be rather moot.

If the alignment of tex with text bothers you, then that's another issue. I think there's a CSS addition you can make to change the alignment, but I forget where on WP I've read that. Cburnett 06:21, 4 Mar 2005 (UTC)

Kalman filter and var(X)

Please comment on the use of var(X) in Talk:Kalman filter - thanks! — ciphergoth 12:39, 2005 Apr 20 (UTC)

Inline TeX

You seem to like inline TeX so much that you're changing inline non-TeX mathematical notation to inline TeX. Why is that? On Wikipedia, TeX looks very good when "displayed", and in the normal use of TeX (as opposed to its use on Wikipedia), it looks very good either "displayed" or inline. But on Wikipedia, when TeX is embedded in lines of text, it often looks terrible; either far to big or badly misaligned or both. Michael Hardy 23:25, 28 Apr 2005 (UTC)

We've already had this discussion at least once.... Cburnett 23:31, Apr 28, 2005 (UTC)

Also, it is weird to write

$X\,$ ~ $N(0,1)\,$

instead of

$X\sim N(0,1).\,$

Michael Hardy 23:29, 28 Apr 2005 (UTC)

That was at MarkSweep's request since \sim isn't converted in HTML when possible. Should fill that out as a bug I guess. I've since changed usage of breaking out of tex since it clashes heavily when forcing PNG rendering. Cburnett 23:31, Apr 28, 2005 (UTC)

Allow me to comment: Let's distinguish inline TeX from inline <math> (because "TeX" is ambiguous between the TeX language and the tex program that is used to convert TeX expressions into DVI, which are then converted into PNG). I think a reasonable solution is to use inline math whenever it is possible to render it in HTML. The problem with ordinary markup (double quotes for italics, etc., as opposed to inline math) is not only that it's more cumbersome and error prone and less intuitive (need to remember to write &minus; etc.), but also that people who prefer math to be rendered as PNG everywhere (per user preferences) don't get formulas constructed with ordinary markup rendered as PNG. For those readers, ordinary markup is a minor annoyance surprise, because their user preferences have no effect. So I suggest we use <math> markup as much as possible, except where it would force an inline formula to render as PNG. So, for example:

rendered	source	comment
$X\sim \mathrm {N} (\mu ,\sigma ^{2})$	<math>X \sim \mathrm{N}(\mu,\sigma^2)</math>	bad, forces PNG rendering
X ~ N(μ, σ2)	''X'' ~ N(''μ'', ''σ''<sup>2</sup>)	bad, precludes PNG rendering
$X$ ~ $\mathrm {N} (\mu ,\sigma ^{2})$	<math>X</math> ~ <math>\mathrm{N}(\mu,\sigma^2)</math>	good, because it neither forces nor precludes PNG rendering

Look at this page with different math rendering preferences to see the difference.

The example on the last row of this table is still problematic, because when texvc renders this formula as HTML it does not italicize lower case Greek letters. On the other hand it incorrectly italicizes upper case Greek letters like \Alpha that are not ordinarly defined in TeX. I've filed a number of requests for enhancement against texvc, and would work on it myself if I was fluent in OCaml, which I'm not. Meanwhile, I think the solution I've optimisitcally labeled "good" is a decent compromise.

To sum up, I recommend using <math> everywhere, provided that if it's used inline with text then HTML rendering must be possible. (There are a number of cases where HTML rendering is possible but looks ugly – all "big" elements, like sums, integrals, fractions, etc. Those should not be used inline in the first place.) --MarkSweep 01:32, 29 Apr 2005 (UTC)

Any reason to object adding \sim <--> ~ conversion on bugzilla? At least it solves the "distributed as" problem. Cburnett 02:13, Apr 29, 2005 (UTC)

I went ahead anyway: http://bugzilla.wikimedia.org/show_bug.cgi?id=2015 Cburnett 02:20, Apr 29, 2005 (UTC)

I was about to say this, but there was an edit conflict:

Perhaps it's more effective to list several of these together? I don't know how to go about this, but there must be a list somewhere of all the macros texvc knows about (we can always consult the texvc source). If there are other symbols like \sim that have Unicode/HTML equivalents and trigger unnecessary PNG rendering, it may be best to replace them all in one go. I don't have time to look into this at the moment. Why don't you go ahead and list it on bugzilla and I'll file a comment to go along with your report if/when I find other affected symbols?

I'll have a look. --MarkSweep 02:25, 29 Apr 2005 (UTC)

Each time so far I intersected with Cburnett we did not agree. :) Forgive my interjecting. Just one remark. According to Wikipedia:How to write a Wikipedia article on Mathematics and Wikipedia talk:WikiProject Mathematics/Archive4(TeX), one should not use inline PNGs. This is the community consensus. So, unless we have a new community talk about this, I believe this should be followed. Cburnett, any comments? Oleg Alexandrov 03:12, 29 Apr 2005 (UTC)

I don't think there is any disagreement. Inline PNGs are not desirable, but that need not stop us from using inline <math>. There is nothing wrong with inline math as long as it does not result in obligatory PNG rendering. So for formulas in text, we should only use <math> markup that can be rendered as HTML and leave it to user preferences to determine how it will actually be rendered. --MarkSweep 04:06, 29 Apr 2005 (UTC)

Precisely. I'm fairly certain that most of my inline tex is renderable as HTML. The exception is \sim, which has been added to bugzilla. Are there others? Cburnett 04:16, Apr 29, 2005 (UTC)

No, I don't have any specific example. I assumed you don't mind inline PNGs from your response in your first conversation with Michael Hardy, way above. So we agree on this one! Oleg Alexandrov 04:34, 29 Apr 2005 (UTC)

I prefer the uniform style for my equations and HTML renders too differently (the image alignment with text is purely a CSS issue to be resolved AFAIC). What would be top notch is if we could set a preference to tip tex as to what font we'd like it rendered as. Cburnett 04:47, Apr 29, 2005 (UTC)

One problem remains: if you set your preference so that inline TeX is redered as HTML, then the minus signs become stubby little hyphens. These need viagra. In subscripts and superscripts, they are especially hard to see. Michael Hardy 03:38, 2 May 2005 (UTC)

I filed a bug report and a patch against that a while ago. This has been fixed in Mediawiki 1.5-alpha. --MarkSweep 03:43, 2 May 2005 (UTC)

Rendering Math

I am editing with a rule in my mind that says "don't use TeX in-line unless absolutely necessary". That was what I was doing with the chi-squared article. Isn't this right? PAR 05:11, 5 May 2005 (UTC)

I've already had this debate with MikeHardy and MarkSweep. Inline tex allows for more error-free writing of equations and I try to stay away from symbols that can't be rendered as HTML. I prefer inline tex at all times and I can't get that when it's hand-coded as HTML. See the Inline TeX just a couple sections above. Cburnett 05:56, May 5, 2005 (UTC)

See the earlier discussion on this talk page. In-line TeX is safe and IMHO preferrable, provided it can be rendered as HTML. The rendering module (texvc) has a few rough edges, but that shouldn't stop us from using inline TeX. --MarkSweep 07:29, 5 May 2005 (UTC)

Ok - I read the above discussion and I still have a problem. I want to see inline TeX as HTML if possible, because inline PNG looks bad. I want to see non-inline TeX as PNG if possible because thats where the complicated things usually go. I have three relevant preference possibilities:

1. Always render PNG
2. HTML if very simple, else PNG
3. HTML if possible, else PNG

Using the first sentence of the chi-squared distribution is a good example. There are three TeX expressions (k, k, and Z...) in the first sentences. None of the three preferences will give me what I want. No. 1 gives all inline's as PNG, No. 2 gives the third inline (Z...) as PNG and No. 3 gives the non-inline as HTML.

It seems to me the best thing is to write inline as TeX such that under preference 2 all inline TeX is rendered as HTML unless thats impossible. Then we write non-inline Tex formulas with the \, character so that they will be forced to TeX under preference 2 but will be HTML under preference 3 (unless thats impossible).

On that basis, in the chi-squared article, the third in-line TeX formula (Z...) is wrong, it should be HTML because its not "simple" enough to be rendered as HTML by preference No. 2. PAR 14:14, 5 May 2005 (UTC)

So you're saying $Z_{1},\cdots ,Z_{k}$ doesn't render as HTML? Does it not like the cdots? Cburnett 14:20, May 5, 2005 (UTC)

Yes, that's the case. It does not render as HTML. Now, Cburnett, there is one thing I would suggest. You being a very prolific editor (and now an admin), it is better to have the rendering preferences set up to the default, so that you see what most other readers/writers see. Then you will not have doubts as above. Just a suggestion, not that I tell you what to do, but that's something to consider. Oleg Alexandrov 15:24, 5 May 2005 (UTC)

Ok, for some reason \cdots, \ldots, nor \dots are rendering as HTML...I was under the impression they were. Looking at the mediawiki code, I don't see what the problem is. \cdots is equivalent to ⋅⋅⋅ and both \ldots and \dots are equivalent to ... Am I missing something here? I've got it on "HTML if possible or else PNG". Cburnett 16:08, May 5, 2005 (UTC)

I think thats consistent. With "HTML if possible, else PNG" (No. 3), everything gets rendered as HTML unless its impossible. That includes TeX lines with the \, "enforcer". If you go to "HTML if very simple, else PNG" (No. 2) then only the "simple" TeX gets converted to HTML. TeX lines with the \, enforcer are not simple. Neither is \cdots, etc. Let's say the word "simple" is whatever is meant by "HTML if very simple, else PNG". Then I think optimum would be

• ALL TEXT  : as simple as possible, but with as much TeX as possible without losing simplicity.
• NON-INLINE : add a \, character at the end if its simple.

Now if somebody wants all PNG, then preference 1 will do it as well as possible. If somebody wants all HTML, preference 3 will do it as well as possible. Preference 2 will give in-line HTML as much as possible, and non-inline PNG always.

PS - I know everyone's first impulse is to agree with me, but I am at a machine that wont allow me to change preferences, so please check above for truth. PAR 17:49, 5 May 2005 (UTC)

"Simple" doesn't even allow subscripts, so I presume that "simple" is only basic stuff you can do with a keyboard in HTML without using tags or special symbols (e.g., &dot). Though, I would expect #3 option to include anything convertable to HTML (e.g., \cdots), but this is clearly wrong by example: $Z_{1},\cdots ,Z_{k}$ should be HTML renderable. Cburnett 20:12, May 5, 2005 (UTC)

I was just defining simple as whatever the "HTML if very simple, else PNG" preference decides is simple. Is there any problem if I adopt the above two rules for editing, even on the chi-squared article? PAR 20:33, 5 May 2005 (UTC)

---

Expanded Ideas ---------

There are three relevant preference choices:

1. Always render PNG
2. HTML if simple, else PNG
3. HTML if possible, else PNG

There are three levels of TeX in an article:

1. Simple - Anything that #2 renders as HTML is simple
2. Complicated - Anything that #2 renders as PNG is complicated or really complicated.
3. Really complicated - Anything that #3 renders as PNG is really complicated.

Articles should be written under these rules:

• ALL TEXT  : as simple as possible, but with as much TeX as possible (for math symbols) without losing simplicity.
• NON-INLINE : add a \, character at the end if its simple. That makes it complicated.

The observed results for the preference choices are:

1. All Tex gets rendered as PNG. That will include a lot of in-line Tex.
2. All in-line gets rendered as HTML, all non-inline gets rendered as TeX (as far as is possible)
3. All TeX is rendered as HTML except really complicated TeX.

In other words, if somebody wants all PNG, then preference #1 will do it as well as possible. If somebody wants all HTML, preference #3 will do it as well as possible. Preference #2 will give in-line HTML as much as possible, and non-inline PNG always.

Mark - what you are telling me (I think) is that the \! character makes the TeX really complicated. We don't want that because then preference #3 will give PNG to somebody who wants as much HTML as possible. PAR

I think all equations and variables should be written in tex: all. For inline tex, make it as HTML compatible for HTML rendering. If there's tex symbols that impede HTML rendering, then we solve the problem with the mediawiki engine and not the text itself. It's *much* easier to fix one problem than to fix every article, maybe wait for mediawiki to be changed, then remember everything that was changed to change it back.

Perhaps we should also propose a <mathi> tag that gives hint to the parser that it's inline tex, which gives rise to another preference: PNG non-inline always (aka #1), HTML inline as much as possible (aka #3). Cburnett 17:12, May 6, 2005 (UTC)

I agree. all. But:

1. Make inline TeX as SIMPLY as possible. If theres a choice between a complicated TeX in-line and non-inline, make it non-inline. If theres a choice between simple and non-simple inline TeX, make it simple. In other words, make it so #1 gives PNG and #2 and #3 give HTML for inline as much as possible.
2. Make non-inline TeX as complicated as possible, but not really complicated. If its simple TeX, make it complicated by adding a /, character. But not a /! character because that makes it really complicated. In other words, make it so that #1 and #2 give PNG for non-inline but #3 gives HTML as much as possible.

The above are style restrictions and need not be fixed if and when the parser gets fixed. They can be relaxed if and when it does. PAR 18:25, 6 May 2005 (UTC)

I do #1 naturally (at least until I find things like \cdots that don't render in HTML). As far as #2...I guess I sit on the fence. :) I don't really care either way since I choose PNG always. Cburnett 20:10, May 6, 2005 (UTC)

Math Articles

Hi Cburnett! I noticed your work on Minimum-variance unbiased estimator and I find that some individuals (not you) in the mathematics are being very pendantic over minuatae, and assuming advanced concepts when interjecting their opinions into the article. I also find that the whole mathematics section is being dominated by a select number of individuals who are writing articles that are very advanced (and I did take advanced math degrees in University), and assuming a university degree (or graduate mathematics degree) knowledge, I find.

Do you have an interest in mathematics? Perhaps a group, or even a wikiproject, designed to try and take the advanced / Ph.D. level bias out of the mathematics articles? We can have advanced topics, but we need more understandable explanations and write ups.

As well, I thought that the sum of the least squared errors was an unbiased estimator. I'll get some direct quotes so we can include that into the article - I think it should be included since it is a useful stepping stone to more 'advanced' details that are being included but, in my opinion, not adaquately explained.

Thanks for your help and interest. --ShaunMacPherson 03:12, 8 May 2005 (UTC)

Yes, I used Mike Hardy's summaries and apparent attitude on that very article to oppose his nomination for bureaucrat, so I have no problem admitting it. I think his heart is in the right direction though.

As far as the level of mathematics. I'm not sure of Mike's credentials (I'd wager a graduate degree in statistics, but I'm too lazy to read his user page at the moment...I've been moving all day and am ready for bed) but I certainly know mine. I do write some of those articles for advanced readers primarily to have things stated clearly and completely. I have zero problem (maybe even negative problem: meaning I'd much like to see it) with writing more novice explanations of the topics. That is, actually, how articles are supposed to be written. A clear introduction with gradually increasing complexity...or something like that.

But, like the vasy majority of article, WP is under a constant state of flux and improvement. In the end, I'd much rather have an advanced math article than no article at all. I think the advanced portions of articles (or "bias" as you put it) shouldn't be deleted, but rather augmented with more basic descriptions. There's plenty of room for both! Cburnett 06:15, May 8, 2005 (UTC)