Wikipedia talk:Manual of Style/Dates and numbers

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style

This is an old revision of this page, as edited by Greg L (talk | contribs) at 05:43, 20 March 2008 (→‎The case for equal status: “in their definitions”). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

edit
Archive
Years and dates archives

General IT prefix discussion

The IEC prefixes were approved in January 1999. After nine years, virtually nobody uses them. Esperanto is in wider use. When Steve Jobs introduced the MacBook Air (skinny notebook) at Macworld he did not use the term gibibyte once. The news reports give the RAM size as 2 gigabyte, 2GB or 2Gbyte. The Manual of Style should reflect what the outside world is doing. The computer industry and the publishing world have ignored the IEC prefixes. -- SWTPC6800 (talk) 06:09, 17 January 2008 (UTC)[reply]

Do you have any opinion on the topic that is being discussed here? — Aluvus t/c 13:02, 17 January 2008 (UTC)[reply]
Yes I do. A few peoples here are trying to get the Manual of Style to adopt an obscure method of measuring computer storage. This edit war has been going on for several years. You are arguing over the rules of the edit war. The real question is should the Manual of Style follow a standard that had not reached 1% adoption in the real world after 9 years. -- SWTPC6800 (talk) 14:52, 17 January 2008 (UTC)[reply]
Just let me extract the interesting parts of your text: "few people", "an obscure method of measuring computer storage", "war", "1% adoption", "real world". Hopefully people will realize how pointless this discussion is. Don't waste your time, don't let them trick you. As long as this topic is under tight control of certain individuals, you can't win. Again don't waste your time with facts. They shall be ignored, absolutely, without remorse. --217.87.122.179 (talk) 05:57, 2 February 2008 (UTC)[reply]
You are wrong and do not attempt to misrepresent other editors with your incorrect anonymous rants about "certain individuals". Fnagaton 10:03, 2 February 2008 (UTC)[reply]
Whether manufacturers are using these units is irrelevant. Fact is that the units are used inconsistently. Sometimes they have a binary meaning, sometimes a decimal one. Many of the readers wil not be aware which meaning is applicable in a specific mention of the unit. Therefore it is the task of an encyclopedia to make sure the reader is able to draw the correct conclusion. This can be achieved by always adding a conversion to (or a confirmation of) a standardised and well documented unit. We achieved consensus to do it that way a while ago. According to the guidelines units from a primary source should come first. So the usage would be:
  • with decimal meaning: 64 MB (61 MiB)
  • with binary meaning: 64 MB (=MiB)
−Woodstone (talk) 19:42, 17 January 2008 (UTC)[reply]
Fact, KB, MB, GB are defined by standards organisation to be power of two. Fact, some manufacturers use other meansing. Lets say for the sake of argument some manufacturers started using KiB but in a decimal sense, that would be inconsistent use, so what then? It's not *always* needed though, just disambiguate (if you need to at all) the first occurrence in an article. Fnagaton 22:18, 17 January 2008 (UTC)[reply]
Regardless of how inconsistent sources are, a conversion to standard units would always tell the user unambiguously what the correct meaning is. I agree that if the same number is used several times, one conversion might be enough. But it is just a welcome service to the reader to convert every number at least once. −Woodstone (talk) 22:31, 17 January 2008 (UTC)[reply]
I'm just going to quote "Fact is that the units are used inconsistently" and "Regardless of how inconsistent sources are" then grin for a while because I find it funny. ;) Seriously though the JEDEC, who are the standard organisation for memory and who have majority consensus, do define kilobyte etc in their standard. So which standard body is the better one to choose, the one that has a tiny 0.5% use (no consensus) in the real world or the one that has the huge majority consensus? And then if there is any use that differs from the JEDEC standard then make a point of disambiguating it with exact numbers of bytes. Fnagaton 22:56, 17 January 2008 (UTC)[reply]
I see your point about fun: it is funny: the more inconsistent usage is, the more there is a need for conversions. You may know exactly in which cases a particular interpretation is standardised by JEDEC, most people have never even heard about JEDEC. Why not help them by addding a conversion? −Woodstone (talk) 23:03, 17 January 2008 (UTC)[reply]
Because according to the JEDEC it's not inconsistent, it is powers of two in size. Following on from the above I could point to companies using KiB but in the decimal sense. Then I could say "inconsistent" and then you'd have to drop pushing for KiB to be used, to ape the arguments used by some IEC supporters for example. Pushing for a particular style of prefix isn't actually the point, as we'll see in a second. What happened is that some other "standards organisation" came along and invented a new term, but it's not used except by a microscopic minority. However the question isn't about what standards organisation is best or whatever, no matter how tempting that is it doesn't actually tackle the real issue and it just causes people to sit behind their preferred camp. Remember you cannot say IEC is consistent since it has been shown IEC is inconsistent with the consensus in the real world. Also remember you cannot say IEC is not ambiguous because of the companies that use KiB in the decimal sense and also because JEDEC define it to be not ambiguous. The question is, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 23:09, 17 January 2008 (UTC)[reply]
Well, a kilobyte appears to be 2 raised to the power 10 (=1,024) in most systems and one megabyte can be either 1,000 kilobytes or 1,024 kilobytes; it gets a bit difficult to determine how many bytes there are in a particular wiggit. Some system is need to sort it out. I've lost track of the arguments, what's your proposal to sort it out - I don't think context is a valid approach.Pyrotec (talk) 23:45, 17 January 2008 (UTC)[reply]
The most common use being power of two. The only non-ambiguous way which also doesn't use neogolisms, i.e. is consistent with consensus, would be the following: Follow JEDEC or be consistent with the sources relevant to the article. If something uses JEDEC specified prefixes but in a non-standard sense then use the units found in the source but disambiguate by stating the exact number of bytes in brackets. Otherwise (and rarely) if some other units are used (like IEC) in the article due to being consistent with sources then disambiguate with JEDEC. Fnagaton 00:00, 18 January 2008 (UTC)[reply]
Or we forget it all for now and just make sure the guideline stays as it is in its stable state. Fnagaton 00:02, 18 January 2008 (UTC)[reply]
There is some confusion on binary versus decimal units of computer storage. However the computer industry and the technical press do not think is significant enough to change to a new units system. Fnagaton is very generous to say that the IEC prefixes have 0.5% acceptance. The industry treats kibi and gibi as something the IEC made up one day. It is not Wikipedia's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Wikipedia could consider using them. -- SWTPC6800 (talk) 01:55, 18 January 2008 (UTC)[reply]
Now that's one horrible misuse of a quote. Did you think it applies because the headline looks fitting? I suggest you actually read this policy. It's also not legit (and I don't need any policy to back this up) to use arbitrary made up numbers like "0.5%" in a discussion. --217.87.122.179 (talk) 22:03, 2 February 2008 (UTC)[reply]
0.5% is not arbitrary and is not "made up".
Historical use search terms Results
kilobyte -wikipedia 1,940,000
megabyte -wikipedia 6,190,000
gigabyte -wikipedia 3,640,000
Total: 11,770,000
IEC Search terms Results
kibibyte -wikipedia 28,800
mebibyte -wikipedia 17,100
gibibyte -wikipedia 19,000
Total: 64,900
Consensus for historical use: 99.449%
Fnagaton 22:51, 2 February 2008 (UTC)[reply]
It's good that you explain how this figure was determined. This shows that the value is less than useless. Many results may to a certain extent show that something is widely known. The opposite is not true. Lack of results does not prove anything. Not to mention that this method is still arbitrary because it excludes the short forms which are far more common in my experience. Of course it's obvious that MiB has more meanings than Mebibyte and MB has also many meanings in different areas. Last but not least, this method excludes not only results from wikipedia or citing wikipedia, it excludes any kind of result which mentions or links wikipedia which may have nothing to do with this topic. --217.87.122.179 (talk) 00:15, 3 February 2008 (UTC)[reply]
The preponderance of evidence shows that real world consensus is against your point of view. What evidence have you given in reply? Nothing, no evidence, you've just written waffle about "less than useless". The numbers are facts that do not support your point of view so you are wrong again because when you claim "it's less than useless" does not make it so. Wikipedia is excluded for the very good reason that a while ago someone made many hundreds of changes to use kibibyte etc and that means including Wikipedia would contaminate real world results. Also Wikiepedia is excluded from the results to show real world use. You also showed a search earlier on that did "-wikipedia", unless you now want to retract your earlier post? Trying to do a search for the much shorter versions like MiB ("Men in Black" for example) is also much more likely to pickup use of those three letters that has nothing to do with computers so your point is not well thought out because your proposal would have less much meaningful results. Fnagaton 01:07, 3 February 2008 (UTC)[reply]
It is Wikipedia's mission to provide clear and accurate information to the general readership. If unit like MB is met, it is never obvious what quantity this represents. Usage depends on the context (e.g. disk, memory chip, data tranfer). Many people do not know which is used when, and even less what JEDEC is and if it applies to the particular occurrence of the unit. The solution is giving a conversion to a world standard. Even if that standard not often used, it is still well documented and unambiguous—just what is needed to eliminate uncertainty. −Woodstone (talk) 09:33, 18 January 2008 (UTC)[reply]
Woodstone, as explained above what you see as "never obvious" is a red herring because what you call "the world standard" is not actually a "world standard" and it is not unambiguous. The real question is this, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 12:04, 18 January 2008 (UTC)[reply]
No, the real question is: how can we inform the reader clearly and unambiguously about the meaning of quanties given. Just using MB does not do that, because its meaning is context dependent. So what device are you proposing to achieve the goal of being informative. −Woodstone (talk) 12:41, 18 January 2008 (UTC)[reply]
Like I said above, express the exact number of bytes as disambiguation in brackets. For example 2KB (211 bytes) is the only unambiguous way of stating the number of bytes without using neologisms and it also shows that in this case it is using the binary context. Fnagaton 13:27, 18 January 2008 (UTC)[reply]
No, "2 KB (2^11 bytes)" is not unambiguous at all because there is always the possibility of mistakes. In this case, I'd assume the editor forgot the "i" and typed KB instead of KiB. Or worse, maybe someone added (2^11 bytes) because he assumed 2 KB was meant to mean 2048 when in reality it's really 2000. You might think it's "obvious" from the context, but context can only provide a rule of thumb. In many cases, the editor was just careless and typed "KB" instead of "kB". Many people don't know that SI prefixes are case-sensitive and that 'K' is incorrect as abbrevation for kilo (1000, one thousand). Thus, a chain of errors and "well-meant" edits can cause the following: 2000 bytes -> 2kB -> 2KB -> 2048 bytes. Same applies to "bits". Last but no least, this kind of hint reinforces the idea that KB absolutely means 1024. Sometimes less is more. If you think writing "(2^11 bytes)" is useful at all, why don't you drop the "2 KB" completely? It's not common practice in Wikipedia to write the same twice in different words. --217.87.122.179 (talk) 21:13, 2 February 2008 (UTC)[reply]
You are incorrect because "2 KB (2^11 bytes)" is not ambiguous and because it expresses exactly the number of bytes that are used. You are also incorrect because your "what if there is a mistake" scenarios are also irrelevant red herrings because as already stated in the guideline "...one must be certain... before disambiguation" and trying to throw out using a particular unit just because someone might edit an article incorrectly is no valid reason at all. Taking your point of view that would mean nobody changing anything because there might be a mistake somewhere. Thus your "many people" point is also irrelevant because if someone is not certain then they shouldn't be editing on a topic they are not certain about. Also changing KB to KiB when in the uncertain "many people" scenario you use is also wrong because the person is not sure what they are doing and could change something incorrectly. Dropping the "2 KB" completely is also not correct since as I have posted before consistency with the terms used in the reliable sources relevant to the subject is important. You are also wrong because disambiguation, "writing the same twice in different words", is very common. Fnagaton 21:24, 2 February 2008 (UTC)[reply]

(unindent) That makes sense. Perhaps more recognisable would be to use only multiples of 3 for decimal and of 10 for binary powers:

  • with decimal meaning: 64 MB (64×106 bytes)
  • with binary meaning: 64 MB (64×220 bytes)

−Woodstone (talk) 16:15, 18 January 2008 (UTC)[reply]

I really like the way this is heading, if it can be made to work. If there were such a guideline, I wonder whether it would actually be followed though. I think it is worth trying. Thunderbird2 (talk) 16:30, 18 January 2008 (UTC)[reply]
Yes using 2 and 10 notation would make it completely unambiguous and it also gives a very good hint as to what format is used for binary or more rarely decimal. Also it lets articles use the type of units that are used in the sources. Which is a bonus since maintaining consistency with sources as well as following the real world consensus is a really important issue for me and I suspect many others think the same. Of course as with disambiguation it need not be everywhere, just so that the article makes sense. Fnagaton 17:00, 18 January 2008 (UTC)[reply]
The suggestion appears to have some merit. Note: powers of three in decimal, e.g. 103x, means that everything is rounded in thousands; and powers of ten in binary, e.g. 210x, means that everything is rounded in kilobytes (=1,024).Pyrotec (talk) 17:11, 18 January 2008 (UTC)[reply]
I'm not sure how many readers wil be comfortable with this notation. In any case, I think what is being suggested is that for the binary meaning of the prefixes, it should be written as a power of 2, where the exponent is a multiple of 10. For the decimal meaning of the prefix, it should be written as a power of ten, where the exponent is a multiple of 3. --Gerry Ashton (talk) 17:28, 18 January 2008 (UTC)[reply]
I'm not sure whether Gerry Ashton's comment relates to my comment above, or an early one. My comment related to a question by Fnagaton which has since been edited, so it reads differently now & is no longer a question. My interpretation of Woodstone's comment, was a sequence of thousands & kilobytes, e.g 0.02*103, 0.2*103, 2.0*103, 0.02*106, 0.2*106, 2*106, etc, and a similar sequence for kilobytes (sorry I'm too lazy to do the binary sequence in kilobyte sequences). But if someone wants to see it?Pyrotec (talk) 17:43, 18 January 2008 (UTC)[reply]

Yes, of course. Very simple: keep the number as it is (no rounding needed) and convert, depending on context:

  • KB to ×210 bytes or ×103 bytes
  • MB to ×220 bytes or ×106 bytes
  • GB to ×230 bytes or ×109 bytes (etc)

Furthermore, it is not very important if all editors follow up on the guidelines. There will always be volunteers that will add proper conversion. Having it in the MOS will hopelfully prevent reversions. We still have to find a way out of the occasional MB = 1024,000 bytes. −Woodstone (talk) 18:03, 18 January 2008 (UTC)[reply]

