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

Archive 25

←

Archive 28

Archive 29

Archive 30

Archive 31

Archive 32

→

Archive 35

Non-base ten numbers

128.186.24.87 changed the non-base ten numbers section recently, to spell out the bases, thus 2345_six rather than 2345₆. Last time I checked mathematical convention was to use the number form 2345₆, which is how it was before. I could not find a discussion on this change (there was one to introduce the section, I was part of it); if there was one, do tell me. This user noted only that it "made more sense", not that it was proper convention. What is normal convention for showing bases? Neonumbers 22:21, 6 October 2005 (UTC)

I doubt that there is a uniform, consistent style used for this.

Some people apparently don't like using base ten numerals to specify the base; it seems to me that our words for numbers are at least as base-ten dependent as the base-ten numerals, and I'd even argue more so.

Skatebiker 07:35, 12 October 2005 (UTC): Another proposal is to standardize the extra digits required for bases greater than ten. Using e.g. T and E for ten, eleven for duodecimal and A and B for the same numerals in hexadecimal is confusing. I propose the digit set 0123456789 ABCDEFGHJK LMNPQRSTUV WXYZ (omitting the 'I' and 'O' preventing confusion with '1' and '0', possibly the 'S' might be omitted as well for the '5') which covers all bases up till 34.

I cannot imagine that there would be enough use of duodecimal numbers on Wikipedia to worry about any perception of inconsistency. Battle it out on the couple of articles which might discuss them.

It doesn't usually matter for integer bases less than 10; if there is some reason to use other symbols, that can be explained when they are used.

The only bases greater than 16 that are likely to be of encyclopedic interest are vigesimal (Mayan numbers) and sexagesimal. You might be able to find graphics of the Mayan glyphs consisting of bars and dots and a football-shaped shell for zero, but otherwise when they are written out, it is customary to use two-decimal digit representations of the vigesimal numbers, and the same is nearly universal for representation of sexagesimal numbers (witness the common sexagesimal fractions of a degree used in latitude and longitude). These are usually separated by a dot or a colon or some other symbol such as the prime and double prime or superscript Roman numerals or written in columns, so that the digit-pairs are clear. I don't see any real need for single-character representations of anything in higher bases than hexadecimal numbers. Gene Nygaard 18:25, 12 October 2005 (UTC)

The format I last discussed is what is used at Maya calendar for the vigesimal numbers—not strictly vigesimal, either, but three digits for a vigesimal count of tun (years of 360 decimal days) and two digits for the count of the days in that tun: "The Long Count started at 13.0.0.0.0 on Julian day 584283", etc. Gene Nygaard 18:36, 12 October 2005 (UTC)

Well, I have a (junior) maths textbook and a C++ progamming learn-in-21-days book, both which reckon the 1234⁶ is standard. Well, in any case, both use that format. I understand if people are sceptical about these being proper references, but I've never before seen any other convention on the matter. Neonumbers 10:44, 19 October 2005 (UTC)

Did you mean 1234₆? (okay to delete this if so and corrected) Gene Nygaard 11:06, 19 October 2005 (UTC)

Whoops, yep, that's exactly what I meant - thanks for pointing that out :-) Neonumbers 09:25, 20 October 2005 (UTC)

To replace this text:

• in all other articles, use subscript notation, for example 137_nine, 241_six, 2X9_twelve, A87D_sixteen (use _and)

With this:

• in all other articles, use subscript notation, for example 137₉, 241₆, 2X9#₁₂, A87D₁₆ (use _and)

This just reverts an undiscussed change from a month ago. All changes since then will be left in tact. If there are no objections in terms of style before 30 October, I will replace the above text as such. Neonumbers 07:06, 26 October 2005 (UTC)

talk page oddity

I notice that there is no article/project associated with the talk page Wikipedia talk:Naming conventions (calendar dates). When I go to that talk page, and click the "project page" tab, I'm redirected to Wikipedia:Manual of Style (dates and numbers).

I find this confusing. Should we somehow merge the 2 talk pages associated with that single project page? --DavidCary 15:46, 8 October 2005 (UTC)

More about overlinking of dates

