Wikipedia talk:Manual of Style/Dates and numbers/Archive 77

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 70 ← Archive 75 Archive 76 Archive 77 Archive 78 Archive 79 Archive 80

%

It would be great to have a source, why there is no space between a number and the % - as far as I know, in good typesetting there should be a small space - so a space is far better than no space. Well a source for that rule would be great. -- 217.84.150.117 01:28, 28 July 2007 (UTC)

Dude, we are the source. Tony 01:39, 28 July 2007 (UTC) —Preceding unsigned comment added by Tony1 (talk • contribs)
Haw! Good one. I laugh longtime. Even if you are being at least half-serious. — SMcCandlish [talk] [cont] ‹(-¿-)› 14:08, 28 July 2007 (UTC)
no, that's something you missunderstood! -- 217.84.150.117 01:43, 28 July 2007 (UTC)
I don't think so; Wikipedia is no longer a child, and is quite able to formulate its own style guide to suit its own unique mode, readership and functions. Please log on if you want to debate the matter. Tony 03:20, 28 July 2007 (UTC) —Preceding unsigned comment added by Tony1 (talk • contribs)
Amen to that latter too, if I may get Wikipolitical for a moment. Anon editing, don't get me started... — SMcCandlish [talk] [cont] ‹(-¿-)› 14:08, 28 July 2007 (UTC)
I had no trouble finding an example of the Chicago Manual of Style site using a numeral and percentage sign with no space in between. This is standard usage in all web copy; I cannot recall ever seeing a space inserted, in any web page. Additionally, 15.65 (subscriber link) specifically notes that no space should be used. Wikipedia is not at all alone in the way it handles percentages. — Aluvus t/c 04:08, 28 July 2007 (UTC)
More sources: Strunk & White's The Elements of Style (4th ed.) is silent on the matter, suggesting (as it is the most concise of the world-renowned style guides) that the matter has never been seen as controversial or even confusing enough to bother mentioning. Chicago Manual of Style (15th hardback print ed.): no space (sec. 9.17, pp. 384-385). Fowler's Modern English Usage (Burchfield's Oxford rev. hardback 3rd ed.): no space (p. 584). Next. Less flippantly, there are two not necessarily conflicting ways of looking at this: 1) It's simply a typesetting convention like putting end-punctuation inside quotations even if it doesn't belong to the quoted material, an incredibly stupid and annoying American habit (I can say that; I'm American) that has fortunately be given the finger by WP, and is on the decline offline as well, but not fast enough for my tastes; or using curly quotes in print, and to my chagrin more and more online, which add no functionality/disambiguation at all, just because they look "pretty". 2) Percentages are not actually a unit of measurement, but rather a phrase; it's simply latin for "out of each one hundred" – "2%" is simply a funky abbreviation for "two per cent" which is a strictly speaking unnecessary Latinism for "2 of each hundred." — SMcCandlish [talk] [cont] ‹(-¿-)› 14:08, 28 July 2007 (UTC)
well that's not resolved: I was not aiming at something may be called "web-style". I think we try to come nearer to the good style of printing nice books. And if you take a look to older books, then you will see that there are mostly spaces in front of the %. Even better - the wikipedia now supports automatic non-breakable spaces in front of the %. So please don't always argue with circle references. Greetings, -- 217.84.168.130 09:16, 6 August 2007 (UTC)
There is nothing at all circular about my reasoning. And this has nothing to do with "web style" whatever that might be. It's simply modern style. The argument you present is essentially the same for sub-scripting numerals like "3" and "9" because that is how typefaces in the eighteenth century printed them. We don't use "older books" as our style guide mentors for a reason. What was considered good style in 1872 often is not what is considered good style today (or rather "to-day" if we were going by "older books"). — SMcCandlish [talk] [cont] ‹(-¿-)› 10:24, 6 August 2007 (UTC) PS: If you still feel it is not resolved, then remove the "Resolved" tag. — SMcCandlish [talk] [cont] ‹(-¿-)› 10:26, 6 August 2007 (UTC)
well ... what I wanted to say is, that because of the technical restrictions of the www a style may have established, which is not a modern style but just a workaround - and if the workaround no longer is necessary, it's a style of nescience (which definitly is the case with a lot of german writers) or maybe ignorance. (Not) By the way: even the BIPM couldn't decide - but they did last year, as I have seen a minute ago: in their actual SI-brochure, they say: When it is used, a space separates the number and the symbol % -- great, that's new to me too, well and also my point of view! -- Schusch 11:33, 6 August 2007 (UTC)
well, I removed the "resolved" with the unproofen claim -- even in the Wikipedia it's not clear, see Percentage and Percent sign -- and the SI (BIPM) and ISO 31 are not of little account in these things. -- Schusch 10:52, 7 August 2007 (UTC)
What some may call web-style is indeed a result of (partially just perceived or previous) technical restrictions, a successor to typewriter-style that brought us straight quotes and apostrophes among other ugliness. (Any print text actually makes a lot of compromises compared to handwritten text, e.g. regarding ligatures.) Non-breaking spaces are harder to enter than normal or no spaces; thin spaces (breaking or not) are not only harder to enter, but also are not that well supported (not as bad as few years ago, but still not well enough). The pragmatic approach therefore is no space between a number and a percent sign – some argue the same way for other symbols, like ‘kg’ – or between dots and letters in abbreviations (e.<here>g.).
I think it still is the best approach for Wikipedia, being mostly read in web browsers, to omit the space before ‘%’ and ‘°’ (with ‘′’ and ‘″’), but if this was primarily a seldomly edited print product non-breaking thin spaces would probably be preferable. They are both representing units of dimension 1, which of course also applies to ‘rad’ for instance, and they are not made of letters, unlike ‘rad’. That is what makes them special.
This is not at all saying we should embrace technical limitations as “modern style”, because typography is about readability, i.e. aiding the readership. We’re in a transitional phase where recent common tools slowly approach the utility of traditional professional ones, which they already largely replaced for different reasons. A major obstacle to general improvement are standardised keyboard layouts which seem hard to change. Previously it also was encoding and font availability, but at least the former has mostly gone with the advent of UTF-8 (the reasonable mapping to Unicode), the latter varies.
Concerning old-style numerals, they’re not only still common in typefaces they fit in, but are seeing a comeback currently due to Open Type features (or similar smart font techniques). They always belonged to the font and had not to be done manually by the typesetter. I’m actually reading WP with Georgia as my default font which uses them (1234567890) and they are in general preferable in prose for their alignment wiht lowercase letters, but not in tables or code where a common or fixed width is recommended. Christoph Päper 23:05, 7 August 2007 (UTC)
(repeating myself: Even better - the wikipedia now supports automatic non-breakable spaces in front of the %. (Bug 10334) -- just give it a try! Thanks for your comment and Greetings, -- Schusch 22:53, 8 August 2007 (UTC))
Wikimedia did that for the French, if you read the bug report closely. We have no need for it. Chris the speller 02:28, 9 August 2007 (UTC)