How about: "This memory stick from company X is labeled as 1MB (1024×103bytes)" Fnagaton 18:09, 18 January 2008 (UTC)[reply]
How about: "This memory stick from company X is labelled as 1MB (210×103bytes)" (not "*" as above). Rich Farmbrough, 14:03 1 February 2008 (GMT).
or "This memory stick from company X is labelled as 1 MB (1.024 million bytes)" Thunderbird2 (talk) 14:10, 1 February 2008 (UTC)[reply]
No. These are the worst options. In one regard it fails as soon as you get to a billion and especially beyond because US and European billion differ. The next higher magnitude which will be common in 2-4 years (tera respectively tebi) has no layman equivalent. If you write "1 MB (2^30 bytes)" any sensitive reader would assume that 1 MB is always exactly 2^30 bytes. There is no reason to assume a unit would differ depending on context. The solution is very simple, use units correctly or don't use them at all. If a unit has supposedly more than one meaning, it is by definition not a U-N-I-T. unit comes from unity. No unity, no unit. Kindergarten logic suffices. --217.87.122.179 (talk) 06:07, 2 February 2008 (UTC)[reply]
You are wrong 217.87.122.179 because the units are de facto standards used in the real world and Wikipedia is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. Fnagaton 09:53, 2 February 2008 (UTC)[reply]
He is right in so far that the IT industry’s adoption of metric prefixes, beginning 40 years or so ago, in a different than standardised sense is the root of the problem. Only that made ambiguity possible. Separate binary prefixes should have been developed back then, but they weren’t, leaving us with the mess.
You are right that Wikipedia is descriptive – in intention at least, by its importance and influence nowadays, being part of the real world, it is defacto quite prescriptive! –, but you are also wrong, because its style guide, unlike encyclopaedic information, has to be prescriptive to some degree. MOS may very well choose to adopt a rule by reason that would not have been derived from observing common usage. IT prefixes used to be such a case, where MOS editors came to the conclusion that it’s better to diverge from common and source usage, adopting an international public standard instead to make the project less ambiguous and more homogenous. Some months ago this changed (after epic-length, tiresome discussions), because some article authors, like you, didn’t like to adapt their habits. The descriptivism myth evolved.
You are also wrong in that you didn’t respond to any of the points the IP user raised; just called him wrong, repeating your weak arguments once again. He does have at least one very valid argument: “There is no reason to assume a unit would differ depending on context.” — Christoph Päper 14:07, 2 February 2008 (UTC)[reply]
The IP user and you are wrong because it is fallacious to try to claim something is "different than standardised sense" just because a so called standards body decides to produce something contrary to what is the de facto standard. You are also wrong because the MOS is not prescriptive beyond what is actually common sense. You are also wrong because I did respond to the "points" the IP user raised, you will note this is the case since I wrote "because the units are..." giving a perfectly valid and correct reason. What you claim is the IP user's "valid argument" is actually shown to be a red herring by the very fact that the units have well known use. You are also wrong because the arguments put forward by me are stronger than what you have put forward and just because you disagree doesn't mean you are correct. Actually I'm giving you the benefit of the doubt here because you have put forward no such counter argument, instead you have attempted to question my motives and claimed a valid logical reason is somehow "repeating your weak arguments" without giving any supporting evidence. You are also wrong in your summary of the history of this topic and I demand that you retract your misrepresentation about what you think my motives are. Fnagaton 18:39, 2 February 2008 (UTC)[reply]
You are reacting on trigger words again instead of reading carefully and responding adequately. First came decimal metric prefixes (which I wrote about), then came bits and bytes (and octets and words), then came binary “adaptation” of SI prefixes in IT – with the side effect of capital k which I welcome –, then came disambiguity, then came IEC prefixes, then came Wikipedia. Where am I wrong here?
There is no such thing as common sense, never use it as an argument. The MOS is not prescriptive in the sense that it would say people what to do, but it’s prescriptive in the sense that it says what articles should look like in the end. (And yes, it’s often watered down in that regard, which I consider a failure.)
The IP users said, a unit with multiple meanings was not a unit by definition. You say that (he’s wrong and) the units under discussion were being used with multiple meanings, trying to prove your but actually also proving his point. His definition can’t be wrong, it just may not match yours.
The (here logical, not empirical) expectations of the readership are quite the opposite of a “red herring” argument in a discussion about our style guide! If the prefixes, when applied to bits and bytes, always were used in a binary sense (and decimal everywhere else), your point might stand, but they ain’t, e.g. in rates (kbit/s etc.).
I tried to limit my response (after I couldn’t suppress it completely), because I think everything has been said on the matter, although people still come to different conclusions, because their views about the role of Wikipedia and its MOS differ. (You try, intensional or not, to devalue the other position by calling it prescriptive and neological, which aren’t bad things per se, neither is de facto.) If I agreed with your presuppositions I would probably come to the same conclusion, because I don’t contest most of the facts you bring up again and again, thinking or at least implying that this was what needs to be discussed when actually we disagree on a higher level, which makes your points irrelevant – weak probably was an inappropriate or misleading term.
You’re in no position to demand anything from me (nor anyone else here), but, please, feel free to correct or at least discredit my summary, my view of the process.
Gee, I wish there was anything besides carnival outside so I hadn’t felt the temper to engage in this again. — Christoph Päper 01:24, 3 February 2008 (UTC)[reply]
You are incorrect because you are at fault here for not "reading carefully and responding adequately" (as you put it). This is because you misrepresent what I write and you attempted to misrepresent my motives in your summary of the history of this topic when you wrote "because some article authors, like you, didn’t like to adapt their habits". You are utterly wrong to try to misrepresent what you think are my motives. You are also wrong when you say there is no such thing as common sense because common sense is a large part of building consensus. Next we get onto you misrepresenting what I write. This is because I point out his "argument" (from 06:07, 2 February 2008 (UTC)) is a red herring and yet you insist on trying to rewrite my point to mean something else entirely. Just so you are perfectly clear, what you wrote is rubbish because I never wrote what you claimed I wrote. You are using a straw man, so your "point" is irrelevant and false. Fnagaton 02:01, 3 February 2008 (UTC)[reply]
I’m sorry it took me so long to respond, but I had much more important, non-WP things to do lately. Actually, I’m just taking a break from them.
So you think I misunderstood you or your motives. Maybe I did, big deal, happens all the time. You wouldn’t even have noticed if I hadn’t paraphrased what I understood and remembered (“misrepresent” you call it), just like I noticed your misreading. It doesn’t help, though, that you don’t explain where and how I misunderstood exactly. I assume it’s only about the changing habits part.
Nobody denies that kilo, mega and giga (at least) with bit or byte are often being used and understood in a binary sense instead of their classic, metric decimal one. Nobody denies that this occasionally results in ambiguity (in any imaginable way). Nobody is happy with the situation, although many take it as a given. Nobody intends a unit (or prefix) to have more than one meaning, although in practice (i.e. your de facto) occasionally one does. The IP user raises this point to a defining quality of a unit, you pragmatically don’t and call this (intentionally) irrelevant to the discussion (“red herring”). Am I right so far?
My main argument, which you ignored, still stands: We have different ideas of the purpose and foundations of this style manual. Therefore we cannot come to the same conclusion! So every argument is moot until we agree on the basic principles.
Whenever you claim the MoS was descriptive not prescriptive you are right and wrong at the same time, because a descriptive observation once published becomes a prescriptive rule in the understanding of many. This is how grammar and orthography “rules” came to be (for most natural languages).
Anyhow, a suggestion for compromise for the time being, although I would much prefer consensus in the long run:
SI prefixes are decimal and do not need disambiguation in general, but when applied to bits or bytes (incl. words and octets) without composition with any other units (as in rates, e.g. kbit/s) their meaning has to be disambiguated (one possibility is the replacement by IEEEIEC prefixes, which are always binary), except for RAM chips [and?] when used with a preferred number based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning. — Christoph Päper 19:36, 21 February 2008 (UTC)[reply]
I can see you are continuing to misrepresent me because I did not ignore your argument, your "argument" is fallacious for the reasons I have already given above and previously on this topic. Your compromise is not good because it does not represent real world consensus. Your "compromise" chooses IEEE which you prefer, which is not a compromise at all, it is pushing your own point of view. For example it is disingenuous to say "SI prefixes are decimal" and not mention the fact that the JEDEC defines K = 210, M = 220 and G = 230 when being used for semiconductor storage capacity and also because recent legal rulings have stated that despite what SI/IEEE/IEC claim the de facto standard is different. RAM chips commonly use the units KB, MB, GB in the binary sense, for example and this is defined in the JEDEC standard. If you really want to get into the whole "orthography" argument then you're going to be refuting your own point of view because orthography is to use correct spelling according to what is considered to be accepted (i.e. generally approved) and established use. In this case orthography easily refutes using the -bi prefixes because it is obvious they are not accepted and established use. Fnagaton 08:42, 22 February 2008 (UTC)[reply]
Gosh, either my English is worse than I thought or productive discussion with you (on this subject) is close to impossible.
I don’t care whether we use IEC prefixes for disambiguation. I just want to limit ambiguity inside and among WP articles. (Ambiguity outside WP is outside the scope of this style manual.) To achieve this we can either
  1. adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
  2. disambiguate (SI prefixes) inline each and every time or
  3. specify in MoS where we assume which default meaning (for SI prefixes), that wouldn’t have to be disambiguated, and where it’s too dubious to choose a default.
The current guideline does nothing to achieve the goal, uses only partially the second option. My suggestion for compromise does the third, although I very much prefer the first. Maybe I set the requirements for a binary meaning of SI prefixes higher than you would like, but with preferred numbers in the field of semiconductor storage capacity most cases would still be covered to your satisfaction. I see no good solution for file sizes, though, because files can be stored on different media (binary or decimal) and can be transmitted (decimal). — Christoph Päper 17:10, 22 February 2008 (UTC)[reply]
I note your continued misrepresentation and use of weak personal attacks, this shows that you are not interested in valid debate. You are also wrong because the current guideline fixes what you think is ambiguous by encouraging the exact number of bytes to be specified in the disambiguation or in footnotes. For example "256 KB (256×210 bytes)".
The first option "adopt something with mutual exclusive meanings" ignores real world consensus and makes articles inconsistent with their sources and actually doesn't solve the problem of using -bi units that can also be ambiguous.
The second option "disambiguate (SI prefixes) inline each and every time" is not logical since the purpose of disambiguation is not to include brackets (or similar inline text) after every number in an article, it is usually the case that only the first occurrence of any such number needs disambiguation.
The third option "specify in MoS where we assume..." is only going to get my support if it follows the real world consensus, i.e. not use -bi. Otherwise it is just going to be pushing point of view against consensus.
The best option, which you don't list, is to use the terms found in the majority of reliable sources relevant to an article. This means internal consistency for articles over and above consistency for the whole of Wikipedia. Fnagaton 17:33, 22 February 2008 (UTC)[reply]
Like I said, the current guideline, if anything, uses the second option. It’s the worst! It being basically optional doesn‘t make it any better. 256 KB would default to binary meaning by my proposed compromise (in the context of semiconductor storage at least) and thus would only have to be diambiguated if it had a decimal meaning instead.
I didn’t deny that the first option would only be internally consistent. Unlike you I don’t consider this a huge problem. I tried to point that out earlier. IEC prefixes are always binary and thus unambiguous, even if you should find someone using them wrongly.[1]
Read it as “disambiguate (SI prefixes) in each and every article” if you must.
Real world consensus is that IEC prefixes are one way to achieve disambiguity where needed; the real world isn’t just very often unambiguous. For symbols the little i is probably the least cumbersome, least space-taking and – like it or not – most established solution. If you don’t like the terms “kibibyte” etc. – I don’t – you may use “binary kilobyte” or something like that where needed.
What you call a best (or fourth) option is not solving the problem at all, because it would mostly result in SI prefixes being used with varying meaning. Every reader would have to make a (hopefully educated) guess. My proposal was to provide a rule of thumb for that guess in the MoS. I already tried (without success) to discuss our different views of the scope for consistency. — Christoph Päper 10:11, 11 March 2008 (UTC)[reply]
The IP user raises only one valid point, that even more confusion will arise when larger memory becomes available. In respect of (computer) memories, in the real world units do change depending on context - read the discussions above: a million can mean 1024 x 1000 and 1024 x 1024 depending whether is a megabyte of storage on a hard drive, memory stick, etc - go and look at amazon.com. The IP user appears to be confused, it is not misuse of units in wikipedia that causes problems it is inconsistent use of units in the computer industry that causes the problems. Wikipedia MOS is attempting to add clarity to the confusion that already exits.Pyrotec (talk) 19:52, 2 February 2008 (UTC)[reply]
I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.Pyrotec (talk) 20:20, 2 February 2008 (UTC)[reply]
Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". Fnagaton 20:35, 2 February 2008 (UTC)[reply]
  • That difference is irrelevant everywhere, except perhaps nursing homes in the UK. Tony (talk) 23:28, 2 February 2008 (UTC)[reply]
Maybe you don't know that "billion" is not only an English word. Billion is still frequently mistranslated as "billion" when it actually means 10^9 in one (European) language and 10^12 in the other like French or German. The UK might have adopted the US meaning by now, that's not true for any other country. You see it's almost the same issue as Megabyte vs. Megabyte. One is 10^6 and the other is 2^20. Keep in mind that this neither the American nor the British Wikipedia, it is an international effort. As there is no official authority for the English language, really nobody can decide which meaning of billion is correct but it is trivial to avoid these few well-known sources of confusion. --217.87.122.179 (talk) 00:00, 3 February 2008 (UTC)[reply]
No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability. —Preceding unsigned comment added by 217.87.122.179 (talk) 20:56, 2 February 2008 (UTC)[reply]
Yes I did mean that so do not presume to tell me what you think I really meant because when you do so you are misrepresenting me and what I wrote. Also your incorrect accusation of "bad faith" shows you have not presented a valid argument because the term "red herring" is actually referring to the logical fallacy, which your "argument" is actually using. This is also pointed out by Pyrotec as being irrelevant. Fnagaton 21:08, 2 February 2008 (UTC)[reply]
Okay, then I'm relieved that I could help in making clear what you actually meant because it wasn't obvious at least to me. I don't quite agree with your presumed definition of red herring but discussing this would be another one and off-topic anyway. --217.87.122.179 (talk) 21:58, 2 February 2008 (UTC)[reply]
Red herring fallacy also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. Fnagaton 22:43, 2 February 2008 (UTC)[reply]
Not taking either side, but the Google test is worthless. As is citing voluntary standards (as are the IEEE's, IEC's, and JEDEC's) as examples of "policy". Voluntary standards are just that, and it's hardly surprising you can find standards which reflect common usage. Consider:
mile -wikipedia - 24,300,000
kilometer -wikipedia - 1,520,000
inch -wikipedia - 26,000,000
centimeter -wikipedia - 6,800,000
pound -sterling -wikipedia - 11,200,000
kilogram -wikipedia - 8,240,000
acre -wikipedia - 3,420,000
square kilometer -wikipedia - 1,660,000
Can these results be used to argue that preference should always be given to imperial units of measure, since apparently more English-speaking people will be familiar with them? Can they be used to decide on a case-by-case basis which units are preferable? Can you say that common use is universally more important than standardization in every case or vice versa? No matter how you concoct the Google Test argument, it is always flawed.
Experience with Wikipedia should tell you that no amount of dialog on this will ever settle the issue wholly in favor of or against IEC prefixes. There's zero editorial direction on this site, and unfortunately the MOS as a whole is more or less a farce (used merely when it is convenient in an argument), so fights like this will keep breaking out. I strongly suggest you look for a middle ground where the use of IEC prefixes is accepted in some contexts and the common prefixes are accepted in others. Pages like the one on floppy disks really do need some concise method to deal with the prefix ambiguity, and the IEC prefixes are one such way.
Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Wikipedia, so that argument won't work. The current reading explains the history of the debate, lays out the facts (common use versus ambiguity) and doesn't take any strong position. The only change that might be useful is provision for changing prefixes to IEC variants where appropriate and discussed beforehand. This excludes contentious en masse changes, but still acknowledges that there are some circumstances in which utilization of IEC binary prefixes might be useful. (maybe also remove the mention of the JEDEC, which is utterly comical since their standards have nothing at all to do with standard prefixes for unit measures)
You will never convince each other. You will not be able to defeat the common usage argument. You will not be able to defeat the ambiguity argument. You will never end this debate by brow beating the same tired and cyclical arguments into one another. I humbly suggest just leaving the dead horse alone and letting the editorial ebb and flow take its course. Otherwise you're just wasting your own time in neverending trite rhetoric. -- 74.160.99.252 (talk) 20:27, 11 February 2008 (UTC)[reply]
Unfortunately the IP user from Germany (not you 74.160.99.252) but the other user from 217.87.122.179 above (and their other IPs in that ISP range) decided that instead of trying dialog they would vandalise ANI, several talk pages including mine and an admin. Eventually leading to several semi-protects and range blocks. The ambiguity argument has been refuted since it relies on the false premise "nobody uses -bi in other ways except binary" because it has been shown that -bi has been used in the decimal sense. Fnagaton 20:39, 11 February 2008 (UTC)[reply]
I'm pretty sure 74.160.99.252 is the same person you're talking about. --85.25.12.31 (talk) 21:28, 11 February 2008 (UTC)[reply]

Don't wikilink units in infoboxes & tables?

This change was just made (change in bold):

  • In tables and infoboxes, use unit symbols and abbreviations; do not spell them out. They should not be internally linked with wikipedia pages.

Why not? Was this change discussed anywhere? —Preceding unsigned comment added by Gerry Ashton (talk • contribs) 18:42, 13 February 2008 (UTC)[reply]

added line - is there a better way to phrase it. CorleoneSerpicoMontana (talk) 21:25, 13 February 2008 (UTC)[reply]

I don't understand the need for this change. Please explain. Thunderbird2 (talk) 21:31, 13 February 2008 (UTC)[reply]
I'm opposed to this change. In infoboxes and tables, space is at a premium, so there no room to explain units. Hence, the need for wikilinks is greater than in the text of articles, not less. --Gerry Ashton (talk) 22:00, 13 February 2008 (UTC)[reply]
I agree with Gerry Ashton. Thunderbird2 (talk) 22:09, 13 February 2008 (UTC)[reply]
I'd rather see links to unit articles in the text but if the unit does not appear in the text & needs linking, why not link from an infobox or table? Generally, yes, in tables & info boxes should use abbreviations but not always, obvious examples are where the abbreviation is not well recognised, could easily be misread or doesn't even exist. Shall we not look into a rephrasing of the whole point? Jɪmp 02:53, 14 February 2008 (UTC)[reply]
re-worded. This comes from working with alot of sports infoboxes where the weights and heights are detailed in both imperial and metric systems. CorleoneSerpicoMontana (talk) 08:40, 14 February 2008 (UTC)[reply]
Can you point us to a specific example that causes a problem? Then we can try to help you solve it. Thunderbird2 (talk) 09:02, 14 February 2008 (UTC)[reply]
The articles from the UK, and Australia at least work in st, lb, & kg, along with ft, in & m. I don't believe the need to be linked as it only makes the infobox garish. The units themselves are described in metric and imperial units and it seems that were someone not used to using either system, which frankly seems unlikely they can go through the search feature. This is a small problem as it is only a very small percentage that currently link units. CorleoneSerpicoMontana (talk) 09:08, 14 February 2008 (UTC)[reply]
See: Wikipedia:Only make links that are relevant to the context "What generally should not be linked" "Plain English words, including common units of measurement." Lightmouse (talk) 10:30, 14 February 2008 (UTC)[reply]
My view is that non-SI units should be linked somewhere in the article, and preferably on first use. If they are linked outside the infobox, there is no need to do so again inside it. Thunderbird2 (talk) 17:55, 14 February 2008 (UTC)[reply]
Depends on the unit. Rods and perches should be linked, simply as rare words, independently of this guideline; linking ton is one way to deal with ambiguity (although explanation, perhaps in a footnote, would be better). But linking foot is as unnecessary as linking leg. Septentrionalis PMAnderson 03:17, 15 February 2008 (UTC)[reply]
In that line, the "stone" as a unit of measure mentioned by CorleoneSerpicoMontana is a rare word to most native speakers of English, let alone to almost all of the many readers we have who are not native speakers of English.
But to say that in infoboxes and tables, units should not be linked is nonsense. There are many SI units which should be linked as well (how many of you understand joules and katals and kelvins and luxes and becquerels well?), as well as hundreds of Fred Flintstone non-SI metric units, English units, and units of a number of other old systems of measurement from all over the world. "Infoboxes and tables" include more than those just listing an athlete's height an weight. They use all sorts of strange and uncommon units.
Like Pmanderson/Septentrionalis says, there is usually not any real need to link feet. There is also not any good reason to link inches or meters or kilograms. But pounds often need to be linked for disambiguation purposes, especially in the thousands of articles we have using both the pound and the pound, as well as to disambiguate both of them from the various currencies of the same name). But even for pounds, when it is a listing of a persons height and weight, there is no crying need for any link. We aren't going to be thinking these are pounds sterling nor wondering what they are in terms of euros, and while some miseducated science-trained people might be confused enough to think they are pounds-force, that's their problem not ours. One little link isn't going to remedy their miseducation, if they've already ignored the evidence of the conversion to kilograms rather than newtons and everythig else.
I agree with Gerry Ashton's point that linking of units is slightly more necessary in infoboxes and tables than in running text. Furthermore, linking in text should not necessarily preclude linking on first appearance in boxes and tables, nor vice versa. For one thing, it isn't always clear which comes "first" in everybody's reading habits, and boxes and tables are likely to be considered in isolation without even reading the text by some, while others will be reading the text and paying little attention to everything else. Gene Nygaard (talk) 14:23, 29 February 2008 (UTC)[reply]

