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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 25 ← Archive 29 Archive 30 Archive 31 Archive 32 Archive 33 → Archive 35

Number notation: application

How are issues like these finally resolved? It appears there are 6 individuals contributing to this discussion. 3 who don't like the current MoS entry and would like to see something more international and 3 who prefer the status quo. That probably means that the vast majority of wikipedians don't care and will carry on doing their own thing. In that case, should this entry in the MoS just be deleted and we accept that there will be a variety of number styles used across wikipedia? The intro to the style guide says that wikipedians are not bound by the style guide. I, for one, will never use commas as thousands separators (nor as decimal separators in English, come to that), whatever the style guide says - to me it is just plain WRONG. And I suspect that Messrs Harmil, Nygaard and Mzajac will never use anything but UK/US format. Maybe an acceptance of diversity is what's needed? --Yaf201 12:49, 14 October 2005 (UTC)

Even if this does fall into Category:Stupid human tricks along with things like driving on the left side of the road, and writing from right to left, that's not enough in itself to change existing guidelines.
Just as Wales should not have some roads on which you drive of the left side and some on which you drive on the right side, and the English language should not have some situations in which we write from left to right and some in which we write from right to left, Wikipedia should strive for a minimum of consistency on this issue, not a free-for-all "acceptance of diversity". I'd accept spaces, had that been the standard from the beginning (and ISO and others were pushing that format long before Wikipedia ever existed, so it could have been). But that isn't the case, and there is insufficient justification to change the existing guidelines now, and lots of problems associated with making such a change now. Gene Nygaard 13:14, 14 October 2005 (UTC)
What problems would changing the guidelines cause? No one is proposing a full scale re-edit of articles just to change number formats. I certainly don't believe that changing the MoS to advise against use of the comma will prevent it being used in future - just as the current guidelines will not prevent me using spaces or avoiding thousands separators altogther. On reflection, I am more convinced that a descriptive approach to this issue would be better than a prescriptive approach. After all, most wikipedians are out there writing and editing articles rather than worrying about number formats. I only came here because I am the weird sort of person who decided to read the MoS before jumping in feet first. I couldn't understand why use of commas was advised and I still can't. "We've always done it that way" has never been a good reason to me. --Yaf201 14:16, 14 October 2005 (UTC)

A related problem is that many of the standards-setters such as CGPM and ISO are lost in their own little world, so out of touch with the real world, that they make no effort to reach out to those who actually set the standards for the style used in newspapers, books, and the like.