There was a recent discussion (Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#Dates_linking_convention_currently_ludicrous) about overlinking date elements. Just in case people did not read the references to a proposed solution, below is a quote from: Village pump archive:

I support this proposal. I agree that linking to dates is a generally cause of over-linkink. i think thjat shuch links, as links, are usually pointless, and should be removed if there were to be another way to apply date preference formmatting. I also think that most links to partial dates (D/month without year, or year alone) are already pointles, and i have started to remove them when I edit articles that have such links, although i don't go looking for them.

I have no idea if the proposal is technically hard or easy. I find it hard to belive that it is impossible. Note that instead of _10 Jan 2005_ we could have #Date(10 Jan 2005) if that were technically easier to implent. DES 22:07, 31 May 2005 (UTC)

There's no need for special syntax, the software can recognise dates in plain text. -- Tim Starling 09:35, Jun 1, 2005 (UTC)

That would be much simpler if implemented! I presume that on occasions (such as this) where we want to see a specific format not altered by preference then putting the date in nowiki tags would allow that? (i.e. 01 June 2005 would appear as per your preference and <nowiki>01 June 2005</nowiki> would always appear that way). Thryduulf 12:50, 1 Jun 2005 (UTC)

Does anybody know how to implement this? Bobblewik 13:38, 6 August 2005 (UTC)

I think the first step will be to put a feature request on bugzilla. Outside of that, I'll point any of the developers at the discussion if I happen to see them later. Thryduulf 09:54, 7 August 2005 (UTC)

I tried getting into bugzilla but failed. I would be grateful if somebody else make the request. Bobblewik 16:11, 9 October 2005 (UTC)

Number notation

Skatebiker 07:48, 12 October 2005 (UTC): In the Number notation section of Wikipedia one is encouraged to write large numbers to split up the digits in groups by three separated by commas. This is against the ISO 31 rule and, moreover, ambiguous in many cases as the comma can be used as a decimal point. Why does Wikipedia not observe the ISO standard ? I propose to change the guideline to avoid writing large numbers with commas (or dots) separating groups of three digits. This is ambiguous particularly for numbers under 1 million. E.g. 123,456 can be interpreted as hundred twentythree point/comma four five six or hundred twentythree thousand four hundred fivty six which is comfusing. ISO 31 advises using spaces (preferably thin spaces HTML : &thinsp;) instead. Commas or points in numbers should only be used as a decimal separator between integer and fraction part.

Moreover using scientific notation writing the exponent notation as usual in computer output or calculator display. This is easier readable. E.g. 5.67e-8 reads easier and takes less space than 5.67×10^-8. So that I propose in the guidelines as well.

• I agree totally. I came here looking for a reason why the style guide deliberately contravenes ISO 31. As wikipedia is truly international, that doesn't make sense to me. I will welcome your change Yaf201 13:59, 12 October 2005 (UTC)

The ISO standard is widely ignored, and its use is almost always considered unusual in many countries. I notice, for example, that the English and Japanese Wikipedias tend to use commas but also a mix of the other forms to a lesser extent; German, Dutch (Netherlands), Italian and Spanish use dots, French, Polish, Bulgarian, and Swedish use spaces. Portuguese uses a mix of dots and spaces, and more often than others will also tend to just show large numbers with no spacing. This information was gathered by looking at the front page and searching for "yen" and "giga" on each site. For some, I had to poke around to find more examples to confirm common usage. The point here is that stomping on common usage in favor of a standard, no matter how prestigious the standards body, is not what Wikipedia is about. If it were, we'd also exclude the use of words that are not listed in the OED.... I suggest that we simply try to make sure that within an article, there is a consistent usage that is appropriate for the subject. If you're discussing SI units, then it makes sense to use ISO numbers, but if you're discussing a topic relating to the English-speaking countries that use commas, I don't see why you would use anything but commas. -Harmil 16:28, 12 October 2005 (UTC)

That ISO 31 standard has not achieved much of a following in general usage outside Wikipedia, so there is no particular reason why Wikipedia to follow it. Can you cite particular style guides which might prescribe it for general use, or certain publications which do in fact follow this rule?

Part of the problem is that the standard itself, by its own terms, deals specifically with usage in connection the International System of Units (with maybe a few non-SI natural units and things like that; it doesn't deal with usage of English units, for example). It isn't presented as a general rule. It can be emulated in other usage, but the standard technically doesn't apply to any usage outside SI. Nobody looks to this standard for the expression of monetary units, or for the expression of population counts, for example.

However, using that format with SI units and not with other units (something occasionally seen in Wikipedia and elsewhere) is downright silly.

I wouldn't want to be the one responsible for making all the changes if were were to change the policy to require spaces.

When that format is used, the spaces should be non-breaking spaces. But that has rarely been done on those fairly rare occasions when that format has been used on Wikipedia. This is more important than any "thin-space" recommendation, for a character whose existence most editors aren't even aware of (and one still, I think, not well implemented in at least one of the major browsers, a problem which has been discussed in the past, resulting in spaces bigger than a normal space). There are also separate "thin space" and "non-breaking thin space" characters in Unicode, IIRC, but at least in the browser in which thin space works for me, the &thinsp; representation of this character is interpreted in a nonbreaking way.

A thin space, and even a normal-sized nonbreaking space, make editing difficult, because these characters are not normally available on our keyboards. They are also not available in the character list which now appears at the bottom of English Wikipedia edit pages (something that is also clumsy for more that isolated use of any of these characters).

There isn't that much ambiguity in the usage within the English language. Most of our problems with it come in edits by non-native English speakers, or more so by rough translations from some foreign-language source (including other Wikipedias). Similarly, there are problems with unconventional division not into thousands but into curious numbers called lakhs and crores by editors from India.

I don't like the second proposal, and think we should discourage the use of that exponents with "e" or "E" format. It may indeed be more familiar to computer geeks, but there are also many people taught in the old school, and the 10ⁿ is more recognizable to most computer geeks than the "e" notation is to people not brought up with that usage. The E works fine for computer languages using ASCII character set without superscripts and subscripts (and only a couple of those superscripts as characters, none negative, in various extensions of ASCII). I would like to see more use of the engineering notation variant, with exponents divisible by 3, but wouldn't want it as a guideline for general use to the exclusion of the one digit before the decimal point type of scientific notation. Gene Nygaard 17:08, 12 October 2005 (UTC)

The ISO 31 number standard is the normal standard in South Africa. Although the comma is widely used as the decimal separator, the point is readily recognised and never assummed to be a thousands separator. Using spaces instead of commas for thousands separators is instantly recognisable in all languages, including all variations of English. If wikipedia is going to deliberatly encourage the use of commas instead of spaces as thousands separators, the style guide should say why and accept the potential for ambiguity.
99 999 and 99.999 are unambiguous; 99,999 is not and should, in my opinion, be avoided. Strict adherence to ISO 31 would allow use of the comma as a decimal separator. I would suggest that, because of its different meanings in different countries, wikipedia style guide should deviate from ISO 31 by discouraging use of the comma in English language articles.

I also am not keen on the second proposal. I think the 10ⁿ format is more recognisable, but that is my subjective view. --Yaf201 08:56, 13 October 2005 (UTC)

Strict observation of ISO 31 is not what I propose but just the writing of large numbers separated by commas or points is what I discourage. This spaces is a strict option from ISO31 but &nbsp; or normal spaces is also OK and even no separation at all for not too large numbers (e.g. under a million). So I'd rather write The distance of the Moon is 384400 km. 384.400 km or 384,400 km appears to be in a low Earth orbit.

I agree here not te prescribe use of commas as the decimal sign in Engligh language articles. Skatebiker 09:42, 13 October 2005 (UTC)

That 99.999 is no more unambiguous than 99,999 is; many people do use the dot as a thousands separator, and I have changed numerous Wikipedia articles which have done so. Yet as I write this, you can still find it in hundreds of articles such as Aircraft carrier and Swisstopo and La Pampa Province. It's just that you are less likely to see 99.999 for 10⁵ − 1 in English by primary English speakers than you are in some other languages such as German, but we often import information from languages using that convention into Wikipedia, or have it added by users more familiar with some other language. Gene Nygaard 22:11, 13 October 2005 (UTC)

My first attempt at using a non-breaking space failed and my example above had 99 at the end of one line and 999 at the beginning of another. So I ditched &nbsp; and instead used &#160; I copied this from a well known web page ie www.wiki.x.io!!!! It's a pity there isn't an easier way of putting this in on my keyboard. A space is not the ideal option for separating groups of digits, but it's much better than a comma or a dot Yaf201 11:49, 13 October 2005 (UTC)

I agree with Skatebiker and Yaf201 that the Manual of Style (MoS) definitely should not be encouraging diametric violation of ISO 31. Because the comma is widely used as the decimal point outside the USA, it should not be recommended as a thousands separator in Wikipedia MoS. Note that using a thousands separator is entirely optional (ISO 31-0, Sect. 3.3.1; BIPM, SI brochure, Sect. A1.4.2), and if used, is never applied to numbers having only four digits (NIST SP811, Sect. 11.11) unless aligning a column of numbers. Therefore, one can use either a space character or no thousands separator at all, but not a comma nor a dot. This mistake indeed needs to be corrected in the MoS and changed to something like the following. "A space character (regular space, &nbsp, or &thinsp) can be used as a thousands separator to separate groups of three digits, if desired, though this is not required. But a comma character should not be used as a thousands separator (because the comma is widely used as the decimal sign outside the USA). Whether a space or no space is used as a thousands separator will depend on the situation at hand, but since a thousands separator is optional, omission often tends to be preferable." --Simian, 2005-10-13, 21:10 Z

I hear a lot of writers are following a standard called written English. Most literate educated English-speakers have never even heard of the European decimal comma, ISO recommendations, and engineering notation (apologies to our more versatile South African friends). Figures and other elements of encyclopedic text should be exactly what people expect them to be, and not make them change their point of reference just to read.

Spaces as separators in numerals don't work right, anyways:

• Using regular spaces as separators makes numbers break at the end of a line, which is unacceptable.
• Entering non-breaking spaces using &nbsp; make wikitext laborious to write and hard to read.
• A Unicode non-breaking space character can be typed as option-space on a Mac keyboard, but some common browsers will silently convert it to a regular space during any subsequent edit.
• Using a thin space is the best typographic style for European thousands separators, but the character isn't supported correctly by any font that comes with Windows, can't be typed easily, and &thinsp; in wikitext has the same disadvantages as &nbsp;.

Please don't enter numerals in European format. —Michael Z. 2005-10-14 01:38 Z

Don't think ISO 31 is a European format. It's an international standard, widely used in some of the USA text books for decades. Nonetheless, you make some excellent points regarding on-line thousands separators. At the same time, we shouldn't push an idiosyncratic local practice upon an international audience, in violation of the international standard widely used, including partially within USA. So I think we can agree, based on your comments, that since the thousands separator is entirely optional, both in ISO 31 and in USA practices locally, then the best option appears to be omission in most cases. Many text books and documents in USA already omit the thousands separator to no ill effect. Let's all agree to quit recommending in the MoS that commas be inserted; they aren't required in USA. --Simian, 2005-10-14, 02:48 Z

I think Simian's suggestion is the best compromise. The dot and the comma are not acceptable for thousands separators in an international forum (if Wikipedia were purely American or British it would be a different matter). The various forms of spaces have typogrphical problems, so I now think that thousands separators should be avoided altogether and the decimal separator can be either the dot or the comma depending on the preference of the writer and/or the regional practice of the area / country being written about.

In the UK, digits are not normally grouped after the decimal point, even if they are before it, so one would write 9,999,999.9999999 wheras in ISO format, this would be 9 999 999.999 999 9. So I see no problems in writing 9999999.9999999, although in real life that degree of precision is unlikely to be required, except in scientific and technical fields where ISO 31 will apply and scientific notation is likely to be used --Yaf201 08:58, 14 October 2005 (UTC)

Ok good idea, do discourage the commas and dots other than the decimal sign. The breaking spaces is indeed an issue as in 'normal' HTML text one can use <nobr>number_with_spaces</nobr> to prevent breakup at the end of a line but Wiki swallows these <nobr> HTML tags. Maybe an option to allow these tags again (not only for numbers but for all text to prevent the problem with &nbsp; &thinsp;. Anyway do not mandate the thousands separator. Skatebiker 09:18, 14 October 2005 (UTC)

The ISO standard being "widely used in some of the USA text books" is far from it being widely used. Saying "we shouldn't push an idiosyncratic local practice" about the standard English-language thousands separator is like saying we should reconsider our parochial use of the Latin alphabet. People who read English know what the thousands comma means, including South Africans according to the discussion above. They don't all know that a comma can also be a decimal point. The ISO notation is based on the normal number format of European languages, and it is different from the normal English-language form.

Writing 9999999.9999999 is a problem, because it is poor writing style. Quick: is that about ten million or a hundred million? If the reader can't determine the order of magnitude without using a finger to count digits on the screen, then the editor has failed.

It's also incorrect that four-digit numbers should never have a comma. They should have a comma when they're in a table column below twelve-digit numbers, for example. —Michael Z. 2005-10-14 10:50 Z

Writing 9999999.9999999 is a problem, because it is poor writing style. Quick: is that about ten million or a hundred million? If the reader can't determine the order of magnitude without using a finger to count digits on the screen, then the editor has failed.

That's a fair point, Michael. To be honest, I'd be unlikely to use this degree of precision and I'd write somthing like "nearly 10 million". If I needed to be this precise, it would almost certainly be in a technical or scientific article when the ISO format of 9 999 999.999 999 9 would be appropriate. Would you write 9,999,999.999,999,9? Yaf201 14:43, 14 October 2005 (UTC)

The separation after the decimal point is of little utility, and is almost never seen with commas. We are generally much more in the order of magnitude of the number, than we are in the precision to which it is expressed.

In other words, we want to be able to tell whether it falls into the "millions" category, or if it is "thousand millions" or "billions", whatever we want to call it. And when you get to bigger -illions, that's best left to the reader, who can tell either tell herself or himself that 9,999,999,999,999 is in the "billions" or that it is in the "trillions" range, whichever is familiar to that reader, something that isn't so easy if someone else who might have different understandings of those words has already done it.

OTOH, once we get to the decimal point, we read it either in our own minds or in speaking it out loud as "point digitname digitname digitname". and we don't care so much if the precision is down to the millionths or billionths or whatever. Gene Nygaard 15:16, 14 October 2005 (UTC)

Users Skatebiker and Yaf201 are using faulty logic in assuming that since there are occasions in which the separators can be omitted, and because omitting them doesn't change the value of the number, that omitting them is an acceptable writing style for all purposes. It most certainly is not.

Mzajac is also correct on his other point. Hardly anybody claims (I don't know if I've seen it other than the arguments of some in this section) that using separators in four-digit numbers is unacceptable. Oh, sure, some people do express that rule for specific types of numbers. One common one is not to use separators in calendar years less than 10,000. But nobody says that you should never use it with fourdigit numbers, and it is broader than tables where consistent usage is normally desirable.

One of the biggest problems with the spaces format is that it is almost always pushed as a part of the use of the International System of Units, and those pushing its use there often recognize that they have no real authority for usage outside that context.

But there are also many people who feel strongly that having different rules in that context than for other numbers such as population counts would be silly, so they quite justifiable stick with the normal rules and do not follow the rules some SI proponents would like them to follow.

Of course, if SI is actually used to full advantage, there would be very little opportunity to use thousands separators in the first place. Judicious choice of prefixes, or the use of scientific or engineering notation, generally avoids the need for them

So even if some technical journals follow this rule, few people are going to learn it because there is only limited actual use of it in a technical context. Therefore, it would logically (and does in fact) have minimal effect on general usage.

For example, if SI were used to full advantage, we would not see things like "The average distance from the Moon to the Earth is 384,403 kilometers" (Moon), but rather "384.403 Mm".

We wouldn't see "distance of about 80,000,000 km" (Mars), but rather "distance of about 80 Gm".

We wouldn't see "about 120,000 parsecs across" and "10,000,000 kelvins" (NGC 4555); instead, we'd see "about 4 Zm across" and "10 MK".

As you can see, people who have little use for the convention aren't really in a strong position to be urging it upon everyone else. Gene Nygaard 12:21, 14 October 2005 (UTC)

I agree regarding four-digit numbers when aligning a column of numbers; and I have now inserted, into my original sentence, the phrase "unless aligning a column of numbers" (highlighted in green).

Michael, SI has been the federal measurement system of USA since 1992. You keep erroneously implying that an arbitrary, nonpreferred system is somehow a preferred measurement system of "English-language" countries, which is not the case. SI is the preferred, federal measurement system of USA since actually 1988; and SI specifically forbids using the comma as a thousands separator. Therefore, using the comma certainly isn't the normal or preferred "English-language form" -- and the MoS is just plain wrong, and needs to be fixed. And you're incorrect in thinking SI (e.g., ISO 31) notation is a "European format." SI is used by all countries worldwide. It is the format preferred by USA since 1988. By no stretch of the imagination is SI a "European format." Also a few others herein implied that SI is somehow only for scientific applications, while some other system is for nonscientific applications. Please eradicate this gross misconception. SI applies to all facets of measurement. It became the federal measurement system of USA since 1992 for commerce, trade, business, and nonbusiness -- not just scientific applications.

Let's agree to quit recommending the wrong format in the MoS. It's not the correct nor preferred system. Where required, &nbsp works fine in the interim until we develop a wiki markup for thin space, keeping in mind that the thousands separator is entirely optional and should be used sparingly. Also, Gene Nygaard is correct in saying the thousands separator can be omitted to the right of a decimal point, keeping in mind that it's optional, as stated in SI by BIPM. --Simian, 2005-10-15, 18:40 Z

I'm not too uptight about things like commas in four-digit numbers, I just don't want to see us over-specify the convention with rules that ought to be regularly disregarded by writers. There has to be room for common sense and exceptions.

But I'm in Canada, where at least in theory, we've been officially completely metrified since the 1970s[1] (with respect to Simian, the US and UK are not). No one in general Canadian usage uses spaces for thousands separators or decimal commas (except of course in French). These SI notations originate in European languages and are comfortable to readers of European languages (I did not mean to imply that SI is in some way "politically European"). SI notation is fine in disciplined scientific writing, but English readers are comfortable with the traditional comma-decimal notation.

If we were to officially mandate SI notation for all of Wikipedia, I would be satisfied with that. It may be jarring to most Anglophone readers at first, but it would be consistent and easy enough to get used to. But until that happens (and we all know it's not likely), we should consistently use the numeric notation readers expect and not something out of an engineering or astronomy publisher's style guide. —Michael Z. 2005-10-20 17:59 Z

Using a separator with four digits before the decimal point is acceptable in broader contexts than alignment of tables. Omitting it is optional outside of particular contexts such as calendar years, one of the few places where using it would be considered inappropriate.

The official style guide for the U.S. government is the U.S. Government Printing Office Style Manual. If you follow the link to Chapter 12 (the html version is rather crudely formatted compared to the pdf version, but either will work for this), you find the GPO Style Manual rule:

• "12.14. The comma is used in a number containing four or more digits, except in serial numbers, common and decimal fractions, astronomical and military time, and kilocycles and meters of not more than four figures pertaining to radio."

Of course, their use of "kilocycles" is a dead giveaway that they aren't really on top of things! Curiously enough, they also have this:

• "12.9. Units of measurement and time, actual or implied, are expressed in figures."

• ...
• "e. Use spaces to separate groups of three digits in a decimal fraction. (See rule 12.27.)

0.123 456 789; but 0.1234"

Note also that SI is a system of units; it does not "forbid" anything.

The BIPM (or CGPM) doesn't has no authority outside the metric system. Expressing such a rule as applicable to the metric system, with no authority to change anything in any other use, is tilting at windmills.

If the ISO expects to promulgate a rule of general applicability, it needs to do so in cooperation with the people who actually write the style guides for various types of writing.

If the ISO expects to successfully promulgate such a rule of general applicability, it needs to make a serious effort at better outreach, and not do silly things such as overcharging for its standards in this area, so that it will reach those with a more casual interest in their rulings.

You see, don't you, that nobody has given ISO any plenary authority to write or to amend our manuals of style for us.

BTW there is another much lesser-used format for the thousands-separator (and I just recently edited it out of one Wikipedia article using it). That is the use of the apostrophe as a thousands separator: 37'252'500. Gene Nygaard 19:04, 20 October 2005 (UTC)

I forgot to mention that from the way the BIPM expresses its rule, it obviously applies only to the British and the French. Americans or Canadians or Australians or Pakistanis or Chileans or Fijians or whatever aren't mentioned in the unofficial English version of the rule, and likely not in the official French version either. Gene Nygaard 19:13, 20 October 2005 (UTC)

Where I said SI specifically forbids, I mean "using the comma as a thousands separator is a violation of the SI standard." The SI rules are widely available, and are also covered in countless text books and web pages, including a summary of ISO 31 here on Wikipedia, plus the BIPM SI brochure is on-line and free. The information is extremely easily obtained for those who make the smallest effort to learn something very simple, and who seek to have understanding. --Simian, 2005-10-26, 16:50 Z

Michael, you and I are pretty much in agreement in that we both are asking that the MoS not be over-specified on this particular topic. Since commas as thousands separators violate SI, the MoS should not be specifying them as the recommended format for an international audience. I'm advocating herein that we should quit over-specifying the wrong format and remove the commas from the MoS. It's wrong to over-specify this direct violation of SI. The thousands separator space would, as always, be optional, as stated in SI, and can be used sparingly. --Simian, 2005-10-26, 16:50 Z