Quick NBSP question

Under the NBSP section, the MoS states "In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line." and as an example, gives "19&nbsp;kg" as an example. My question is, if I wrote out "19" as "nineteen", would I still put a non-breaking space in-between the number and the unit of measure? In other words, which would be correct: "nineteen&nbsp;kg" or "ninteen kg"? Thank you. Dlong (talk) 16:38, 19 February 2008 (UTC)[reply]

That (nineteen kg) would breach WP:MOSNUM. Also, if you prefer {{nowrap}} to nbsps, you can use that. SandyGeorgia (Talk) 16:42, 19 February 2008 (UTC)[reply]
Better use "nineteen kilogram", with a normal space. Full numbers go with full names. &mminus;Woodstone (talk) 17:52, 19 February 2008 (UTC)[reply]
In other words, irrespective of the non-breaking space (which I do not have a view on) use either "19 kg" or "nineteen kilograms". (surely not "nineteen kilogram" ?) Thunderbird2 (talk) 17:55, 19 February 2008 (UTC)[reply]
A normal space in "nineteen kilograms" (plural) will be just fine—a line break between those words won't look awkward or be hard to read. Neonumbers (talk) 03:43, 21 February 2008 (UTC)[reply]


I don't think the current wording makes that clear at all.

Followup. Suppose you have "is Cp = 38.171 J mol−1 K−1 at"

Tell me:

  1. Where you think the current MoS rule "recommends" non-breaking spaces. How many? All seven spaces? only some of them? Five? One? Three?
  2. Where this should logically be allowed to break.
  3. Whether they are different.

I'd say our screwball rules, read literally, clearly call for one nbsp in this case (before the J)—and that one is precisely at the place where it is most logical to allow a line break.

You may well think that the rules call for more than that. Explain where, and explain why that is so in terms of the current rule.

Now, don't peek at the coding until you've answered the parts above, and I'll put in the nbsp which to me seem absolutely essential: "is Cp = 38.171 J mol−1 K−1 at ..." Well, maybe not absolutely essential: there is an alternative for two of them; you can use a centered dot instead, but it should not be the dot on the line used in the actual article from which I borrowed this expression.

Obviously, there are a lot of people writing these rules who are incapable of grasping anything more complicated than "19 kg" when it comes to measurements, who might be blissfully unaware that people do use much more complicated numbers and much more complicated units than that. Our rules used to call for a nonbreaking space only in that situation, between a number in numerals and a symbol for a unit of measurement (metrologists like to distinguish these "symbols" from ordinary "abbreviations", which unlike the symbols are usually language-dependent and might change in the plural be followed by a dot or be italicized and things like that).

  • Why was it changed, without discussion, to even apply to spelled-out names of units of measurement in any case, whether they are preceded by a number in words or by a number in numerals?
  • And why hasn't it ever been changed to recommend non-breaking spaces in the places where it really matters, such as within a number itself (e.g., 14&nbsp;3/16 in) and within the symbols for a unit (which are not "numerical and non-numerical elements ... separated by a space"), such as the "J&nbsp;mol−1&nbsp;K−1" in my example. Gene Nygaard (talk) 10:43, 28 February 2008 (UTC)[reply]


Well, I don't know what the page said when you read it but my own extrapolated conclusion from the current page text and my personal point of view is that the whole formula should be prevented from wrapping. However the current page text recommends using {{nowrap}} for the more complex cases which doesn't work in your case since your formula contains characters that is interpreted by the MediaWiki template engine. So I would instead use the new {{nowrap begin}} + {{nowrap end}}, like this: 

"is {{nowrap begin}}''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup>{{nowrap end}} at"

Which renders this:

"is Cp = 38.171 J mol−1 K−1 at"

Neat, isn't it?

You can read up on line wrapping at the brand new how-to guide Wikipedia:Line break handling.

--David Göthberg (talk) 22:10, 12 March 2008 (UTC)[reply]

DWT

The shipping term deadweight ton refers to a long ton (2240 lb) of deadweight. It is abbreviated as "DWT". A similar term, deadweight tonne, refers to the same but this time in tonnes (1000 kg). The problem is that it seems that the same abbreviation, "DWT", is used. Russ Rowlett's Dictionary of Units of Measurement has this to say.

deadweight ton (dwt)
a traditional unit of weight or mass used in the shipping industry. The deadweight tonnage of a ship is the difference between its weight when completely empty and its weight when fully loaded. This includes the weight of everything portable carried by the ship: the cargo, fuel, supplies, crew, and passengers. The deadweight ton is traditionally equal to the British ("long") ton of 2240 pounds (1016.047 kilograms). However, more and more often it is being taken to equal the metric ton (exactly 1000 kilograms, or 2204.623 pounds).

How do we go about dealing with the ambiguity? It has been suggested, by Haus, that we choose a standard for Wikipedia. Other means of disambiguation have also been suggested. So far four approaches have been considered. Symmetry would have us consider a fifth (I do like symmetry). Let me list them.

  1. Let "DWT" always stand for long tons of deadweight and spell deadweight tonne(s) out whenever necessary.
  2. Let "DWT" always stand for tonnes of deadweight and spell deadweight ton(s) out whenever necessary.
  3. Avoid the abbreviation, "DWT", altogether and always spell both terms out.
  4. Use "DWT (metric)" and "DWT (long)" for tonnes and long tons respectively of deadweight.
  5. Use "DWTmetric" and "DWTlong" for tonnes and long tons respectively of deadweight.

Here are some of the advantages and disadvantages that I see with these.

  1. This follows tradition. As far as I can tell, this is the most common meaning of "DWT". However, I've got only my own Googling to to support this and we're aware of the American dominance of the web. Also, as the decades, centuries ... millenia ... wear on ... Wikipedia is forever, right. The long ton meaning of "DWT" might fall out of favour.
  2. Against tradition & common use but may be forward-looking, this has the added advantage of naturally conforming to standard Wikipedia practice in which conversions to metric are generally given whereas conversions to avoirdupois are generally not and in which (in text as opposed to infoboxes) the units converted from are generally spelt out and the units converted to are generally abbreviated: in other words 2. allows "125 deadweight tons (127 DWT)" whereas with 1. we can only have either "125 DWT (127 deadweight tonnes)" or "125 deadweight tons (127 deadweight tonnes)". Of course, both 1. and 2. require that readers and editors be familiar with the Wikipedia standard — this may be a big ask.
  3. This avoids any possibility of ambiguity and is unbiased towards this or that system of measurement but means that we have to have a lot more text.
  4. This again avoids the ambiguity and bias. It allows both terms to be abbreviated. It makes it clear to those none too familiar with shipping that it is a long ton rather than a short ton (or even a metric ton) which is being refered to. However, it is kind of ugly especially if you're a conversion, e.g. "125 deadweight tons (127 DWT (metric))", even more so if you want to abbreviate both units, e.g. "125 DWT (long) (127 DWT (metric))".
  5. This has the advantages of 4. whilst avoiding the ugliness, however, it could be argued that a subscript is part of the symbol therefore "DWTmetric" & "DWTlong" could be seen as being symbols of our own invention.

So, what say you? What do we do here? My preference is going to 5. (I had been keen on 4. until I started typing examples out & saw how it looks). Jɪmp 07:29, 4 March 2008 (UTC)[reply]