Is this the source you are looking for? "When [the symbol %] is used, a space is left between the symbol % and the number by which it is multiplied [6: ISO 31-0] ...". NIST Special Publication 811, p20. Thunderbird2 16:41, 9 September 2007 (UTC)

Precision

All that I can find about precision deals with conversions and geographical coordinates. But what about precision in measuring? The specific case is Interstate 79 and its talk page. The West Virginia Department of Transportation gives a length of 160.52 miles. But, when using trip planning software, the length comes out as 159.75. JA10 wants to use the trip planning software to calculate intermediate distances to exits, but I don't think it's valid, because a primary source that measures its own roadways disagrees with a third-party source that has numerous places in the process that errors can enter. --NE2 04:29, 28 July 2007 (UTC)

So can you state your question in precise terms; unsure what we should be deliberating on—are you proposing that a new point be incuded in MOSNUM? Tony 04:32, 28 July 2007 (UTC) —Preceding unsigned comment added by Tony1 (talk • contribs)
I'm asking for advice. --NE2 04:41, 28 July 2007 (UTC)
This seems like a "no original research" issue. As much as your colleague would like to do better, this is primarily an instrument for reporting third-party information. Tony 06:54, 28 July 2007 (UTC)
The thing is that it is third-party information: use the program and tell it to go from the beginning to the interchange. --NE2 07:17, 28 July 2007 (UTC)
Sorry, I meant that WP is primarily an instrument for reporting existing information, rather than new, fresh, original research (i.e., the results of which haven't already been published). Tony 11:27, 28 July 2007 (UTC)
Simple computations are not original research. --NE2 12:05, 28 July 2007 (UTC)
The difference is so insignificant I could run that distance in under a minute. Just approximate. That's what we have to do when we have two "reliable" sources that differ in their calculations. Just average the distance and call it "approx. x.yz". NB: I suspect that the cause of the error is either a) government incompetence, b) bad programming, or c) (most likely, really) that the points of measurement were different, e.g. from the furthest possible point to still be considered "on target" to the opposite furthest point, vs. the exact inverse of that determination. The underlying question is necessarily an approximation anyway, because we are not talking about geometric points, but landmarks. How far is it from my house to the mall? You'll get at least as big a variance as you are seeing in your data if you consider "my house" and "the mall" to be the center points of each, or the property boundaries of each on the inner side of the measurement. — SMcCandlish [talk] [cont] ‹(-¿-)› 13:50, 28 July 2007 (UTC)

IEEE/IEC binary prefix mess...less messy!

I just rewrote WP:MOSNUM#Binary prefixes, in plain English that is parseable by someone without an EE degree. I don't think I changed any facts or nuances about where things stand right now, or balance (though I note a very challenging HTML comment in there from a GiBi-booster that should probably come out (not only because it's PoV-pushing, but because extended commentary on rationales belongs on talk pages); didn't delete it myself as I was on useability patrol not PoV patrol). If I'm reflexively reverted on this cleanup spree, I urge others to actually look at the changes I made and reintegrate as many of them as possible without a flame/revert war ensuing, especially a) the reduction of utterly pointless geekery and organizational name tossing, and b) the much more consistent language so that we always know precisely what set of units is being discussed in what clause. There were many other clarifications and grammar/wording twiddles as well. I.e., it would be a mistake to revert the lot because someone disagrees with three details of the 50-something-detail overhaul. — SMcCandlish [talk] [cont] ‹(-¿-)› 13:40, 28 July 2007 (UTC)

Your changes imply (through use of the phrase "IEEE prefixes" and phrases like it) that the IEEE continues to endorse the use of decimal prefixes, which is not especially true. I personally suspect the MOSNUM would be just as well off if that entire first paragraph were excised in favor of a link to binary prefixes (and if the binary prefixes article were heavily revised). Neither of those is likely to happen without stirring up a new, massive fight though; so finding a better phrase than "IEEE prefixes" will have to do. — Aluvus t/c 22:29, 28 July 2007 (UTC)
I'm not sure I'd go that far, but the IEEE thing is a good point. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:23, 29 July 2007 (UTC)
Done. Changed "IEEE" used as an adjective to "historical". Also, removed the combative HTML comment mentioned above. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:26, 29 July 2007 (UTC)
The historical binary prefixes should not be called IEEE prefixes. The rewrite reads better but it is factually wrong.
In the 1950s, K was used for 1024 as in 8K words. By the 1970s, kilobyte (KB) and megabyte (MB) were common as binary units. In 1986 the IEEE (and ANSI) codified the computer industry's usage of binary units. In the 1990s several more standards affirmed the usage. The IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, 2000 is the most current one to defined KB, MB, and GB as binary units. This just recognizes the computer industry's common usage.
In the late 1990s various standards organizations defined new units that were codified by the IEC. These new units clarify the difference between decimal and binary but have not been adopted by the vast majority of the computer industry. In 2005 the IEEE recommended using the IEC units but even their publications still use the traditional ones.
Earlier version of this style guide implied that the traditional binary prefixes were haphazardly chosen by conniving marketers and slipshod engineers. That is not the case; the traditional binary prefixes were codified in ANSI/IEEE standards. The standards originations have attempted to convince the industry to use the new IEC prefixes but the industry does not see a benefit and has stayed with the previous standards. Use of IEEE and IEC standards is strictly voluntary.
A rewrite should explain the benefits of the IEC prefixes and note that the historical prefixes were also codified in standards. The IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, 2000 is a good example of the previous standards. If the Eight Edition uses the IEC prefixes, the industry may still follow the units that were defined in the Seventh Edition. -- SWTPC6800 00:06, 1 August 2007 (UTC)
Huh? This has already been fixed. A big long history lesson isn't helpful here. Please read the current version and explain briefly if you find anything still wrong about it. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:27, 1 August 2007 (UTC)
You removed the fact that the historical prefixes were an official standard. For the past two years this style guideline has portrayed the choice between common usage and the "standard" prefixes. The choice is between the previous standard and a new standard. The guideline should say the industry is still following the previous standard. -- SWTPC6800 02:13, 1 August 2007 (UTC)
The opening sentence is totally wrong. The historical prefixes are not the current IEEE prefixes. That is what the conflict is about. The style guideline from before your current edits is factually correct. Your current wording is not. You should have proposed your changes on the talk page before making a radical change. If the facts are wrong a revert to the previous stable version is in order. -- SWTPC6800 02:28, 1 August 2007 (UTC)
I have corrected the opening and reduced the waffle. The guideline is not the place to have a history lesson, that should be for articles instead. I've also clarified the section about consensus because it was misleading and added confusion by mentioning both types of prefix in the same sentence. Fnagaton 08:20, 1 August 2007 (UTC)
Right. Per Fnagaton just above, I "should" have done just what I did, and you "should" have simply fixed any unintentional errors in it, instead of going on an on about it, SWTPC6800. WP:BOLD (and the related WP:BRD exists for a reason.  :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 17:56, 1 August 2007 (UTC)
The binary prefix section was mired in a ferocious dispute for 6 months and had just become stable. I was concerned that the technical errors would start another dispute. I only voiced my concerns on the talk page and not by editing the main page. I asked Fnagaton to look at the binary prefix section which he did. I think the edits that you and Fnagaton made have improved the section. -- SWTPC6800 01:04, 2 August 2007 (UTC)
Understood. I believe that the bulk of that swampy argument was due directly to the amount of geeky, off-topic detail and namedropping in it. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 04:01, 2 August 2007 (UTC)
Thank you SWTPC6800. :) I also agree with SMcCandlish about the namedropping in the guideline, it was a bit much. Fnagaton 09:05, 2 August 2007 (UTC)

Decision time for this draft

Dear colleagues

I'm keen to implement the draft soon at MOS and here: it's taken a lot of my time and I have to get on with real life. What we have is an immense improvement on the existing situation. However, there are a few remaining issues. I'm calling for prompt, definitive feedback on these.

Dots after imperial-unit abbreviations (in. and ft. versus in and ft)

  • OPTION 1 (current): say nothing
  • OPTION 2 (as currently in the new draft): no dots after any unit abbreviation:
    • "The bridge, only 10 metres (33 ft) across, stretched for 8 kilometres (5 mi) across the bay"
  • OPTION 3: (SMcCandlish's proposal): dots optional after imperial unit abbreviations, but not after metrics:
    • "The bridge, only 10 metres (33 ft) across, stretched for 8 kilometres (5 mi) across the bay"
  • OPTION 4: (Tony-modified version of Option 3): no dots after metric abbreviations; dots after imperial units are acceptable, but dot-free is recommended


  • (2) is my preference; (3) I could tolerate, but don't like the jarring of dot-free metrics and dotted conversion straight after; (4) would be better than (3); (1) is unacceptable. Tony 02:47, 29 July 2007 (UTC)
  • (2) no dots. SandyGeorgia (Talk) 02:49, 29 July 2007 (UTC)
  • (2) or (4). I'm flexible, but I've gotten used to the no-dots look and it gives better consistency in appearance throughout ... not to mention that simple rules are easiest to remember. Askari Mark (Talk) 04:51, 29 July 2007 (UTC)
  • (2) the best solution, clear & simple Jɪmp 08:00, 29 July 2007 (UTC)
    • I think, then, that (2) wins the day; no change to the draft. Tony 11:58, 29 July 2007 (UTC)
  • Waitaminit! I barely had time to sleep... (4) or (3). Option 4 is barely behind option 2 in acceptability level with my input counted, and one day is not long enough to gauge consensus on something like this. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:35, 29 July 2007 (UTC)
You're the only one, SMcC. Let's list this as an issue that needs to be resolved SOON. I'm keen to implement the text in MOSNUM alone. Tony 01:22, 30 July 2007 (UTC)
Huh? I count 2 before me saying (4) would be okay. It's still out-!voted, so I'll let it lie this round. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:34, 30 July 2007 (UTC)

Abbreviated units in main text?

This has just been raised by SMcCandlish and has previously been supported by him and Tony, unsuccessfully.

  • OPTION 1 (as now and in the new draft): spell out main values throughout, abbreviate converted values throughout
  • OPTION 2 (change in policy): allow (not force) abbreviated main values on subsequent appearances:
    • "The bridge, only 10 metres (33 ft) across, stretched for 8 kilometres (5 mi) across the bay", and subsequently "The other bridge, only 5 m (17 ft) across, stretched for 10 km (6 mi) across the bay"
  • Prefer Option 2; would tolerate current. Tony 02:47, 29 July 2007 (UTC)
  • Don't care; {{convert}} has a field to control abbreviation. SandyGeorgia (Talk) 02:52, 29 July 2007 (UTC)
  • I'm not comfortable removing the spell out units in text passage. Perhaps it's just the feeling of my old English professor looking over my shoulder saying that if you use abbreviations [as we would proscribe doing] in this manner it shows the laziness in your writings. —MJCdetroit 03:41, 29 July 2007 (UTC)
(1) It's nothing to do with laziness; it's from the reader's point of view. (2) No one is suggesting compulsion—just permission if (as always implied) there's consensus among contributors to an article, and usage is consistent within it. Can you revisit your comment in this respect? Tony 06:43, 29 July 2007 (UTC)
  • (2), intolerant of current, which is irrational: There isn't anything special about content "X" just because it is parentheses; for example "(Jones ain't gonna play in the 2007 championship)" is unacceptable inside parens as outside; parens do not magically transform the nature of the content inside them in any way. Furthermore, we have longstand principles elsewhere that the first occurrence of an acronym, or another form of shorthand, is given in full. And other concerns. The point is, the current text is conflicting with standard WP practice. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:35, 29 July 2007 (UTC)
  • I have no problem with allowing the writing out of units with their first usage; it is consistent with the rest of our style guides and probably proper usage, if we think about it. However, should not the example for Option 2 be:
  • "The bridge, only 10 metres (33 feet) across, stretched for 8 kilometres (5 miles) across the bay", and subsequently "The other bridge, only 5 m (17 ft) across, stretched for 10 km (6 mi) across the bay"
Askari Mark (Talk) 21:08, 29 July 2007 (UTC)
Good point; I wasn't going to go there this round, but I've been thinking that all along. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:34, 30 July 2007 (UTC)
Well, no: I'm assuming that current policy is that it's 8 kilometres (5 mi) across, then 16 kilometres (10 mi) across: all the same. The proposal is to allow the main units to be abbreviated as well, but only after first occurrence: 8 kilometres (5 mi) across, then 16 km (10 mi) across. I didn't want to fiddle with the requirement for converted units; I suspect that the rationale for abbreviating in every instance, including the first, is that the foregoing main unit and value and the parentheses are sufficient highlighting for even the dumbest reader to realise that a converted mi means mile, or km means kilometre. It's only an option where contributors agree, and is intended for articles in which a unit is repeated again and again. See what you think when it's pasted into MOSNUM. Tony 01:19, 30 July 2007 (UTC)

Proscribe superscript squared etc?

Just been raised by SMcCandlish. ft2/m2 versus sq ft

  • OPTION 1 (as now and in the new daft): say nothing
  • OPTION 2 (change in policy): discourage superscript ("are normally written as")
  • OPTION 3 (change in policy): ban it ("are spelled out ..."


  • Prefer Option 2 Tony 02:47, 29 July 2007 (UTC)
  • (2), the superscripts are often hard to read. I was just editing Mauna Loa to prep for main page, and there is a superscript I can't read. SandyGeorgia (Talk) 02:56, 29 July 2007 (UTC)
    • That particular page uses an unusual character that is a superscript 3 (³), rather than making a superscript out of an ordinary 3 (3), which is a fairly unusual way to go about it. The special character (which is available under "Symbols" in the Edit Tools box below the page-editting box) does has the advantage of not altering line spacings, and copy-pastes better than an ordinary superscript. I'm curious, do you mean you cannot read it because it is too small, or because it does not display correctly for you? As for the question of superscripts, I would like a little better definition of what is being discussed. All superscripts on units, or only on non-metric ones? — Aluvus t/c 03:38, 29 July 2007 (UTC)
      • I can't see it; too small. Can you fix it? That article appears on the main page next week, and the main editor is no longer on Wiki. SandyGeorgia (Talk) 03:49, 29 July 2007 (UTC)
  • I would say (as I did above) that only the imperial measurements should not use the superscripts because they are rarely encountered with the superscripts (outside of wiki, anyway). Whereas, metric/SI units are commonly encountered with the superscripts. In fact, NIST and SI handbook prescribe that only the superscript way of showing these abbreviations (actually they're symbols) be used. Therefore, I think that it is best to contrast between systems, e.g. {{sq mi to km2|10|abbr=yes}}, {{convert|1250|sqft|m2|abbr=on}}, 10 cu yd (7.6 m²). I also think that because these are the most commonly seen ways of abbreviating imperial and metric units, it would be easier to gain consensus for this proposal than trying to outlaw superscripts for SI units. —MJCdetroit 04:05, 29 July 2007 (UTC)
So the proposal, then, is that superscripts not be permitted for imperial-unit abbreviations ("use sq"), but must be used for metrics (km²). MJCdetroit's entry here brings up another point: I'm continually irritated by the use of the <sup> function, which yields a huge superscript, making the lineage lumpy. MJC has used ... yes, it's there down the bottom, a little "2" superscript in the edit tools. Why not make this compulsory for 2 and 3 (not m2 but m²)? Tony 06:36, 29 July 2007 (UTC)
  • SandyGeorgia notes above that the superscripted characters are too small to read on her screen, and I find that when I load IE (with basically all default settings, at a reasonable text size) they are in fact quite hard to read. Restricting editors to use only that way of writing superscripts would probably be an inconvenience to the majority of readers. — Aluvus t/c 06:58, 29 July 2007 (UTC)
Well, IE gets in the way of a lot of improvements. I hate it. It wouldn't be a Bill Gates invention, would it? Tony 07:00, 29 July 2007 (UTC) PS Does it get in the way of the "frac" template suggested below? Tony 07:01, 29 July 2007 (UTC)
I would agree: always use superscripts for metric units but never use them for imperial/US customary units. Jɪmp 08:07, 29 July 2007 (UTC)
OK, I'm updating the draft accordingly. Will avoid using the nice edit tool, and won't even mention it: surprised it's been included down there, frankly, if IE screws it up. Tony 08:41, 29 July 2007 (UTC)
Is this OK? "Squared and cubed metric-unit abbreviations are always expressed with a superscript number (5 km2, 2 cm3); squared imperial-unit abbreviations are rendered with sq, and cubed with cubed (15 sq mi, 3 cubed ft)." AND MORE: Should the subsection be called just "Unit symbols" rather than the current "Unit symbols and abbreviations"? MCJdetroit says that the abbreviations are symbols. And thus, instead of "squared imperial-unit abbreviations, we have "squared imperial symbols"? No, it's needed for imperial units. Tony 08:55, 29 July 2007 (UTC) AND another point: there is a huge difference between 15 square miles and 15 miles squared (= 15 mi × 15 mi). Should this distinction be mentioned? Tony 08:57, 29 July 2007 (UTC)
It would be cubic feet not cubed feet & do keep in mind that the imperial system & the US customary one are different. Jɪmp 09:39, 29 July 2007 (UTC)
Thanks on the "cubitc"—done. Confused as to which term to use for the [non-metric] system; and as to whether sq ft and ft squared are an issue. 3 metres squared is 9 square metres, yes? And when not abbreviated, I'm presuming that these words are all fully spelled out. Tony 09:49, 29 July 2007 (UTC)
What's the abbreviation for 3 metres squared? Is it (3 m)2? Epbr123 10:41, 29 July 2007 (UTC)
I don't think "feet squared" (and similar expressions) are all that common in WP, but I could be wrong. They aren't hugely common in English, to begin with. 3 meters squared would be 9 square meters, or 9 m2. The exponent indicates the unit is squared, not the unit and the quantity. — Aluvus t/c 10:46, 29 July 2007 (UTC)
So it's very important that we tell people that 3 m2 means 3 square metres and not 9 square metres, yes? And that if they want to, they can write out 3 metres squared, which does mean 9 square metres. I'll insert this unless there's a problem.
That one seems kind of silly to me. Who on earth is going to think that 3 m2 means 9 square meters?!? — SMcCandlish [talk] [cont] ‹(-¿-)› 06:34, 30 July 2007 (UTC)
  • (Outdent) Epbr123 is referring to a debate going on at Wikipedia:Featured_article_candidates/Chicago_Board_of_Trade_Building concerning how we can more neatly express 27 m × 27 m. Aluvus, how then, do you express three square metres when it's abbreviated in brackets? (As opposed to 3 metres squared, or 9 square metres.) Tony 11:55, 29 July 2007 (UTC)
  • Concur with MJCdetroit, and would also make it clear that superscripts are preferred in mathematical formulas. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:38, 29 July 2007 (UTC)
  • Isn't cubic feet often shorted to cu ft, not cubic ft? (Seriously confused about all the indenting.) CR7 23:55, 29 July 2007 (UTC)
Thanks, CR7, will change (later: Detroit beat me to it.).
SMcC, you think it's worth cluttering the "Common mathematical symbols" subsection with a statement not to spell out squared? I'd have thought anyone writing such sumbols would know that. Tony 01:03, 30 July 2007 (UTC)
<shrug> I'm not feeling that strongly on it either way. I was addressing more the possibility of if we "banned" sup for square footage/meterage, not to ban it for math usage. Moot point, I think. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:34, 30 July 2007 (UTC)


How to write two and three quarters as numerals?

We say nothing on this: you people tell me! Tony 02:47, 29 July 2007 (UTC)

  • All things being equal, 2.75. Is there some particular case where fractions, improper fractions, or mixed fractions are preferable for some reason? Unless that is extremely common, I would say it is enough to say "avoid fractions unless you have a good reason" and be done with it. — Aluvus t/c 03:47, 29 July 2007 (UTC)
  • There has been some related discussion on this issue. The problem really only comes up with English measures and the sense of the earlier discussion was to discourage decimalizing them because of the problem of “false precision”. Certainly 2.75 in isn’t a problem since it’s a nice, neat conversion, but when you get to 2-3/8 it gets dicier. Askari Mark (Talk) 05:12, 29 July 2007 (UTC)
There is a ¾ in the edit box along with a ½, a ⅓, a ⅔, a ¼, a ⅛, a ⅜, a ⅝ and a ⅞. So 2¾ can be entered directly. Otherwise, use {{frac}}. {{frac|2|3|4}} gives 2+3⁄4. Jɪmp 06:23, 29 July 2007 (UTC)
I'm very happy to insist on the use of the edit box for fractions, and to ban the hyphen (2-3/4 yuck). How about it? Tony 06:40, 29 July 2007 (UTC)
I'm with you there. Would anyone actually write 2-3/4? Ban it: it looks too much like "two minus three-quarters". I rather see 2&3/4 or 2+3/4 but none of that nonsense is necessary: we've got the tool box & the frac template. Note that the tool box is no good for denominators five, six, seven or anything greater than eight. Jɪmp 07:56, 29 July 2007 (UTC)
Does IE screw up the frac template too? I don't have IE 6 to test it with. Tony 09:02, 29 July 2007 (UTC)
  • Exact opposite opinion as Jimp; many do in fact write "2-3/4"; this has been standard style since long before I was born. The unicode fraction are an accessibility problem for many (I don't just mean screen reader; they are so small that many cannot read them even with their glasses!), and the {{frac}} template is a hideous abomination. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:41, 29 July 2007 (UTC)
The Unicode fonts are indeed a problem on IE6. I can only make out clearly the denominators ‘2’ & ‘4’ among Jimp’s examples, and the numerator ‘5’ could be a ‘3’ for all I can tell. The {{frac}} template seriously messes up line spacing. The hyphen – with no spaces – has long been the standard way to write mixed fractions, in my experience. Askari Mark (Talk) 20:55, 29 July 2007 (UTC)
{{frac}} and {{fraction}} are horrid. SandyGeorgia (Talk) 21:00, 29 July 2007 (UTC)
  • How about "II et III/IV", since the kind of numerals was not specified? ;-) Chris the speller 00:49, 30 July 2007 (UTC)
Then why don't we just remain silent on this, as now? Tony 00:54, 30 July 2007 (UTC)

Batting averages

Numbers between minus one and plus one require a leading zero (0.02, not .02). Except batting averages, which are never written with a leading zero. http://mlb.mlb.com/mlb/stats/index.jsp SandyGeorgia (Talk) 03:00, 29 July 2007 (UTC)

I've added to the point thus: "*Numbers between minus one and plus one require a leading zero (0.02, not .02); an exception is made for performance averages in sports where a leading zero is not commonly used." Tony
Do we know of any such sports other than cricket? Jɪmp 07:58, 29 July 2007 (UTC)
It is referring to baseball, not cricket. There would be very few batting averages in cricket between 0 and 1. GizzaDiscuss © 08:02, 29 July 2007 (UTC)
I was trying not to sound US-centric, and expecting that baseball would not be the only sport to which this applied. Not sure it has to be specified, since no one else will use the 'concession'. Tony 09:01, 29 July 2007 (UTC)
Calibers, when expressed in inches (as they often are), are also an exception here. It's always "caliber .22" and never "caliber 0.22". But that falls under WP:UCN so I don't know if it needs to be mentioned in this guideline. -- Jao 11:03, 29 July 2007 (UTC)
Quite so; thank you. So check my addition of "an exception is .... and common usage such as .22 caliber rifle"?
I'd mention it here anyway; it may be convered with regard to article titles at WP:UCN, but people will be confused if they coming looking in the number style guide and don't find mention of it. Also, I like the "and common usage" phrasing; oviates the need to keep adding exceptional examples every time someone thinks of a plausible one. — SMcCandlish [talk] [cont] ‹(-¿-)› 21:02, 29 July 2007 (UTC)
They are used broadly in sports, so don't limit to baseball (though a batting average example would be familiar to most American and Canadian readers); for example my VNEA eight-ball average this season is .73 (as of last Tue.)  :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 06:27, 30 July 2007 (UTC)
Whatever VNEA is ... The current draft wording embraces this. Please sign. Tony 00:49, 30 July 2007 (UTC)
The point kind of was that it doesn't matter what VNEA is; the zeroless format is used in sporting broadly and generally (oh, and it is the Valley National Eightball Association, which is doubly misnamed since it has branches in Europe and Australia now, and they also have nine-ball leagues. Go figure.) — SMcCandlish [talk] [cont] ‹(-¿-)› 06:27, 30 July 2007 (UTC)

How to write "four by four"

At Super Nintendo Entertainment System, we find: Sprites can be 8x8, 16x16, 32x32, or 64x64 pixels, ... is that correct and is it covered? SandyGeorgia (Talk) 15:34, 29 July 2007 (UTC)

It's incorrect: well, it will be in 10 hours' time. Common mathematical symbols must be spaced on both sides, and the letter ex must not be used for a multiplication sign, which is rendered by clicking on the symbol in the edit tools below the edit box. Tony 15:36, 29 July 2007 (UTC)

Also, this (it uses {{fraction}} which is really ugly on my screen): RAM is accessed at 3.072 MHz, with accesses multiplexed between the SPC700 (1⁄3) and the DSP (2⁄3). SandyGeorgia (Talk) 15:38, 29 July 2007 (UTC)

Strongly disagree; "4x4", etc. do not mean "four times four" they mean "four-by-four"; in purely mathematical situations, the phrases are ultimately equivalent, arithmetically, but they are not identical. The former are dimensions (among other things, as in automotive usage), not mathematical formulas or formula fragments. If I smack you in da head wit' a big chunk o' wood, that headache generator was a "two-by-four" (if you were lucky; could have been a 4x6!), a "2x4", which is not spaced and uses a normal "x", not a "two-times-four", which is "2 × 4", spaced and with a different symbol. Don't confuse math and phrase. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:49, 29 July 2007 (UTC)
PS: Concur that the {{fraction}} this is ugly, and should be deprecated.
PPS: Where do you see the mathematical "×" in the stuff below the edit box? It should be there, under "Symbols", but I don't see it. No true-minus, division sign, etc., either. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:52, 29 July 2007 (UTC)
When in edit mode, there's a line beginning with Insert right below the line that says Do not copy text from other websites without a GFDL-compatible license. It will be deleted. SandyGeorgia (Talk) 20:58, 29 July 2007 (UTC)
Oh, duh. I was looking below that in the "Symbols" section. I don't see the point of having two lines of click-to-insert symbols, myself. Honestly, I really don't use that thing down there at all; I have a menu bar popup widget that lets me insert characters into whatever field I'm in in whatever app, and I've used it for years, so I've never felt a need to learn a new and less functional way of doing that on WP. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:27, 30 July 2007 (UTC)
I hope IE 6 doesn't screw up the multiplication sign as well. Find it, SMcC? They're just after the big black word "Insert". Now, I understand the distinction you've made, which is going to be hard for many readers to understand. But I agree that the distinction is worth making if there's consensus to adopt it. Three issues: (1) is it established usage, and does any other authority suggest its use?, and (2) it's a very bunched-up look, (3) does 4 × 4 look bad, and will it be misunderstood in context? I ask the first question because, although WP is quite capable of making its own style decisions, I'd be less comfortable if we were "going it alone". Tony 00:41, 30 July 2007 (UTC)
The problem with #1 is I don't think any authority outside of science style guides even recognizes any difference between "x" and "×", so the question is kind of moot. You won't find that even in a truly huge and comprehensive modern general-usage style guide like Chicago, I'd wager, but I don't have it on my lap right now to be sure. Re: #2/#3 which seem to be the same question/issue, when referring to "four-by-four", the use of the mult. symbol as in "4 × 4" is simply "incorrect. Writing "4x4" for "four-by-four" actually helps disambiguate, for actual measurements, "4 in x 4 in", the space would be required, so maybe just say "use spaces", period. My main thrust with this was that x="by" and ×="times" are not the same thing and shouldn't be confused. It's another one of those things, though, that if the MOS recommends something wrong, people will just ignore it, and MOSwarriors will use AWB to "fix" it, and people who know it is wrong will revert that, etc., etc., and people will fight over something trivial. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:27, 30 July 2007 (UTC)
Does this do it? "*For a multiplication sign, use ×, which is input by clicking on it in the insert box beneath the edit window or by keying in &times; do not use the letter ex. (However, the letter ex is accepted as a substitute for by in such terms as 4x4)." Tony 09:20, 30 July 2007 (UTC)
Yes, but for typo, "&times;". Fixing it would probably require a new sentence at "Do not use the letter ex". — SMcCandlish [talk] [cont] ‹(-¿-)› 09:44, 30 July 2007 (UTC)
Thanks; I think it's right now. Tony 13:52, 30 July 2007 (UTC)

So, is the Nintendo example (above) correct, or does it need spaces? SandyGeorgia (Talk) 14:01, 30 July 2007 (UTC)

Good question; we don't agree on this as individuals. The unspaced 4x4 is now the sole example for dimensional expressions in the text of MOSNUM (I'm unhappy about the visual appearance and the use of ex rather than the mulitiplicadtion sign, but we've all been compromising in this overhaul.) It does say only that it's "acceptable", after talking of the real multiplication sign (which below is billed as spaced). So I'd say it's not wrong to write 64 × 64 pixels under the new wording, and I'd do that myself. But the bunched-up ex now acceptable; therefore, there's no grounds for complaint at the FAC page. Others please correct me if I'm wrong. Tony 14:50, 30 July 2007 (UTC)
Works for me; I would write "64x64 pixels", Yankee style, but write in a math context "64–×–64=..." If I encounted "64–×–64 pixels", I wouldn't wig out. Might change it, but I wouldn't grumble in the process (and yes I would if I found "64x64=..." in a math context.)

Dates of birth and death

The section "Dates of birth and death" should , I feel, make some reference to the four templates:

indicating the correct way to use them, and mentioning that they are required, if birth dates are to be included in hCards produced by infoboxes. Andy Mabbett | Talk to Andy Mabbett 17:10, 29 July 2007 (UTC)

Forgive my questioning attitude, please: convince me that these templates are useful in the normal scheme of things. Isn't it easier to simply type the date? Will other editors know how to use them. (Mostly not, I think.) And do the templates work with IE 6? And since the subsection goes to pains to say that, at the start of an article, the dates of birth and death shouldn't be tangled up with location (and presumably age at death, too, it confuses things, doesn't it? Tony 00:47, 30 July 2007 (UTC)
They are actually getting a lot of buy-in in infoboxes. It's not such much whether J.Q. Editor will use them, but people who care about microformats will, with AWB. And some of us (my hand is raising) do it manually when editing anyway. I don't think MOS should tell people they have to use these things, by any means. That's what gnomes and bots are for. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:27, 30 July 2007 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_77&oldid=1142534986"