Furthermore, they had so little clout in the early days of computing that, even though they prescribed an international symbol for ohms, until Unicode was introduced and became fairly well established, most of us had no convient way to make this symbol Ω on our computers. Sure, many web pages used clumsy kludges, such as using graphics files for this symbol (but though the other letters were scalable, those weren't, often making things look funny). Actually, it goes back even further than that; they didn't have much more clout with those making daisy wheels for typewriters, either.

Another related problem is that these organizations often charge outragous prices for their standards, ensuring that they won't be bought by anyone outside of their captive audience of those required to do so because various governments have adopted those standards as applicable to a particular activity. They aren't going to be purchased, or followed, by those with only a casual interest in the subject. Gene Nygaard 12:58, 14 October 2005 (UTC)

I can't comment on the connection of CPGM and ISO with reality. But it seems to me that we're not going to hit consensus on the number format issue. So why not look at this issue another way? Should the MoS be prescriptive or descriptive? Should it aim to clarify by imposing rules for us to follow or to clarify by providing explanations of what we have done? If the MoS itself says that contributors are not bound by its contents, then I think it should be the latter. The number section could just describe the various number formats that the reader is likely to encounter on wikipedia? --Yaf201 13:13, 14 October 2005 (UTC)

Skatebiker 08:24, 15 October 2005 (UTC):
Then I have a completely different idea. For each user logged in one can set preferences like skin, timezone, etc. So why not number format ? As Wikipedia is virtually completely script driven on PHP (therefore 'wikifies' the content which is edited by the user) it is therefore possible to 'wikify' numbers to the user's preferred number format as e.g. '''bold text''' 'wikifies' to bold text. Simple PHP regular expressions functions like preg_replace() do the job.
A number like 9,999,999,999.9999 will be 'translated' into the user's preferred format. But in numbers containing a single point or comma like 2,005 is may not work.

Instead, why don't we just create a new wiki markup for &thinsp? This would address the issue Michael Z. brought up in his second and fourth bullets. Whatever the Wikipedia software converts it to will be transparent to the user, and secondly, it will have contextual meaning, a big advantage. Third, it will be upward compatible in the future whenever all browsers correctly display a nonbreaking thin space (though there certainly would be no rush on this, since &nbsp works fine, these days, in the interim). Can anyone think of an excellent markup symbol for &thinsp? --Simian, 2005-10-15, 22:07 Z
No,   doesn't "work fine" either. It often makes edit screens very difficult to work with as is. If we were to replace all the comma thousands separators which this six-character-and-no-visible-space abomination (and eight characters for the thin space), many of the exit screens would be really horrible messes.
Furthermore, we already have people sticking in unnecessary nbsp between numbers and units of measure, because this guideline suggests that silliness. There are a few occasions when it is nice to not have a break there, but there is absolutely no reason to present that as a general rule. Gene Nygaard 04:06, 16 October 2005 (UTC)
It works acceptably, iff it is used sparingly. That's all. Gene Nygaard 04:09, 16 October 2005 (UTC)
To clarify, I'm referring above to wiki markup, not html markup. I currently propose that we use (create) a wiki markup symbol consisting of two semicolons (;;) to represent a so-called "&thinsp" (even though initially it will actually be &nbsp). An example follows.
10;;000;;000.000000 would render as 10 000 000.000000
So can anyone tell us if there's any conflict with using two semicolons embedded between two numerals? Note that the symbol must be embedded between two numerals in order to qualify as a valid thousands separator. Is this unique and not in use? Can we move forward with this idea and resolution? --Simian, 2005-10-17, 05:48 Z
Okay, here's my take (some of which may already be resolved, I accept):
  • Context matters. Most ISO standards cannot be applied to most general contexts. Scientific notation cannot be used to represent, say, money, or the number of seats in a legislative house, or the population of a country. That said, the ISO debate seems to have died already.
  • With regard to scientific notation, 1.234×10n, and only that form, is correct. Other methods of representing it are used on calculators and similar devices only.
  • With regard to decimal points with dots and commas, I had no idea that any English speaking nation anywhere used the comma as a decimal point and a dot as a thousands separator, but that might just be me.
  • I don't like this idea of adding this to markup. These are numbers. Adding it to markup would be a very poor solution, because numbers appear all the time and as I say, context matters.
  • Does this make me the seventh contributor? Anyway, most people (unlike me) find better things to do than discuss things on a MoS talk page! This is just my interest, because I think this is one of the backbones of a good encyclopedia.
The thing I want to bring to attention here is that there is no one-size-fits-all solution. Because of their very nature, natural-scientific articles will always display large numbers or even small numbers differently to social-scientific articles. The best we can do is make a suggestion for each, or explicitly mention what not to do. Neonumbers 09:47, 20 October 2005 (UTC)
Just to clarify, no one here is advocating the use of scientific notation nor small numbers. SI provides ample means for avoiding or handling large or small numbers, but certainly doesn't prohibit their use, and we aren't trying to do so herein. SI specifies an optional thousands separator for large numbers. What we advocate herein poses no restriction regarding the size of numbers an editor wants to use. --Simian, 2005-10-26, 17:35 Z
I'm a bit lost there — my point was that context matters, not that certain sizes of numbers should or shouldn't be used. My comment on scientific notation was to say that 4.56e-8 should not be used — not that scientific notation should or shouldn't be used always.
I'll provide an example. Take, say, the speed of light, in a scientific article. This may (emphasis may), if appropriate in the case, be expressed as 2.99×108 m/s² (note: in the article speed of light it's just expressed as 299,792,458, but that's not the point). Or, the mass of an electron might be 9.11 × 10−31 kg.
The population of China, however, would not be 1.3 × 109; it would be 1.3 billion. And of course, these examples will be different in different places — infoboxes, different sections, the accuracy desired, lots of things. If this has already been established, then that's fine.
I cannot find anything in the SI manual, by the way, about any mention of a thousands separator. Neonumbers 10:19, 27 October 2005 (UTC)
There are multiple links regarding the thousands separator in SI in my first post. E.g., ISO 31-0, Sect. 3.3.1. --Simian, 2005-10-27, 13:06 Z
I was looking through the 7th edition (1998) of "The International System of Units" published by the Bureau International des Poids et Mesures. Anyway, that's beyond the point, I'm not too worried about that.
Just as long as my point about context is acknowledged — context appears to have been overlooked in this discussion (and in all discussions in general, for that matter). Neonumbers 22:53, 28 October 2005 (UTC)

year zero

I suppose I open an old wound here, but I'm not going to search through 27 archives. Maybe there should (also) be a single index to all the archives. Anyway...

I'm abhorred. Wikipedia does not use a year zero? I know that that causes a problem with old dates because the Romans didn't yet know about the zero. But there have been more changes in dating, such as the change to the gregorian calendar, so why not take this next logical step. Surely, Wikipedia should prefer an ISO norm (ISO_8601#Dates) over an illogical tradition. At 1st century someone even removed the reference to that 'alternative'. This is sort of like only using feet and removing all translations into meters. Actually, it's even worse, because one can work quite decently with other systems than the metric system, but leaving out the zero would make modern science impossible. Even the simplest basics wouldn't work anymore. The invention of the zero is one of the greatest leaps ahead in human knowledge.

Suppose some aliens would pass by Earth, have a look at that great encyclopedia they see we have and happen to first read the 1st century article. Surely, they'd have to conclude that, since we haven't invented the zero yet, we're not worth contacting. :) And it looks extra stupid comsidering the table at the bottom. It looks like we have a great big gaping hole in our decimal system. How is it we have a '0' in our system but don't use it as a separate number? DirkvdM 05:45, 13 October 2005 (UTC)

Generally speaking, I like ISO standards, because they discourage us from believing that the way we do things is the way the rest of the world does them. I certainly have fallen foul of the American date format, missing a teleconference because i thought it had been scheduled for 5/6, which I read as 5th June not May 6. ISO 8601 is one way of avoiding that and current Wikipedia style of using month names is another. I'm happy with either.

Logically there should be a year zero, but I doubt little confusion actually arises because wikipedia doesn't use it. Maybe the wikipedia style guide should allow the use of any calendar eg, Gregorian, Julian, Jewish, Islamic etc as long as the ISO date is also given? Having said that, I personally don't like the fact that the ISO date is based on the Gregorian calendar - maybe it could have had a more culturally neutral basis? But I suppose we're stuck with it --Yaf201 09:23, 13 October 2005 (UTC)

Agreed it is just normal logic that a year 0 does exist as the natural number 0 does exist. Skatebiker 09:27, 13 October 2005 (UTC)

About using the gregorian calender as a basis; you have to pick one and a neutral one would have been one that no-one uses, which would be 'politically correct' but impractical. Now at least several hundred million people (?) don't have to change what they're used to. I'm afraid that using year 0 as a Wikirule is not going to happen because there will be too much opposition. But deleting a reference to it at 1st century certainly won't do, so I'll go and change it back. To change the text on this project page I'd like to have a little more consensus first, though, so I'll first wait for any further reactions. DirkvdM 18:26, 13 October 2005 (UTC)

If you really feel the need to do math with dates, just remember that the zeroth year of our calendar is called 1 AD; it shouldn't be too hard after that (also keep this in mind if you think that the twentieth century started in the year 2000). But using a different name for what ninety-nine percent of the world refers to as the year 1 BC would be completely contrary to the spirit of Wikipedia's conventions. —Michael Z. 2005-10-13 19:27 Z
The use of year zero was a convention of astronomers before it was included in the ISO 8601 data transmission format. Nonetheless, for a long time the Wikipedia software, though it used the all-digit YYYY-MM-DD format as its preferences option, it did not handle dates wikified in that format with a negative year properly, nor the display in that format of years wikified in other formats (at least one of these, I think it was both). In fact, I was the one who made the bug report to Bugzilla that finally got it fixed only a few months ago, after I had brought up the problems a few times on this talk page. Gene Nygaard 20:34, 13 October 2005 (UTC)
Michael, I acknowledge that tradition goes against logic here, and both need to be mentioned (if only so as not to confuse those who only know about the traditional way). So the notions that the 20th century started in 2000 or 2001 should both be mentioned where applicable. As well as the the first year of our calendar being '1 AD' or 'year 0' (note the difference in notation - the year before that would be '1 BC' or 'year -1' respectively). But you say the zeroeth year is 1 AD. The zeoroeth year? What is that? Ah, there's an article on zeroth. Apparently that's a computer term (where it does indeed make some sense). Not quite what you had in mind, though, I suppose. DirkvdM 08:58, 14 October 2005 (UTC)
Well, the basic definition in zeroth is exactly what I was thinking of: "The zeroth item is the initial item of a sequence, if that sequence is numbered beginning from zero rather than one." I meant that precisely 2000.5 years after the (nominal) date of the birth of Christ is the middle of the 2001st full year, the year we label 2001. In the same way, a one year old baby is in its second year of life, but no one argues that this is a lapse of logic or that "leaving out the zero" makes science impossible.
I agree that ISO dating should be mentioned and explained here. I've been using the ISO short date notation for a while because it is much less ambiguous than "01/01/01", but until reading this discussion I had no idea that it had a year zero, and used different numbering for years BCE. I'm quite surprised that the ISO people would move the start of their calendar a year earlier than the start of the traditional Western calendar. —Michael Z. 2005-10-14 10:27 Z
I suppose a central problem is the notion of a 'start of the calendar'. Time is continuous and where one puts the zero (or one) is completely arbitrary from a non-religious point of view. All other units have an absolute 'point zero', but with time one can not even place it at the Big Bang because that is just a theory and it is not even known when it took place. And it would make for very cumbersome dates. So I suppose ISO just took one system that happens to be in wide use and made that more logical. The only problem arises with years before year 1 where a precision of a year or less is needed. Before, say, -5000 that is rather unlikely to happen, so the only problem lies with a few thousand years of which so little is known that the difference is irrelevant.
A not-yet-one-year-old baby is in its first year of life, which is year zero (which is confusing, which is probably the reason that some shift it and use 'zeroth item'). (btw, you don't say a baby is zero years old because you use more precision that case - months, weeks, days, hours). This is however a different system than the one that puts 2000.5 years after year 1 in the middle of the 2001st full year' because that system doesn't use a year 0 (unless you put the birth of Christ at 1 January 0).
By the way, you seem to imply (earlier) that 99% of people don't acknowledge the year 0. But most people will first learn about the number system (with a 0) and then maybe later learn about the leaving out of the 0 by some systems. I was in my thirties when, to my surprise, I learned about this. It's like with the way kids learn language. First they learn the logic and then the exceptions, thus for a while using words like 'ringed' in stead of 'rang' and the like. DirkvdM 08:04, 15 October 2005 (UTC)

When a user's date format preference is set to ISO format (YYYY-MM-DD), 1 BC becomes -0000, not 0000. That is not necessarily an error but is an idiosyncrasy. In any case, it cannot be 0 because ISO 8601 requires at least four digits for any year (the option of just the last two digits was deleted from the 2004 edition). On the other hand, astronomical dating does permit year 0, without requiring four digits. Of course, all earlier astronomical years are shifted by one: −1 is really 2 BC (but historians never use a year zero so when they use negative years they regard −1 as 1 BC).

A disconcerting ISO 8601 requirement which cannot be tolerated in Wikipedia is the requirement that all dates, including those before 1582, be in the Gregorian calendar. This would produce havoc with historical dates because almost all sources use Julian calendar dates before 1582. Thus Wikipedia's date preference does not change any month/day when using the ISO date preference. — Joe Kress 05:21, 19 October 2005 (UTC)

Adjectival use of dimensions

Someone just changed "a 100-millimetre (4-in) pipe for 10 miles (16 km)" to "a 100 millimetre (4 in) pipe for 10 miles (16 km)". I was taught that compound adjectives are hyphenated: "4 in" means "four inches", "4-in" means "four-inch". Which is correct? —Michael Z. 2005-10-20 18:44 Z

I can't comment on the inches and miles, but I'd expect "a 100 mm pipe for 16 km" to see millimetres and kilometres written in full looks strange to me and the hyphen looks decidedly wrong. I don't know of any rules for this, that's just how it looks to me. 192.85.50.1 12:32, 21 October 2005 (UTC)

Most style manuals recommend not hyphenating abbreviations but do recommend hyphenating compound adjectives. Some examples:
  • a 100-millimetre (4 in) pipe for 10 miles (16 km)
  • a four-foot-tall statue
  • a 100 m dash
—Wayward Talk 12:47, 21 October 2005 (UTC)
I guess in running text writing out "hundred-millimetre pipe" would be preferable. Would one ever abbreviate this "100-mm pipe", or always "100 mm pipe"?
In many articles about artillery and tanks this can appear many times on a page, and there isn't a clear preference. Many editors and respectable publications write "125mm gun" without a space, but others dislike this. —Michael Z. 2005-10-21 15:04 Z

Ahem. The text was discussed many times before it went in the Manual without a hyphen. Then a hyphen was added without discussion on 20:44, 14 September 2005. Thus whoever changed it back was actually correcting an undiscussed change in style. Just look at the history.

We discussed the hyphen several times. We also looked at what is said in other styleguides. There is currently no Wikipedia policy. Anyone that would like to create a Wikipedia policy should read the previous discussions. Please look in the recent archives of this talk page. Bobblewik 17:32, 24 October 2005 (UTC)

Am I wrong in remembering the earlier discussion as dealing specifically with numeral and unit symbol combinations, and not with spelled out words for which the rules can be and often are different? Gene Nygaard 21:53, 24 October 2005 (UTC)

Yup, B., I remember putting that hyphen in, with an edit summary explaining why I thought it was correct. I vaguely remember some related discussion, but not the details—couldn't find it when I looked, and perhaps I'm remembering something else.

The example cited was placed to demonstrate the use of units in running text vs. tables, and notation of source units vs. converted units. It's confusing because the two examples of measurements are used one as an adjective and the other as a noun, but there was no indication that this was meant to be a guide for those two different uses, or that that was even considered. I thought it hadn't been, and explicitly made an annotated change that attempted to resolve this. Editors' usage is all over the place, now there's a revert war which has finally removed the distinction instead of explicating it.

If there's no policy regarding this question, then how can you say am I creating new policy by changing what's there? By this reasoning, wasn't whoever originally wrote it the other way guilty of creating a new policy without agreement?

Guess I'm just a big dope. When I have some time on my hands, I may delve into the talk archive and see if I can find the discussion you're alluding to. But since it was inconclusive, I think I'll just keep it simple and discuss the pertinent facts here now.

Wayward's suggestion looks pretty good to me. I would add that in a tank history article where it appears many times, a contraction of the space like "100mm gun" reads quite smoothly, but "100 mm gun" seems awkward to me every single time. I start reading "hundred millimetres gun", oh, oops; "hundred-millimetre gun". I've also tried out pedantically sticking to hyphenating adjectives, but "100-mm gun" doesn't look so hot either.

I'd like to agree on a set of acceptable guidelines, because it's difficult enough to read an article with dozens of letter-and-number fragments, like "the Pzkw-IV with its 88, and T-34-85 tanks of 1943 with 76.2mm guns and 60 mm of armour," etc. etc., having to read three different notation formats. It's time-consuming and difficult just to determine what is already in use in a long article like this before editing, and usually there are two, three, or more inconsistent formats already there, some merely differing in style, and some definitely incorrect. —Michael Z. 2005-10-25 05:09 Z

I understand that you would have liked a hyphen. There is nothing wrong with starting an informed discussion again about Wikipedia having a hyphen style. As far as that example is concerned, JimWae has adjusted it so that it demonstrates the bullet points without confusing the issue with hyphens. That seems good to me. Regards Bobblewik 08:46, 25 October 2005 (UTC)

Here is feedback to some of the excellent questions raised by Michael Z. Adjectival unit symbols are never hyphenated (100 mm pipe). This rule is specified in NIST SP811, Sect. 7.2.b; SAE TSB-003, Sect. C.1.17.12; etc. As such, it is consistent and therefore more logical to also not hyphenate noncompound adjectival, spelled-out unit names (100 millimetre pipe). Secondly, the space between a numeric value and its following unit symbol is never omitted (regardless of whether it's in adjectival use or not). This rule is specified in ISO 1000, Sect. 6.1; ISO 31-0, Sect. 3.4; NIST SP811, Sect. 7.2; SAE TSB-003, Sect. 7.3.10; ASTM SI-10, Sect. 3.5.1.e, etc. --Simian, 2005-10-31, 20:20 Z

Thanks, Simian. Anyone know if English-language style guides agree with the ISO? —Michael Z. 2005-11-1 02:13 Z
The Times (newspaper of the U.K.) Style Guide pretty much butchers everything to do with measurements, not only omitting the space, but also omitting the degree sign from degrees Fahrenheit and degrees Celsius. The NPL (the U.K standards agency), on the other hand, does state this rule (spaces, not hyphens or closed up, with symbols; normal English rules when spelled out) in its short page of SI conventions, and refers readers to the NIST guide for more detailed information. Gene Nygaard 07:09, 1 November 2005 (UTC)
Neither the Times nor the Guardian states the rule explicitly, but if you search for "metric" on those pages you'll see that the people who wrote their style guides don't mind contracting figures and units, as in 44mm or 1,343ft (although the Economist does get specific). Where you write "pretty much butchers" i'll read "disagrees with me". Cheers. —Michael Z. 2005-11-1 09:10 Z
Character space is cheaper on the web than it is in newspapers and books. I will drop the space character when space is limited but I have yet to come across an example on Wikipedia. I am happy that Wikipedia is consistent with ISO.
It is easy to apply the guideline always use a space. It happens to make searching for instances of the unit easier. Once you provide 3 style options to include no space and hyphen, you get 6 error permutations.
The guidelines for the 6 permutations are complicated and widely ignored. They are widely ignored for good reason i.e. unless the text is ambiguous, people can understand it equally well with each of the three options. Wikipedia editors should not be given the additional burden of knowing whether a term is an adjective. We only need clarity of expression. A hyphen is a tool that can resolve reasonable ambiguity, it is not part of spelling. So people can add hyphens when the text is unambiguous, but let's be clear about why we are doing it. It is either there for improving comprehension or it isn't. Bobblewik 13:16, 1 November 2005 (UTC)
The presence or absence of a hyphen (as opposed to a space, even a non-breaking space) won't affect any search engines I use, though it will affect the more literal page search functions in browsers.
However, it is well worth mentioning that a major factor in omitting the space (or hyphen) in our modern electronic world is not the aesthetics of it. Rather, this does seriously mess up the usefulness of search engines in finding informaion. Gene Nygaard 15:16, 1 November 2005 (UTC)
Those are some good points, Bobblewink. But I am skeptical that these high-quality publications would adopt a rule just to save the occasional single letter space, if it wasn't considered within the bounds of good writing style. But knowing when something is an adjective is pretty important, I would say. —Michael Z. 2005-11-1 15:59 Z
An adjective consisting of only a dimension (a space-separated number and unit) is a single adjectival entity, not a compound adjective. It is illogical and inconsistent to hyphenate a noncompound adjective just because the unit name is spelled out. Therefore, the correct, consistent, logical form is as follows.
  • a 95 mm pipe
  • a 95 millimetre pipe
The only time hyphens may be appropriate is in compound adjectives, such as 95-mm-diameter pipe, or 95-millimetre-diameter pipe. One can optionally recast the compound adjective to a noncompound adjectival form, such as a pipe of 95 mm diameter, which now contains the noncompound adjective "95 mm," though this isn't required.
In summary, the space between a numeric value and its following unit name or unit symbol should never be omitted, except when replaced with a hyphen. But the space should never be replaced with a hyphen whenever the dimension is (a) a noun, or (b) only a noncompound adjective, regardless of whether the unit name is spelled out or not. --Simian, 2005-11-02, 02:38 Z
As NIST says, when the units are spelled out (no matter if the number is in words or in numerals), the normal rules of English apply. The normal rules of English are to use the hyphen. We have many such useful parts-of-speech clues in our written language. They actually belong in the number-symbol combinations, too, except for the fact that number-symbol combinations in the Internaional System of Units are a translanguage feature, something universal across languages. The keepers of the standards for the use of SI set international rules for the use of the symbols; they let spelled out words follow the rules of their native language (e.g., in English, we can spell meter either that way or metre, but its symbol is always "m"; in Italian, even though they use the chilogrammo spelling, its symbol is still "kg"). Gene Nygaard 03:47, 2 November 2005 (UTC)
Normal English rules don't require hyphenation for adjectives that are relatively clearly understood to be a single adjectival entity. E.g., we typically write physical therapy expert, not physical-therapy expert. We typically write baby blue sky, more than baby-blue sky. A noncompound, space-separated dimension is even more clearly and obviously known to be acting as a single adjectival entity. If a style guide states or implies that 35-millimetre camera is an example of what is always required in normal English rules, then it is incorrect. Chicago Manual of Style states, in general, compound modifiers that would not be misread may be left unhyphenated. --Simian, 2005-11-02, 06:32 Z
Simian, I understand your logic about adjectival entities, but I don't think it works that way. "95 mm" is a plural noun: "ninety-five millimetres". But it's not "a ninety-five millimetres pipe", but "a ninety-five–millimetre pipe" (a careful typographer would set that with a hyphen in "ninety-five" plus an en dash to make the compound phrase). Read these fragments out loud and compare the rhythm, which should be preserved in the written version as well as its abbreviation. I would abbreviate that "95-mm pipe", which looks a bit too leggy, or "95mm pipe", which may look strange when examined in isolation, but reads quite smoothly when encountered in running text, and better conforms to leaving out unneeded hyphens.
Ultimately it is a matter of style and consistency. Maybe always having a space in abbreviations would be the most practical simplified specification for editors, which would work sufficiently well in all situations. But reading something like 95 mm pipe always puts a blip in the sentence, and just doesn't seem right to me. —Michael Z. 2005-11-2 06:45 Z
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_31&oldid=1137420729"