Just to point out that we're not the only ones having difficulties with this, the GPO uses inconsistent deinitions where "ton=long ton," "t=metric ton (or tonne)," but "dwt"="deadweight ton." My inclination is also orbiting #4 and #5 above. On the surface, it seems that a clever use of wikilinks could be used to stave off confusion, but it seems to work poorly on long pages with many uses of the forms "DWTmetric" & "DWTlong" Cheers. HausTalk 15:05, 4 March 2008 (UTC)[reply]
Overall I too would prefer #4 or #5 (the latter being better due to being prettier). It should be remembered however that the problem of ambiguity also extends to sources - for instance this very useful website lists a DWT figure for mosts ships but I've no idea whether they're in tons or tonnes (presumably the metric ones, but is that an assumption I can make?). -- Kjet (talk · contribs) 15:32, 4 March 2008 (UTC)[reply]
Of course, your linking could go like this "DWTmetric" & "DWTlong" but, yes, disambiguation via links is problematic not only for the reason mentioned above but also because it requires the reader to click on the link (unless they're familiar with the tool-tip-hover-over trick), which can be a great distraction and which will be impossible if you're sitting on the train with a copy of the article you'd printed during lunch. Jɪmp 16:23, 4 March 2008 (UTC)[reply]
My two cents.
Avoid "DWT" entirely. Spell out deadweight when appropriate.
  • For what it's worth, you also see "dwt tons"; the "t" at the end of dwt doesn't even have to come from "tons" or "tonnage" in any flavor; rather, some look it as the "wt" being a common abbreviation of "weight" with a d stuck in front to identify "deadweight".
Any discussion of using "tonne" is inappropriate without also considering American English, where it is a metric ton not a "tonne", and French, where tonne is as ambiguous as ton is in English.
What is needed with all the ton of different "tons" used in shipping is more clarity in what is being measured. More clarity on the meaning of "light weight" and various other things used as well as dead weight. More clarity on basics such as whether the measurement is a measurement of volume or one of mass. For example, what do we do with submarines? Their surface displacement is a normal measurement of mass, but their dived displacement is essentially a measure of volume: Archimedes' principle, a floating object displaces its mass and a submerged object displaces its volume.
It is truly unfortunate that the BIPM and other standards agencies consider any tons acceptable for use with SI, and doubly unfortunate that they choose to specify a symbol for it (t) that is also used for long tons or for short tons.
To be more specific on my first point. I especially mean not to use "DWT" (nor the more appropriate lowercase "dwt") as a symbol for a unit of measure. It is less objectionable to use it as part of the identification of the quantity being measured, but you should not have a number followed by "dwt" used as a unit symbol, whether standing alone or the subscripted suggestions above. It's part of the general rules about not attaching information to the units of measure, and especially not to the metric units. Using something like psia or psig is frowned upon for the same reasons.
  • Unacceptable: The ship is 9,400 dwtlong (9,400 dwtmetric)
  • Acceptable: The ship has a dwt of 9,400 long tons (9,550 t) [at least on first use in an article, I'd say that it is better to spell out "deadweight tonnage" than to use "dwt" in this case]
Gene Nygaard (talk) 18:55, 4 March 2008 (UTC)[reply]
So, we have a sixth option.
6.  Don't use "DWT", use "dwt". However, "dwt" is an abbreviation of "deadweight" not "deadweight tonne" or "deadweight ton". Neither use "deadweight tonne" nor "deadweight ton" but treat "deadweight" like "height", "length", "speed", etc.
Of course, "dwt" (lower case) is the symbol for the obsolete pennyweight (here's another example of "wt"'s standing for "weight" ... also "cwt") but if (when we're talking about deadweight tonnage) we're not using "dwt" as a symbol for a unit of measure, there can be no confusion.
One must admit that Gene's approach is the easiest to comprehend as it follows the norms of English — "The ship has a dwt of 9,400 long tons (9,550 t) and the captain has a height of 6 foot 2 inches (188 cm)." We'd also avoid the temptation to use the fancy unconventional linking I suggested above (linking "DWT" to Tonnage and the subscripts to articles on their respective unit).
Gene, I suppose this means that the likes of "bhp", "shp", etc. is also frowned on.
Jɪmp 01:14, 5 March 2008 (UTC)[reply]
I like the #5 option. I wouldn't use dwt because of the pennyweight measurement. —MJCdetroit (yak) 02:00, 5 March 2008 (UTC)[reply]
Trying to distinguish "dwt" meaning deadweight from "DWT" meaning deadweight metric tons (or deadweight long tons, whatever) is just sheer lunacy. We have enough articles tainted by Wikipedia usage already, without having to create a new way of accomplishing this.
And worrying about a unit the Brits—and by extension, most or all of the Commonwealth—outlawed over 129 years ago (as of 1 Jan 1879, together with its pound, while retaining its ounce as an official exception to metric conversion in the 21st century), is not far behind. Especially when it is 3⁄1960000 as large; anyone who thinks for more than a millisecond that these ships might be weighed in pennyweights probably ought not be allowed to use an encyclopedia in the first place.
These are not different units of measure. We should not have different unit symbols depending on the particular application in which they are being used. These proposals are like using "French degrees Celsius" and inventing a Wikipedia symbol FC for them in articles related to France, and "Swedish degrees Celsius with a symbol SC for them in articles related to Sweden. Gene Nygaard (talk) 14:46, 5 March 2008 (UTC)[reply]
I'd be interested in seeing a reference which defines "dwt" as "deadweight" and not "deadweight tons" or "deadweight tonnage." Various forms including "DWT," "dwt," "d.w.t." are used to indicate "deadweight tons" or "deadweight tonnage" at the GPO as I mentioned earlier, 6 dictionaries and the three industry-specific technical manuals I have at hand. HausTalk 15:05, 5 March 2008 (UTC)[reply]

←outdent← Weighing ships in pennyweights ... hilarious. No, anyone with half a brain could tell the difference. My concern, however, was that a template can't. Jɪmp 15:50, 5 March 2008 (UTC)[reply]

Not much different from the half-baked notion that we should not use "kt" as a symbol for the unit of speed for those same ships, because somebody might confuse it with a symbol for non-SI and not-acceptable-for-use-with-SI units of energy, is it?
I realize where you are coming from. My main point is that a template for converting measurements should not be concerning itself with what those units are being used to measure. It is the same "tons" that are used for "light weight" of a ship as for "deadweight" of a ship, the those same tons are also used for "standard displacement" and for "full load displacement" and various other weights. Two or three different units all called "tons", to be sure, (plus a ton of other tons measuring volume and energy and force and power and whatever) but not 15 or 24 or whatever different units of mass.
But for those who do not realize where you are coming from, let me explain. User:Jimp is the one and only person on the planet Earth who is capable of editing the monster template {{convert}}. It can do lots and lots of different things, most of them quite well. It also does many other things very poorly. But it is so bloated, so convoluted, that nobody other than its chief creator (at least since the early days as a simple template) can figure out how to fix it if it isn't working as well as it should. He has total control; no fixes can be made without going through him, even if the template weren't "protected". Even ordinary users would have to study it for the equivalent of a 6-semester hour college course in order to be able to understand its intricacies and use that black box well in all situations. To show just the tip of the iceberg:
  • The Category:Subtemplates of Template Convert has 1,024 articles.
  • Special:All pages for the template namespace has somewhere in the neighborhood of 3,033 subpage templates and subpage template redirects under the main convert template.
  • Yet, despite all this complexity (or perhaps more properly because of this unbelievable complexity), you can
Apparently convert nautical miles to siemens per tesla:
  • {{convert|1347|nmi|S/T}} → 1,347 nautical miles ([convert: unknown unit])
    1. That's not an accurate conversion, of course. And in any case, even when you figure out that the "S/T" symbol isn't intended to represent siemens per tesla (whose dimensions are the inverse of those of acceleration, L−2 T), you still have the problem that despite its overwhelming complexity, the convert black box does no dimensional analysis of the units, and lets you blithely convert apples to oranges. Perhaps not literally, or I just don't know the symbols for 1,347 apple[convert: unknown unit], one of the few missing on that Special:All pages list. But, in this case, the eguivalent nautical miles (dimensions: L) to short tons (dimensions: M) does not produce an error message, unlike the attempt to literally convert from apples.
    2. What that "S/T" is intended to represent indicates a significant need to expand the scope of the current discussion beyond the original "DWT" issue.
Or, suppose you have a product with nutritional information "per 12 ounces" and you want to convert it. Using "per {{convert|12|oz|mL|disp=/|sp=us}})" looks reasonable, doesn't it?
  • If you want to see what happens, go look at the article where I added exactly that conversion 3½ months ago. It is still there as I write this.
  • Once again, bitten by a failure to do dimensional analysis.
Furthermore, the template has a strong bias against the use of American English, requiring explicit addition of a parameter (sp=us) to achieve it. Yet, when it comes to "metric tons", that parameter doesn't work. Instead, the spelling setting is ignored and what is spelled out depends on the unit parameters used.
Maybe this discussion should instead branch out to a more general discussion of whether or not the use of complicated black boxes of this sort is appropriate on Wikipedia. Gene Nygaard (talk) 17:18, 5 March 2008 (UTC)[reply]
I sympathise with Gene's statement that "a template for converting measurements should not be concerning itself with what those units are being used to measure" as a logical consequence of "the general rules about not attaching information to the units of measure", which, in turn, seem quite reasonable to me especially when looked at from the point of view of comprehensibility. However, if people are going about breaking these rules we either have to enforce them or work around the situation. Now, I was lead to believe that the terminology "deadweight tons", either long or metric, was what is in use and started to add such a work-around to {{convert}}. If instead we could somehow get editors to follow those aforementioned rules against this type of terminology, I'd be more than happy to trim the deadweight out of the black box. "1000 tons of deadweight" is a whole lot easier to comprehend to those unfamiliar with shipping terminology than "1000 deadweight tons" (better still if we specify what flavour of ton we mean). As for "DWT", "dwt", "d.w.t." or however you write it; if we can't make up our minds on what it's meant to stand for, why don't we just ban it? Thus a seventh option:
7.  Do not attach information to units of measure. Therefore don't use "deadweight (long/metric) ton(ne)(s)". Treat "deadweight" like "height", "length", "speed", etc. Don't abbreviate "deadweight", always spell it out.
As for Gene's comments regarding {{convert}}, some of them he has already voiced on the template's talk page and I have responded there; but, for those who might not feel like searching the template's talk archive, let me breifly recap. To that which we haven't yet covered there I'll respond here but again briefly, let more detailed discussion be carried out there.
Others can and have edited the monster (including Gene), though, yes, anything more than minor edits would require more patience in getting familiar with a rather complex template than most editors probably have. It is complex, it was, however, never my intention to make it so complex that I'd be the only one editing. If there is a significantly simpler way to get it to do what it does without increasing the pre-expand size, I'll be happy to see it replace the current version. I'd be only too happy to relinquish my "total control".
The lack of dimensional analysis is a down fall in the template. If this is a real problem, it could be fixed. Fixing it would, of course, require more code & therefore more complexity. I was aware of this as I wrote the template but I thought "Garbage In, Garbage Out" — if you try to convert litres per hundred kilometres to hectares, expect nonsense. I left it up to the template users to know what they're doing. Yes, unfortunately, this means that an editor might plug in oz hoping for fluid ounces but get avoirdupois instead. Then there's "PS" which the template takes to be metric horsepower as opposed to petaseimens and "S/T", mentioned by Gene, for short tons.
The template has a bias against ... [[WP:ENGVAR|? ... American English. How is it strong? What are our options? Unless we make it such that there is no default, requiring explicit addition of the sp parameter either way (which would benifit nobody); the bias has to go one way or other. I cannot see how a bias against American spelling is any worse than a bias against the way the rest of us spell.
Connect the whether the template gives "tonne(s)" or "metric ton(s)" to the spelling parameter, that could be done easily enough. It hadn't occured to me. I guess I think of "tonne(s)" and "metric ton(s)" to be completely different terms rather than simply different spellings of the same term.
Maybe a more general discussion of whether or not the use of complicated black boxes of this sort is appropriate on Wikipedia is in order. Maybe it should find its own section. Maybe this discussion should get back to how we want to deal with expressing deadweight tonnage.
Jɪmp 07:47, 6 March 2008 (UTC)[reply]
The only difficulty with #7 is that it inhibits succinctness. "DWT" occurs over 15 times in articles like Bulk carrier and Oil tanker. (There either are or will be lists where the term will be used many, many more times.) Reading back over this thread, an approach of "define it, then use it" emerges. In this edit, I worked a short definition into the first use in the article: "coastal tankers of a few thousand long tons of deadweight (DWT) to the mammoth supertankers of 650,000 DWT." Any feelings? HausTalk 11:51, 6 March 2008 (UTC)[reply]

Prices are numbers too

We often don't bother to give numbers to four significant figures, and, wishing to avoid pedantry and the wasting of space, I therefore changed

for US$19.99, £12.99 in the UK or AU$24.99 in Australia

to

for US$20, £13 in the UK or AU$25 in Australia

in this edit. Realizing that this might be controversial, I immediately announced the change on the talk page of this popular article. To my surprise, it got just one (unfavorable) response. What do you people think? -- Hoary (talk) 10:04, 4 March 2008 (UTC)[reply]

For some purposes exact numbers are preferable, and for others they are unnecessary. Unnecessarily reducing the accuracy of data can make it less useful to some people. In the case of prices, the difference between £12.99 and £13 is negligible; but there is no advantage in changing £12.99 to £13. If you are writing an article and you want to say £13 instead of £12.99, fine; but don't edit other people's work to make this change as you just annoy people and potentially make the data less useful.--Toddy1 (talk) 19:19, 4 March 2008 (UTC)[reply]

I am trying to think of when it would be necessary to quote the cents/pence/koupek... As WP:NOT#DIRECTORY, we are discouraged from putting retail prices except when they are historically relevant. Use of the units after the decimal place appears to matter the most from the sales (price pointing) perspective for any given product, although occasionally one may be called upon to cite a historical high or low share price or discuss the psychological impact of this type of price pointing in same, but generally the simplicity of $13 over $12.99 within wikipedia is a clear advantage, AFAICT. Ohconfucius (talk) 03:57, 5 March 2008 (UTC)[reply]

The size of a thousand

Commas are used to break the sequence every three places left of the decimal point; spaces or dots are never used in this role (2,900,000, not 2 900 000).

says the manual under the heading Large numbers. We do intend this to start a 1,000, don't we? I'm suggesting we tighten the language to make it clear what exactly we mean by large. Are we considering numbers in the range of 10,000 > x ≥ 1,000 to be large here? Jɪmp 14:36, 4 March 2008 (UTC)[reply]

Concern: commas and dates

MOS:DATE#Dates (or any other section I'm aware of) does not clarify that commas have to be inserted for full dates which are wiki-linked. Example; a comma automatically appears in February 14 2008 (see the linked [[February 14]] [[2008]] here, note that it does not for February 14 2008 and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in this revert? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline should say that a comma does not need to be inserted for a correctly linked date. Is this understandable? Lord Sesshomaru (talk • edits) 02:52, 5 March 2008 (UTC)[reply]

See also Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_94#Commas_in_linked_dates. Some people still don't realize a comma is added in [[February 14]] [[2008]] (February 14 2008), and removed in [[14 February]], [[2008]] (14 February, 2008), even for IP editing. The revert was based on a misunderstanding. Gimmetrow 03:03, 5 March 2008 (UTC)[reply]
So you agree that these things should be mentioned in the guideline? Lord Sesshomaru (talk • edits) 03:08, 5 March 2008 (UTC)[reply]
I can agree with saying a comma does not need to be inserted with the [[February 14]] [[2008]] format, but I'm less clear on recommending it. No comma seems to confuse editors. With [[14 February]], [[2008]], I think the comma should be removed and not restored, since MediaWiki removes it anyway for viewing, but editing solely for this would be a trivial edit. Gimmetrow 03:30, 5 March 2008 (UTC)[reply]
The guideline doesn't say that is HAS to be added, but it also doesn't say it HAS to be removed. If the comma is optional, the guideline probably should note that, but I don't think that should be a justification to remove them. Does having the comma there cause any actual problems? If not, when doing February 14, 2008, why remove the comma? It seems like a personal editing preference, and not one that needs to be "corrected" unless there is an actual reason to do so. Collectonian (talk) 03:35, 5 March 2008 (UTC)[reply]
This argument is a bit pointless. When a complete date is wikilinked, it will always display correctly—for the American style the comma will be inserted where it is not present. The opposite applies for British style, where the comma is deleted if present. This applies also for unregistered users. But mention should be made of this somewhere to prevent unnecessary editing. I had a discussion about this before (here) and still have the test in my sandbox (if anyone's interested be sure to switch of dates preferences beforehand). TINYMARK 04:07, 5 March 2008 (UTC)[reply]
It's just like the image sample I cited: why add |right| if |thumbnail|, |frame|, etc., already does the job? It's past redundant. Therefore, the guideline should make note of this. Do we have an agreement? Can this be indicated in the guideline now? Lord Sesshomaru (talk • edits) 04:17, 5 March 2008 (UTC)[reply]
I'd link to see an alternative way of formatting dates than using double brackets ([[ ]]). The problem I see lies in there not being consensus on how dates should appear (American vs international), leading to a system where user preferences can be set to recognise and format all dates marked in a certain way. Fine, up to a point. However, in using the article linking mechanism, dates are being linked left right and centre, when there is no real reason to - many dates in articles have no great historical significance, and do not even warrant a mention in the linked date article. Nevertheless, there appear to be editors who spend most of their time manually making these links. This labour-intensive and overlinking to dates and years articles (just check their backlinks and you will see what I mean - there are well in excess of 20,000 articles linked to January 1 alone), and the paranoïa apparently associated with it drives me nuts. Ohconfucius (talk) 05:15, 5 March 2008 (UTC)[reply]
You're absolutely right. There should as well be a section on which layout is preferred. That'll be hard to decide, albeit there really isn't a standard preference, it'll have to be one or the other. Lord Sesshomaru (talk • edits) 05:34, 5 March 2008 (UTC)[reply]
What we should not be doing is what you did in your original post, Sesshomaru. Don't link February to the article on the month, link 14 (meant to be the day of the month) to article on the year AD 14 and 2008 to article on the year AD 2008. That's already covered in the MoS, isn't it?
Our standard "look and feel" is the results we get from dates properly formatted for user preferences. There is no preference from among those options, if that's what you are talking about. It is best to enter it the way it appears, but the missing or extra comma we are talking about there won't make much difference in the results, and in not in itself reason to edit an article.
Yes, the software will fix some of the problems even for users who are not logged in. I used to think, after the software started acting that way, that it no longer mattered if a linked-for-preferences date was linked as "[[January 15]], [[1961]" or "[[January 15]], [[1961]", but if I recall correctly, somebody pointed out some case in which it does make a difference. But maybe I just imagined that, I cannot tell you what it would be. Gene Nygaard (talk) 15:18, 5 March 2008 (UTC)[reply]
Not quite sure if you're upset or bothered by anything Gene. I was making a simple point about the comma in those samples. In any case, shall I update this page per discussion or are there any opposing? Seems to be legit. However, I'll refrain from mentioning how dates should appear, American vs international-wise, since that would require a separate section. Agreed by all parties? Lord Sesshomaru (talk • edits) 16:55, 5 March 2008 (UTC)[reply]
If I understand your point, and going by what you were edit-warring about, we most certainly should not be saying not to use commas on the edit page, in places where they would normally appear in what readers see on the article page. Why in the world are you even asking for that? Gene Nygaard (talk) 17:51, 5 March 2008 (UTC)[reply]
Edit warring? What in the world are you talking about? Lord Sesshomaru (talk • edits) 18:04, 5 March 2008 (UTC)[reply]
Okay, I take that back; not edit-warring. It was just a first impression, when you were complaining about someone's reversion of your edit removing commas from the Month DD, Year format. I don't think you have any cause for complaint; we should not be running around removing the commas. That's the point I'm trying to get across. Gene Nygaard (talk) 18:31, 5 March 2008 (UTC)[reply]
Compromise: how about having the guideline say something like, "commas for the [[February 14]] [[2008]] format do not need to be inserted since they are visible even without them in the edit."? Implying not to use commas no matter the circumstance is a tiny bit irrational, I guess. This makes sense? Lord Sesshomaru (talk • edits) 18:52, 5 March 2008 (UTC)[reply]
Okay. I'll do the compromised edit to the guideline tommorrow. Any additional comments? Lord Sesshomaru (talk • edits) 06:04, 8 March 2008 (UTC)[reply]

(deindent) Make sure to note that just because they are not needed is no reason to run around removing them from existing articles. Collectonian (talk) 21:13, 10 March 2008 (UTC)[reply]

I think I know why you're saying this. You don't want the commas removed in pages that you heavily edited, like List of Star Ocean EX episodes? Can I ask why? If someone has enough spare time on their hands, I don't see why they should not run around and get the job done. It's optional. Thoughts? Lord Sesshomaru (talk • edits) 21:28, 10 March 2008 (UTC)[reply]
I'd have thought the reason is obvious. Do you want to see your watchlist explode ?? ;-) TINYMARK 21:34, 10 March 2008 (UTC)[reply]
You're right, I don't. I see no point to it. I find it rather annoying, as it isn't needed or useful at all. If people have time on their hands, I'd rather them do something that actually improves the articles rather than just do such an extremely meaningless edit. It would be one thing if removing the commas actually fixes anything, but it doesn't. Even tag and go is more useful than stripping out the commas. Its about as pointless an edit as one can get. And, as TinyMark notes, it is another watchlist addition that gets to be doubly annoying when someone comes along, is editing, noticing there are none, and feels they need to fix it. I also find the code looks very ugly without the commas and I think it would be very confusing to anyone who doesn't understand that the commas are not needed (a good chunk of editors, I'd suspect). Maybe I'm an anal web developer, but I seriously abhor ugly code :P Collectonian (talk) 21:51, 10 March 2008 (UTC)[reply]
I don't really think the layman will assume that a comma is missing (that's what the preview button is for). But I see both of your points. What about the dates in pages that already have no commas? Are you two suggesting that the commas should be inserted because the layman will think they are missing and will "explode" one's watchlst? Lord Sesshomaru (talk • edits) 22:10, 10 March 2008 (UTC)[reply]
If any article is already without commas, then no need to insert either. So my basic position is, if they are there, leave them there, if they aren't, leave them out, though if a newbie editor comes alongs and adds them because they think they are missing, no need to yell either (though feel free to undo and explain). Its kind of like referencing, I guess. If a valid referencing style is already in heavy use (such as Harvard referencing), don't run through and completely redo to your preferred referencing style (maybe using templates). In the case of citation styles, Wikipedia:Citing sources includes language regarding that:
"Any style or system is acceptable on Wikipedia so long as articles are internally consistent. You should follow the style already established in an article, if it has one; where there is disagreement, the style or system used by the first editor to use one should be respected."
Perhaps something similar would work here? Collectonian (talk) 22:26, 10 March 2008 (UTC)[reply]

I guess that could work, but what about Death Note? Some dates there have a comma, others do not. And if someone comes along and removes the commas while doing other good faith edits, like I did here, one should not revert blindly or undo only the removal of the commas, as that seems to be a case of Wikipedia:Ownership. So can we integrate what I just said into the guideline as well? Lord Sesshomaru (talk • edits) 22:37, 10 March 2008 (UTC)[reply]

For Death Note, if we use the citation guideline, then whichever was used first should be kept and the rest changed to match. As for the Star Ocean issue, well, as has already been noted, removing wasn't necessary. The list was created with them (first editor to use), and that shouldn't have been changed. Your other good faith edit (only one other thing) was put back. Collectonian (talk) 01:09, 11 March 2008 (UTC)[reply]
So how should it be written in the guideline? I know what to include, but don't know how to phrase it. Any thoughts or suggestions? Lord Sesshomaru (talk • edits) 01:18, 11 March 2008 (UTC)[reply]
I think a slight modification of the quote from cite, retooled to dates, would be fine. So something like: "Commas are not required to be used in full format American dates. Their inclusion or exclusion is a stylistic and editorial preference. Either style is acceptable so long as articles are internally consistent. You should follow the method already established in an article, so that if the article has dates with commas, then the commas should be left alone and new dates added to the article should have commas. If the dates in the article do not have commas, then they should not be added to existing dates and new dates should not have them. Where there is disagreement or the article currently has a mix of commas and no commas, then the earliest format used should be respected and the article changed to be consistent with that format." Collectonian (talk) 20:02, 11 March 2008 (UTC)[reply]
Sounds great! I noted that the Death Note page first used commas, then some were removed. I shall correct this problem soon. Okay, go ahead and update the guideline, would you? Lord Sesshomaru (talk • edits) 20:08, 11 March 2008 (UTC)[reply]
The page is currently edit protected, so before I put in an editprotected request, does anyone else want to comment on this? Collectonian (talk) 04:04, 12 March 2008 (UTC)[reply]
Go for it. Seems we have concluded. Lord Sesshomaru (talk • edits) 20:09, 12 March 2008 (UTC)[reply]
Added. I wasn't completely sure where to put it, so I put it in the section on full date formatting. If someone feels it should be positioned differently, feel free to shift around.Collectonian (talk) 17:57, 13 March 2008 (UTC)[reply]

This has not been thought through. It is not necessary or even useful to have a different standard for articles that pertain to American topics. If I am editing a section of an article on a clearly British topic to correct a misspelled word, and then also see a mess like "happened on the 14<sup>th</sup> of Sept [[1777]]", I can simply change it to "happened on [[14 September]] [[1777]]". If I see this in a section of an article on a clearly American topic, I would, according to these new instructions. need to:

  • get out of edit mode on that section.
  • view or edit the entire article, examining it to see if there are any dates in either of 2 formats, [[July 4]], [[1776]] or [[July 4]] [[1776]].
  • if there are none, pick one format and use it for the mess I found.
  • if all other dates are in one of those 2 formats, use that format to fix the messy date.
  • if there are several dates in each format, spend half the afternoon digging through the revision history trying to find the revision that first introduced one of these 2 formats, and use that format to fix the other dates that were added since, and the messy date.

If this strikes anyone as an unrealistic burden to throw on the back of editors who are trying to clean up articles on American topics, I agree and sympathize with you completely. Before the manga edit skirmish began, we had 2 formats: [[July 4]], [[1776]] or [[4 July]] [[1776]], for west of the Atlantic and east of it. I feel that adding a 3rd format and encouraging its use (just because it is known that the software will fix it for general display) detracts from Wikipedia. I will remove that recommendation from the guideline. An agreement between two editors doesn't constitute much of a consensus. Chris the speller (talk) 18:19, 19 March 2008 (UTC)[reply]

No one is saying anything about adding a 3rd format. The article already says you can use [[July 4]], [[1776]] or [[July 4]] [[1776]]. The paragraph just clarifies that people shouldn't go around removing all the commas in an article because the comma isn't needed, nor should they be added in, rather as with sources, stick with the method already in use in the article. Collectonian (talk) 18:35, 19 March 2008 (UTC)[reply]
Your statement is completely incorrect. Nowhere does the guideline say that [[July 4]] [[1776]] is an acceptable format. Please remove that paragraph or allow me to remove it again. Chris the speller (talk) 20:40, 19 March 2008 (UTC)[reply]
It is shown in the table lower in the page. Personally, I agree, but as other editors have used this guideline to say commas are not required and have removed them (and not just the case noted here), something should be added to clarify. The paragraph is an attempt to do so. Do you have another suggestion for a better way to deal with it? Collectonian (talk) 20:46, 19 March 2008 (UTC)[reply]
I think you will see that I am on your side if you read the discussion "Commas in linked dates" in Archive 94 of this talk page. Back then I was afraid that including "[[May 15]] [[2005]]" in the table would lead to some editors to think that it was an acceptable format, but there was an insistence on leaving it in to provide a complete list of formats that the autoformatting software could or could not handle. You have shown that my fears were justified. The omission of the comma has come up several times, but a consensus to allow dropping it has never been achieved. My last comment in that discussion clearly shows that I opposed editing just to remove a comma from the British-style dates, so I wholeheartedly oppose removing them from American-style dates. The removal of commas from the manga article was not only a waste of time for that editor and a waste of Wikipedia resources, but turned into a further burden on those taking part in discussions here. I kept getting beat up about that table and the green check marks and red X's. If you want to support adding a couple of red X's to that table instead of the 2 wimpy asterisks, maybe we can get this cleared up. Chris the speller (talk) 21:55, 19 March 2008 (UTC)[reply]
That might be a good idea, and I could see it being cleaner than the paragraph addition. I'd support making it clearer for sure. Collectonian (talk) 22:22, 19 March 2008 (UTC)[reply]
What do you think of the green checks and red X's that were in the table here? Never mind that the legend below it is inaccurate in this version. Would something like this work to show what formats are acceptable? Chris the speller (talk) 01:20, 20 March 2008 (UTC)[reply]
I think that would work. It makes it clearer what formats are acceptable and much easier to quick read. Collectonian (talk) 01:23, 20 March 2008 (UTC)[reply]

Whose turf?

People are making changes in MOSNUM issues at the main MoS page, changing the wording there with respect to spelling out of numbers (which numbers are spelled out, adding "end of a sentence" stuff, etc.), then coming here and claiming in their edit summaries that this is an issue which needs to be discussed THERE, rather than HERE where it belongs. Lets make that clear at Wikipedia talk:Manual of Style#Lack of jurisdiction, and move the discussion here where it belongs. It is nonsense like that which leads to the inconsistencies in various MoS pages which some editors like to complain about. Gene Nygaard (talk) 16:23, 6 March 2008 (UTC)[reply]

Note in particular that they have conducted that discussion there, relative to this quintessential "numbers style" issue, at that different forum, without even having the decency to post a notice here—the appropriate forum for the discussion in the first place—that that discussion was taking place. Then they hae changed the guidelines not only on that WP:MOS page, but on this WP:MOSNUM page as well, without ever having discussed it here. Gene Nygaard (talk) 16:59, 6 March 2008 (UTC)[reply]
Calm down, please. I'm sure it was an oversight, rather than a deliberate slight. People will ask questions about it there, because the content is on the main MOS page, and people will answer there, and discussions will crop up there. The oversight is failing to either move it here or notify here, and there's no need for it to end up a big row, which your tone feels like it's heading towards. SamBC(talk) 17:46, 6 March 2008 (UTC)[reply]
Yes the subject needs to be talked about here before changes are made to the page. Fnagaton 12:21, 7 March 2008 (UTC)[reply]
The changes that have been objected to now were reversions of a previous undiscussed change. We need to discuss reversions of undiscussed changes now? It happens that it was discussed, somewhere else, but there was no forward motion in the change that was made and objected to, merely a reversion. SamBC(talk) 12:53, 7 March 2008 (UTC)[reply]
I reverted the change that has the edit summary starting with "Revert; see WT:MOS; it doesn't need to be discussed at WT:MOSNUM...". It makes the assumption that changes don't need to be discussed here when actually they do. Fnagaton 13:06, 7 March 2008 (UTC)[reply]
Furthermore, it the edits by User:Centrx which were reverted here were themselves a reversion of an earlier undiscussed change of the longstanding "ten" to "nine" by User:Tony1. Gene Nygaard (talk) 17:50, 7 March 2008 (UTC)[reply]

Talk of "jurisdiction" is off-topic wikilawyering; content is at both places, discussion was there, consensus was there, broader readership and input is there. SandyGeorgia (Talk) 12:39, 14 March 2008 (UTC)[reply]

Misleading and difficult to parse advice about dates

The guidance says:

  • Full dates, and days and months, are normally autoformatted by inserting double square-brackets, as for linking.

I find that to be misleading and difficult to parse. It can be interpreted as requiring square brackets around solitary days and solitary months. People often quote the MOS as requiring links to solitary years (a user has just now made this claim on my talk page). It takes effort to explain that the MOS does not require that. I think that the phrase above needs changing. It also need supplementing by a specific statement that it does not require links to fragments such as centuries, years, months, days etc. Lightmouse (talk) 09:35, 7 March 2008 (UTC)[reply]

The present phrasing is indeed deplorable; but in rephrasing, we do need to say more than "no fragments". We do autoformat 2 April; whether this is a good idea is another question, which should be decided by another appeal to the developers, not here (because this page can't solve it). Septentrionalis PMAnderson 16:16, 8 March 2008 (UTC)[reply]
I agree with both your sentences. With regard to your first sentence, you are right, we need strong simple sentences that mention specific fragments. We could build on the negative sections that are already there. Would anyone like to propose wording?
In addition, we probably need a full time bot to tackle these fragments that sometimes are merely annoying and sometimes actually break autoformatting. Lightmouse (talk) 21:38, 11 March 2008 (UTC)[reply]
Does anybody have any suggested wording? Lightmouse (talk) 09:29, 13 March 2008 (UTC)[reply]
I have fixed some of the grammar of this new entry. I do think you should have put up a draft here first. This way, we can avoid points of view seeping into the text. Woody (talk) 13:52, 13 March 2008 (UTC)[reply]
In the absence of objections, I have eliminated the misleading and difficult to parse text. Explanations of the nuances does not appear to be effective, even many experienced editors make errors because nobody checks all date links in all preference modes. I have attempted to make it simple and shorter so that confused users can be directed to a directly worded appropriate bullet point about what is not required. Lightmouse (talk) 13:55, 13 March 2008 (UTC)[reply]
I know what you have tried to do, I simply thought that you should have brought the text here for discussion before implementing it. There were no objections to the principle of rewording the text; but the text itself had not been discussed. Other editors should have seen the text first. As it is, it needs the fixes in situ. Woody (talk) 14:04, 13 March 2008 (UTC)[reply]
I take your point, it is well made. Sorry about that. Lightmouse (talk) 14:11, 13 March 2008 (UTC)[reply]

the terabyte has become a unit of bandwidth

It seems that the terabyte is now a unit of bandwidth. Comments on the talk page are invited. Thunderbird2 (talk) 09:41, 7 March 2008 (UTC)[reply]

Uncertainty vs. repeating decimal

I have just edited the Conversion of units article because it used parentheses to indicate a repeating decimal. For example, it used "3.3(3) × 10−4 m" to mean that the rightmost 3 repeats forever. I changed it to read "3.3 ×10−4 m" because this notation is also used for repeating decimals, and it will not be confused with uncertainty.

An example of an expression of uncertainty is in Seidelmann's Explanatory Supplement to the Astronomical Almanac (1992, p. 693) where the Newtonian constant of gravitation is given as 6.67259 (85) ×10−11 m3kg-1s-2. A longer expression for the same thing would be 6.67259 ×10−11 ±0.00085 ×10−11 m3kg-1s-m3kg-1s-2.

I believe this guildeline should have a section added to specify that repeating decimals are expressed with overbars, not parentheses, to avoid confusion with an expresion of uncertainty. I also believe that it should have a section recommending that uncertainty should be expressed with ± notation rather than parentheses because people unfamiliar with this notation would not know the order of magnitude of the uncertainty. That is, in the previous example, it isn't obvious whether the uncertainty is ±0.00085 ×10−11, ±0.000085 ×10−11, or ±0.0000085 ×10−11. --Gerry Ashton (talk) 19:22, 8 March 2008 (UTC)[reply]

Good point. This looks like sensible advice to me. Thunderbird2 (talk) 19:32, 8 March 2008 (UTC)[reply]
±8.5 ×10−15 may be easier to read, as long as we're recommending; but the deprecations should include a caveat: 3.3(3) × 10−4 m would be fine, if it were clear what was meant. Septentrionalis PMAnderson 21:40, 8 March 2008 (UTC)[reply]
BIPM advocates use of parentheses in this way. And that would be fine if it were clear to everyone, but that's a big if isn't it? Thunderbird2 (talk) 21:50, 8 March 2008 (UTC)[reply]
  • Note above that the plus-or-minus sign requires a space, and en dashes or minus signs are required, not hyphens. Tony (talk) 00:51, 9 March 2008 (UTC)[reply]
    • Disputed, as invisible nonsense. Septentrionalis PMAnderson 16:19, 10 March 2008 (UTC)[reply]
      • Is it the span tag to create the overbar that you dispute? If so, do you have a solution to the ambiguity? --Gerry Ashton (talk) 19:36, 10 March 2008 (UTC)[reply]
        • No, I dispute the mandatory space around ± (we should do what is clearest in the circumstances), and the mandatory use of a endash instead of a hyphen in an exponent, where the difference is invisible to the reader. Septentrionalis PMAnderson 22:47, 10 March 2008 (UTC)[reply]
        • The substantive question of ambiguity should be dealt with by suggesting explanatory phrases at first use of any of these notations. Any of them will be clear to some readers and unknown to others. Septentrionalis PMAnderson 22:49, 10 March 2008 (UTC)[reply]
          • I still feel we should recommend different typography for uncertainty vs. repeating decimals, but I think PMAnderson's suggestion to use explanatory phrases near the first use is wise. Since this is a matter of typography, it would be particularly difficult for readers who don't understand the convention to think of keywords to search for in their favorite search engine. --Gerry Ashton (talk) 23:23, 10 March 2008 (UTC)[reply]

The problem with overlines for repeating digits is that there are at least two variants and both have their issues.

  1. Inline CSS: 0.1<span style="text-decoration:overline">37</span> – 0.137
  2. Unicode: 0.13̅7̅ = 0.13&#x305;7&#x305; (U+0305) or 0.13̄7̄ = 0.13&#x304;7&#x304; (U+0304) – 0.13̅7̅ or 0.13̄7̄

— Christoph Päper 20:30, 13 March 2008 (UTC)[reply]

The span approach displays properly on Windows XP, both Internet Explorer 7 and Firefox. The unicode approach does not display properly in either case; it displays as a square after the 3 and the 7. --Gerry Ashton (talk) 02:35, 14 March 2008 (UTC)[reply]
Yes, the problem with the Unicode approach is its state of support, but the CSS approach is more fundamentally flawed in that the style, which conveys the information, is lost in plain-text environments, such as copy and paste, text or non-CSS browsers, search engines. Using a different HTML element that, unlike span, has a default styling only helps in few of these cases. Years ago I used a non-combining overline (or macron) in front of the first digit to repeat: 0.1¯37 – 0.1¯37. It doesn’t look as good, but is very safe. One could also imagine using brackets or braces instead of parentheses: 0.1[37] or 0.1{37}, but I think this would be a WP-specific convention, which we try to avoid. — Christoph Päper 09:09, 14 March 2008 (UTC)[reply]

large ranges of numbers

I'm not sure how to format a range of large rounded numbers. An article I saw expressed the figure of 'twenty to thirty thousand' as "20-30 000" Since commas and not spaces are supposed to be used in large numbers, I changed it to "20-30,000". However, to me it still doesn't look right. Can anyone confirm this is probably the best way, or suggest an alternative?? Thanks a lot, Chebyshev (talk) 03:51, 12 March 2008 (UTC)[reply]

When this is discussed in style guides, the normal decision is that you should not abbreviate the first number. If your intention is 20 000 to 30 000, have exactly that, or 20 000 – 30 000 with a spaced en dash (which unfortuantely might look like a minus sign!). Spacing is a separate matter, much discussed recently. If you do not use spaces between the digits of a number, you should use an unspaced en dash: 20,000–30,000. This is all sound advice generally, but others here may have different advice more finely attuned to Wikipedia.
Note that even in words the meaning has to be clearly presented. If your meaning is 20,000–30,000, in some contexts your words (spoken or written!) may need to be twenty thousand to thirty thousand, without any shortening. One such context:

The ion-emission drive enabled the craft to accelerate from twenty thousand to thirty thousand miles per hour in one week.

Without the first thousand, the meaning would be ambiguous. Both interpretations would be realistic. To disambiguate the other way, you might even need to have this:

The ion-emission drive enabled the craft to accelerate from twenty miles per hour to thirty thousand miles per hour in one week.

No wonder we invented figures, and abbreviations. :)
–⊥¡ɐɔıʇǝoNoetica!T– 05:36, 12 March 2008 (UTC)[reply]
Thanks a lot for your help Chebyshev (talk) 11:11, 17 March 2008 (UTC)[reply]

Non-breaking spaces

In the current version of this MOS page there is a section called "Non-breaking spaces" that talks a little about how to handle line wrapping. We now have a detailed technical how-to guide about line wrap handling at Wikipedia:Line break handling.

I would like that the section "Non-breaking spaces" of this MOS page in some way link to Wikipedia:Line break handling. Perhaps as a "see also" link at the top of that section?

--David Göthberg (talk) 22:36, 12 March 2008 (UTC)[reply]

Since no one protested I boldly went ahead and added "See also: Wikipedia:Line break handling and Wikipedia:Manual of Style#Non-breaking spaces" to the top of the "Non-breaking spaces" section.
--David Göthberg (talk) 15:35, 13 March 2008 (UTC)[reply]

Why was this raised on this page rather than at WP:MOS, which gets broader attention? SandyGeorgia (Talk) 12:36, 14 March 2008 (UTC)[reply]

SandyGeorgia: Oh, I see you misunderstood what I was asking. With "this MOS page" I meant "this Manual of Style page", that is Wikipedia:Manual of Style (dates and numbers) = "MOSNUM". I see that my way of writing it wasn't very clear, sorry. I wanted to add those links to THIS page.
But anyway, WP:MOS also has such a section so I asked the exact same thing there. So I did raise the question on both affected pages. :))
--David Göthberg (talk) 16:24, 14 March 2008 (UTC)[reply]

Remove edit blocking please

The page has been blocked from editing since 6 March.

  • Edit blocking of pages should only be used if there are many editors doing bad things. If there are only a few editors doing bad things, then the target should be those editors, not the page.
  • Edit blocking should only remain in place if the bad things would still happen without it.

I do not see any justification for the edit block today. Please remove it. Lightmouse (talk) 09:27, 13 March 2008 (UTC)[reply]

That's a good suggestion, Lightmouse. Unfortunately, when the protection was applied it locked in an edit that made a guideline inconsistent with the corresponding guideline at WP:MOS. The protection explicitly does not aim to endorse or entrench that edit. Since the content of the edit was undiscussed and non-consensual, and contradicts WP:MOS, reverting it would be a Good Thing. Don't be surprised if such a Good Thing happens, at the first opportunity.
–⊥¡ɐɔıʇǝoNoetica!T– 09:58, 13 March 2008 (UTC)[reply]
That would not surprise me at all. What surprises me is the edit block. Lightmouse (talk) 10:27, 13 March 2008 (UTC)[reply]
Yes, I'm sure it raised more than a few eyebrows. We'll see. Let's just continue to act in good faith, with respect for discussion and consultation towards consensus.
–⊥¡ɐɔıʇǝoNoetica!T– 10:40, 13 March 2008 (UTC)[reply]
I agree with these calls for the block to be removed. It might have been appropriate for a few days to allow things to cool down, but it's unacceptable for a longer period. We need to agree here on a strategy to avoid the revert-wars. This need should not stand in the way of an immediate unblocking: the issues should probably go to arbitration while other ongoing issues are dealt with in MOSNUM. Tony (talk) 12:22, 13 March 2008 (UTC)[reply]
Even though I see no resolution in sight, I do think that we can all be civil here. Do not keep on reverting, discuss it here or WT:MOS, otherwise I won't hesitate to protect this again. Woody (talk) 12:31, 13 March 2008 (UTC)[reply]
Thanks Woody. In fact, the issue has been discussed extensively at WT:MOS recently. Any proposal for change to the version that had been in place for several months should indeed be raised there, or here if the proposer prefers.
–⊥¡ɐɔıʇǝoNoetica!T– 10:08, 14 March 2008 (UTC)[reply]

Ga, Ma, ka preferred to bya, mya, tya

Wikipedia talk:Manual of Style (dates and numbers)/Archive 78 danced around the question, but never quite addressed the question of whether to discourage use of mya, focussing instead on discouraging MYA. Everyone seemed to prefer ka, Ma, Ga although there was some confusion over capitalization (SI usage for multipliers is quite unambiguous: k for kilo, M for mega, G for giga, T for tera, but it seems this wasn't universally grasped). Once archived, the discussion ended without addressing it. As phrased now, it leaves the impression that mya is an equally desirable choice to Ma, yet I don't believe that was the intention of those discussing the question. Reopen? LeadSongDog (talk) 07:40, 14 March 2008 (UTC)[reply]

I prefer to spell it out in full as "million years ago" wherever it occurs in the article, and use Ma where abbreviation is necessary (e.g. in taxobox fossil ranges). I feel this looks smarter and saves people translating it in their heads each time they see it. I agree that mya is obsolete though. That said, I've not got a very firm opinion yet... Verisimilus T 08:36, 14 March 2008 (UTC)[reply]
My feeling from working with a number of geophysicists is that Ma is preferable, and I'm quite willing to agree to a prescription here that it should be preferred. I can't agree with Verisimilus that the whole three-word phrase should be trotted out many times in an article, unless used only twice or three times, perhaps: tedious to read. Besides, the fact of the abbreviation itself helps to focus the readers' minds. Tony (talk) 08:47, 14 March 2008 (UTC)[reply]

The present text reads

I would suggest a change to read

Would something like this work for us? LeadSongDog (talk) 17:37, 14 March 2008 (UTC)[reply]

Is it really necessary to wikilink each term if you've explained what it means? I find excessive links distracting. What more could a user want to know about "mya" than what it means? Verisimilus T 18:18, 14 March 2008 (UTC)[reply]
Fair enough. I had them each wikilinked to annum anyhow, the one time should be enough.LeadSongDog (talk) 19:53, 14 March 2008 (UTC)[reply]

Now we have

Absent further comment, I'll make the above change in a day or two.LeadSongDog (talk) 18:10, 17 March 2008 (UTC)[reply]

emend: strike "and wikilinked"; RC only gd 4 ¬50000a. --Verisimilus T 19:56, 17 March 2008 (UTC)(no kb!)[reply]
How on earth did I miss that??? Good catch!LeadSongDog (talk) 21:56, 17 March 2008 (UTC)[reply]

checkY Done. LeadSongDog (talk) 18:00, 18 March 2008 (UTC)[reply]

{{delimitnum}} template

Note that if this section becomes structurally complex, with many different sub-discussions and threads, I will, where necessary to avoid confusion, take the liberty of rearranging things here after-the-fact (after people have responded). However, I will do so in ways that makes it clear who was responding to what. I think this will be necessary to keep this topic organized and understandable.

I thought everyone would be interested to know that another of our regular editors, Zocky visited Kilogram and saw all my cumbersome code (like 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg), which was all just for generating numbers like


So he created a template, {{delimitnum}}, and now all editors need to code is {{delimitnum|6.02246479|30|23|kg}} to accomplish the exact same thing. This is the issue many of us discussed here at Archive #94 of Talk:MOSNUM. In a nutshell though, this template parses as follows:

{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}

The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are much easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.

The Natural logarithm article (first paragraph) and Kilogram (throughout, with 2 kB of savings) have both been updated with this template.

What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a template and really required a parser function (magic word). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox here on my talk page to assist him in his effort.

As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).

My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:

Per current MOSNUM policy, numeric values must have the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a full stop (.), e.g. 1,234.567. Further now, the use of the {{delimitnum}} template/parser function (magic word) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the significand (the digits to the right of the decimal marker). The use of {{delimitnum}} delimits values like 6.022461342 so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as Excel-pasteable numeric values.

In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or non-breaking spaces (e.g. coding 0.187&nbsp;985&nbsp;755 or 0.187 985 755 to produce 0.187 985 755) because such text strings can break at line-end word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.

Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.


The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: 0.187 985 755 2), would formally be considered as “incorrect” and should be irreversibly upgraded.

Greg L (my talk) 22:42, 14 March 2008 (UTC)[reply]

I tried this out in the sandbox and the first attempt failed:
  • {{delimitnum|1234567.7654321| |12}}
  • with template functioning: Template:Delimitnum
  • renders to me in IE7 like 1,234,567.765 4321 096 × 1012 (with spurious 096 inserted)
−Woodstone (talk) 22:47, 14 March 2008 (UTC)[reply]
There's a limit to significant digits and precision in WPs math magic words. The example in the documentation works with 13 digits, but too many digits will break the template:
Woodstone's example has 14 digits. A different issue:
Gimmetrow 23:00, 14 March 2008 (UTC)[reply]
  • Indeed. The template sometimes has problems beyond twelve digits—particularly if lots of them are in the integer portion of the signficand, which will be a rare occurance indeed. Still, it is a potential problem and certainly is a legitimate issue to discuss. This was a known inadequacy of the template-based method that was foreseen. Note however, that maybe 95% of the time, values will be a single digit in the integer portion and most of the digits will be in the fractinoal side. It could be that this might be enough of a problem that it can’t be considered as “ready for prime time.” However the Kilogram is likely very representative of the kind of article that will be using this and has encountered no difficulties. Greg L (my talk) 23:21, 14 March 2008 (UTC)[reply]
There is still a problem with a single digit in the integer portion: {{delimitnum|1.01}} = Template:Delimitnum, {{delimitnum|1.001}}: Template:Delimitnum. This can be fixed, though, as it's not a fundamental limitation (like 13-14 digits). Gimmetrow 23:38, 14 March 2008 (UTC)[reply]
  • I can see that the template may be too buggy. I noticed that while in preview mode while making my edits, all my examples were working fine but no longer worked after I saved the page. I believe what was occurring is that previous wonked-out examples (for instance, Woodstone’s examples weren’t parsed as he intended), and your 14-digit values left the template on the fritz. I can’t defend this behavior. As you can see from Kilogram, it worked great there. I don’t know whether to pull this proposal. Please see this sandbox, which really exersized the template (I think). Greg L (my talk) 23:27, 14 March 2008 (UTC)[reply]
  • Clearly, given that there are still some problems with some values, I’m withdrawing my proposal that the template be formally made available for general use. Zocky and I both worked hard to proof-check the template and thought it had been thorougly wrung out. I can now see it wasn’t. I’ll continue to use it in Kilogram as it works damn nicely there. However, I am rather expert in its use and pay particularly close attention to the numbers when I use the template. It clearly can't be put into the hands of general users until it can reliabily work with ≤12 digits. I know Zocky has put so much work in this too.
Show below is what it does do rather well now (at least in "Show preview" mode. I’ll see how they look when I click “Save page” here…

NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <code> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES” (adviso added later by Greg L (my talk) 21:22, 15 March 2008 (UTC))[reply]

{{delimitnum|12345.6789012}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|Hz}} → Template:Delimitnum
{{delimitnum|6.02214179|30|23|kg}} → Template:Delimitnum
{{delimitnum|1579800.298728}} → Template:Delimitnum
{{delimitnum|1.356392733||50|Hz}} → Template:Delimitnum
{{delimitnum|0.45359237|||kg}} → Template:Delimitnum
{{delimitnum|6.022461}} → Template:Delimitnum
{{delimitnum|6.0224613}} → Template:Delimitnum
{{delimitnum|6.02246134}} → Template:Delimitnum
{{delimitnum|6.022461342345}} → Template:Delimitnum
{{delimitnum|1579800.298728|||}} → Template:Delimitnum
{{frac|{{delimitnum|1.602176487||–19|}}}} → 1⁄Template:Delimitnum

Greg L (my talk) 23:51, 14 March 2008 (UTC)[reply]

Zocky, Here’s additional examples, most of which doesn’t work:

{{delimitnum|1.01}} → Template:Delimitnum (I note that no one would use this template to delimit a number that doesn’t need delimiting)
{{delimitnum|1.00001}} → Template:Delimitnum
{{delimitnum|1.10001}} → Template:Delimitnum
{{delimitnum|1.11001}} → Template:Delimitnum
{{delimitnum|1.11201}} → Template:Delimitnum
{{delimitnum|1.11231}} → Template:Delimitnum
{{delimitnum|1.11232}} → Template:Delimitnum (this one doesn’t end with a 1 and works)
{{delimitnum|0.29872801}} → Template:Delimitnum
{{delimitnum|0.29872821}} → Template:Delimitnum (this one doesn’t end with an 01 and does work)

Greg L (my talk) 00:03, 15 March 2008 (UTC)[reply]

OK, I thought just showing the problem with 1.01 would be enough illustration, but apparently not given the above examples. The problem can manifest itself in various ways with any group of three starting with a 0. It doesn't just happen with numbers ending in '1', and it's not just a symptom of numbers too short to delimit. Gimmetrow 01:41, 15 March 2008 (UTC)[reply]
{{delimitnum|1.0001}}: Template:Delimitnum
{{delimitnum|1.00001}}: Template:Delimitnum
{{delimitnum|1.00101}}: Template:Delimitnum
{{delimitnum|1.00102}}: Template:Delimitnum
{{delimitnum|1.000001}}: Template:Delimitnum
{{delimitnum|1.000002}}: Template:Delimitnum
  • I understood that Gimmetrow. I appreciate that you’re in this with us trying to figure out its current limitations. Thanks. In my last example above, I made a it a point to show that a number that finally didn’t end with 01 would work. Clearly, it has a problem with anything ending in an 01. But the bugs don’t end there. I just added a over 200 new progressions to my test sandbox in a special section titled Progressions of features and digits. Please check it out. You can see where it’s having problems and maybe that will guide you in other directions. As you will see there, I tried all 100 progressions that end with two-digit groupings from 00–99. I also added 100 progressions with three-digit groupings from 000–099. It shows that numbers ending with two-digit groupings like 25 or three-digit groupings like 026 can be a problem. The patterns are unobvious. Maybe someone who really understands templates can discern a pattern. Greg L (my talk) 02:47, 15 March 2008 (UTC)[reply]
  • One problem (the spurious 09x) is roundoff error in the math used to separate the digits. The other problems appear to be: two digit groups with "0" (07) are evaluated as 7 rather than 70 (so treated as a single digit), and a first group of 000 loses the decimal point. Gimmetrow 02:59, 15 March 2008 (UTC)[reply]
  • Thanks Gimmetrow. Hopefully all this will assist Zocky. That is, if he isn’t sick to death of this exceedingly complex template. Are you out there Zocky?

    *crickets chirping*

    Let me know if I can be of further assistance. Greg L (my talk) 04:17, 15 March 2008 (UTC)[reply]

I'm not very proficient with template magic, but may I suggest to do it character based instead of math based? That would avoid problems with number of digits and 01 being seen as 1, or groups of 000 being overlooked. It would place restrictions on the input, such as forbidden commas or spaces, but that would not be a problem in my view. −Woodstone (talk) 13:35, 15 March 2008 (UTC)[reply]
Unfortunately, we can't make it character-based with a template, because we don't have the appropriate parser functions. I made a general template for this kind of spacing, {{spaced}}, which can be used to space anything:
. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.
As for the bugs, the missing . is easy to fix, so I'll go and do that now. I'll also look into the other reported bug and get back to you. Zocky | picture popups 14:42, 15 March 2008 (UTC)[reply]
I've fixed two more bugs - the missing leading 0 in 1.01, and the 099 additions that were caused by rounding errors in the parser functions. Any more problems? Zocky | picture popups 15:47, 15 March 2008 (UTC)[reply]
Starting to look good. My 14 digit example above works as well now. To even improve more on size of numbers, would it be an alternative to split the integer and mantissa part into separate arguments? So the template would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. −Woodstone (talk) 17:22, 15 March 2008 (UTC)[reply]
(unindented)
  • All: I created an all new section of Delimitnum sandbox with all 3960 possible variations of two, three, and four-digit groupings. I was really tempted to just declare that this is good to go but knew we would have been making the judgment based largely on what we see in the sandbox. I knew better than that and added all possible combinations I can think of which might cause rounding errors. I’m glad I did too because two-digit groups following 5 thru 9 still suffer from rounding errors (with trailing “9”s). Three and four-digit groups are all good though! To see what I’m talking about, go to the two-digit groupings section (click the underlined “two” link, above), and search on the value 0.12501. Greg L (my talk) 20:10, 15 March 2008 (UTC)[reply]

  • That was fast. All those have apparently been fixed. Please now search here for all occurrences of these (in both maroon input values and the black output values):

    0.125019
    0.125069
    0.125101
    0.125241
    and
    0.125569
    0.125597
    0.125601–0.125603
    0.125629–0.125631
    0.125735–0.125741

    Greg L (my talk) 21:52, 15 March 2008 (UTC)[reply]

Section start

Template:Delimitnum

Section end

the above result comes out of {{delimitnum|100000.000001}}
showing to me as 1.0E+5.000001

I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. −Woodstone (talk) 21:56, 15 March 2008 (UTC)[reply]

  • It seems to randomly display as 100,000.000 half the time and as 1.0E+5.000 the other half for me (on Safari). Greg L (my talk) 05:25, 16 March 2008 (UTC)[reply]
  • I created an Excel spreadsheet to help me identify breaks in the progression. Here is a more concise list:

    0.125013
    0.125021
    0.125041
    0.125048
    0.125069
    0.125075
    0.125097
    0.125101–0.125104
    0.125124
    0.125131
    0.125153
    0.125186
    0.125208
    0.125214
    0.125236
    0.125241
    0.125263–0.125271
    0.125291
    0.125298
    0.125319
    0.125325
    0.125346
    0.125353
    0.125375–0.125381
    0.125402–0.125408
    0.125431–0.125436
    0.125457
    0.125485
    0.125492
    0.125513
    0.125520
    0.125541–0.125547
    0.125568
    0.125575
    0.125596–0.125603
    0.125624–0.125631

    The list goes on but if this all gets fixed, I suspect everything after this will too. Greg L (my talk) 22:56, 15 March 2008 (UTC)[reply]

  • For convenience, I’ve here provided a triple-view of some of the above. They parse as follows:

    input → live template return / (at time of this posting)

    0.125402 → Template:Delimitnum / (0.125 402)

✓ The following are all supposed to end with three-digit groups
0.125403 → Template:Delimitnum / (0.125 402)
0.125404 → Template:Delimitnum / (0.125 403)
0.125405 → Template:Delimitnum / (0.125 404)
0.125406 → Template:Delimitnum / (0.125 405)
0.125407 → Template:Delimitnum / (0.125 407) ✓
0.125408 → Template:Delimitnum / (0.125 407)
0.125431 → Template:Delimitnum / (0.125 43)
0.125432 → Template:Delimitnum / (0.125 431)
0.125433 → Template:Delimitnum / (0.125 433) ✓
0.125434 → Template:Delimitnum / (0.125 433)
0.125435 → Template:Delimitnum / (0.125 434)
0.125436 → Template:Delimitnum / (0.125 436) ✓
0.1235436 → Template:Delimitnum / (0.123 543 599) This one is supposed to end with the four-digit group “5436”
0.29872821 → Template:Delimitnum / (0.298 728 209) This one is supposed to end with the two-digit group “21”

Most of this data was discovered at Delimitnum sandbox in the newly added section with 3960 possible variations, which displays all possible variations of numbers ending in two, three, and four-digit groupings.

Greg L (my talk) 00:34, 16 March 2008 (UTC) Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). Tony (talk) 02:08, 16 March 2008 (UTC)[reply]

Thanks Tony. I’m not trying to be difficult, but what plus sign? Greg L (my talk) 03:01, 16 March 2008 (UTC)[reply]
My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. With an example of use {{formatnum|1000|.0001}} (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. −Woodstone (talk) 09:14, 17 March 2008 (UTC)[reply]
  • Woodstone, I tend to agree with you; it doesn’t look very promising that anyone—even Zocky—can overcome the fundamental limitations of templates. Perhaps in the future, templates will have access to character-based parser functions. Unless Zocky pulls a rabbit out of the hat on this one, it seems the template-based version of {{delimitnum}} won’t be something that can be put into the hands of the general editing community. However, it will only be a short time before one of our behind-the-scenes developers delivers a parser function-based magic word by the same name. As it will use character-based (not math-based) delimiting, it is a much simpler process. I heard yesterday from the developer that the magic word is done but he isn’t happy with the look of the code. “Programmers,” you see; they like tight code.

    In response to your above statement: “Also, as remarked by above by [sic] Tony, a leading explicit "+" sign should be maintained”, I assume you mean a default + sign should precede positive base-ten exponents (e.g. ×10+9). I’m sure there are different ways to format scientific notation. However, the way it has been implemented here is a very common and exceedingly professional way to do it; both the NIST and BIPM, for instance, format scientific notation the exact same way (see NIST:Fundamental Physical Constants and SI Brochure, Section 3.1). As you can see, both default to omitting the utterly unnecessary + sign in front of positive base-ten exponents. This reality is acknowledged in Wikipedia’s own Scientific notation and SI Prefixes articles as well as the {{SI multiples}} and {{e}} templates. Coding {{e|9}}} and {{subst:e|9}} omits the preceding + sign and returns ×109. I note however, that the {{e}} template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as SI Brochure: 5.3.5 for examples of proper formating in this regard). This oversight was addressed with {{delimitnum}}, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.

    Don’t despair though, if a user really has a “thing” for the unnecessary + sign and doesn’t care if he or she is flouting the BIPM and NIST, they can always code {{delimitnum|1.567892||+9|kg}} to obtain Template:Delimitnum, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including Template:Delimitnum. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Wikipedia articles on advanced mathematical concepts where the distinction must be emphasized for some reason.

    Note that every single aspect of this template was debated for a long time by many users—including Tony—here at Archive #94 of Talk:MOSNUM and everyone was quite pleased with the proposal. It seems to me that that was the time for appearance issues like adding a + in front of positive exponents to be raised so all the others could weigh in on the subject. Does it strike either you or Tony that now is the time to try to change things after all that discussion has transpired (and after a near-unanimous consensus has already been achieved)? There were one or two things I might have changed after-the-fact on this template myself but I was disinclined to even head down that path since I am entrusted with shepherding the group’s consensus decision through to completion in good faith. Greg L (my talk) 17:10, 17 March 2008 (UTC)[reply]
Actually I was referring to an explicit "+" for the whole number. Entering {{delimitnum|+123}} results in "123" without "+" sign. But I now realise the problem can be circumvented by entering +{{delimitnum|123}}. This trick should be added to the description of the template (whenever it comes to releasing it). −Woodstone (talk) 10:49, 18 March 2008 (UTC)[reply]

Sandbox moved

All: I moved the proof-checking sandbox to User:Greg L/Delimitnum sandbox. Greg L (my talk) 23:06, 17 March 2008 (UTC)[reply]

Deadly failure

I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:

  • {{delimitnum|1.1200|25}}
  • which should lead to 1.1200(25),
  • but with current methods would come out like 1.12(25) (my hard coding)
  • or from the current template as Template:Delimitnum (for me now mysteriously looking like 1.012(25))

The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.
−Woodstone (talk) 09:27, 19 March 2008 (UTC)[reply]

Trials and disambiguations

Opinions are invited on how best to disambiguate the megabyte at DEC 3000 AXP. I would like to avoid an unnecessary strand, so please reply directly on the talk page and not here. Thanks. Thunderbird2 (talk) 17:31, 16 March 2008 (UTC)[reply]

proposed change to wording of "Binary prefix"

The text reads

  • There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be certain whether "100 GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256 KB (256×210 bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also acceptable for disambiguation (256 KiB). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

The way I read it there was never an intention to imply one form of disambiguation was preferred over the other, but it can be interpreted that way. To make this clear I propose changing the words "Use of IEC prefixes is also acceptable for disambiguation (256 KiB)" to "Use of IEC prefixes is equally acceptable for disambiguation (256 KiB)". Thunderbird2 (talk) 07:35, 18 March 2008 (UTC)[reply]

I disagree. The intention of the discussions when the guideline was updated was to specifically state there is no consensus to use IEC prefixes and that is what it says. There isn't any confusion because it does mention "disambiguation". Actually I think IEC prefixes should not be supported at all in MOSNUM and the bit which says "Use of IEC prefixes is also acceptable for disambiguation" should be removed because it is pushing a failed standard and because stating the exact number of bytes is perfectly good for disambiguation or footnotes without needing extra options. Fnagaton 09:54, 18 March 2008 (UTC)[reply]
I second Fnagton. Wikipedia should reflect real world usage, not try to enforce a failed push for change of standards. Likewise, the current wording was specifically crafted to allow for people who want to use IEC notation in newer articles to do so, while protecting articles whose notation is not IEC. It was IEC notation that was given undue weight in the recent past, which is what lead to the current wording - which was done by consensus I might add. --Marty Goldberg (talk) 15:25, 18 March 2008 (UTC)[reply]
Yes there was consensus for the present wording, but what I am questioning is the interpretation. Was there a consensus to deprecate use of the IEC prefixes? I see no evidence of such a consensus. What happened is this:
  • On 26 January Fnagaton made this edit, citing a talk page discussion for justification. As best I recall, the discussion in question centred around a way to disambiguate the megabyte by means of exact numbers of bytes. There was consensus (which I supported) to permit this kind of disambiguation but no consensus to prefer it over the use of IEC prefixes. I therefore followed Fnagaton's change by reinstating an explicit statement that use of KiB, MiB etc was also acceptable.
I did not interpret the words then to imply that either one is preferred - if I had done I would have made a case at the time for giving the two options equal weight. That is what I am doing now because I see now that the words are being interpreted in this way. Thunderbird2 (talk) 17:08, 18 March 2008 (UTC)[reply]
I second Thunderbird2. I see no reason that IEC Binary Prefixes (Ki, Mi, etc) should be deprecated and IMO the short length of IEC Binary Prefixes makes them preferred to other forms of disambiguation (i.e., MiB is better than either 1,048,576 bytes or 220 bytes) Tom94022 (talk) 17:40, 18 March 2008 (UTC)[reply]
Using MiB is not better than 220 because MiB can be ambiguous (this has been shown before) and it is pushing a term which has very limited use in the real world. Thunderbird, the "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units" comes from previous discussions when the guideline was last changed and this can be found in the talk page history. Changing the guideline to say "is equally acceptable" goes against the spirit of what was discussed at the time because the consensus is leaning away from using IEC prefixes. If you look at the guideline from about two years ago you'll see it is very pro -bi prefixes, now it is not because a small minority of people were making thousands of robot like changes to convert all prefixes to binary IEC prefixes and this really annoyed a lot of people. Fnagaton 17:51, 18 March 2008 (UTC)[reply]
  • Thunderbird’s proposal to disambiguate by means of a footnote (∆ here) makes a lot of sense to me. I note too that his proposal was acceptable to Fnagaton at that time. Has something changed since then? As I stated earlier, representing a unit of measure using symbols that aren’t generally recognized by an article’s readership is no good at all. IMO, the original MOSNUM policy on this issue was in error and far too rapidly embraced—or at least accommodated—the IEC proposal because of its perceived merits. That was unwise. Wikipedia, vis-a-vis MOSNUM, should have waited to see if the practice was adopted by at least one influential computer magazine before taking up the cause too. It is not uncommon for otherwise meritorious proposals by influential organizations like the IEC to not do well at all. When that happens, early adopters find themselves out in the snow all by themselves, waving the Esparanto banner.

    It is generally recognized that transistorized memory like RAM is always measured in binary units. There is no need to use unit symbols that are unfamiliar to a knowledgeable reader for RAM, nor is there even a need to disambiguate. Thunderbird’s proposal is appealing to me because hard drives are a different matter; they’re huge cesspools of mechanical storage and the manufacturer broke away from binary math in their “horsepower race.” It is articles on hard drives, for instance, that could benefit from disambiguation. Thunderbird’s proposal accomplishes that end, and further, doesn’t rely on the use of unfamiliar symbols that readers never encountered before until they land on Wikipedia. Greg L (my talk) 19:11, 18 March 2008 (UTC)[reply]

For the record, it is an urban myth that HDD manufacturers broke away from binary math in their “horsepower race.” The evidence is that HDD manufacturers always used M in its common decimal meaning. Tom94022 (talk) 19:42, 18 March 2008 (UTC)[reply]
Using a footnote is fine as long as the footnote does not use the IEC prefixes because those prefixes can be ambiguous for example and also because it introduces prefixes that are not widely used in the real world. Having the footnote specify the exact number of bytes, in power notation if brevity is needed, is fine by me. I actually prefer power notation for disambiguation or footnotes because the powers give a very good example if it is decimal or binary. Fnagaton 19:30, 18 March 2008 (UTC)[reply]
  • Which is what his proposal does, yes? He suggested the following for disambiguation (I took the liberty of changing his example of “SCSI transfer speeds” to “hard drive storage”):
  • when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
    • 1 KB = 1024 B
    • 1 MB = 1024 KB
    • 1 GB = 1024 MB
  • when applied to data transfer the quantities KB and MB are defined as
    • 1 KB = 1000 B
    • 1 MB = 1000 KB
I know that T-bird still embraces the use of Kib, but at least the above seems to currently satisfy everyone. I like it because it 1) doesn’t use symbols that aren’t widely recognized, 2) clarifies ambiguity, and 3) does so as a footnote and therefore doesn’t clutter the meat of the article. Good, yes? Greg L (my talk) 19:51, 18 March 2008 (UTC)[reply]
Apart from propsing that the text is changed to say "Use of IEC prefixes is equally acceptable" which I don't support. IEC prefixes should not be pushed into being used when they are not used by the sources relevant to an article. Which is why I propose removing any mention of the IEC prefixes for disambiguation. Fnagaton 20:24, 18 March 2008 (UTC)[reply]
I suggest 220B is just as unknown to many users as MiB. I also challenge that there is any ambiguity about IEC Decimal Prefixes, unknown to some, perhaps, but ambiguous - how? Rather than a footnote, I think an inline link might be the best solution to disambiguation, something like 256 "MB" (MiB) where disambiguation is necessary. Tom94022 (talk) 19:42, 18 March 2008 (UTC)[reply]
That's not accurate because 220 is better understood since raising one number to the power of another number is mathematical in nature. The -bi prefixes can be ambiguous because it has been shown how some people in the real world have used them in the decimal sense. Using numbers to express the number of bytes is less ambiguous than using the IEC prefixes. Since reducing ambiguity is the stated aim of some here then that logically means not using IEC prefixes and instead stating the number of bytes. Fnagaton 20:16, 18 March 2008 (UTC)[reply]
Just because someone has used some term wrongly once doesn’t make it ambiguous. SI prefixes became ambiguous for bits and bytes, because many people used them wrongly, which eventually was standardized later (by other organisations of course).
Like pretty much everything else, I’ve said that in the currently first section of this page already. Anyhow, I’ll repeat (and slightly modify) my suggestion:
Say in MOSNUM that binary meaning of SI-like prefixes is the default for bits, bytes and words in – list perhaps incomplete: – semiconductor storage and file sizes, decimal meaning is the default for other storage (e.g. magnetic and optical) as well as speeds, otherwise it’s ambiguous. In deviating cases (e.g. decimal RAM, binary rates) disambiguation is needed. IEC prefixes are one way of disambiguation. IEC symbols are unproblematic (just an added i and best accepted in “real world”), but binary kilobyte is preferred to kibibyte in prose, thus it can also be contrasted with decimal kilobyte.
Overall make the section more general on disambiguation needs, which are mentioned in the parent section. — Christoph Päper 23:29, 18 March 2008 (UTC)[reply]
"Happen once"? Well that's a gross understatement. The -bi prefixes can be ambiguous, fact. Disambiguation using IEC prefixes is not needed because the IEC prefixes can be ambiguous and there are other methods that are more accurate. For example, the only completely non-ambiguous way to disambiguate is to state the number of bytes either in full or using power notation. Fnagaton 00:10, 19 March 2008 (UTC)[reply]
You haven't provided any actual examples of such occurences, nor provided any indication that they are common enough to actually be an issue of any kind. It would probably also be a good idea to demonstrate that raw numbers of bytes (which take some mental gymnastics for most readers, including myself, to convert into something they can make sense of) are easier to understand than an unambiguous term linked directly to a definition of that term. — Aluvus t/c 01:57, 19 March 2008 (UTC)[reply]
"You haven't provided any actual examples of such occurences" - Yes I have, so you are wrong. As for "being an issue" it is up to you to show that what you think are issues with kilobyte are enough to warrant needing to use -bi prefixes and you have not done so. The -bi prefixes can be ambiguous, that is a fact. So stop pushing for those prefixes to be used when there already exist better methods to disambiguate. Fnagaton 10:56, 19 March 2008 (UTC)[reply]
  • Tom, the IEC’s proposal makes rational sense. But if readers of computer magazines and computer Web pages have never encountered a term before, we are subverting the very purpose of Wikipedia when we use unfamiliar language: to effectively and clearly present information to the reader with minimum confusion. Representing units of measure using symbols that many readers have never encountered before until they land on Wikipedia is a poor practice that has been measured at 2.6 Mc. It should therefore be avoided in my opinion. Greg L (my talk) 20:10, 18 March 2008 (UTC)[reply]

