This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 95 | Archive 96 | Archive 97 | Archive 98 | Archive 99 | Archive 100 | → | Archive 105 |
Conversation copied from WP:MoS, and closed there. It is sloppy for me to bring this over here without reading the archives, but I'm pressed for time. There's nothing on micron on MOSNUM, or (other than the following) in recent MoS discussions.
I'm going to take your word for that, Gerry, rather than pulling up a PDF with at least 155 pages, but this is a complete surprise to me. American Heritage does say "no longer in use". Micrometre and Merriam-Webster say that micron is fine. Scientists and engineers still use the word frequently. I'm fairly sure that a MoS rule that says to avoid micron will be widely and forcefully ignored by scientists and engineers, at least in 2008. I agree that micrometre/er is completely fine. - Dan Dank55 ( talk) 20:36, 9 April 2008 (UTC)
Actually, Dan's summary of the Micrometre article isn't quite accurate, it says "Some people (especially in astronomy and the semiconductor industry) use the old name micron and/or the solitary symbol µ (both of which were official[citation needed] between 1879 and 1967) to denote a micrometre." My electronics engineering experience was that μ in writing was common up to the early eighties, but after that μm was generally used. (The computers back then often didn't support Greek letters, and sometimes didn't even support lower-case, so "u" was often substituted for "μ".) The word micron was often spoken long after the written form had become "μm". -- Gerry Ashton ( talk) 16:49, 10 April 2008 (UTC)
The primary source for SI units is the official SI website. Terms like 'micron', 'Centigrade', and 'degrees Kelvin' were once part of SI, but they are not anymore. The continued use of legacy terms is widespread in all sorts of domains and it should not surprise anyone that this happens in SI too.
This debate started because somebody wanted to know what the current SI units are. The answers are at the official SI website. Lightmouse ( talk) 17:40, 10 April 2008 (UTC)
Ї
Ѧ
ρ 18:13, 10 April 2008 (UTC)Temperature: Gerry, re the dropping of degree with Kelvin, see this ref LeadSongDog ( talk) 21:41, 10 April 2008 (UTC)
Micron is used for dot pitch on LCD displays. DavidPaulHamilton ( talk) 22:45, 10 April 2008 (UTC)
The rules and conventions for writing inverted SI units is given at the official SI website 'Rules and style conventions for expressing values of quantities'. You may also find useful ISO and IEC standards and SI is generally compliant with those. The original query was about paper described as either "80 g/m2" or 80 gm-2. As far as I am aware, both forms are equally valid in official terms and are equally valid in Wikipedia terms. Toss a coin. Lightmouse ( talk) 08:28, 11 April 2008 (UTC)
The relevant MOSNUM text reads:
Therefore g/m2 and g·m−2 are both permitted, but g m−2 and gm−2 are not. Thunderbird2 ( talk) 14:02, 11 April 2008 (UTC)
Thanks Gene, I enjoyed the micron (wool) article. I guess it's just a matter of time before we find micron (paper thickness), micron (wavelength) and micron (font size) ;-) Returning to your point about the space as a separator, MOSNUM is not completely silent:
I interpret that as ruling out g m−2. Do you read it differently? Thunderbird2 ( talk) 15:43, 12 April 2008 (UTC)
I noticed that the abbreviation for circa is given as "ca." or "c." The latter is wrong, as it is the standard abbreviation for century (e.g. "4th c.") If c is used to mean "circa" then it should not be followed by a dot (e.g. c10,000 men). This is confirmed by the supreme authority on the English language, the Oxford English Dictionary. It seems to me that, as a public work of reference, Wiki must follow standard abbreviations and not invent its own. EraNavigator ( talk) 21:11, 16 April 2008 (UTC)
Hey folks: Greg L drew my attention to MOSNUM, a page I've been playing truant from for some time. I see that it has there have been a lot of changes this month, and I'm charged with producing a summary of substantive changes at the end of each month.
My reading is that before the change:
Now, Anderson's recent modification is in italic below, and Crissov's change is bolded; both are fine by me.
Tony (talk) 15:53, 18 April 2008 (UTC)
I don't accept any connection between the variety of English used in an article, and the system of units listed first. Even though a particular variety of English is used in an article, the readership is worldwide, so the units should be metric unless the subject of the article is tied to the U.S. or U.K. If, for example, the subject of an article is beer, which has no ties to any particular country, and isn't necessarily a scientific article, the first unit of measure should be metric, no matter which variety of English it is written in. -- Gerry Ashton ( talk) 17:55, 18 April 2008 (UTC)
Why is MOSNUM being changed so frequently? Lightmouse ( talk) 17:54, 20 April 2008 (UTC)
- Dan Dank55 ( talk)( mistakes) 18:19, 20 April 2008 (UTC)
Should we include any guidance on the difference between these two? Granted, one needs to be doing conversions to 6 or more decimal places before encountering any noticeable differences in the metric conversions, but I can see the rare occasion where it would be significant. Caerwine Caer’s whines 19:26, 20 April 2008 (UTC)
Ї
Ѧ
ρ 06:43, 21 April 2008 (UTC)Returning to the international mile, I said before that a conversion is over the top, but I've changed my mind now. When such high precision is required, a conversion to an unambiguous unit (in this case the square kilometre) is the best solution. Thunderbird2 ( talk) 20:06, 21 April 2008 (UTC)
I've just encountered the Erlang unit for the first time. The article talks of "1 Erlang" and "2 Erlangs", both of which look odd to me. (I would have intuitively written "1 erlang" and "2 erlang"). What do others think? Thunderbird2 ( talk) 16:31, 20 April 2008 (UTC)
I found this definition at Rowlett's site:
That definition suggests that the unit is an erlang (1 E), with plural two erlangs (2 E). Comments? Thunderbird2 ( talk) 16:36, 20 April 2008 (UTC)
Ї
Ѧ
ρ 16:39, 20 April 2008 (UTC)I have raised a MOS policy about policy changes question at the village pump. Feel free to read it and comment. Lightmouse ( talk) 11:26, 23 April 2008 (UTC)
I thought everyone would be interested to know that another of our regular editors,
Zocky visited
Kilogram and saw all my cumbersome code (like 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)
× 10<sup>23</sup> kg
), which was all just for generating numbers like
“ | 6.02246479(30) × 1023 kg | ” |
So he created a template,
{{delimitnum}}, and now all editors need to code is {{delimitnum|6.02246479|30|23|kg}}
to accomplish the exact same thing. This is the issue many of us discussed
here at Archive #94 of Talk:MOSNUM. In a nutshell though, this template parses as follows:
{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}
The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are much easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.
The Natural logarithm article (first paragraph) and Kilogram (throughout, with 2 kB of savings) have both been updated with this template.
What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a template and really required a parser function ( magic word). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox here on my talk page to assist him in his effort.
As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).
My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:
6.022461342
so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as
Excel-pasteable numeric values.In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or
non-breaking spaces (e.g. coding 0.187 985 755
or 0.187 985 755
to produce 0.187 985 755) because such text strings can break at line-end
word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.
Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.
The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: 0.187 985 755 2), would formally be considered as “incorrect” and should be irreversibly upgraded.
Greg L ( my talk) 22:42, 14 March 2008 (UTC)
NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <code> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES” (adviso added later by Greg L ( my talk) 21:22, 15 March 2008 (UTC))
{{delimitnum|12345.6789012}}
→ 12,345.6789012
{{delimitnum|12345.6789012||12|}}
→ 12,345.6789012 × 1012
{{delimitnum|12345.6789012||12|Hz}}
→ 12,345.6789012 × 1012 Hz
{{delimitnum|6.02214179|30|23|kg}}
→ 6.02214179(30) × 1023 kg
{{delimitnum|1579800.298728}}
→ 1,579,800.298728
{{delimitnum|1.356392733||50|Hz}}
→ 1.356392733 × 1050 Hz
{{delimitnum|0.45359237|||kg}}
→ 0.45359237 kg
{{delimitnum|6.022461}}
→ 6.022461
{{delimitnum|6.0224613}}
→ 6.0224613
{{delimitnum|6.02246134}}
→ 6.02246134
{{delimitnum|6.022461342345}}
→ 6.022461342345
{{delimitnum|1579800.298728|||}}
→ 1,579,800.298728
{{frac|{{delimitnum|1.602176487||–19|}}}}
→ 1⁄1.602176487 × 10–19
Zocky, Here’s additional examples, most of which doesn’t work:
{{delimitnum|1.01}}
→ 1.1 (I note that no one would use this template to delimit a number that doesn’t need delimiting)
{{delimitnum|1.00001}}
→ 1.00001
{{delimitnum|1.10001}}
→ 1.10001
{{delimitnum|1.11001}}
→ 1.11001
{{delimitnum|1.11201}}
→ 1.11201
{{delimitnum|1.11231}}
→ 1.11231
{{delimitnum|1.11232}}
→ 1.11232 (this one doesn’t end with a 1 and works)
{{delimitnum|0.29872801}}
→ 0.29872801
{{delimitnum|0.29872821}}
→ 0.29872821 (this one doesn’t end with an 01 and does work)
Greg L ( my talk) 00:03, 15 March 2008 (UTC)
. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.
0.12501
.
Greg L (
my talk) 20:10, 15 March 2008 (UTC)0.125019
0.125069
0.125101
0.125241
and0.125569
0.125597
0.125601–0.125603
0.125629–0.125631
0.125735–0.125741
100,000.000001
the above result comes out of {{delimitnum|100000.000001}}
showing to me as 1.0E+5.000001
I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. − Woodstone ( talk) 21:56, 15 March 2008 (UTC)
0.125013
0.125021
0.125041
0.125048
0.125069
0.125075
0.125097
0.125101–0.125104
0.125124
0.125131
0.125153
0.125186
0.125208
0.125214
0.125236
0.125241
0.125263–0.125271
0.125291
0.125298
0.125319
0.125325
0.125346
0.125353
0.125375–0.125381
0.125402–0.125408
0.125431–0.125436
0.125457
0.125485
0.125492
0.125513
0.125520
0.125541–0.125547
0.125568
0.125575
0.125596–0.125603
0.125624–0.125631
The list goes on but if this all gets fixed, I suspect everything after this will too.
Greg L (
my talk) 22:56, 15 March 2008 (UTC)
input
→ live template return / (at time of this posting)
0.125402
→ 0.125402 / (0.125 402) ✓ The following are all supposed to end with three-digit groups0.125403
→ 0.125402 / (0.125 402)0.125404
→ 0.125403 / (0.125 403)0.125405
→ 0.125404 / (0.125 404)0.125406
→ 0.125405 / (0.125 405)0.125407
→ 0.125406 / (0.125 407) ✓0.125408
→ 0.125407 / (0.125 407)0.125431
→ 0.12543 / (0.125 43)0.125432
→ 0.125431 / (0.125 431)0.125433
→ 0.125432 / (0.125 433) ✓0.125434
→ 0.125433 / (0.125 433)0.125435
→ 0.125434 / (0.125 434)0.125436
→ 0.125435 / (0.125 436) ✓0.1235436
→ 0.1235436 / (0.123 543 599) This one is supposed to end with the four-digit group “5436”0.29872821
→ 0.29872821 / (0.298 728 209) This one is supposed to end with the two-digit group “21”
Most of this data was discovered at Delimitnum sandbox in the newly added section with 3960 possible variations, which displays all possible variations of numbers ending in two, three, and four-digit groupings.
Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). Tony (talk) 02:08, 16 March 2008 (UTC)
My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. With an example of use {{formatnum|1000|.0001}} (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. − Woodstone ( talk) 09:14, 17 March 2008 (UTC)
{{e|9}}}
and {{subst:e|9}}
omits the preceding + sign and returns ×109. I note however, that the {{e}} template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as
SI Brochure: 5.3.5 for examples of proper formating in this regard). This oversight was addressed with {{delimitnum}}, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.{{delimitnum|1.567892||+9|kg}}
to obtain 1.567892 × 10+9 kg, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including 2.468 × 10
useless “
+”
sign 9 kg. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Wikipedia articles on advanced mathematical concepts where the distinction must be emphasized for some reason.All: I moved the proof-checking sandbox to User:Greg L/Delimitnum sandbox. Greg L ( my talk) 23:06, 17 March 2008 (UTC)
I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:
{{delimitnum|1.1200|25}}
The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.
−
Woodstone (
talk) 09:27, 19 March 2008 (UTC)
Um, since when was there any consensus at all that this weird and user-confusing spacing of long numbers was going to be sanctioned by MOS in the first place? I realize I've been off doing other things for a while but the last time I checked in on that debate, there was a strong majority against it, as a geeky practice that no one but mathematicians is likely to understand, with most users experiencing strings like that as a bunch of separate numbers. Just because some people have spent inordinate amounts of time developing elegant templates to do something doesn't mean that doing them makes any sense on WP. If I really did miss an overwheming consensus shift, then we at least need to make the spaces way smaller, like half that size.
PS: Lest I be thought to be nothing but a nay-sayer today, I will add that I like the fact that the spacing effect (which I hate in this case, because no one writes numbers that way but people in lab coats) is done entirely in CSS and does not touch the content in any way. I think a solution like this would probably be much better than
-spacing in a lot of other cases, and would also obviate all the angsting over at
WP:MOS proper about the inability to use  
because some browsers don't support it – you could simply have one template that took a space character and made it smaller for cases where a space really does belong there in the content but looks too big on-screen, and another to use the above pure-CSS spacing trick to make things visually easier to read without actually inserting any spaces. But I'm rambling... —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 01:26, 5 April 2008 (UTC)
Just to add to the conversation, I created {{
val}} (or {{
ScientificValue}} as it was originally known). It has some of the features that {{
delimitnum}} has, but lacks the spacing. It does have a few added features, which I think make it better. I am looking at copying the spacing code from {{
delimitnum}} into val (or just transcluding it). I hope that we can merge the two into one template that covers all requirements for values. Since {{
val}} is still "in production", we can make breaking changes there without having to modify large amounts of pages. Once {{
val}} is done, maybe we can deprecate one or the other name and get a bot to modify all current use of both {tl|val}} and {{
delimitnum}} and manually coded values to use the new template?
--
SkyLined
(
talk) 16:53, 9 April 2008 (UTC)
Ї
Ѧ
ρ 17:02, 9 April 2008 (UTC)Perfect, though I'd like to look at converting manually entered values to use of this new template, which would include a much larger number of instances (and would be substancially harder to do correctly)
--
SkyLined
(
talk) 17:06, 9 April 2008 (UTC)
There's been some debate about the use of comma's to delimit large numbers at
Template talk:ScientificValue#New_.7B.7Bval.7D.7D_convention. There are some (unconfirmed) claims that SI specifically advocates against it. I believe some of you have been through this discussion before, but I haven't got time to find everything that was said in various places and read all of it. Is there one place where we document the rationale behind the decisions that lead to the current MOS? Could somebody help me summarize all discussions, so we have something to point to when the argument pops up again?--
SkyLined
(
talk) 10:28, 23 April 2008 (UTC)
In February, there was a discussion about links to [[As of xxxx]]. This issue still needs resolving. Guidance at
wp:overlink already has a bullet list titled
In general, do not create links to.
I propose adding the following bullet text:
Furthermore, I propose that we delete
Wikipedia:As of. I welcome comment from anyone that has read the
previous discussion.
Lightmouse (
talk) 15:26, 24 April 2008 (UTC)
And such discussions as have occurred have included the argument that this is an easy-to-maintain way to make dated assertions. WP:Overlink does impose a cost-benefit text; go see if those benefits (such as they are) are still felt worth it. Septentrionalis PMAnderson 03:35, 25 April 2008 (UTC)
I tend to agree with Lightmouse that the usefulness of [[As of xxxx]] links has not been demonstrated. I would emphasize that, to the reader, [[As of xxxx]] simply tempts them to click on a link that will take them to a page that 1) typically takes a long time to load, and 2) has almost no relevance to the article they're reading. I don't monitor [[As of xxxx]] linking to direct my editing efforts. If someone does, now is the time to speak up! In addition, I also agree that continued use of 'As of xxxx' text is important for qualifying statements that date. Whether the {{update after}} template is a useful way to deal with statements that date is something of a separate issue. The point here is whether [[As of xxxx]] links add more benefit than the cost imposed on readers. I believe they do not. Noca2plus ( talk) 17:25, 25 April 2008 (UTC)
Ї
Ѧ
ρ 19:34, 25 April 2008 (UTC)I disagree with Lightmouse. This is not the place to hold this discussion. The benefit of the template to the encyclopedia is the ease of maintenance provided by having the link, which is traceable. If there is consensus to do this at TfD, with a link to the template, more power to all of you; but it would be simpler to save the template and rewrite it (to, say, include a span id, or a link masked with a space) to address any reservations. Septentrionalis PMAnderson 19:59, 25 April 2008 (UTC)
Please vote to keep, delete or amend 'Wikipedia:As_of' as you think best. Please go to
Wikipedia:Miscellany_for_deletion#Wikipedia:As_of
Lightmouse (
talk) 16:13, 26 April 2008 (UTC)
There are two problems with: "Because expressions like the 1700s are ambiguous (referring to a century or a decade), they are best avoided." The first is that if you can find someone who uses, say, the "late 1700s" to mean 1708, I'll eat my hat. There is no ambiguity. The second is that this guideline is widely and thoroughly ignored, even in articles that have gone through WP:FAC and WP:Peer review, such as the one I'm reviewing now, Black Moshannon State Park. Indeed, if the 18th century ran from 1701 to 1800, then how else would one describe the period from 1700 to 1799? - Dan ( talk) 21:26, 17 April 2008 (UTC)
←Sept, I trust your judgment, so fill me in; it will save everyone's time. There are three cases here; which are we dealing with?
←I hit "500" and got for the last few links:
1698 and 1697 use templates that define "1700s" as 1700 to 1709. The other 6 articles all put brackets around 1700s assuming that meant 1700-1799. This was a random selection; if there's really any doubt what the result would be if I kept going, then I'll keep going. I'd say we have a problem. I'll come back to this when I have time. - Dan Dank55 ( talk) 21:31, 18 April 2008 (UTC)
I have been trying to find a definite ruling on this but failing. The MOS says use words for low numbers and provide metric/imperial conversions. The convert template forces numerics and the all words version does not look right to me. The word with a numeric conversion looks good but goes against the use words rule.
Any suggestions? MortimerCat ( talk) 07:07, 25 April 2008 (UTC)
Ї
Ѧ
ρ 18:11, 25 April 2008 (UTC)Is there a stylistic preference between saying "$58 million" or "58 million dollars"? — Josiah Rowe ( talk • contribs) 17:43, 26 April 2008 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 95 | Archive 96 | Archive 97 | Archive 98 | Archive 99 | Archive 100 | → | Archive 105 |
Conversation copied from WP:MoS, and closed there. It is sloppy for me to bring this over here without reading the archives, but I'm pressed for time. There's nothing on micron on MOSNUM, or (other than the following) in recent MoS discussions.
I'm going to take your word for that, Gerry, rather than pulling up a PDF with at least 155 pages, but this is a complete surprise to me. American Heritage does say "no longer in use". Micrometre and Merriam-Webster say that micron is fine. Scientists and engineers still use the word frequently. I'm fairly sure that a MoS rule that says to avoid micron will be widely and forcefully ignored by scientists and engineers, at least in 2008. I agree that micrometre/er is completely fine. - Dan Dank55 ( talk) 20:36, 9 April 2008 (UTC)
Actually, Dan's summary of the Micrometre article isn't quite accurate, it says "Some people (especially in astronomy and the semiconductor industry) use the old name micron and/or the solitary symbol µ (both of which were official[citation needed] between 1879 and 1967) to denote a micrometre." My electronics engineering experience was that μ in writing was common up to the early eighties, but after that μm was generally used. (The computers back then often didn't support Greek letters, and sometimes didn't even support lower-case, so "u" was often substituted for "μ".) The word micron was often spoken long after the written form had become "μm". -- Gerry Ashton ( talk) 16:49, 10 April 2008 (UTC)
The primary source for SI units is the official SI website. Terms like 'micron', 'Centigrade', and 'degrees Kelvin' were once part of SI, but they are not anymore. The continued use of legacy terms is widespread in all sorts of domains and it should not surprise anyone that this happens in SI too.
This debate started because somebody wanted to know what the current SI units are. The answers are at the official SI website. Lightmouse ( talk) 17:40, 10 April 2008 (UTC)
Ї
Ѧ
ρ 18:13, 10 April 2008 (UTC)Temperature: Gerry, re the dropping of degree with Kelvin, see this ref LeadSongDog ( talk) 21:41, 10 April 2008 (UTC)
Micron is used for dot pitch on LCD displays. DavidPaulHamilton ( talk) 22:45, 10 April 2008 (UTC)
The rules and conventions for writing inverted SI units is given at the official SI website 'Rules and style conventions for expressing values of quantities'. You may also find useful ISO and IEC standards and SI is generally compliant with those. The original query was about paper described as either "80 g/m2" or 80 gm-2. As far as I am aware, both forms are equally valid in official terms and are equally valid in Wikipedia terms. Toss a coin. Lightmouse ( talk) 08:28, 11 April 2008 (UTC)
The relevant MOSNUM text reads:
Therefore g/m2 and g·m−2 are both permitted, but g m−2 and gm−2 are not. Thunderbird2 ( talk) 14:02, 11 April 2008 (UTC)
Thanks Gene, I enjoyed the micron (wool) article. I guess it's just a matter of time before we find micron (paper thickness), micron (wavelength) and micron (font size) ;-) Returning to your point about the space as a separator, MOSNUM is not completely silent:
I interpret that as ruling out g m−2. Do you read it differently? Thunderbird2 ( talk) 15:43, 12 April 2008 (UTC)
I noticed that the abbreviation for circa is given as "ca." or "c." The latter is wrong, as it is the standard abbreviation for century (e.g. "4th c.") If c is used to mean "circa" then it should not be followed by a dot (e.g. c10,000 men). This is confirmed by the supreme authority on the English language, the Oxford English Dictionary. It seems to me that, as a public work of reference, Wiki must follow standard abbreviations and not invent its own. EraNavigator ( talk) 21:11, 16 April 2008 (UTC)
Hey folks: Greg L drew my attention to MOSNUM, a page I've been playing truant from for some time. I see that it has there have been a lot of changes this month, and I'm charged with producing a summary of substantive changes at the end of each month.
My reading is that before the change:
Now, Anderson's recent modification is in italic below, and Crissov's change is bolded; both are fine by me.
Tony (talk) 15:53, 18 April 2008 (UTC)
I don't accept any connection between the variety of English used in an article, and the system of units listed first. Even though a particular variety of English is used in an article, the readership is worldwide, so the units should be metric unless the subject of the article is tied to the U.S. or U.K. If, for example, the subject of an article is beer, which has no ties to any particular country, and isn't necessarily a scientific article, the first unit of measure should be metric, no matter which variety of English it is written in. -- Gerry Ashton ( talk) 17:55, 18 April 2008 (UTC)
Why is MOSNUM being changed so frequently? Lightmouse ( talk) 17:54, 20 April 2008 (UTC)
- Dan Dank55 ( talk)( mistakes) 18:19, 20 April 2008 (UTC)
Should we include any guidance on the difference between these two? Granted, one needs to be doing conversions to 6 or more decimal places before encountering any noticeable differences in the metric conversions, but I can see the rare occasion where it would be significant. Caerwine Caer’s whines 19:26, 20 April 2008 (UTC)
Ї
Ѧ
ρ 06:43, 21 April 2008 (UTC)Returning to the international mile, I said before that a conversion is over the top, but I've changed my mind now. When such high precision is required, a conversion to an unambiguous unit (in this case the square kilometre) is the best solution. Thunderbird2 ( talk) 20:06, 21 April 2008 (UTC)
I've just encountered the Erlang unit for the first time. The article talks of "1 Erlang" and "2 Erlangs", both of which look odd to me. (I would have intuitively written "1 erlang" and "2 erlang"). What do others think? Thunderbird2 ( talk) 16:31, 20 April 2008 (UTC)
I found this definition at Rowlett's site:
That definition suggests that the unit is an erlang (1 E), with plural two erlangs (2 E). Comments? Thunderbird2 ( talk) 16:36, 20 April 2008 (UTC)
Ї
Ѧ
ρ 16:39, 20 April 2008 (UTC)I have raised a MOS policy about policy changes question at the village pump. Feel free to read it and comment. Lightmouse ( talk) 11:26, 23 April 2008 (UTC)
I thought everyone would be interested to know that another of our regular editors,
Zocky visited
Kilogram and saw all my cumbersome code (like 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)
× 10<sup>23</sup> kg
), which was all just for generating numbers like
“ | 6.02246479(30) × 1023 kg | ” |
So he created a template,
{{delimitnum}}, and now all editors need to code is {{delimitnum|6.02246479|30|23|kg}}
to accomplish the exact same thing. This is the issue many of us discussed
here at Archive #94 of Talk:MOSNUM. In a nutshell though, this template parses as follows:
{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}
The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are much easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.
The Natural logarithm article (first paragraph) and Kilogram (throughout, with 2 kB of savings) have both been updated with this template.
What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a template and really required a parser function ( magic word). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox here on my talk page to assist him in his effort.
As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).
My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:
6.022461342
so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as
Excel-pasteable numeric values.In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or
non-breaking spaces (e.g. coding 0.187 985 755
or 0.187 985 755
to produce 0.187 985 755) because such text strings can break at line-end
word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.
Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.
The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: 0.187 985 755 2), would formally be considered as “incorrect” and should be irreversibly upgraded.
Greg L ( my talk) 22:42, 14 March 2008 (UTC)
NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <code> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES” (adviso added later by Greg L ( my talk) 21:22, 15 March 2008 (UTC))
{{delimitnum|12345.6789012}}
→ 12,345.6789012
{{delimitnum|12345.6789012||12|}}
→ 12,345.6789012 × 1012
{{delimitnum|12345.6789012||12|Hz}}
→ 12,345.6789012 × 1012 Hz
{{delimitnum|6.02214179|30|23|kg}}
→ 6.02214179(30) × 1023 kg
{{delimitnum|1579800.298728}}
→ 1,579,800.298728
{{delimitnum|1.356392733||50|Hz}}
→ 1.356392733 × 1050 Hz
{{delimitnum|0.45359237|||kg}}
→ 0.45359237 kg
{{delimitnum|6.022461}}
→ 6.022461
{{delimitnum|6.0224613}}
→ 6.0224613
{{delimitnum|6.02246134}}
→ 6.02246134
{{delimitnum|6.022461342345}}
→ 6.022461342345
{{delimitnum|1579800.298728|||}}
→ 1,579,800.298728
{{frac|{{delimitnum|1.602176487||–19|}}}}
→ 1⁄1.602176487 × 10–19
Zocky, Here’s additional examples, most of which doesn’t work:
{{delimitnum|1.01}}
→ 1.1 (I note that no one would use this template to delimit a number that doesn’t need delimiting)
{{delimitnum|1.00001}}
→ 1.00001
{{delimitnum|1.10001}}
→ 1.10001
{{delimitnum|1.11001}}
→ 1.11001
{{delimitnum|1.11201}}
→ 1.11201
{{delimitnum|1.11231}}
→ 1.11231
{{delimitnum|1.11232}}
→ 1.11232 (this one doesn’t end with a 1 and works)
{{delimitnum|0.29872801}}
→ 0.29872801
{{delimitnum|0.29872821}}
→ 0.29872821 (this one doesn’t end with an 01 and does work)
Greg L ( my talk) 00:03, 15 March 2008 (UTC)
. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.
0.12501
.
Greg L (
my talk) 20:10, 15 March 2008 (UTC)0.125019
0.125069
0.125101
0.125241
and0.125569
0.125597
0.125601–0.125603
0.125629–0.125631
0.125735–0.125741
100,000.000001
the above result comes out of {{delimitnum|100000.000001}}
showing to me as 1.0E+5.000001
I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. − Woodstone ( talk) 21:56, 15 March 2008 (UTC)
0.125013
0.125021
0.125041
0.125048
0.125069
0.125075
0.125097
0.125101–0.125104
0.125124
0.125131
0.125153
0.125186
0.125208
0.125214
0.125236
0.125241
0.125263–0.125271
0.125291
0.125298
0.125319
0.125325
0.125346
0.125353
0.125375–0.125381
0.125402–0.125408
0.125431–0.125436
0.125457
0.125485
0.125492
0.125513
0.125520
0.125541–0.125547
0.125568
0.125575
0.125596–0.125603
0.125624–0.125631
The list goes on but if this all gets fixed, I suspect everything after this will too.
Greg L (
my talk) 22:56, 15 March 2008 (UTC)
input
→ live template return / (at time of this posting)
0.125402
→ 0.125402 / (0.125 402) ✓ The following are all supposed to end with three-digit groups0.125403
→ 0.125402 / (0.125 402)0.125404
→ 0.125403 / (0.125 403)0.125405
→ 0.125404 / (0.125 404)0.125406
→ 0.125405 / (0.125 405)0.125407
→ 0.125406 / (0.125 407) ✓0.125408
→ 0.125407 / (0.125 407)0.125431
→ 0.12543 / (0.125 43)0.125432
→ 0.125431 / (0.125 431)0.125433
→ 0.125432 / (0.125 433) ✓0.125434
→ 0.125433 / (0.125 433)0.125435
→ 0.125434 / (0.125 434)0.125436
→ 0.125435 / (0.125 436) ✓0.1235436
→ 0.1235436 / (0.123 543 599) This one is supposed to end with the four-digit group “5436”0.29872821
→ 0.29872821 / (0.298 728 209) This one is supposed to end with the two-digit group “21”
Most of this data was discovered at Delimitnum sandbox in the newly added section with 3960 possible variations, which displays all possible variations of numbers ending in two, three, and four-digit groupings.
Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). Tony (talk) 02:08, 16 March 2008 (UTC)
My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. With an example of use {{formatnum|1000|.0001}} (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. − Woodstone ( talk) 09:14, 17 March 2008 (UTC)
{{e|9}}}
and {{subst:e|9}}
omits the preceding + sign and returns ×109. I note however, that the {{e}} template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as
SI Brochure: 5.3.5 for examples of proper formating in this regard). This oversight was addressed with {{delimitnum}}, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.{{delimitnum|1.567892||+9|kg}}
to obtain 1.567892 × 10+9 kg, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including 2.468 × 10
useless “
+”
sign 9 kg. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Wikipedia articles on advanced mathematical concepts where the distinction must be emphasized for some reason.All: I moved the proof-checking sandbox to User:Greg L/Delimitnum sandbox. Greg L ( my talk) 23:06, 17 March 2008 (UTC)
I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:
{{delimitnum|1.1200|25}}
The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.
−
Woodstone (
talk) 09:27, 19 March 2008 (UTC)
Um, since when was there any consensus at all that this weird and user-confusing spacing of long numbers was going to be sanctioned by MOS in the first place? I realize I've been off doing other things for a while but the last time I checked in on that debate, there was a strong majority against it, as a geeky practice that no one but mathematicians is likely to understand, with most users experiencing strings like that as a bunch of separate numbers. Just because some people have spent inordinate amounts of time developing elegant templates to do something doesn't mean that doing them makes any sense on WP. If I really did miss an overwheming consensus shift, then we at least need to make the spaces way smaller, like half that size.
PS: Lest I be thought to be nothing but a nay-sayer today, I will add that I like the fact that the spacing effect (which I hate in this case, because no one writes numbers that way but people in lab coats) is done entirely in CSS and does not touch the content in any way. I think a solution like this would probably be much better than
-spacing in a lot of other cases, and would also obviate all the angsting over at
WP:MOS proper about the inability to use  
because some browsers don't support it – you could simply have one template that took a space character and made it smaller for cases where a space really does belong there in the content but looks too big on-screen, and another to use the above pure-CSS spacing trick to make things visually easier to read without actually inserting any spaces. But I'm rambling... —
SMcCandlish [
talk] [
cont] ‹(-¿-)› 01:26, 5 April 2008 (UTC)
Just to add to the conversation, I created {{
val}} (or {{
ScientificValue}} as it was originally known). It has some of the features that {{
delimitnum}} has, but lacks the spacing. It does have a few added features, which I think make it better. I am looking at copying the spacing code from {{
delimitnum}} into val (or just transcluding it). I hope that we can merge the two into one template that covers all requirements for values. Since {{
val}} is still "in production", we can make breaking changes there without having to modify large amounts of pages. Once {{
val}} is done, maybe we can deprecate one or the other name and get a bot to modify all current use of both {tl|val}} and {{
delimitnum}} and manually coded values to use the new template?
--
SkyLined
(
talk) 16:53, 9 April 2008 (UTC)
Ї
Ѧ
ρ 17:02, 9 April 2008 (UTC)Perfect, though I'd like to look at converting manually entered values to use of this new template, which would include a much larger number of instances (and would be substancially harder to do correctly)
--
SkyLined
(
talk) 17:06, 9 April 2008 (UTC)
There's been some debate about the use of comma's to delimit large numbers at
Template talk:ScientificValue#New_.7B.7Bval.7D.7D_convention. There are some (unconfirmed) claims that SI specifically advocates against it. I believe some of you have been through this discussion before, but I haven't got time to find everything that was said in various places and read all of it. Is there one place where we document the rationale behind the decisions that lead to the current MOS? Could somebody help me summarize all discussions, so we have something to point to when the argument pops up again?--
SkyLined
(
talk) 10:28, 23 April 2008 (UTC)
In February, there was a discussion about links to [[As of xxxx]]. This issue still needs resolving. Guidance at
wp:overlink already has a bullet list titled
In general, do not create links to.
I propose adding the following bullet text:
Furthermore, I propose that we delete
Wikipedia:As of. I welcome comment from anyone that has read the
previous discussion.
Lightmouse (
talk) 15:26, 24 April 2008 (UTC)
And such discussions as have occurred have included the argument that this is an easy-to-maintain way to make dated assertions. WP:Overlink does impose a cost-benefit text; go see if those benefits (such as they are) are still felt worth it. Septentrionalis PMAnderson 03:35, 25 April 2008 (UTC)
I tend to agree with Lightmouse that the usefulness of [[As of xxxx]] links has not been demonstrated. I would emphasize that, to the reader, [[As of xxxx]] simply tempts them to click on a link that will take them to a page that 1) typically takes a long time to load, and 2) has almost no relevance to the article they're reading. I don't monitor [[As of xxxx]] linking to direct my editing efforts. If someone does, now is the time to speak up! In addition, I also agree that continued use of 'As of xxxx' text is important for qualifying statements that date. Whether the {{update after}} template is a useful way to deal with statements that date is something of a separate issue. The point here is whether [[As of xxxx]] links add more benefit than the cost imposed on readers. I believe they do not. Noca2plus ( talk) 17:25, 25 April 2008 (UTC)
Ї
Ѧ
ρ 19:34, 25 April 2008 (UTC)I disagree with Lightmouse. This is not the place to hold this discussion. The benefit of the template to the encyclopedia is the ease of maintenance provided by having the link, which is traceable. If there is consensus to do this at TfD, with a link to the template, more power to all of you; but it would be simpler to save the template and rewrite it (to, say, include a span id, or a link masked with a space) to address any reservations. Septentrionalis PMAnderson 19:59, 25 April 2008 (UTC)
Please vote to keep, delete or amend 'Wikipedia:As_of' as you think best. Please go to
Wikipedia:Miscellany_for_deletion#Wikipedia:As_of
Lightmouse (
talk) 16:13, 26 April 2008 (UTC)
There are two problems with: "Because expressions like the 1700s are ambiguous (referring to a century or a decade), they are best avoided." The first is that if you can find someone who uses, say, the "late 1700s" to mean 1708, I'll eat my hat. There is no ambiguity. The second is that this guideline is widely and thoroughly ignored, even in articles that have gone through WP:FAC and WP:Peer review, such as the one I'm reviewing now, Black Moshannon State Park. Indeed, if the 18th century ran from 1701 to 1800, then how else would one describe the period from 1700 to 1799? - Dan ( talk) 21:26, 17 April 2008 (UTC)
←Sept, I trust your judgment, so fill me in; it will save everyone's time. There are three cases here; which are we dealing with?
←I hit "500" and got for the last few links:
1698 and 1697 use templates that define "1700s" as 1700 to 1709. The other 6 articles all put brackets around 1700s assuming that meant 1700-1799. This was a random selection; if there's really any doubt what the result would be if I kept going, then I'll keep going. I'd say we have a problem. I'll come back to this when I have time. - Dan Dank55 ( talk) 21:31, 18 April 2008 (UTC)
I have been trying to find a definite ruling on this but failing. The MOS says use words for low numbers and provide metric/imperial conversions. The convert template forces numerics and the all words version does not look right to me. The word with a numeric conversion looks good but goes against the use words rule.
Any suggestions? MortimerCat ( talk) 07:07, 25 April 2008 (UTC)
Ї
Ѧ
ρ 18:11, 25 April 2008 (UTC)Is there a stylistic preference between saying "$58 million" or "58 million dollars"? — Josiah Rowe ( talk • contribs) 17:43, 26 April 2008 (UTC)