It never fails to amuse me to see well-meaning but misguided people thinking that they are too smart to use standards that someone else wrote. Not invented here should not be regarded as a thing we want in WP. If you really think the standard is broken, get involved with the standards track, don`t hide out on WP and snipe at it. There`s no reason we can`t use the standard. The fact that some readers will encounter new information while reading a WP article should hardly frighten us, that`s what they are here for. Just wikilink the first usage of the unit and move on.LeadSongDog (talk) 05:05, 19 March 2008 (UTC)[reply]

Well that's a silly thing to write since Wikipedia does not blindly follow the standards organisations and instead usually makes the wise choice that it follows the real world consensus. Fnagaton 10:52, 19 March 2008 (UTC)[reply]
I'll assume that was intended as civil and move on. The above discussion can hardly be construed as "blindly follow[ing]" the standard: it is a reasonable, informed debate. It is not, however, remotely close to the years of discussion that go into crafting an open standard. Having worked as editor on a number of other IEEE standards (1109, 1154 and others), I can attest that every word of them is subject to sweat, debate, compromise, and bargaining by people who are constantly trading off in their minds the interest of the standard against the interest of their employers in having a viable competitive position. The tension in that process works to make the standard the best that can actually be implemented. None of it is just casually tossed off.
The JEDEC standard already makes provisions for the imprecise popular usage, we can use those provisions. Nothing I've seen here or elsewhere suggests a substantive difficulty in using the standard, simply reluctance to adopt precise language in a large number of articles, leading to a lack of concensus. That's something that has been addressed many times before on WP, it can be done again. Can anyone point out a specific case where the standard cannot work? LeadSongDog (talk) 15:32, 19 March 2008 (UTC)[reply]
You did just try to insinuate editors here are "misguided people" with your "05:05, 19 March 2008" comment, so look at your own comment for not being civil. Your summary of what is going on here is entirely wrong because it isn't "misguided people thinking that they are too smart to use standards that someone else wrote" (which is another slur from you) and isn't a case of "not invented here". You then try to use the fallacious point about getting involved with the sdtandards process. That is why your comment is silly. The effort that goes into creating standards has nothing to do with the topic. The -bi prefixes are not as precise as stating the exact number of bytes because the -bi prefixes can be ambiguous. When a "standard" is made and after ten years the majority of the real world still ignores it ipso facto the standard has failed. The "standard" doesn't work because it has only gained very limited use in the real world, therefore pushing for it to be used in Wikipedia goes against what Wikipedia is about. That is your substantive reason where the "IEC/SI standard" cannot work and that is why the "IEC/SI standard" cannot be used here. Fnagaton 16:16, 19 March 2008 (UTC)[reply]
I could have been clearer in my phrasing. I should perhaps have chosen "well intentioned people engaged in a misguided effort"". It's spilt milk now. We all do it at times, that's why it's amusing. It's a simple human foible. I still contend that it is precisely a case of not invented here. What's going on is an attempt to create an alternative standard to serve the same function as an existing one. I'll not address the question of whether that is a worthy goal, I just contend that if the effort is to be pursued, WP isn't the place for it. This isn't wikitechnicalstandardsdevelopmentforum. Just adopt an extant, unambiguous standard and I'll be content - I'm not particularly fond of this one, but I still haven't seen an example of a case where it cannot be made to work. Got an article as an example?LeadSongDog (talk) 17:59, 19 March 2008 (UTC)[reply]
Well you are wrong becaise it is not a case of "not invented here" for me because it has always been my position that Wikipedia follow the example given by the majority of reliable sources relevant to the topic. Do not try to second guess my motives. It is not about creating another standard because it is about following the example set by those that supply the reliable sources that each article is attached to. The IEC/SI prefixes are not unambiguous by the way and that is a fallacious argument. The only unambiguous standard is to explicitly state the exact number of bytes using power notation if brevity is required. The example of where it cannot work has already been given in my previous comments above. As for a specifc article that is irrelevant because the reasons I gave in my previous comment apply to all articles related to this topic that have the majority of reliable sources which use kilobyte/megabyte/gigabyte/KB/MB/GB. Fnagaton 18:11, 19 March 2008 (UTC)[reply]
Reliable sources do not use KB etc in their binary sense because the notation is ambiguous. Reliable sources do not use ambiguous units. Thunderbird2 (talk) 18:22, 19 March 2008 (UTC)[reply]
You are wrong and you demonstrate that you do not understand what "reliable source" actually means. You need to read Wikipedia:Reliable sources. The majority of reliable sources relevant to the articles in Wikipedia use the terms kilobyte/megabyte/gigabyte/KB/MB/GB in the binary sense when they are talking about powers of two numbers. Fnagaton 19:17, 19 March 2008 (UTC)[reply]
  • It seems that there are some new editors weighing in here who may not have participated in—or read—where this started on Talk:DEC_3000_AXP. So it’s worth repeating myself.

    Just because a new word, term, unit of measure, or a symbol for a unit of measure is proposed by an influential organization, doesn’t mean it automatically becomes widely accepted and recognized. The International Union of Pure and Applied Physics once proposed that expressions like “ppm” (parts per million) be replaced with a new unit called the uno. Notwithstanding that it was arguably a great idea, in 2004, a report to the International Committee for Weights and Measures (a committee that makes recommendations to the BIPM, which oversees the SI) stated that response to the proposal of the uno “had been almost entirely negative” and the principal proponent “recommended dropping the idea.” The IUPAP proposal on the uno wasn’t the first one to go down in flames for lack of adoption and it won’t be the last. It doesn’t matter if an IEC proposal for “KiB” is a good one, it has to be widely adopted and recognized before encyclopedias can use it. And so far, it hasn’t been widely adopted and appears destined to join the scrap heap of other proposals that had merit but just didn’t catch on for some reason.

    Yes, people come to Wikipedia to learn—more about a subject; you don’t use unfamiliar language, terminology, and units of measure that no other encyclopedias use. How do encyclopedias decide what terms to use? Encyclopedias use terminology that a typical reader who will be visiting that article already recognizes or should recognize in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. Wikipedia can’t be be using future-talk (why not “kilocochranes”) just because “it’s a good idea” when hardly anyone except a few Wikipedia authors and people who helped write the damned proposal know what it means. Wikipedia authors can’t start thinking of themselves as coming from the United Federation of Planets who will use Wikipedia as a venue to take every good idea from the future and turn it into a standard that it clearly isn’t. Wikipedia must reflect common language usage, not try to promote change.

    As for the allegation that some editors here fear the use of “KiB” because it “wasn’t invented here”, well, neither was “MB” or “KB” or any other SI prefix that was appropriated from the SI by the pioneers of computers. All that pioneering was done long ago by people who had nothing to do with Wikipedia, long before most editors weighing in here on this forum were even born. So an assertion that opponents of “KiB” and “MiB” have an issue with “not invented here” is just a metric ton of weapons-grade bullonium and I’ll have none of it. It was nothing more than a specious attempt to bait others. So I will ignore that particular author from hereon since 1) his position on the subject is misguided, 2) he isn’t properly arguing his point here in a fashion that can possibly be considered as constructive, and 3) he obviously can’t be reasoned with

    There is only one valid metric to evaluate whether terms like “KiB” and “MiB” should be used here on Wikipedia: Is it widely used by trade magazines, general-circulation books, brochures, advertisements, owners manuals, etc. Clearly the answer is no. And that’s why the terms aren’t used by other encyclopedias. Whereas Wikipedia and other encyclopedias might explain these terms in an article like Byte, they don’t routinely used them to denote numerical equivalencies in other articles. Why? To avoid confusing readers. It doesn’t matter if they can click on a disambiguation link; the reader is effectively being expected to remember unfamiliar language that will only be encountered on Wikipedia. That is just so unwise. Current MOSNUM policy allowing the use of these terms is in error and should be changed.

    MOSNUM already has an exceedingly practical policy, here at #Which system to use that clearly can be of some utility in concluding this debate. It reads:


It’s time for proponents of “KiB” and “MiB” to familiarize themselves with that policy, ponder the wisdom behind writing it, and consider its implications. Greg L (my talk) 19:04, 19 March 2008 (UTC)[reply]
  • P.S. Thunderbird had a perfectly workable solution when he suggested the use of a <ref> note. (I took the liberty of changing his example of “SCSI transfer speeds” to “hard drive storage”). The note could read something like:
  • when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
    • 1 KB = 1024 B
    • 1 MB = 1024 KB
    • 1 GB = 1024 MB
  • when applied to hard drive storage, the quantities KB and MB are defined as
    • 1 KB = 1000 B
    • 1 MB = 1000 KB
Why not use that proposal? Greg L (my talk) 19:07, 19 March 2008 (UTC)[reply]
As Greg points out I have no objection to the use of this form of disambiguation. No, I support this kind of disambiguation wherever it is used. I just think that it is unlikely to be popular, because it is hard work to explain every time exactly which kind of MB you are talking about. We should let natural selection play its role here. Thunderbird2 (talk) 19:28, 19 March 2008 (UTC)[reply]

The case for equal status

There was no consensus for Fnagaton’s change of 26 Jan because the possibility of deprecating the MiB and its cousins had not previously been raised on the talk page. My edit (also 26 Jan) established what I saw as equal preference for the two forms of disambiguation (though others have interpreted it differently). That’s way changing “also preferable” to “equally preferable” only clarifies the intended meaning without changing it. We seem to all agree that disambiguation is desirable, but clearly there is little agreement on how that should be achieved. The two main contenders are a) use of IEC prefixes for binary powers (eg MiB) and b) use of exact numbers of bytes using powers (eg 220or 10242). My opinion is that these two options should be given equal preference here, and this is why:

  • Clearly there is reluctance amongst editors to use MiB to disambiguate, and rightly so. It is unfamiliar to many, and it will take some getting used to.
  • I maintain there will be similar reluctance to use exact numbers of bytes. This is partly because expressions like 220 may also be unfamiliar to some, and partly because of the sheer effort required to type it all out.

The only way to find out which is preferred is to give them equal status here. Thunderbird2 (talk) 19:23, 19 March 2008 (UTC)[reply]

  • T-bird, well, now I see why you two are so animated and are the principal combatants here. No one like’s to have another editor wade in and change someone’s work without so much as a “hello” on a talk page. Now that there is a head of steam on this debate, I suggest we not quit until a consensus has been reached on how to resolve this once and for all for all articles. Wikipedia needs some standardization in its computer-related articles and currently doesn’t. That’s not good. I am absolutely convinced there is common ground that can clarify ambiguity where it exists, and which 1) doesn’t use unfamiliar units of measure, and 2) requires a minimum of clicking on links and loading in new pages. Whatever that consensus is, it should be more than a gentlemens’ agreement; it should be memorialized in an official MOSNUM policy. Greg L (my talk) 19:34, 19 March 2008 (UTC)[reply]
Thunderbird2, what you propose (about mentioning IEC prefixes with equal weight) gives editors who prefer one style to force it into articles regardless of what is used in the reliable sources for that article, that is wrong. The only way is to follow the reliable sources from the real world and then disambiguate by stating the exact number of bytes with power notation if needed. Stating the exact number of bytes gives no Wikipedia preference or personal bias to any system, that is the only completely fair option. What it does do is makes sure the real world consensus is reflected. The real world consensus, just so you are left with no doubt, is to not use the -bi prefixes. It is clear in the real world that IEC prefixes do not have "equal weight" so Wikipedia must not enforce "equal weight" for those prefixes either. Otherwise it is like Wikipedia having "affirmitive action" to help support the minority prefixes, which is not going to be tollerated. It is not the job of Wikipedia to support failing standards. Fnagaton 19:35, 19 March 2008 (UTC)[reply]
Also I object to disingenuous accusation that my change had not been discussed. It was discussed as the change comment clearly links to the discussion. I was also implementing another editor's suggestion that had been talked about. I say disingenuous accusation because I also explained to you at the time where it had been disucssed on your talk page. So you do know it was discussed because I told you so I demand that you retract what you wrote. Fnagaton 19:56, 19 March 2008 (UTC)[reply]
I don't recall saying there had been no discussion. The discussion reached a consensus, which I supported, for quoting an exact number of bytes for disambiguation, not for deprecating IEC prefixes for the same purpose. Thunderbird2 (talk) 22:16, 19 March 2008 (UTC)[reply]
Removing the IEC prefixes for disambiguation from the guideline is the logical result of only needing to state the exact number of bytes and following real world consensus. This is because the IEC prefixes can be ambiguous and stating the exact umber of bytes is the only unambiguous way of expressing the number of bytes. Putting it another way, since the IEC prefixes can be ambiguous then there is no point having them as a choice for disambiguation because as you agree there is no point using what can be ambiguous terms for disambiguation. As Woodstone says "Having it in the MOS will hopelfully prevent reversions" which is what happened when I made the change the editor propsed. As already explained on your talk page, you know this, so stop trying to misrepresent the situation. Fnagaton 23:32, 19 March 2008 (UTC)[reply]
Although I agree that the IEC prefixes have not caught on, and that is a good reason to minimize their use in Wikipedia, they are not ambiguous. The example Fnagaton gave earlier of alleged ambiguity was of some post to some obscure open-source software project; just because you can find one clueless programmer, that does mean a set of units is ambiguous. If we want to ban something for ambiguity, let's ban something really ambiguous, like 12:00 PM or midnight. --Gerry Ashton (talk) 00:06, 20 March 2008 (UTC)[reply]
It means that the IEC units can be ambiguous and it has been shown how they are used in the decimal sense, something the user above had claimed to have never seen before. Since the mistake of using IEC prefixes has been shown the prefixes can therefore be ambiguous. It doesn't matter if the incorrect use is rare or not, the fact remains that stating the exact number of bytes is the least ambiguous way of disambiguation when compared with IEC prefixes. Since removing ambiguity is the goal then prefixes which can be ambiguous are not to be used in disambiguation which leaves the option of explicitly stating exactly the number of bytes. There is no way 12:00 PM or midnight is ambiguous either because they are twelve hours apart and PM means post meridiem which means after noon and noon is obviously the middle of the day, generally speaking. Fnagaton 00:28, 20 March 2008 (UTC)[reply]
Fortunately this guideline already rules out 12 am and 12 pm; NIST agrees, saying that "the terms 12 a.m. and 12 p.m. are wrong and should not be used." --Gerry Ashton (talk) 04:25, 20 March 2008 (UTC)[reply]
  • It was my fault for misinterpreting what you wrote T-bird. Greg L (my talk) 23:00, 19 March 2008 (UTC)[reply]
  • Why is this complex? Wikipedia should use the units employed in the current scientific literature on that topic. In this case, that means only KB, MB, GB, etc. If it’s an article on hard drives, there can be a <ref> note at the first occurrence of “GB” explaining that it means decimal math. This would effectively be a wholesale adoption of the way current advertisements for hard drives handle the disambiguation. This is just one way to handle the problem; if there are a better ways to accomplish this end, let’s see them. Greg L (my talk) 19:51, 19 March 2008 (UTC) P.S. Real life calls and I’ve got something to do for the rest of the afternoon. I’ll check back and see if things have degraded to the point where we are questioning each others parenthood. ;-). Greg L (my talk) 20:05, 19 March 2008 (UTC)[reply]
    • There are currently no better ways that are compatible with the Wikipedia way of doing things that I can think of. And compatibility with Wikipedia is the important issue here, not what some standards body seems to think is important. Fnagaton 20:08, 19 March 2008 (UTC)[reply]
  • Fnagaton, if you are interested in resolving this issue across all of Wikipedia’s computer-related articles, may I suggest that you craft a proposed policy that you hope would be adopted by MOSNUM? I find that this sort of thing is the most difficult of all text I ever write on Wikipedia. I know it’s quite a challenge because to be successful, it needs buy-in from parties with widely divergent views on this matter. It seems though, that you, T-bird, and I have identified some common ground to build upon. I suspect the first step in this proposal procedure would be to not invite a straight “Support” / “Oppose” “vote”, but rather, to go first to discussion with the expectation that your first draft will evolve.

    I think you’ve got a superb ally in this effort: MOSNUM itself. MOSNUM’s own policy on units of measure (#Which system to use), requires that editors should use the units employed in the current scientific literature on that topic. Thus, current MOSNUM policy, which permits the use of the IEC “…iB” unit symbols, makes MOSNUM in conflict with itself. The IEC units, like “KiB” are absolutely unambiguous in their definitions; that much is clear. But virtually no computer magazines nor any other encyclopedia routinely use them. Thus, they are poorly recognized by the typical reader. That much too, is clear. Greg L (my talk) 05:40, 20 March 2008 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=199533924"