Wikipedia talk:Manual of Style/Dates and numbers

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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]
To tie this thread with the new thread this comment demonstrates why Crissov is still wrong for the same reasons as above. Fnagaton 19:13, 24 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]

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]

How about adding green check marks on the left of the table, just for the two formats that are accepted by the MOS? Red X's are already used on the right to indicate what will display as a dead link. Chris the speller (talk) 15:30, 26 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]
I've never seen a non-combining overline before; I didn't even know this character existed. I suspect few people would know how to enter it. I think it would be just as much a WP-only convention as square brackes or curly braces. --Gerry Ashton (talk) 00:30, 22 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]

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]

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]

  • Thanks Woodstone. I’ll copy this to the top of the sandbox to ensure it is noticed. Greg L (my talk) 18:29, 20 March 2008 (UTC)[reply]
  • I posted it over on the sandbox. I doubt that a math-based template can do anything about this one. The upcoming character-based magic word should be able to properly digest it. But just to make sure this issue is dealt with, I notified the developer of the magic word than trailing zeros in the significand shouldn’t be truncated if the uncertainty pipe has a value in it. Greg L (my talk) 18:53, 20 March 2008 (UTC)[reply]
In my opinion, numbers should never be truncated. Just use whatever digits the editor supplies. −Woodstone (talk) 09:18, 24 March 2008 (UTC)[reply]
  • It's not impossible to overcome this type of thing with templates (look at {{rnd}} for example) but if there's a magic word in the works, might we not just be happy to hold our breath? Jɪmp 03:49, 24 March 2008 (UTC)[reply]
In template "rnd" this can be achieved because the number of digits is an explicit parameter. Requiring that in this case would make the template less usable.−Woodstone (talk) 09:18, 24 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]
Rationale underlieing the hybrid proposal
  • 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 ambiguous expressions like “ppb” (parts per billion) be replaced with a new unit called the uno. An expression like “2 ppm” would be “2 µU”, “2%” would be “2 cU”, and “2 ppb” would be “2 pU”. 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.” So we’re still stuck with ambiguity because “billion” has different meanings in different countries. And we Wikipedia editors can’t routinely use the uno to denote relative proportions because it’s not a widely recognized unit. 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 the IEC proposal for “KiB” is a good one too; it must 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.

    Further complicating matters is there is no article-to-article consistency on Wikipedia. If “Dave”—an experienced programmer—encounters “34.5 GB” in an article, he has to wonder if he is currently on an article that recognizes the IEC prefixes (in which case, “GB” refers exclusively to base-ten math), or if he is reading an article that uses the term conventionally, in which case he just considers the context or looks for an earlier footnote or other disambiguation. But if the reader is a relative novice who has simply purchased computer equipment in the past, converses with his friends, reads his owners manuals, and is interested in a computer subject and wants to learn more on Wikipedia, the distinction between base-ten and base-2 values is usually unimportant (a 7 % difference for gigabyte). Thus, the unfamiliar term “gibibyte” (symbol “GiB”) is nothing more than 1) initially confusing, and 2) won’t be remembered anyway as it will likely never be reinforced anywhere else except here. If “Greg”—an advanced amature—is reading a Wikipedia article, he knows that “2 GB SODIMM card” always denotes a base-2 value. He knows that “80 GB hard drive” is base-ten math, and is often an approximate, pre-formated value anyway so it doesn’t matter. But when he encounters “GiB” in a Wikipedia article, he knows it is simply that special practice he sees only on Wikipedia that is intended to distinguish between binary and decimal math but can’t quite remember which one it is without 1) clicking on a link, or 2) simply considering the context. He must deeply commit “GiB” to memory as it will likely never be reinforced anywhere else except on Wikipedia. By the way, I wrote “7 %” above—with the extra space—and not the “7%” we’re all used to seeing just to show what happens when one follows a practice officially recommended by a big standards organization just because it makes good sense (always using a space to separate a numeric value and a unit symbol). MOSNUM wisely flouts this BIPM policy regarding the SI.

    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. New words aren’t added to the lexicon in encyclopedias and dictionaries until they achieve a certain level of ubiquity in the real world.

    As for the above 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]

But if an article follows the "SI with unambiguation" route, you might end up with an article talking about a computer with, say, "1 GB (1,073,741,824 bytes) of random access memory and 300 GB (300,000,000,000 bytes) of hard drive space." The very article will then be obviously (and gallingly) in conflict with itself. You don't have to have memorized all the powers of two, let alone be able to do multiplications on those numbers in your head, to recognize that 300 multiplied by multiplied by 1,073,741,824 does not equal 300,000,000,000. Most scientific literature in this field is going to be talking about one type of resource or another, and so doesn't have this problem; it can't be the final arbiter here. Of course this could be addressed by describing, say, a machine with 512 MiB of RAM as having "537 MB (536,870,912 bytes)". That would be unambiguous, and a correct usage of a decimal prefix. But somehow I doubt that's what you want. Jeh (talk) 22:22, 27 March 2008 (UTC)[reply]

Proposed policy on disambiguating bytes

First draft for consideration
I'll give it a go. Considering what you say about Wikipedia wisely following the example of the real world and ignoring the standards organisations when needed. Also considering what was said about not supporting one style of prefixes over another especially when that style is obviously in the minority. Considering what was also said about not hinting about deprecating one style. And considering what you say about the use of units employed in the current scientific literature. The only logical and fair conclusion is to remove reference to any hint of support for any of the standards organisation styles at all and make it clear that the units must defer to the sources for the article which will then logically defer to what is the real world consensus. In doing so all the text about "no consensus for using IEC prefixes" is removed as is the text explaining the history of the prefixes. This is because the respective articles already contain the history of these prefixes. The guideline says "without using any other prefix styles" specifically to stop any editor using their own preferred choice of prefixes for disambiguation and to avoid any kind of bias from individual editors. Also gone is the text about not changing from one style to the other and keeping with the original style, this is important because it allows articles to naturally change over time to reflect what is the consensus in the real world if the sources for that article considerably change from using KB to KiB for example. This is also to try to remove what is seen as a Wikipedia guideline pushing any one standard over another and to remove any bias coming from Wikipedia. The guideline then becomes a series of examples of what to do for disambiguation, wikilinking and footnotes. So it would result in something like this:
{{Quantities of bytes}}
Editors must use the units/prefixes employed in the sources used by the article. Editors must be certain whether the units/prefixes are binary or decimal in the material at hand before disambiguation. When this is certain the use of parentheses to disambiguate the number of bytes without using any other prefix styles is acceptable as is the use of footnotes and wikilinking. The rule of thumb for disambiguation is keep the number as it is in the sources (no rounding needed) and state the number of bytes in full or with power notation depending on context and brevity.
  • KB to ×210 bytes or ×103 bytes
  • MB to ×220 bytes or ×106 bytes
  • GB to ×230 bytes or ×109 bytes (etc)
For example, article text which is "256 KB" should be disambiguated as "256 KB (256×210bytes)".
Disambiguation text for footnotes can contain prefixes but these prefixes must still be consistent with the sources used in the article and the lowest prefixed number of bytes must be stated in full or power notation for brevity. For example:
  • When applied to computer memory (RAM or cache) the quantities KB, MB and GB are typically defined as:
    • 1 KB = 1024 B
    • 1 MB = 1024 KB
    • 1 GB = 1024 MB
  • When applied to hard drive storage, the quantities KB, MB and GB are typically defined as:
    • 1 KB = 1000 B
    • 1 MB = 1000 KB
    • 1 GB = 1000 MB
This system allows for the rare types of storage media (very very rare but they do exist somewhere) which may use the calcuation "1MB = 1024000 bytes".
  • This storage media uses a rare prefix style:
    • 1 KB = 1000 B
    • 1 MB = 1024 KB
    • 1 GB = 1024 MB
When wikilinking prefixes use the wikilink that points exactly to the respective prefixes used in the article, for example: "KB" becomes "KB" , "KiB" becomes "KiB" and "kilobyte" becomes "kilobyte" etc.
Measures that typically use decimal multiples:
Measures that typically use binary multiples:

Fnagaton 08:58, 20 March 2008 (UTC)[reply]

Suggested tweak
More general:

=== Ambiguous units ===
Disambiguation is necessary whenever a unit has more than one definition and the context of the article does not suffice to select the intended meaning.

Editors must be certain which kind of meaning (e.g. binary or decimal for SI-like prefixes with bits and bytes) is intended in the material at hand before disambiguation. The explanation can be done by the use of footnotes, wikilinking, parentheses containing exact numbers, possibly in power notation, without ambiguous units, or by employing "unit qualifiers" (e.g. binary megabyte or nautical mile). The rule of thumb for disambiguation is to keep the number as is without rounding and decide on an option depending on context and brevity. For example, article text which is "4 KB" may be disambiguated as "4 KB (4×;210 byte)".

Explain deviations from defaults in footnotes, e.g. rare types of storage media may use the calcuation "1MB = 1024000 bytes":

This storage media uses a rare prefix style: 1 KB = 1000 B, 1 MB = 1024 KB, 1 GB = 1024 MB.

==== Defaults and possibilities ====
Bits and bytes:

  • When applied to semiconductor storage (e.g. RAM or cache) and file sizes, the prefixes K, M and G for bits and bytes are typically defined as the powers of 1024 (= 210.
  • When applied to hard drive storage and speeds, the prefixes K, M and G for bits and bytes are typically defined as the powers of 1000 (= 103).
  • The prefixes Ki, Mi and Gi for bits and bytes are always defined as the powers of 1024 (= 210).

Miles: ... Pounds and ounces: ... Tons: ...

— Christoph Päper 13:17, 20 March 2008 (UTC)[reply]
Discussion
Crissov I do not support to your changes because you have inserted your own point of view with repeated references to "Ambiguous units" and "SI-like prefixes" etc. You also added various other terms such as "without ambiguous units" which means you are trying to make it possible to add IEC prefixes to articles that do not have them and that is against one of the goals of the guideline and what Greg was saying. The guideline is not for your biased point of view and should be as neutral as possible, you are making it less neutral with that kind of language. Fnagaton 14:58, 20 March 2008 (UTC)[reply]
I support Crissov's proposal. He will be the first to acknowledge that it needs some refinement, but it is a step in the right direction. Thunderbird2 (talk) 15:45, 20 March 2008 (UTC)[reply]
Then we don't have consensus. It is a step backwards and nothing in it can be used because it is too biased. Fnagaton 15:59, 20 March 2008 (UTC)[reply]
(unindented)

I've been trying to understand Fnagaton's reluctance to accept what appears to me an innocuous change. Reading the existing text through carefully, it occurs to me that it could be based on a misunderstanding. The relevant paragraph reads (verbatim):

  • 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.

I interpret this to mean (implied words in bold)

  • 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 (equally) acceptable for disambiguation i.e., 256 KB (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.

In other words, the (permitted) role of KiB is to disambiguate KB, not to replace it. Is that also how others read it? Thunderbird2 (talk) 16:15, 20 March 2008 (UTC)[reply]

There isn't any misunderstanding on my part. I've said this before but I will say it again. IEC Prefixes are not equally used in the real world, therefore it is not Wikipedia's place to try to force them to be equal in the guideline. There are two choices. 1) Remove all attempts at pushing IEC prefixes in the guideline by agreeing to not use any biased wording, my proposal does not contain biased wording whereas Crissov's does use biased wording and POV. 2) Leave the guideline as it is which clearly says "There is no consensus to use the newer IEC-recommended prefixes". KiB should not even be used to disambiguate KB for the reasons already given above regarding the potential for ambiguity and the fact that stating the number of bytes is the least ambiguous method. Fnagaton 16:39, 20 March 2008 (UTC)[reply]
In that case I remain as puzzled as ever. Are you suggesting that "256×210 bytes" is more common than "256 KiB"? Thunderbird2 (talk) 16:51, 20 March 2008 (UTC)[reply]
It is because I agree with Greg's (19:04, 19 March 2008 (UTC)) comment that using unfamiliar IEC prefixes to denote (or disambiguate) the well known terms such as KB is more confusing to the readers and going by other related Wikipedia guidelines it is also unwise to try to advocate using those IEC prefixes when the article does not. I also agree that explaining the exact number of bytes is the least biased option and is the option that is least confusing to the reader who is looking to be educated about the exact size of 64 KB in a specific context, for example. So that's why anything that softens the guideline to try to allow equal standing to the minority prefixes does not get my support. I'm all for a completely neutral guideline as my proposed text shows because that fits with other Wikipedia guidelines about letting the real world consensus decide. It's about being consistent with the sources. Fnagaton 17:01, 20 March 2008 (UTC)[reply]
I oppose Fnagaton's proposed wording because it includes the sentence "Editors must use the units/prefixes employed in the sources used by the article." This is unwise because
  • no one editor is likely to have access to all or most of the sources, so only the select few who have access to most of the sources can edit the article
  • most of the sources might be old and use outdated units, such as angstroms
  • most of the sources might use specialized units, while more generally understood units might be more suitable for an encyclopedia. --Gerry Ashton (talk) 17:11, 20 March 2008 (UTC)[reply]
  • A fallacious objection because my proposed text says one must be certain before making changes. If you are not certain don't edit the article and instead leave it to someone else who is better equipped to make the changes. This is standard editing etiquette. Also to refute your other points, going back to what Greg said the units used in articles must be consistent with those used by the sources because that makes the reader less confused. It doesn't matter if the units used in the sources are against what the standards body you prefer says, what matters is being consistent with the literature/reliable sources relevant to the article. Put simply it is not your judgement call what might be better understood units. Lastly, and most importantly, it is not unwise at all. In fact it is very wise because it basically says what the parent MOS entries say about being consistent with the sources of the article. Fnagaton 17:25, 20 March 2008 (UTC)[reply]
A person may be thoroughly equipped to edit an article without having access to the specific works in the reference list. For example, an article might cite five roughly equivalent textbooks, and an editor might have access to only two of them (plus three others that are not on the reference list). An editor should not have to consult most of the works in the list just to decide which unit to use. To require otherwise constitutes article ownership.
I do not mean to suggest someone should pick one publication of a standards body and use it, even though that standard has been widely ignored by practicioners in the field. I do mean that the units used should be those generally used by modern sources in the field, even if a majority of the particular sources in the reference list happen to use some outdated or uncommon unit. --Gerry Ashton (talk) 17:39, 20 March 2008 (UTC)[reply]
  • All, I am truly surprised at how much common ground there is between these two proposals. Fnagaton, it appears to me that Christoph and T-bird bought off on your entire basic framework of how to disambiguate bytes. The differences appear to be merely in some lead-in body text explaining the rationale and basis for the policy. What is gone from all of this is any reliance upon unfamiliar units such as “KiB”. This is a major step forward and the differences between these truly seem trivial to me. I can easily go in and draft a proposed fusion of this but believe it would be premature to do so. Let’s solicit more comments from others.

    (*sound of crickets chirping*)

    Greg L (my talk) 17:09, 20 March 2008 (UTC)[reply]

  • Except the bits where it calls units "ambiguous" and rationale which is POV and the bits that open the doorway for adding IEC prefixes to articles that don't use them. The "KiB" is still there tucked away in the hidden meaning of "without ambiguous units". The wording needs to be neutral, not biased. I think it is a good time for the guideline to be changed because I don't particularly like "there is no consensus" bit as it has served its purpose to educate some users that they cannot use IEC prefixes everywhere and ignore the reliable sources. However the guideline needs to be changed for the better to avoid the situation happening again in the future. If anyone remembers the many bad vandalism changes Sarenne made you would know where I am coming from. Fnagaton 17:19, 20 March 2008 (UTC)[reply]
  • Common Fnagaton, I think we need more “assuming good faith” here. I may be wrong, but I believe he was calling it “ambiguous” because there are three meanings to “MB”: 1,000,000 bytes, 1,024,000 bytes, or 1,048,576 bytes. Thus, KB, MB, GB, etc. are ambiguous. That’s sort of a “well… duhh” fact here; otherwise, we wouldn’t be having this discussion, would we? Perhaps it would help to have an explicit clause saying that “unit symbols like “KiB” shall not generally be used to denote numeric equivalencies of computer storage since the terms are not well recognized.” If your suspicions are well founded, then someone will object to this proposal, no? Does anyone object to this? Greg L (my talk) 17:39, 20 March 2008 (UTC)[reply]
  • Anyway... I'm going to be taking a break over Easter, so don't make any guideline changes while I'm gone. ;) Fnagaton 17:32, 20 March 2008 (UTC)[reply]
  • I’ve also spent more time reading the above discussion. The basic framework of your proposal is entirely sound but the premiss seems to be wrapped too much around the subject of revising articles. I understand this is the hot-button issue that started all this. However, the MOSNUM policy on disambiguating “MB” needs to start first with the general policy of how articles are supposed to be written in the first place, how articles are supposed to appear, and what methods are acceptable. Then it can advance on to issues of editing existing articles—what editing practices are recommended, permissible, and impermissible. This is the “hard part” of writing MOSNUM policy I was writing earlier about; you damn near have to have a legal mind to pull it off. It helps though, to start off simply and gain consensus on that first. The details of revising existing articles should fall into place easily once everyone has agreed to what the ideal practices are. Greg L (my talk) 17:59, 20 March 2008 (UTC)[reply]
  • Somebody asked: Are you suggesting that "256×210 bytes" is more common than "256 KiB"? I would say, probably yes, although it's difficult to search for that. — Arthur Rubin (talk) 21:34, 20 March 2008 (UTC)[reply]

Third, hybrid proposal

All, I’m (Greg L) going to take a stab at a hybrid proposal for us to discuss. I’m going to start out short and simple for a variety of reasons: 1) it will keep me from getting too invested into my own work since there will be little of it, 2) I want to reserve the potentially more contentious issue of revising existing articles until after a consensus has been reached on where we want to go with new articles (Well, that didn’t happen), and 3) I am going to use head-on, direct language to demonstrate that others have no hidden agendas to keep on using IEC terms like “MiB” as Fnagaton fears. Here (MOSNUM:Binary prefixes), is the current MOSNUM policy that would be replaced.

Binary prefixes in computer memory and storage
The 1999 IEC proposal on binary prefixes (IEC 60027-2), which introduced unit names like “kibibyte” (symbol “KiB”) to represent 1024 bytes (210), and “mebibyte” (symbol “MiB”) to represent 1,048,576 bytes (220), etc., has not been widely adopted by the computing industry and trade magazines and is therefore unfamiliar to most readers.

In acknowledgment of this reality, it is no longer permissible on Wikipedia to routinely use the IEC 60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage. It shall remain, however, acceptable to use the IEC 60027-2 prefixes in verbatim quoted text, in articles where the primary cited source uses the IEC 60027-2 prefixes, and in articles that describe the IEC 60027-2 prefixes directly (such as Binary prefix, Kibibyte, Kilobyte, Byte, etc.). Broadly stated: in a given Wikipedia article, authors should use the terminology, units of measure, and methods of disambiguation typically employed in the primary literature for the intended readership.

As the terms “kilobyte”, “megabyte”, “gigabyte”, etc. (and their unit symbols “KB”, “MB”, “GB”…) are ambiguous as to their magnitudes, disambiguation in articles may be required.

Generally speaking, it should be assumed that file size and transistorized computer memory (DRAM, SRAM, etc.) are quantified using binary mathematics as shown in the table below.

BASE 2 BYTE PROGRESSIONS
Unit name Value In terms of
preceding
measure 		Exponent Bytes
Kilobyte 1 KB 1024 B 210 bytes 1024 bytes
Megabyte 1 MB 1024 KB 220 bytes 1,048,576 bytes
Gigabyte 1 GB 1024 MB 230 bytes 1,073,741,824 bytes
Terabyte 1 TB 1024 GB 240 bytes 1,099,511,627,776 bytes

…and so forth

Generally speaking, it should be assumed that hard drives—including solid-state models—are quantified using decimal mathematics as shown in the table below.

BASE 10 BYTE PROGRESSIONS
Unit name Value In terms of
preceding
measure 		Exponent Bytes
Kilobyte 1 KB 1000 B 103 bytes 1000 bytes
Megabyte 1 MB 1000 KB 106 bytes 1,000,000 bytes
Gigabyte 1 GB 1000 MB 109 bytes 1,000,000,000 bytes
Terabyte 1 TB 1000 GB 1012 bytes 1,000,000,000,000 bytes

…and so forth

The challenge for editors who must use ambiguous units of measure and their symbols is to mitigate confusion, not contribute to it. Common sense will suffice in all but the rarest of circumstances. When in doubt, look to current articles in well respected, general-circulation periodicals like PCWorld and Macworld for guidance on how and when to disambiguate. On Wikipedia, disambiguation should be implemented in a fashion that avoids use of terminology that would be poorly recognized by the typical reader, is minimally obtrusive within the body text, entails a minimum of directing readers to separate articles, and which uses links in a way that best adheres to WP:Principle of least astonishment. Note the following examples:

The original Macintosh had 128 kilobytes[1] of RAM. The next version, informally known as the “Fat Mac,” had 512 KB of RAM. Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem.

Notes

1.   ^  Throughout this article, kilobyte (symbol: KB) equals 1024 bytes.


The Seagate Cheetah 15K.5 ST373455LW, “80-gigabyte”[1] hard drive had an actual formated capacity of 73.4 GB and could hold a 2-hour, compressed HD movie with a file size of up to 68.3 GB.[2] Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem.

Notes

1.   ^  One gigabyte (symbol: GB) equals one billion bytes when referring to hard drive capacity.

2.   ^  When used as a measure of actual digital file capacity, GB equals 230 or 1,073,741,824 bytes.

Existing articles that use the IEC 60027-2 prefixes should be brought into compliance with this policy. Two imperatives must be met when revisions are made: 1) all changes must be correct so the articles remain accurate, and 2) courtesy should be afforded to editors who are currently shepherding an affected article or had recently greatly expanded an affected article. If you abide by expected etiquette and treat other editors as you would hope to be treated, all should go smoothly.

As regards, point #1 above (accuracy), read the existing text and research your material before making changes. As regards point #2 above (courtesy), post a message on the talk page of the article as well as the talk page of the shepherding editor. In that message, bring this MOSNUM policy regarding proper use of IEC 60027-2 prefixes to the editor’s attention and allow him or her a reasonable opportunity to update the article. Observing this second point has the dual virtues of keeping editing Wikipedia a fun hobby for all of us, and best ensures articles remain factual and correct.


That is my proposal. The rationale underling this proposal is encapsulated here via this link. Comments please. Greg L (my talk) 00:49, 21 March 2008 (UTC)[reply]

Support or oppose

Support, MOSNUM adoption of Hybrid proposal: “Binary prefixes in computer memory and storage”:
Please sign with # [brief statement] ~~~~

  1. Support For reasons outlined here. Greg L (my talk) 05:56, 23 March 2008 (UTC) Extensive discussions have reached a point where the views of those who are most animated about this are clear as glass and their positions have only hardened. We’ll now see how others feel and, hopefully, they’ll join into the discussion too. Greg L (my talk) 18:35, 23 March 2008 (UTC)[reply]
  2. Support In the interests of trying to build consensus I support Greg's proposal. It clearly states what is acceptable and what is not. Fnagaton 15:16, 24 March 2008 (UTC)[reply]
  3. Support—I've read the proposal and am acquainted with the preceding debate. Although it's not my field, I find the proposal to be eminently sensible and a workable solution to a long-standing issue. Tony (talk) 06:54, 23 March 2008 (UTC)[reply]
  4. Support This explains the meaning of a unit whose value is debatable in the context in which it is used, mirroring the real life applications of it. Rilak (talk) 22:46, 23 March 2008 (UTC)[reply]
  5. Support As Rilak says mirroring real life is a good reason. DavidPaulHamilton (talk) 13:00, 24 March 2008 (UTC)[reply]
  6. Support For the sames reasons others above expressed. --Marty Goldberg (talk) 21:48, 24 March 2008 (UTC)[reply]
  7. Support – Using the same units for both uses will require some explanation for our readers, but so does using a unit virtually nobody knows about. So, we are left with the pure benefit of doing away with the disused unit. Waltham, The Duke of 01:43, 25 March 2008 (UTC)[reply]
  8. Support We find ourselves in a situation where ambiguity and confusion exist in the real world. This proposal sets out a means of resolving these problems - without introducing further confusion by sanctioning the (essentially unused) IEC symbology. Sheffield Steeltalkstalk 21:13, 25 March 2008 (UTC)[reply]
  9. Support Wikipedia should follow the practices of the real world. -- SWTPC6800 (talk) 03:27, 26 March 2008 (UTC)[reply]
  10. Support. Very reasonable proposal. Is a long standing issue and I agree with Greg L entirely. カラム 07:33, 26 March 2008 (UTC)[reply]
  11. Support. Its all been said above. Pyrotec (talk) 19:34, 26 March 2008 (UTC)[reply]
  12. Support Wikipedia should not be used to change the publics perception, but should mirror it. Mahjongg (talk) 23:55, 26 March 2008 (UTC)[reply]
  13. Support My computer article edits are mostly on Apple's products, and Apple never uses the lowercase i units. The company's language reflects the general consensus of computer manufacturers. (Although that's not to say we can't have links to the clarifying binary prefix article.)--HereToHelp (talk to me) 02:25, 28 March 2008 (UTC)[reply]

Oppose, the proposed policy should not be adopted:
Please sign with # [brief statement] ~~~~

  1. Oppose at least until actual discussion of this can occur. Polls are evil, and voting is not a substitute for discussion. Attempting to ram this through with a rapid vote will only breed enmity and cause this topic to come up again (and again, and again) in the future. — Aluvus t/c 07:43, 23 March 2008 (UTC)[reply]
  2. Oppose especially because it is absolutely unclear from the messy box above what is actually being proposed. Also, I don't see anything wrong with using the IEC prefixes for disambiguation. −Woodstone (talk) 18:57, 23 March 2008 (UTC)[reply]
  3. Oppose polling at this stage. We need to discuss. WHoever put this together didn't even include a section for "comments". I'll fix that... SamBC(talk) 19:05, 23 March 2008 (UTC)[reply]
  4. Oppose deprecation of unambiguous IEC prefixes. The proposal does not address the fundamental ambiguity inherent in the megabyte and its cousins. The tables work fine in simple articles with a clear separation between the discussion of RAM and hard drive storage. But any attempt to describe transfer of data from one medium to another would quickly become incomprehensible because the MB would have to change its meaning half-way through a sentence. We are trying to produce unambiguous articles here and the IEC is trying to help us. Thunderbird2 (talk) 13:47, 24 March 2008 (UTC)[reply]
  5. Oppose deprecation of unambiguous IEC prefixes. The arguments in favor of deprecation are fallacious. Tom94022 (talk) 15:04, 24 March 2008 (UTC)[reply]
  6. Oppose That text is an outright ban of MiB and GiB and includes an order to change existing articles. So I guess that if this goes through then the next target for Greg L and Fnagatron will be to ban "British English, except in direct quotes and if the article is about British English", right? --David Göthberg (talk) 19:56, 26 March 2008 (UTC)[reply]
  7. Oppose as per Tom94022. Jeh (talk) 20:27, 27 March 2008 (UTC)[reply]
  8. Oppose Just because computer magazines and manufacturers use a wrong term does not menan we should use it too. There was a reason to create a new standard and it should be the only adopted here. Maybe with a small explanation on the bottom regarding KiB/KB confusion. --Denniss (talk) 00:16, 28 March 2008 (UTC)[reply]

Discussion

As the previous discussion set was getting long, and since it became so at a rather convenient point (a long thread on #10), I’ve taken the liberty of starting a new one here for convenience. Assuming there are no objections to this, you pay post new comments here (and continue old threads in the old set as required).
  1. Comment Regarding your vote statement, David Göthberg, it’s not exactly an “outright ban” as you allege (but it’s close). Unless they are being used in directly quoted text or are being used in articles that describe IEC 60027-2 directly, terms like “kibibyte” (symbol “KiB”), “mebibyte” (symbol “MiB”), kibibit (symbol “Kib”), (or Kibbles ‘n Bits for that matter), are to be no longer used since they are not generally recognized by most readers and are unlikely to be encountered elsewhere. But no, “British English” is not the next policy to change; current policy on this is imminently sensible. Suggesting as much is classic ‘this will lead to that’ fear-mongering. Greg L (my talk) 20:38, 26 March 2008 (UTC)[reply]
    • You can add "Use of terms like "mebibyte" in Wikipedia articles will lead to confusion" to this list of classics. --217.87.90.29 (talk) 16:01, 27 March 2008 (UTC)[reply]
  2. The reason a 80 GB does NOT(sic!) hold 80 Gigabytes is that it holds exactly 80 Gigabytes. Therefore Apple is already conforming to IEC 60027-2 in that regard. It's incorrect that none of Apple's product uses the new prefixes: http://developer.apple.com/documentation/Darwin/Reference/Manpages/man8/raidutil.8.html --217.87.90.29 (talk) 02:37, 28 March 2008 (UTC)[reply]

First Discussion set (1–10)
  1. Comment I am very troubled by the section saying that current articles "should" be brought into compliance. I haven't time right now to articulate a clear explanation of what I mean, but there are several issues with that section. It also seems to completely deprecate the IEC prefixes, which while I agree are silly, and rarely (not never) used in real-world and/or everyday situations, are not worth effectively banning. SamBC(talk) 19:05, 23 March 2008 (UTC)[reply]
    • Well, your newly added “comments” section is what the Discussion of hybrid proposal (right below, there ↓) was for. But that’s fine SamBC, we now have a fresh place to start. If the last two paragraphs of the proposal was deleted, would that change your vote? Greg L (my talk) 20:01, 23 March 2008 (UTC)[reply]
  2. Comment I support the use of these tables for disambiguation by consensus on individual articles. I strongly oppose any proposal that prefer ambiguous units over unambiguous ones. Thunderbird2 (talk) 13:38, 24 March 2008 (UTC)[reply]
  3. Comment There is no evidence that the general public has anymore knowledge of the meaning of MB than the meaning of MiB. As Morrison noted 40 years ago we practitioners are aware of a potential ambiguity in K between 1,000 and 1,204, but there is no evidence that such knowledge exists in the general public. So to deprecate one poorly unknown symbol in favor of another is not justified. Tom94022 (talk) 15:04, 24 March 2008 (UTC)[reply]
  4. Comment That is not exactly the argument Tom94022. The actual argument is that the evidence is clear that the general public do see KB/MB/GB more than the IEC prefix versions. Secondly the proposed guideline is not about "deprecation of IEC prefixes", the guideline is about making sure the biased POV of some editors does not spill into the guideline and editing articles. According to the proposed guideline if there is an article where its sources use a lot of IEC prefixes then yes that article will naturally use binary prefixes. Fnagaton 15:21, 24 March 2008 (UTC)[reply]
    • The proposal says that articles shouldn't use IEC prefixes except in verbatim quoted text, unless they are about the IEC prefixes or related topics. The final two paragraphs, which is has been suggested be removed, also say that existing articles using the IEC prefixes should be "fixed". Sounds like deprecation to me, if not more than deprecation. Saying IEC prefixes should be used wherever they are clearly meant is biased, but so is saying they mustn't be used, which is what the proposal seems to be saying, and will be taken to mean. SamBC(talk) 15:46, 24 March 2008 (UTC)[reply]
      • "articles shouldn't use IEC prefixes except in verbatim quoted text, unless they are about the IEC prefixes or related topics" - So that means the proposal does not deprecate IEC prefixes. In fact the proposal supports use of IEC prefixes where they should be used as shown by the article sources. Fnagaton 16:22, 24 March 2008 (UTC)[reply]
        • What that says is that articles shouldn't use IEC prefixes unless, basically, they have to. That sounds like deprecation to me; deprecation as opposed to outright ban. Any article can include them in a verbatim quote; it would be a contradiction of other rules otherwise, so that's obviously got to be there. Articles about the IEC prefixes could hardly not use them. The proposal says that no article should use them unless it's about them, except in quotes. That's saying that an article on any other topic shouldn't use the units in newly-written text, and the last two paragraphs then suggest that editors should feel free to run around changing any instance of the IEC units to the less-silly-sounding ones. This is not, in my opinion, a good idea. SamBC(talk) 20:52, 24 March 2008 (UTC)[reply]
          • No, it's called "being neutral and unbiased" and "following the example set by the sources used". Fnagaton 20:56, 24 March 2008 (UTC)[reply]
            • Fnagaton, by the wording of the above proposal, even if all of the sources for an article, including some quoted verbatim, used the IEC units, the text of the article could not do so, except in the verbatim quotes. Unless the article is about the IEC units, of course. SamBC(talk) 21:31, 24 March 2008 (UTC)[reply]
              • If you're going to read it like that then I can see why you would object but I think you're reading it incorrectly. The part you are interested in is this "terms like “KiB”, “MiB”, and “GiB” ... should be used only in articles that describe IEC 60027-2 directly". I read that to mean, "if the article sources use the IEC prefixes then the article can use IEC prefixes.". If you're interested and if it would change your view to a "support" I would advocate changing the text to read "Unless IEC prefixes are being used in verbatim quoted text, terms like “KiB”, “MiB”, and “GiB”, generally speaking, should be used in articles where the relevant article sources use IEC 60027-2 directly." How does that sound? Fnagaton 21:44, 24 March 2008 (UTC)[reply]
                • I'm really not sure how else it could be read; I honestly mean no offence by this, but I don't actually see how it could be read the way you take it, and as there are some who are just as crazy-ass obsessed with getting rid of the IEC units as some are with using them (and both groups are at least slightly cooked, if you ask me), I'd be willing to bet it would be read the way I describe on a regular basis. I still prefer the alternative proposal below, but with a change along those line, and possibly some others (I need to spend some more time reading it and thinking about it), I wouldn't oppose this one. SamBC(talk) 12:25, 25 March 2008 (UTC)[reply]
              • None of this is locked in stone. It’s a proposal and everything is fair game for modification if it helps to gain consensus. If the wording you cited is ambiguous, then please tell exactly what tweaks you think should be made. I am disinterested in dealing with people who feign being “undecided” and engage in stalling tactics. But I am quite anxious to truly work cooperatively with anyone to build a better policy than what we’ve got now. Greg L (my talk) 21:58, 24 March 2008 (UTC)[reply]
                • I'll get back to you on that later today (I'm in the UK, so it's early afternoon here). That's not a stalling tactic, it's just that I have real-life things that need doing, like MSc work, housework, shopping... :) SamBC(talk) 12:25, 25 March 2008 (UTC)[reply]
  5. Comment Thunderbird2 the proposal does address those concerns about "becomming incomprehensible" as you put it. If you can show me an article that is "incomprehensible" (as you put it) then I'll show you a way within the scope of the proposed guideline that will make the article understood. If you cannot show an article then I think your objection can be changed to a support. Fnagaton 16:28, 24 March 2008 (UTC)[reply]
    There's already a pretty good example of what I meant in the proposal itself:
    • The Seagate Cheetah 15K.5 ST373455LW, “80 GB”[1] hard drive had an actual formated capacity of 73.4 GB and could hold a 2-hour, compressed HD movie with a file size of up to 68.3 GB.[2]
    Am I the only one who is confused by this? To understand it at all I had to read it three times. Is the 73.4 GB "formatted capacity" about file sizes or hard drive size? The reader should not have to work this hard. And that's without introducing the additional complication of data rates. Thunderbird2 (talk) 23:05, 24 March 2008 (UTC)[reply]
    Sorry, I don't understand why you would find that confusing. Care to elaborate? In the context of the quote and according to the disambiguation supplied the 80GB and 73.4GB capacity is using decimal and the 68.3 GB file size is using binary. Not knowing where the "formatted capacity" comes from is not to do with needing to use IEC prefixes per se since that isn't going to help you, more like it sounds like it is to do with not knowing about how file systems work on drives when it comes to storing the bits and bytes. :) It is worth remembering that the difference between unformatted and formatted drive capacity is due to needing to have allocation tables, directory structure and all manner of data not actually used for storing the contents of files. This isn't mentioned in the quote but would most likely be mentioned in the article. I say most likely because I cannot find an actual Wikipedia article containing the text that was in the quote, my Google Fu is weak this evening. Fnagaton 23:39, 24 March 2008 (UTC)[reply]
    I think you are overestimating the knowledge and (mental) gymnastic ability of our average reader. I’m afraid I cannot get my brain to parse the the two different meanings of GB in the same sentence - that is a problem that will arise with any context-based definition, and cannot be fixed by tweaking the sentence - only by restructuring the article to keep the two meanings apart. Then there's that 73.4 GB; without your expert help I am unable to tell whether it refers to a "file capacity" (binary) or a "hard drive capacity" (decimal). And use of an IEC prefix would certainly help, regardless of my ignorance of hard drive formats, because I would then know which ones were gibibytes in which ones were true gigabytes. Thunderbird2 (talk) 00:15, 25 March 2008 (UTC)[reply]
    I see, so even if the article used GiB for the file size the average reader would still not be any the wiser as to why the numbers are different because the numbers are different due to the difference in unformatted and formatted capacity and file system internal workings, not just because they use decimal or binary values. :) The 73.4 GB should be disambiguated with the same footnote as for the 80GB I suppose. Is this text from the quote actually from an article? You see I'm guessing a bit here but in this specific example the article sources would most likely be using GB and not GiB, so this means if the article used GiB then the reader would be saying "WTF is this doing here it's not in the sources?". The article text itself needs to be split here so that the separation between unformatted, formatted capacity and file size is more distinct and obvious along with explanation about file systems etc. The disambiguation with the footnote would then make it clear that these numbers are using decimal or binary values, if the reader is so interested that they need to know the exact numbers these could be included in the article text. But after more searching I still cannot find if this example text comes from an article, so I'm guessing it doesn't and the example text is short so that the guideline doesn't end up having half an article imported into it. :) Fnagaton 00:26, 25 March 2008 (UTC)[reply]
  6. Comment At the risk of giving it the "kiss of death", I support Woodstone's proposal. Thunderbird2 (talk) 17:34, 24 March 2008 (UTC)[reply]
  7. Comment I'm with Thunderbird2 on this, except I'd make one relatively minor alteration. "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units" should be extended with ", nor is there consensus to avoid their use". The sentence then seems a pretty accurate description of the situation - there is no consensus either way and there's no broad agreement. It's getting to the point where we ought just to accept that. SamBC(talk) 20:56, 24 March 2008 (UTC)[reply]
  8. Comment As editors, I think some of us have become too familiar and comfortable with terms like “KiB” and “GiB.” Any honest assessment of reality would show that most readers have never encountered such terms before; not in any computer magazine off the newsstand, nor any owners manual for any piece of computer equipment, nor any advertisement. It doesn’t matter if using these unfamiliar terms makes lives of Wikipedia editors easier because such units have scientific and logical purity. We should use the terminology and methods of disambiguating used in the real world since this is what our readers are accustomed to and comfortable with. The editors and authors of MacWorld or PCWorld write about RAM, hard drives, file sizes, etc. each month and manage to do so in a way that is clear enough for the average reader. So too does every single one of the manufactures who advertise in these magazines. Arguments here that we need to go beyond these real-world communication techniques and use methods that most readers only encounter on Wikipedia amounts to nothing more than trying to solve a problem that exists only in our imaginations. Wikipedia should follow the communications practices observed by influential computer periodicals and other encyclopedias. Just because “the IEC says to” isn’t good enough. The BIPM says we’re suppose to write “75 %” (with a space) but you don’t see Wikipedia following that standard do you? Our policy is to wisely use the convention readers are accustomed to: “75%”. Greg L (my talk) 19:15, 24 March 2008 (UTC)[reply]
  9. Comment I do not support Woodstones proposal because it supports a particular POV. Fnagaton 20:59, 24 March 2008 (UTC)[reply]
    • I'm just interested, what POV do you think Woodstone's proposal pushes, and how are you convinced that Greg's doesn't represent a particular POV? In the absence of authoritative sources, any argument about the real-world acceptance of the IEC units is POV, even if one has better evidence than the other. What I'm getting at is that WP:NPOV and WP:OR apply to articles, not to guidelines and policies; the determining factor for those is consensus, so if there's consensus that what something says is what the policy should be, it doesn't matter if it's OR or POV. (Obviously, that doesn't mean we can freely misrepresent reality, but i think you know what I mean). SamBC(talk) 12:34, 25 March 2008 (UTC)[reply]
    I'm specifically thinking of the sister guideline to this regarding the scientific articles one which effectively says "use the terms found in the sources for the article." That has less POV than Woodstone's proposal about what system to use. Greg's proposal also has less POV than Woodstone's proposal. Fnagaton 12:43, 25 March 2008 (UTC)[reply]
  10. Comment Greg, I think we all agree that many readers will be unfamiliar with MiB. That's why they need to be introduced each time they are used (least astonishment). To your other points:
    • The editors and authors of MacWorld or PCWorld are not writing an encyclopaedia and have no need to make unambiguous statements.
    • By introducing the new prefixes, the IEC is not dictating to anyone, only facilitating.
    • 75% is a red herring because there is no ambiguity either way. Thunderbird2 (talk) 21:04, 24 March 2008 (UTC)[reply]
      • T-bird, if not magazines (and the manufacturers of computer equipment) then shouldn’t we observe the practices of other encyclopedias, like Encyclopedia Britannica? I have to head out now for an errand. Since I don’t own the set of Encyclopedia Britannica, I’ll stop at the library while I’m out and see how they handle it. Greg L (my talk) 21:34, 24 March 2008 (UTC)[reply]
        • Hmm, I'm curious indeed to hear the outcome of your library visit. But, having said that, it will not change my view either way. I have no influence over what is written in Brittanica, but I do here. I think we should simply strive to do our best, which in the end is what we are all trying to do. The fact we all have a different view of what constitutes "best" is a good thing, right? Thunderbird2 (talk) 21:46, 24 March 2008 (UTC)[reply]
          • "The fact we all have a different view of what constitutes "best" is a good thing, right?" I can agree with that statement Thunderbird2. ;) Fnagaton 21:47, 24 March 2008 (UTC)[reply]
          • I went to the library. Encyclopedia Britannica does not use the IEC 60027-2 binary prefixed unit symbols like “MiB” and “GiB”. Instead, they spell out “megabyte” every time they need to reference the unit of measure. Perhaps, this is to help avoid inundating novice readers with too much arcane terminology. Perhaps there is something instructive there for us to think about.

            Note however, that although Encyclopedia Britannica is using the full unit name all spelled out, they are still eschewing the IEC 60027-2 proposal because they are not using the unit name “mebibyte”. No one does. What is even more instructive in all of this is what dictionaries say.

• Microsoft Computer Dictionary 2002 (ISBN 0-7356-1495-4) lists “Megabyte” and says “Abbreviation: MB”
• The three-volume set Acronyms, Initialisms & Abbreviations Dictionary, 25th Edition has entries for “MB” and “GB” (explaining they are prefixed forms of byte), but has no computer-related definitions for “MiB” and “GiB” (although “Gib” has "Gibraltar ” as one of its definitions).
• Finally, the most recent resource from 2006, High Definition: An A–Z Guide to Personal Technology lists “Megabyte” and also states that the abbreviation is “MB” but (again) lists no other alternatives.

It just seems, T-bird, that the IEC prefixes have not found real-world adoption. No one in the industry (manufacturers or any general-circulation magazines) uses terminology like “a 2-gibibyte SIMM card.” I’ve never met anyone since the 1999 proposal who has once spoken that way. Using them in Wikipedia articles, as if “Oh, don’t-cha know, this is the way it’s really done,” (when it’s really not) doesn’t best serve the interests of our readers IMO. Using the IEC prefixes is clearly the way it ought to be done—no doubt about that—because they are unambiguous. But the terms are so rarely, if ever, used out in the real world, no reader can even find them in computer dictionaries. Virtually all Internet readers get their very first exposure to the IEC prefixes here on Wikipedia and have no reason whatsoever to remember them because of their near-total obscurity outside of Wikipedia. In my opinion, that is just so not the proper thing for any encyclopedia to do. When it comes to the very language we use to communicate, Wikipedia should follow current usage, not try to lead by example. The reasons for our continued practice of doing so—no matter how well intentioned—aren’t compelling enough for us to be so eccentric on this. Greg L (my talk) 01:22, 25 March 2008 (UTC)[reply]

Greg, thanks for putting in the legwork. It's appreciated (honest!), but there are couple of statements you make that I would challenge:

  • No one in the industry (manufacturers or any general-circulation magazines) uses terminology like “a 2-gibibyte SIMM card.”

and

  • no reader can even find them in computer dictionaries

I would have phrased these statements in terms of "not many in the industry ..." and "there are not many computer dictionaries" that define them. Is that what you meant? Thunderbird2 (talk) 18:01, 25 March 2008 (UTC)[reply]

  • Virtually no one uses these terms and virtually no no dictionaries have definitions for these terms. Virtually adv.: In practical effect, if not in reality. I can’t prove a negative (no one can) but it is indisputable that the IEC prefixes have been very poorly adopted in the industry. Note however, that my local library had a limited supply of recent dictionaries (the IEC proposal was in 1999 so publications after 2005 would be nice) so I asked the reference desk librarian to help me. We looked up what reference tools were available at the other area libraries. Then she called two other branches and asked their reference desks to look up the terms in the dictionaries they had. T-bird, have you ever met anyone in your life who said something like “I bought a 512 mebibyte thumb drive”?  When I say “no one uses language like that,” I guess I mean “virtually no one uses language like that;” I know that I’ve certainly never encountered it and my best friend is a programmer. He and I designed a variety of microprocessor-based industrial devices when we worked together at another company. Hell, I’ve got a patent on a new algorithm that a microprocessor can use to reverse-calculate the equation of state of non-ideal gases under high pressure; I try to keep up-to-speed on computer technology and am certainly no novice on this stuff. I’m only saying that notwithstanding the shortcomings of the English language and the terminology we have to work with, the terminology used in our computer-related articles should mirror what users encounter in real life and will encounter virtually no other place except Wikipedia. Greg L (my talk) 19:06, 25 March 2008 (UTC)[reply]
  • We live with ambiguity in spoken language all the time, relying on context and interactive feedback to get us out of trouble; written ambiguity is very different. Just for the record, I can think of two on-line dictionaries that define the kibibyte, namely FOLDOC and Wolfram. As far as the computer industry is concerned there are parts of it that try to be unambiguous (see binary prefix for a list). From my own experience I would add Ubuntu; I'm sure there must be other examples. Thunderbird2 (talk) 19:24, 25 March 2008 (UTC)[reply]
  • I dare say that literally no manufacturer uses language in their advertisements like “1 gibibyte, 200-pin SODIMM”.

    My point is simple: notwithstanding the shortcomings of the English language and the terminology we have to work with, the terminology used in our computer-related articles should mirror what users actually encounter in real life. If we keep on as we’re doing, we just tend to produce readers who encounter reactions like this (see post #29 in the link) when they try to use the terminology we’re promulgating here. Disambiguating terms like “gigabyte” and “megabyte” can be accomplished easy enough if we set our minds to it; we can look to current literature for guidance. Greg L (my talk) 19:35, 25 March 2008 (UTC)[reply]

  • Manufacturers can't tell the difference between a calorie and a kilocalorie, but I see no one suggesting we should ban the use of "calorie" to mean 4.184 J. Thunderbird2 (talk) 19:45, 25 March 2008 (UTC)[reply]
  • Thunderbird2 did you have a look at your FOLDOC cite? It says "Although this new naming standard has been widely reported in 2003, it seems unlikely to catch on.". And as for mebibyte or gibibyte "Sorry, the term mebibyte is not in the dictionary". ;) As for people who are confused between 1000 and 1024 for these prefixes it goes on to say they are "marketoids" and the definition for that is "Or "marketing slime", "marketeer", "marketing droid", "marketdroid")..." [2] Again I will have to use a ;) at this point. Fnagaton 19:55, 25 March 2008 (UTC)[reply]
  • Yes, I did read it. Blatant POV like "seems unlikely to catch on" would last approximately three milliseconds on Wikipedia. My point was that the definition is there if you care to look for it.Thunderbird2 (talk) 12:25, 29 March 2008 (UTC)[reply]
  • T-bird2, what you’re effectively saying is that it doesn’t matter what the computer manufacturers do in their advertisements, product brochures, packaging, and owners manuals, (because manufacturers can’t even get “calorie” correct) nor does it matter what other encyclopedias do, nor how people really talk and write in the real world. Your position seems to be that the IEC proposal is just simply too meritorious to ignore. That isn’t the right thing to do in my opinion and does our readers a disservice. When Wikipedia adopted its current policy of allowing the IEC prefixes, it didn’t foresee that they would be as poorly adopted as they have been. It is clearly now, time for a change in course. Greg L (my talk) 20:24, 25 March 2008 (UTC)[reply]
  • There are elements of truth in what you suggest, but you make it sound like I’m tucked away in some ivory tower, oblivious of day-to-day events, and I don't accept that. Let me put it in my own words. An encyclopaedia needs to be unambiguous; we should attempt to explain the meaning of (e.g.) MB in such way that it does not confuse our readers. Do we agree so far? I know your intentions are good but I think you underestimate the difficulty of this task. We are faced with a choice between a) the use of an unfamiliar unit (MiB) and b) the double-take of trying to understand that a megabyte in device A is almost but not quite the same as a megabyte in device B, except when it’s travelling between A and B and then it really is the same as in device A (but not B). Which of those two is more confusing? You have one opinion; I have another, and yes, I confess to having made the sentence more confusing than it needs to be most of the time. I do so to make a point. In the end what we all need to accept that it is not a simple task. Why complicate that task even further by tying one hand behind our collective backs? I don’t see the sense in that. My view is that sometimes one solution will work best and sometimes the other. Let’s keep an open mind and permit consensus to develop on an article by article basis. I would support a solution along the lines of “editors need to bear in mind that the IEC prefixes are unfamiliar to many readers and are therefore encouraged to exhaust other means of disambiguation (footnotes or tables or whatever) before resorting to them”. Thunderbird2 (talk) 19:28, 26 March 2008 (UTC)[reply]
  • I think you hit the nail on the head there Thunderbird2 when you said "You have one opinion; I have another" because it all comes down to opinion about what you think is the better choice of prefiex. There is a key difference between you and me and I'll explain what I think our two positions are. On the one hand you think IEC prefixes should be used to disambiguate regardless of what is in the sources for each article. I on the other hand thinks the real world consensus should be used for each article and to disambiguate without pushing any point of view about any particular prefix style which means having to state the number of bytes. That's accurate isn't it? But since we as article writers have to try to be as unbiased as possible then we should leave behind what we think is "the better choice" of prefix, surely you must agree with not pushing a point of view and being unbiased? An editor who is strongly religious should be able to accurately edit an article about genetic research if they leave their religious point of view behind and just go by the facts. Then if the solution is better explained by using IEC then the sources for the article will reflect that consensus then and only then should the article use IEC prefixes. However in the majority of cases the sources that we cite when writing articles will be using KB/MB/GB etc and we should use respect what they use and not push our own point of view about a particular prefix style. Simple really, no? Fnagaton 19:52, 26 March 2008 (UTC)[reply]
  • Also by the way Thunderbird2, did you notice that when installing Ubuntu 7.10 (the latest version) it uses GB for the disk size, not GiB as your link and dschmitt's comment in that link seem to imply. Also when installing if I use the "File Browser" application it shows the properties of files like bzcmp to be "2.1 KB (2128 bytes)" and chgrp "32.6 KB (33416 bytes)" and sh.distrib "685.2 KB (701680 bytes)". Note it is using KB in the binary sense here as well. I'll be happy to take screen shots for you if you wish? Fnagaton 21:03, 25 March 2008 (UTC)[reply]
  • Fnagaton, I’m glad you pointed out yet another authoritative real-world player in the computer world (Ubuntu) that uses “GB” to denote binary math. But let’s not allow ourselves to be corralled so we’re effectively trying to prove or disprove whether or not there are any manufacturers who use the IEC prefixes. Only a common-sense test is of any validity in determining what future MOSNUM policy should be. Too few (if any) manufacturers use IEC terminology like “gibibyte” and too few (if any) general-circulation computer magazines do.

    There are exquisitely good, unambiguous Spanish words for familial relationships (like the mother of my daughter’s husband) that English has no equivalent for. I believe Spanish even has words that distinguish which gender a cousin is as well as whether it’s paternal or maternal relationship. The equivalent terms in English are too few and ambiguous. Still, it would be unwise to use them in an English-language encyclopedia in a routine “oh… didn’t-cha know”–fashion as they would be poorly recognized.

    It doesn’t matter if Wikipedia provides a link to an article explaining what “mebibyte” means, dictionaries and encyclopedias don’t create articles for new words until they achieve a certain measure of ubiquity in real-world usage. Why in the world would anyone advocate that Wikipedia be immune from this common-sense standard? Even though the IEC prefixes (mebibyte, gibibyte, and their unit symbols) are unambiguous, they amount to nothing more than a “proposal that failed to catch on”. As such, they are poorly recognized and are a poor choice to rely upon in Wikipedia. Greg L (my talk) 22:01, 25 March 2008 (UTC)[reply]

  • I'm a bit surprised by all this ranting against something that is not being proposed. It is not proposed to strike all mention of GB (etc). The proposal is to leave as primary unit, the one from the source, which will almost always be GB (etc) according to your statements. Just, because we know that GB is ambiguous, it is requested to disambiguate in brackets or footnotes. It is proposed to add an expression of the quantity as a power of 2 or 10 or by equating or converting it to the IEC units. A reader who is not aware of the meaning of the disambiguating unit can either ignore it or follow the link to the explanation. So their is no question of ignoring what manufacturers and marketeers put in their communications. Just adding an appropriate disambiguation. −Woodstone (talk) 21:09, 25 March 2008 (UTC)[reply]
  • That's not the point and Greg has made it clear what the actual point is i.e. "don't use IEC prefixes to disambiguate when the article sources don't use them". It is completely unambiguous to state the exact number of bytes for disambiguation without needing to push the POV that IEC prefixes can be used. Fnagaton 21:16, 25 March 2008 (UTC)[reply]
    • Um, I wouldn't say that it was POV that IEC prefixes can be used... there's absolutely no reason to suppose that they can't. Shouldn't, maybe, but it's certainly possible to use them. It seems pretty clear here that the situation is that there's no consensus that they should be used, and no consensus to deprecate their use. Now, without formulating a specific proposal from this, do people agree or disagree? I know, I'll start a new section ;) … actually, that's not a bad idea. SamBC(talk) 21:40, 25 March 2008 (UTC)[reply]
  • SamBC , go ahead and start any other proposal that makes more sense than what we have now. With regard to your “[there is] no consensus to deprecate their use”, as if this writing, we’ve been voting and debating for all of 48 hours. 22:11, 25 March 2008 (UTC)
  • If I added something like "only use KB/MB/GB for disambiguation" to the guideline do you agree that would be pushing a particular point of view about what system to use? Fnagaton 21:48, 25 March 2008 (UTC)[reply]
    • Yes, it would; so would something saying only use KiB/MiB/GiB. However, the effect of what Greg actually wrote above is only to use KB/MB/GB (not for disambig), and disambiguate with numbers. The disambiguate with numbers I have no problem with, and the restriction to KB/MB/GB I do; your suggestion below, however, significantly reduces (possibly even eliminates) that concern, and once everyone understands it, I believe consensus could probably be gathered behind it. See my caveat about reviewing it below, though, 'cause I'm not 100% certain yet. SamBC(talk) 12:18, 27 March 2008 (UTC)[reply]
  • Actually there are reasons to say why they can't be used, just look at the guideline on MOSNUM about being consistent with sources. Fnagaton 21:49, 25 March 2008 (UTC)[reply]
  • Well, again, I'd say that's "shouldn't", but then we're getting into semantics... but could you point me to where on MOSNUM that guideline is? SamBC(talk) 21:55, 25 March 2008 (UTC)[reply]
  • here "In scientific articles, use the units employed in the current scientific literature on that topic." Fnagaton 22:00, 25 March 2008 (UTC)[reply]
  • Fnagaton: I note that to accomodate the concerns of Sambc, we’ve made material changes to the proposal. All that text has already been voted on and approved by many others so I am rather disinclined to head down that path unless doing improves the bottom-line metric: vote count towards a consensus. Are you expecting that Sambc will be changing his vote as a result of this? Greg L (my talk) 16:58, 27 March 2008 (UTC)[reply]
  • Yes that change was done to help build some extra consensus from SamBC and maybe one or two others who are floating on the edge. If SamBC (or anyone else) doesn't like the change enough to change their vote to a support or at least remove their oppose I'd advocate putting it back to what it was before my change. I'd definitely like to give consensus a chance so I would like SamBC to have time to think about it though. Fnagaton 17:05, 27 March 2008 (UTC)[reply]
  • Very well. Is there an example article which exemplifies “articles where the primary cited source uses the IEC 60027-2 prefixes”? My concern is that if there are currently no applicable articles, this could be used to circumvent the clear and obvious intent of the policy. Greg L (my talk) 17:14, 27 March 2008 (UTC)[reply]
    • Greg L, I don't understand your question. Are you asking for articles that use k to express 1000? Or are you only talking about the new prefixes like kibi-, mebi-, gibi- etc.? --217.87.90.29 (talk) 19:40, 27 March 2008 (UTC)[reply]
    • Well, that depends what the "clear and obvious intent of the policy" is. Firstly, though, it's a guideline... anyway, but if the intent of the policy is that wikipedia usage reflect real-world usage, now and in the future, then it seems fine to me. If the intent is to ensure that the units are basically not used on wikipedia at all, then I can see it being circumvented, but that certainly shouldn't be the intent. SamBC(talk) 19:54, 27 March 2008 (UTC)[reply]
  • Sambc, my objective is to have Wikipedia reflect real-world usage of terminology and not use terminology unfamiliar to the typical reader that will be visiting a particular article. Per current MOSNUM policy (#Which system to use), one uses the units of measure used in current scientific literature on the subject. I’m not interested in people latching onto that wording and saying “well, the IEC uses it in their internal papers.” General articles on computer subjects should use gigabyte and GB and disambiguate as required because that’s what such readers are used to dealing with and readily accept. There is no need in rehashing all that. This part of it all is abundantly clear in the proposal. Now I’m talking about addressing the various exceptions to the rule under which it is acceptable to still use the IEC prefixes. In this regard, the proposal also stipulates that articles about the bytes and the prefixes that might precede them can (and should) discuss the IEC prefixes. Directly quoted text is also addressed. And now, to ameliorate a concern of yours, articles which heavily rely upon a citation referencing a primary source that uses the IEC prefixes may use the IEC prefixes. If such articles exist, I assume they are geared to a different audience: a scientifically oriented one, an article that is naturally of interest to a particular readership that is already familiar with such terms. This would be in perfect conformance with “#Which system to use”. It would be nice if you could provide me with an example of such an article so I can include it in the proposal text as an example of what is being spoken of. Or are we adding this text as an eventuality because such an article currently does not exist? Greg L (my talk) 20:25, 27 March 2008 (UTC)[reply]
Suggested statement of consensus

This is a suggested point that we can agree on to help us see a way forward, and edit one or more of the proposals, or formulate a new one. It's not a proposal for something to go into MOS, just an attempt to get us to agree on the current state of play.

  1. "There is currently no consensus to prescribe, nor recommend, the IEC binary prefixes; nor is there any consensus to deprecate or proscribe such units."
  2. "There is consensus that the real world usage of these prefixes is limited at best, and therefore that they should not be 'units of choice' in Wikipedia articles in general."

Please indicate agreement or disagreement with either or both of these points; at this point, I am not suggesting debate as to whether either of these positions should be consensus, just trying to see if people agree with what the current situation is. Please don't critique them as overall positions, only as descriptions of the current state of the debate. SamBC(talk) 21:49, 25 March 2008 (UTC)[reply]

Here's another one to help us clarify where we are (or not):

Extra point: There is consensus that IEC units should not be proscribed (banned) or prescribed (usage required).

I think that shouldn't be too controversial. Please note that the lack of qualification means that the pro- and prescription are meant as complete. SamBC(talk) 13:27, 26 March 2008 (UTC)[reply]

Agreement, disagreement, and discussion:
  • Disagree - I do not agree with the first statement above since it doesn't accurately portray what the consensus is. The second statement, while being nearly accurate, doesn't actually help solve the problem of pushing POV in the guideline. Fnagaton 21:55, 25 March 2008 (UTC)[reply]
    • You would say there is consensus for any of those four things? Which one(s)? Remember that I'm not saying what consensus is in that statement, rather what the consensus isn't. SamBC(talk) 21:57, 25 March 2008 (UTC)[reply]
      • In the current text of the guideline, which is currently the most recent and completed test of consensus. Fnagaton 21:59, 25 March 2008 (UTC)[reply]
        • The very fact people are debating this indicates that the current text is (probably) not in line with consensus – consensus can change. This debate is the most current measure of consensus. Appealing to the current text of the guideline is, essentially, meaningless. There are, by my last count, three people actively arguing for IEC prefixes to be permissible in a "if you've got good reason" sense, or even more permissible than that, and two people arguing to almost-never use them. That doesn't sound to me like a consensus either way. SamBC(talk) 22:11, 25 March 2008 (UTC)[reply]
          • Until the debate has reached a conclusion I wouldn't want to try to predict what the new consensus is going to be. Citing the current text is not meaningless at all, the current text is the only reliable evidence at the moment. I count eight support and five oppose and each of those people have played or are playing an active part in the debate. Fnagaton 22:23, 25 March 2008 (UTC)[reply]
            • My response to Greg below covers this; quick summary, I think my intention here has been misinterpreted, despite my (clearly insufficient) attempt to clarify the goal.
    • This isn't about solving any problems, POV pushing or otherwise, just about establishing where this debate is now. SamBC(talk) 22:11, 25 March 2008 (UTC)[reply]
      • Well you could help me understand what you think (therefor ehelp to establish where the debate is) by giving me reply for this question and to give feedback on what you think would imrpove the "deprecate IEC prefixes" thing you pointed out earlier.  ;) Fnagaton 22:23, 25 March 2008 (UTC)[reply]
  • Disagree (obviously) SamBC, as we have only been voting on the hybrid proposal for 48 hours, this is entirely premature; these things go on for weeks. You seem to be overly anxious to suggest that a conclusion had been reached as regards a consensus. While you are no doubt well intentioned here, given the fact that you voted “Oppose” on the above proposal makes me question your objectivity here. You are free to advance another proposal to see if it becomes wildly embraced. But please stop trying to imply that other proposals have reached a final conclusion when they have really only just started. Your proposed declaration is only an accurate statement of where we’ve been in the past. Greg L (my talk) 22:40, 25 March 2008 (UTC)[reply]
    • Okay, you've both misunderstodd my intent here, and I'm prepared to accept that's because I didn't make it clear. I'm not trying to say what the result is, and not trying to put anything in MOSNUM (that part I definitely made clear). All I'm trying to do is get people to step back and look at where we are now in the debate. Agree and accept where we have common ground and where we haven't. The reason I felt this worth doing is because the debate has gotten a little tangled and there seems to be some confusion as to who is supporting what position, including, it seems, a feeling that at least one good-faith user supporting each of several relatively extreme positions that, I get the feeling, no-one actually supports. See my new point above for another attempt in that direction... SamBC(talk) 13:24, 26 March 2008 (UTC)[reply]
    • It's also useful sometimes to isolate what we want any new text to do and to mean before we try to draft it, especially when the text is obviously going to end up fairly complex. I have some experience of this both on and off wikipedia. SamBC(talk) 13:24, 26 March 2008 (UTC)[reply]
  • Sambc, your effort at clarification only further baffles me. Why would you write “There is consensus that IEC units should not be proscribed” when the new draft policy, which calls for precisely that, is obviously gaining consensus? Also, I can not understand why you would write “It's also useful sometimes to isolate what we want any new text to do and to mean before we try to draft it, especially when the text is obviously going to end up fairly complex” since it is clear that the proposed policy (the light-green section titled “Binary prefixes in computer memory and storage”) isn’t a description of a kinda-sorta direction of where we might like to go (if the proponents and opponents could only agree on the nasty little details); it is the policy that would replace the current one (4.3.1 Binary Prefixes). Aluvus captured the essence of what the new draft policy portended when he wrote “This is a proposal that would effectively eliminate the IEC prefixes from Wikipedia, period. No sense in dancing around that.”  That’s why the voting and discussions here have been so heated: the new policy is blunt, in-your-face, unambiguous, calls for existing articles to be revised, and describes precisely how to accomplish that end. I think the policy accomplished all that without its text “ending up fairly complex.” Greg L (my talk) 17:22, 26 March 2008 (UTC)[reply]
    • It seems strange to say that it is "gaining consensus" when there are several good-faith editors with reasoned arguments (that you happen to disagree with) who aren't happy with it... I was just trying to take a step back and figure out what we do and don't agree on, my belief being that there's more that we agree on than we really realise. SamBC(talk) 11:58, 27 March 2008 (UTC)[reply]
    • Also, the proposal doesn't proscribe them; it allows them in verbatim quotes (and ought to allow them in paraphrases to boot, in my view) and in articles about the units. That's more deprecation than proscription. No-one has suggested proscribing them, and no-one is suggesting prescribing (mandating) them either; sounds like consensus to do neither of those things to me. SamBC(talk) 12:00, 27 March 2008 (UTC)[reply]
    • Finally (I hope), the reason to figure out what we want something to say and mean before drafting it is shown by the considerable debate above about what the proposal actually means (eg, are IEC prefixes allowed anywhere except quotes and articles about them). If people disagree about what it means, how can there be meaningful agreement of its acceptability? SamBC(talk) 12:03, 27 March 2008 (UTC)[reply]
  • Does, the new wording:
In acknowledgment of this reality, it is no longer permissible on Wikipedia to routinely use the IEC 60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage. It shall remain, however, acceptable to use the IEC 60027-2 prefixes in verbatim quoted text, articles where the primary cited source uses the IEC 60027-2 prefixes, and articles that describe the IEC 60027-2 prefixes directly (such as Binary prefix, Kibibyte, Kilobyte, Byte, etc.).
…address your concern over what the proposal actually means? Greg L (my talk) 18:50, 27 March 2008 (UTC)[reply]
  • P.S. However, I rather like your point #2 above. I think if MOSNUM had that policy in place a year ago or so (and all editors had adhered to it in the spirit intended), we wouldn’t be where we are now. Greg L (my talk) 01:10, 26 March 2008 (UTC)[reply]
  • After thinking it over today and in the interests of trying to move this forward somewhat I'd like to propose the current proposed guideline text be tweaked slightly to be more like "Unless IEC prefixes are being used in verbatim quoted text, terms like “KiB”, “MiB”, and “GiB”, generally speaking, should only be used in articles where the sources use IEC 60027-2 directly.". The idea behind this tweak is to refute those that are saying "it removes IEC prefixes" because obviously the proposed text still allows IEC prefixes but only where the real world consensus allows them. For most articles, like Commodore 64, IEC prefixes would still not be allowed by the proposed text. Also then if anyone objects because of the "IEC prefixes being deprecated" then it would show they are more interested in not being objective and pushing their POV over real world consensus. I don't think this change would affect of the support votes so far? Fnagaton 17:45, 26 March 2008 (UTC)[reply]
    • I like this. The "generally speaking" gives leeway for cases where there's a good logical reason not predicted by the text, and the reference to sources means that real-world consensus is represented; this is good, because real-world consensus could change, and this gives us a measure of future-proofing. I'd want to read over the tweaked version in full before deciding whether I fully support it, though. SamBC(talk) 12:12, 27 March 2008 (UTC)[reply]
      • SamBC I agree with you that real world consensus could change. I've made a tweak that uses the change we have discussed. Fnagaton 13:03, 27 March 2008 (UTC)[reply]
That is definitely the most extreme formulation so far. Instead of working towards consensus you are working away from it. This is totally unacceptable. −Woodstone (talk) 19:57, 26 March 2008 (UTC)[reply]
You are wrong because what I have just proposed is a bit more flexible for the reasons I already gave. So do not misrepresent what I wrote, instead I encourage you to be objective and then if you still cannot write with something constructive then you should not write anything at all. Fnagaton 20:02, 26 March 2008 (UTC)[reply]
I'm not sure that Woodstone was referring to your suggestion; the indenting is ambiguous; he might have been talking to me. Woodstone, care to clarify? If it was addressed to me, that means that I managed to be so unclear that both sides of the debate thing I'm veering heavily to the other side, which is slightly amusing... SamBC(talk) 12:12, 27 March 2008 (UTC)[reply]
Alternative Proposals

I propose a balanced formulation as follows:

Binary prefixes

{{Quantities of bytes}}
Quantities of bits or bytes in computing are sometimes expressed in binary numbers (powers of 2) and sometimes in decimal (powers of ten). As a consequence there are two different de facto standards for using symbols K, M, G (representing prefixes kilo-, mega- and giga-, respectively), one in powers of 1024 (210), and the other as in the SI prefixes, using powers of 1000 (103). To attempt to resolve this ambiguity, the IEC introduced new prefixes including kibi-, mebi-, gibi-, and symbols such as Ki, Mi, Gi in 1999 to specify binary multiples of a quantity. These replacements for the historical units have gained only limited acceptance outside the standards organizations. Most publications, computer manufacturers and software companies continue to use the historical binary units (KB, MB, GB). Note that the prefix for 1000 is a lowercase "k"; some publications use an uppercase "K" to indicate the prefix for 1024.

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 a quantity means binary not decimal units in the material at hand before disambiguation. When this is certain, values from sources can be disambiguated in brackets using explicit bit or byte quantities, or IEC prefixes. For example:

  • "597 MB (597×220 bytes)" or
  • "597 MB (597  MiB)" or
  • "626 MB (626×106 bytes)" or
  • "626 MB (597  MiB)"

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. Alternatively, footnotes may be used to indicate the right interpretation of the units given.

−Woodstone (talk) 17:20, 24 March 2008 (UTC)[reply]

Discussion of hybrid proposal

The proposal does not provide for using KiB and the like within quotations. --Gerry Ashton (talk) 01:03, 21 March 2008 (UTC)[reply]

  • Exactly. And why is that the case? In part, because the proposal includes the following text: “Disambiguation should be implemented in a fashion that avoids use of terminology that would be poorly recognized by the typical reader.”

    Gerry, there is no point relying upon a term that is unambiguous in its definition but is unknown by most readers. When that’s the case, the purported reason for adding the parenthetical—to explain—does nothing of the sort and is effectively just asking the reader to remember unfamiliar terminology that will only be encountered on Wikipedia. Please enumerate for me, all the computer magazines that routinely use “GiB.” 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. This is the central tenet of this proposal. You’ve made your feelings clear but we will just have to agree to disagree if you feel otherwise Gerry. Greg L (my talk) 01:35, 21 March 2008 (UTC)[reply]

  • P.S. When you wrote “…KiB and the like…” what exactly are you referring to? I think I used all the good alternatives in my proposed examples above. Are there some other good ones (besides IEC 60027-2 binary prefixes) we should know about? If so, make them known and we’ll add them to the above examples. As long as it’s a well recognized term, it is suitable for use as a parenthetical explanation intended to clarify. Greg L (my talk) 01:45, 21 March 2008 (UTC)[reply]
It is generally considered improper to change a quotation. If we wish to quote someone who chose to use KiB, or any of the other IEC binary prefixes, we have to keep the unit in the quote. Your reply seems to have nothing to do with this situation. --Gerry Ashton (talk) 02:31, 21 March 2008 (UTC)[reply]
  • D’oh! A thousand pardons, I misunderstood what you wrote although it was perfectly clear. For some crazy reason, I thought you were proposing to disambiguate as follows “The hard drive has a formated capacity of 73.4 GB (68.3 GiB).” In other words, I thought you were proposing to use the term in parentheses. To be conservative with space here and keep things tidy, I’ll go back up and add some wording to address this oversight. Let it hereby be known to all that my first draft of the hybrid proposal did not address this issue of quoted text until Gerry correctly pointed out the omission. Greg L (my talk) 03:28, 21 March 2008 (UTC)[reply]
  • If anyone else has a comment to add here over the next 24 hours, you may have to take care to write with extraordinary clarity so even I can understand your point. Judging from the above, it is clear my mind isn’t hitting on all two cylinders. Greg L (my talk) 03:52, 21 March 2008 (UTC)[reply]
  • What is this a hybrid of, and in what sense? It is simpler to just describe what you intend to change from the existing guidance: never use IEC prefixes unless you are forced to do so, and disambiguate with footnotes. I suppose that is the logical conclusion of the long, brutal "process" we have seen on this issue up to this point. I am not sure how you think you are avoiding the matter of existing articles in any way; your proposal basically spells out that IEC prefixes must be purged. This is a proposal that would effectively eliminate the IEC prefixes from Wikipedia, period. No sense in dancing around that. Previous proposals have generally not gone that far because their authors realized how much opposition there was to that idea. And what is this about "hidden agendas"? — Aluvus t/c 04:45, 21 March 2008 (UTC)[reply]
  • It’s a hybrid in the sense that I was trying to capture elements from Fnagaton’s proposal of 08:58, 20 March 2008 (UTC) and Christoph Päper’s 13:17, 20 March 2008 (UTC) proposal. The “hidden agenda’s” issue arose from a 17:19, 20 March 2008 (UTC) posting by Fnagaton who wrote “Except the bits where it calls units "ambiguous" and rationale which is POV and the bits that open the doorway for adding IEC prefixes to articles that don't use them.” That, in context with prior writings up to that point, indicated to me that Fnagaton was skeptical about wording that might allow use of the IEC units because he felt that if given an open door, some editors would. However, it was my feeling that this concern was unwarranted and there were no hidden agendas to exploit loopholes as he feared. My interpretation of Christoph’s use of the term “ambiguous” was that he was simply trying to describe the obvious: that terms like “MB” and “GB” are ambiguous, and that is why we need to disambiguate them somehow. Please take note of how I explicitly acknowledged the ambiguity of “MB” and “GB” in my proposed hybrid, or merged, version.

    As for your statement, “I am not sure how you think you are avoiding the matter of existing articles in any way,” I’m not trying to and I haven’t the fogiest idea how you could come to that conclusion if you had read my proposal in full. I clearly stated as much in the preamble leading into the proposal, which reads as follows:

All, I’m (Greg L) going to take a stab at a hybrid proposal for us to discuss. I’m going to start out short and simple for a variety of reasons: 1) it will keep me from getting too invested into my own work since there will be little of it, 2) I want to reserve the potentially more contentious issue of revising existing articles until after a consensus has been reached on where we want to go with new articles, and 3) I am going to use head-on, direct language to demonstrate that others have no hidden agendas to keep on using IEC terms like “MiB” as Fnagaton fears.

…and then concluded with this text:

Given this policy, current articles that use the IEC 60027-2 prefixes…

Between the preamble and the last sentence, which I cut off right in the middle with the ellipsis, it should be abundantly clear that I fully well intend to address how to handle current articles—after we have reached an agreement on the basic principals here. Otherwise, we’re fritting away on details when we haven’t reached an agreement on the essential elements of what we’re trying to accomplish.
As for your “your proposal basically spells out that IEC prefixes must be purged”, well said. I perceived there was a whole bunch of beating around the bush in the above discussions and it was time for all that to end. If I’m going to spend hours on this issue, I’m not going to waste anyone’s time by using U.N.-style, ambiguous diplo-speak that can be interpreted any way one wants. I think what I’ve got explains the rationale clear as glass and then goes on to implement that rationale precisely as one would expect. No beating around the bush. Yes?
The IEC prefixes are damned poor units of measure to use in numerical equivalencies describing the capacity of computer memory and storage. Why? While they certainly have the virtue of absolutely unambiguous definitions, they are unrecognized by most readers and this makes them entirely unsuitable for any encyclopedia. When editors use them, we are effectively just asking the reader to remember unfamiliar terminology that will only be encountered on Wikipedia. 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 must reflect common language usage, not try to promote change by prematurely adopting proposed units of measure that no other encyclopedia, computer magazine, or computer-equipment manufacturer uses. Current MOSNUM policy is clear: “In scientific articles, use the units employed in the current scientific literature on that topic.” It was an error to have allowed the IEC 60027-2 prefixes be used here in Wikipedia before first waiting for them to become widely adopted in the industry.
Aluvus, the proposal isn’t anything other than what it seems to be on the surface. If you disagree with it, say so. Please argue with the proposal, not the process that brought about the proposal; it’s still a work in progress—a draft. But if you disagree with it, please then explain why using terms that aren’t well recognized by readers and aren’t generally used in the industry is such a good practice to embrace. If your disagreement goes even deeper than that, and you disagree with its basic premiss and the facts underlying it, please enumerate for us, all the computer magazines, owners manuals, and advertisements that routinely use “GiB” instead of “GB”. If you’ve got a suggestion to improve what’s already here, as Gerry Ashton did, let’s hear it. If you are in basic agreement with the policy as it applies to new articles but have reservations about its implications for existing ones, say so; we haven’t even gotten to that stage yet. Greg L (my talk) 06:17, 21 March 2008 (UTC)[reply]
In the interests of trying to build consensus I support Greg's proposal (with the tweaks). This is because 1) It closes the doorway for some users wanting to sneak in IEC prefixes where they are not being used by article sources, therefore is helps to maintain consistency with real world consensus. 2) It contains much less POV. 3) It improves upon the current guideline a great deal. 4) I agree there has to be no beating around the bush that IEC prefixes must be purged because they are unrecognised by most readers which makes them completely unsuitable for Wikipedia. And now I really do start my Easter break. ;) So I will be out of action for a while. But please can we use the term "mathematics" and not "math" in the proposal? :) I appreciate the time you have spent on this subject Greg, it is not an easy choice of guideline to debate. Fnagaton 08:26, 21 March 2008 (UTC)[reply]
  • Thanks Fnagaton, the two sentences in the draft proposal that used to read similarly to this one: “Generally speaking, it should be assumed that file size and transistorized computer memory (DRAM, SRAM, etc.) are quantified in binary math” now end with “…are quantified using binary mathematics.” Greg L (my talk) 17:04, 21 March 2008 (UTC)[reply]
While I really appreciate the polemic that rehashes the exact same arguments we have seen on this page dozens of times, it has nothing to do with anything. I am getting the distinct impression that you have stumbled on this issue, did not read any previous discussion (and I don't blame you; it is really, truly horrible), and now believe you come to us with the One True Solution to this matter. But what I think you have missed entirely is that the "beating around the bush" and complexity of this issue arise because people disagree about how it should be handled. There are people that want to eliminate IEC prefixes from the project entirely, and people that want them used in every appropriate context, and people that fall in between. The "beating around the bush" comes from compromises, not all of which were wise, that were meant to secure some kind of relative peace.
One of the major roadblocks seen in previous discussion is people that answer specific comments with rambling, off-topic polemics. It has stalled numerous discussions, and actually led to at least one editor entirely leaving the project out of disgust. If you genuinely want to help "solve" this issue, please avoid that tactic. It does not do anyone any good.
But back to the original topic. There is no hidden agenda in my previous comment, if that is what you are hunting for. Your original description of this proposal was completely unclear as to what the proposal was, (these tend to pile up, and a brief summary is very valuable) and indicated you thought you had somehow put off dealing with the issue of existing content. But that makes no sense; your proposal says, in short, "never use IEC prefixes". That seems to speak pretty clearly to the matter of existing content.
I consider this proposal less bad than many that have come before, and an improvement on the current guidance. That is only because I dislike the "split the baby in half" solutions, and because there is a possibility that this would actually settle the matter for more than a month. But your little tirade was certainly not endearing. — Aluvus t/c 06:29, 22 March 2008 (UTC)[reply]
  • All: Let’s wait two or three more days for additional comments on the current portion of the draft proposal, which addresses the fundamental principals of this issue and where we want to go with new articles. Then we’ll go onto the issue of how to handle current articles; there’s no avoiding it. Note that I have never had a hand in writing any of the computer-related articles; I just happened upon a few (where I saw “MiB” and didn’t know what it meant). Accordingly, I have only the most general idea of the hot-button issues editors must be facing when an article is revised by another. I ask that between now and then, you be thinking about what it is about the current revision process that most needs fixing and what you’d like to see in a formal policy. Greg L (my talk) 18:31, 21 March 2008 (UTC)[reply]


  • P.S. At the end of the current proposed policy, in the form of a hidden editors note, is notional verbiage for bringing current articles into compliance with this policy. It’s a starting point for what I’m thinking about at the moment anyway. I hope to receive input from you all. To see the notional text, click here to go to edit mode in the relevant section. Scroll down about half way in the edit window to find it. Greg L (my talk) 21:38, 21 March 2008 (UTC)[reply]
  • I oppose any proposal deprecating use of the IEC units. The current wording on them is already quite negative and I see no reason to totally ban them. They are still a professionally recognised standard and an excellent way of disambiguation. The current text was reached after long discussions and should not be upset quickly without a very clearly established wide consensus. −Woodstone (talk) 15:01, 22 March 2008 (UTC)[reply]
  • Heavens, I'm trying to work out why Alvulus is being so hostile towards Greg L and his proposal. The use of language such as "ram this through" is degrading the debate. I see no reason why the vote is premature; Alvulus, you can have your say here, if you want to, but please be more measured and depersonalise the issue. Tony (talk) 08:24, 23 March 2008 (UTC)[reply]

Attempt to find out where everyone stands on separate points

So, here's some statements. Under each one, it would be useful if anyone who feels themselves involved in this debate indicate whether they agree or disagree with the statement. Hopefully, they';ll be no need in this section to say more than that; hopefully we can leave subtle distinctions for now, and caveats will be covered by the other points. However, if you really need to say more, then that could make sense; there's just no need to explain why you agree or disagree here. I've indicated my own views through these. If you want to add an extra statement, go right ahead. Just to note, this time I'm not asking people to judge where there is or isn't consensus, just to give their own views.

The rationale here is that I'm fairly convinced that we've gotten tangled up and don't realise which things we already all (or nearly all) agree upon. If you don't want to pick "agree" or "disagree", feel free to say "undecided". SamBC(talk) 18:17, 27 March 2008 (UTC)[reply]

These statements are not sufficiently unambiguous and are inviting applying improper conclusions. --217.87.90.29 (talk) 19:49, 27 March 2008 (UTC)[reply]
Really? Part of the idea was that they aren't (all) mutually exclusive, so subtleties can be indicated by combinations; but I feel that, if they're read for no more than what they say, they're pretty clear. Could you give a counterexample?
Some of the comments added confirm that these statements are problematic. For example, the sentence "IEC units should not be used in the general text of an article, but are an ideal choice for disambiguation" combines two statements. This is certainly valid but complicates things and people may agree on this statement but still disagree on the meaning because they understand them differently or apply differing emphasis. I don't see the necessity to combine these two and the use of "ideal" is not ideal either. The statements added by Thunderbird2 are better (albeit not perfect either) because they are shorter and straight-forward. I find it perfectly valid to point out flaws without providing better alternatives, as long as the arguments are valid. --217.87.66.130 (talk) 16:22, 29 March 2008 (UTC)[reply]
IEC units shall not routinely be used, except in quotes, articles specifically discussing the units, and articles in which they are employed by the primary cited source
  • Question in the interests of comparability, can we read this as being equivalent to the "should be banned" wording, or the "should be discouraged" wording, or neither; if neither, how do you mean it to differ? SamBC(talk) 20:07, 27 March 2008 (UTC) The new title is as close to what the proposal actually calls for as I can make it. As this is essentially voting on the proposal, I think it is fair to assume that the votes below, if everyone weighed in here, would reflect what is seen in the above voting. Greg L (my talk) 23:12, 28 March 2008 (UTC)[reply]
  • Agree Greg L (my talk) 18:28, 27 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 18:40, 27 March 2008 (UTC)[reply]
  • Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)[reply]
  • Disagree Tom94022 (talk) 05:11, 28 March 2008 (UTC)[reply]
  • Agree Fnagaton 16:41, 28 March 2008 (UTC)[reply]
  • Disagree LeadSongDog (talk) 23:47, 28 March 2008 (UTC)[reply]
  • Disagree Dpbsmith (talk) 23:50, 28 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
By the way, if you click on this link: [edit], you can vote in all these segments in a single session. Greg L (my talk) 22:51, 28 March 2008 (UTC)[reply]
  • Disagree, mathematical conversions to different units of measurement are always allowed, and well that they should be, here and elsewhere. The use of an ambiguous unit over an unambiguous one does readers a tremendous disservice. Seraphimblade Talk to me 15:07, 29 March 2008 (UTC)[reply]
  • 'Disagree, obviously. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
IEC units should be banned from wikipedia outright, except where policy would require their use
IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves
IEC units should be discouraged, except where they are widely used by the sources for an article
  • Question What I mean is that there's a world of difference between deprecating IEC prefixes and encouraging alternatives. Which is intended here? Thunderbird2 (talk) 23:27, 27 March 2008 (UTC)[reply]
    • Answer My dictionary defines "discourage" as "show disapproval of". Thunderbird2 (talk) 23:40, 27 March 2008 (UTC)[reply]
    • Answer the general meaning of this is meant to be basically the same as the extra point added by Greg. It's probably my worst-worded point, actually. Basically, by discourage I was meaning to indicate that we might say "don't use these without some good reason". Like "should not generally be used", followed by the exceptions that are seemingly accepted by even the most anti-IEC participants here (ie direct quotes, articles talking about the IEC units, and articles whose sources use IEC). SamBC(talk) 00:14, 28 March 2008 (UTC)[reply]
  • Agree SamBC(talk) 18:17, 27 March 2008 (UTC)[reply]
  • Conditionally If the proposal isn’t adopted, this is a good first step. Greg L (my talk) 23:15, 28 March 2008 (UTC)[reply]
  • Undecided My position on this depends on how you define "discouraged". Thunderbird2 (talk) 18:46, 27 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 23:46, 27 March 2008 (UTC)[reply]
  • Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)[reply]
  • Disagree Tom94022 (talk) 05:12, 28 March 2008 (UTC)[reply]
  • Agree Fnagaton 16:42, 28 March 2008 (UTC)[reply]
  • Disagree LeadSongDog (talk) 23:51, 28 March 2008 (UTC)[reply]
  • Disagree Dpbsmith (talk) 00:00, 29 March 2008 (UTC)[reply]
  • Disagree, conversion of units of measurement is a simple, factual, indisputable mathematical task and has never been forbidden, even if sources may use a different measurement type. There's no difference here. Seraphimblade Talk to me 15:04, 29 March 2008 (UTC)[reply]
  • Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
IEC units are good, and should be used wherever feasible
  • Comment Would switch to agree if "should be used ..." were replaced with "may be used where appropriate". Thunderbird2 (talk) 10:07, 29 March 2008 (UTC)[reply]
  • Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)[reply]
  • Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 18:48, 27 March 2008 (UTC)[reply]
  • Agree Jeh (talk) 20:48, 27 March 2008 (UTC)[reply]
  • Disagree I would agree if the work feasible were changed to appropriate.Tom94022 (talk) 05:14, 28 March 2008 (UTC)[reply]
  • Agree if word "feasible" is changed to "appropriate", as with Tom94022. Dpbsmith (talk) 23:50, 28 March 2008 (UTC)[reply]
  • Agree if word "feasible" is changed to "appropriate", as with Tom94022. LeadSongDog (talk) 23:53, 28 March 2008 (UTC)[reply]
  • Agree for the symbols at least. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
IEC units should not be used in the general text of an article, but are an ideal choice for disambiguation
SI-style byte multiples should be disambiguated as appropriate
  • Agree SamBC(talk) 18:17, 27 March 2008 (UTC)[reply]
  • Agree Thunderbird2 (talk) 18:38, 27 March 2008 (UTC)[reply]
  • Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)[reply]
  • Disagree if an SI style multile needs disambiguating that only proves that the IEC version should have been used. Jeh (talk) 20:48, 27 March 2008 (UTC)[reply]
  • Agree Most people have no idea what MB means, the next largest category thinks it means million bytes, only programmers and the like know it might mean something about 1,048,000 (I refuse to calculate the number any more)Tom94022 (talk) 05:17, 28 March 2008 (UTC)[reply]
  • Agree But not disambiguated with IEC prefixes since that doesn't solve the problem, it adds to the confusion by adding virtually unknown terms. Fnagaton 16:44, 28 March 2008 (UTC)[reply]
  • Disagree If the appropriate units are used, no dab is needed LeadSongDog (talk) 23:58, 28 March 2008 (UTC)[reply]
  • Agree. What matters is whether the reader understands what it meant. Dpbsmith (talk) 00:01, 29 March 2008 (UTC)[reply]
  • Agree, if “as appropriate” means if they are used in a binary sense or when there is profound reason to think they could be. OTOH, Jeh has a point, too. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
SI-style byte multiples should be disambiguated at every occurrence, except close repetitions
  • Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)[reply]
  • Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 18:37, 27 March 2008 (UTC)[reply]
  • Disagree per above comment. Jeh (talk) 20:48, 27 March 2008 (UTC)[reply]
  • Agree per above comment, disambiguation is necessary and this could easily be done by defining it as a link each time, e.g. MB and cleaning up the destination pages. Tom94022 (talk) 05:22, 28 March 2008 (UTC)[reply]
  • Agree Dpbsmith (talk) 00:01, 29 March 2008 (UTC)[reply]
  • Disagree if dab means more than a wikilink to the appropriate unit. LeadSongDog (talk) 00:20, 29 March 2008 (UTC)[reply]
  • Disagree. Cluttering is to avoid for readability reasons. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
SI-style byte multiples do not need disambiguation where it is clear that one is speaking about RAM, HDD, etc, where the meaning is generally "obvious"
  • Undecided SamBC(talk) 18:17, 27 March 2008 (UTC)[reply]
  • Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 18:36, 27 March 2008 (UTC)[reply]
  • Disagree It is "obvious" to me that an 80 GB hard drive is 80,000,000,000 bytes, but not to many consumers, and most operating systems further the confusion by reporting it as "75 GB" or so. Jeh (talk) 20:48, 27 March 2008 (UTC)[reply]
  • Disagree Most consumers don't have a clue. They become confused when the operating system reports a different number for a HDD than is labeled on the drive and its box. I also bet they also get confused when they add a 512 MB RAM module and they find the capacity increase is not 512,000 KB. Tom94022 (talk) 05:28, 28 March 2008 (UTC)[reply]
  • Agree Fnagaton 16:44, 28 March 2008 (UTC)[reply]
  • Strongly disagree. I would have agreed a few decades ago when the usage really was consistent. That's not true any more. Usage has changed over time and is, at the present time, inconsistent. Lawsuits over drive capacities show that this is not a moot point. You cannot infer the meaning from context. Dpbsmith (talk) 00:03, 29 March 2008 (UTC)[reply]
  • Disagree LeadSongDog (talk) 00:23, 29 March 2008 (UTC)[reply]
  • Agree. MOSNUM should say where which one is the default. (Actually I’d of course still prefer them to be decimal all the time.) — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]

I added a few more theses with the same objective and following similar principles to SamBC. For "megabyte", read "kilobyte, megabyte etc" and similarly for "mebibyte" Thunderbird2 (talk) 17:18, 28 March 2008 (UTC)[reply]

The word “megabyte” (symbol MB) is ambiguous
The word “mebibyte” (symbol MiB) is ambiguous
  • Agree As shown some people have been confused, therfore it can be ambiguous. It is also virtually unused which only adds to the potential for readers finding it to be ambiguous. Fnagaton 16:47, 28 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 16:40, 28 March 2008 (UTC)[reply]
  • Disagree --Gerry Ashton (talk) 17:31, 28 March 2008 (UTC)[reply]
  • Disagree Just because some folks get confused doesn't mean the term is ambiguous. Tom94022 (talk) 22:34, 28 March 2008 (UTC)[reply]
  • Disagree It may not be “ambiguous” as to its definition, but it is poorly understood and therefore is a very poor tool for communicating to the intended audience. Greg L (my talk) 23:02, 28 March 2008 (UTC)[reply]
  • Disagree It's not ambiguous. It is unfamiliar. A case can be made for defining it on its first appearance in an article, even though you'd think that Wikilinking the first appearance of the term would be good enough. Dpbsmith (talk) 00:05, 29 March 2008 (UTC)[reply]
  • Disagree per dpbsmith LeadSongDog (talk) 00:26, 29 March 2008 (UTC)[reply]
  • Disagree unfamiliar, and occaisionally misused, but well-defined with no variation due to context or whim, so not ambiguous. SamBC(talk) 12:49, 29 March 2008 (UTC)[reply]
  • Disagree, I doubt that your average person knows the precise definition of a mole, either, but it does have a precise definition and thus is unambiguous. The same is true of the binary prefixes. The very purpose of the binary prefixes is to remove the ambiguity inherent in having "kilobyte", "megabyte", etc., mean two different things, one of those things being different than the standard meanings that the average person expects of the metric decimal prefixes. Seraphimblade Talk to me 14:42, 29 March 2008 (UTC)[reply]
  • Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
The word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader
  • Agree Greg L (my talk) 23:02, 28 March 2008 (UTC)[reply]
  • Agree, but it is readily understood from context. Or Wikilinking. Or defining them on their first apperance. The people who express a strong visceral reaction to the terms are not confused by them, they merely dislike them. Dpbsmith (talk) 00:07, 29 March 2008 (UTC)[reply]
  • Agree per dpbsmith LeadSongDog (talk) 00:27, 29 March 2008 (UTC)[reply]
  • Agree Fnagaton 06:00, 29 March 2008 (UTC)[reply]
  • Agree Thunderbird2 (talk) 09:56, 29 March 2008 (UTC)[reply]
  • Agree – dpbsmith's points make sense also... SamBC(talk) 12:50, 29 March 2008 (UTC)[reply]
  • Partially agree, the typical reader or at least the typical computer savvy reader should be able to guess it’s something similar to “megabyte” (MB), especially for the symbol. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
  • Agree TONY (talk) 07:41, 30 March 2008 (UTC)[reply]
The word “megabyte” (symbol MB) is widely recognized by the typical Wikipedia reader
  • Agree Fnagaton 06:29, 29 March 2008 (UTC)[reply]
  • Agree Thunderbird2 (talk) 09:57, 29 March 2008 (UTC)[reply]
  • Depends on intent, if you mean "has heard the term before", I certainly agree. However, I would venture a guess that the average Wikipedia reader does not know that the term is ambiguous and may mean different things in different contexts. Generally, only those with a strong computing background would know this, and that is not the majority of Wikipedia's readership (nor are those the people who would benefit from disambiguation). Seraphimblade Talk to me 14:45, 29 March 2008 (UTC)[reply]
  • Agree on recognized, wouldn’t agree on understood, i.e. I agree with Seraphimblade. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree, caveat as per Crissov and Seraphimblade. SamBC(talk) 19:50, 29 March 2008 (UTC)[reply]
  • Agree, but possibly misunderstood. Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
The word “megabyte” (symbol MB) is not widely understood by the typical Wikipedia reader
  • Comment Based upon my brief and very unscientific survey, I am of the opinion that the typical reader does not even know that mega could be 1,000,000 much less something else. Mega means large to all but technical persons, arguably a small portion of the Wikipedia audience and therefore not typical. Accordingly, any arguments and corresponding remedies based upon lack of knowledge of a prefix or symbol should equally apply to MB and MiB, etc. Tom94022 (talk) 06:21, 29 March 2008 (UTC)[reply]
  • Agree Tom94022 (talk) 06:21, 29 March 2008 (UTC)[reply]
  • Disagree This knowledge even passes the "my Dad test". Fnagaton 06:28, 29 March 2008 (UTC)[reply]
  • Mu this is a subtle and complex question that depends on your precise definition of 'understood'. SamBC(talk) 13:00, 29 March 2008 (UTC)[reply]
  • Comment It also depends on the definition of "typical Wikipedia reader". Thunderbird2 (talk) 14:38, 29 March 2008 (UTC)[reply]
  • Agree, any reasonably educated person with some knowledge of the metric system will (quite reasonably) assume that the prefix "mega" means one million, as it does in megaton and similar terms. Only those with strong backgrounds in computing will know that in computer science it is sometimes used to represent a value other than one million. Seraphimblade Talk to me 14:47, 29 March 2008 (UTC)[reply]
  • Agree — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
  • Disagree—Yup, the Mom test even works. TONY (talk) 07:41, 30 March 2008 (UTC)[reply]
  • Question I seriously don't understand what people are "agreeing" or "disagreeing" on here. SamBC makes an important point that has not been addressed. Does "understand megabyte" mean:
    • "know that a megabyte is a unit used to measure the size of large files on my computer"
    • "know that a megabyte is roughly a million bytes"
    • "know that a megabyte is exactly a million bytes"
    • "know that a megabyte is exactly 10242 bytes"
    • "know that a megabyte is sometimes a million bytes, sometimes 10242 bytes depending on the context"
  • ? We could add 5 more theses to clarify this, but perhaps the originator of the statement (I'm not sure who it was) can clarify the intended meaning. Thunderbird2 (talk) 09:38, 30 March 2008 (UTC)[reply]
Disambiguation of “megabyte” should be encouraged
  • Agree Thunderbird2 (talk) 17:24, 28 March 2008 (UTC)[reply]
  • Agree Tom94022 (talk) 22:36, 28 March 2008 (UTC)[reply]
  • Agree Greg L (my talk) 23:02, 28 March 2008 (UTC)[reply]
  • Agree Dpbsmith (talk) 00:07, 29 March 2008 (UTC)[reply]
  • Agree to the extent of a wikilink LeadSongDog (talk) 00:28, 29 March 2008 (UTC)[reply]
  • Undecided, this partly depends on whether it is being used inconsistently SamBC(talk) 13:02, 29 March 2008 (UTC)[reply]
  • Agree, it should always be clear whether "megabyte" is referring to the value 106 or 220. This is well done by using "megabyte" or "MB" to refer only to 106, and using "mebibyte" or "MiB" to refer to 220, eliminating ambiguity in terminology. Wikilinks are appropriate to serve readers unfamiliar with the difference. Seraphimblade Talk to me 14:49, 29 March 2008 (UTC)[reply]
  • Disagree Fnagaton 16:06, 29 March 2008 (UTC)[reply]
  • Agree, where necessary binary or decimal should be prepended. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
Disambiguation of “mebibyte” should be encouraged
  • Agree Since it is virtually unknown then most readers will find it confusing, so disambiguation is needed. Fnagaton 17:37, 28 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 17:24, 28 March 2008 (UTC)[reply]
  • Disagree However, because it is relatively unknown, its use should always include a hot link to an explanation. That is, it is sufficient to use it as MiB. Same thing for KiB, GiB. We hot link everything we can, it is the perfect solution for these terms since they are unambiguous! Tom94022 (talk) 22:40, 28 March 2008 (UTC)[reply]
  • Disagree The term should only be encountered in articles where it is widely recognized by the intended audience or in articles that describe the IEC units in detail anyway. Greg L (my talk) 23:04, 28 March 2008 (UTC)[reply]
  • Disagree It's not ambiguous, so how can you disambiguate it? Defining it on first appearance might be reasonable. Dpbsmith (talk) 00:08, 29 March 2008 (UTC)[reply]
  • Disagree just link it LeadSongDog (talk) 07:40, 30 March 2008 (UTC)[reply]
  • Disagree – define or link, can't disambiguate something that isn't ambiguous SamBC(talk) 13:03, 29 March 2008 (UTC)[reply]
  • Disagree, definition is desirable and can be established through appropriate wikilinking, but disambiguation is not desirable for a term which has no ambiguity in the first place. Seraphimblade Talk to me 14:50, 29 March 2008 (UTC)[reply]
  • Disagree, explanation by linking to binary prefix or similar, though. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
The best method to disambiguate “megabyte” is to specify an exact number of bytes
  • Agree Or by using power notation for brevity, for example 210Fnagaton 16:49, 28 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 22:11, 28 March 2008 (UTC)[reply]
  • Disagree This is an acceptable method. Tom94022 (talk) 22:43, 28 March 2008 (UTC)[reply]
  • Disagree Different methods of disambiguation are needed in different situations; there is no single “right” way. Greg L (my talk) 23:02, 28 March 2008 (UTC)[reply]
  • Disagree it isn't best, just clearest. LeadSongDog (talk) 00:34, 29 March 2008 (UTC)[reply]
  • Disagree no best method, lots of factors to weigh up SamBC(talk) 13:04, 29 March 2008 (UTC)[reply]
  • Disagree, while it's better than no disambiguation at all, most readers would find this confusing and be unable to relate it to anything. The binary terms and abbreviations are close to the decimal terms, so a reader would (correctly) intuit that "MiB" or "mebibyte" is at least near the value of a megabyte, while likely being confused upon seeing a purely numerical representation. (If used as a secondary method, however, such disambiguation could possibly be useful in some cases.) Seraphimblade Talk to me 14:52, 29 March 2008 (UTC)[reply]
  • Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Neutral Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
The best method to disambiguate “megabyte” is to precede it with an adjective like "decimal" or "binary" ("binary megabyte" or "decimal megabyte")
Specifying an exact number of bytes is an acceptable method to disambiguate “megabyte”
  • Agree Thunderbird2 (talk) 11:36, 29 March 2008 (UTC)[reply]
  • Agree (weakly) SamBC(talk) 13:05, 29 March 2008 (UTC)[reply]
  • Disagree ...
  • Agree somewhat, but certainly not a first choice. Perhaps in a footnote exact numbers could be specified, but in the main body of an article it would be terribly awkward. Seraphimblade Talk to me 14:54, 29 March 2008 (UTC)[reply]
  • Agree A lot less awkward than using virtually unknwon IEC prefixes. Fnagaton 16:06, 29 March 2008 (UTC)[reply]
  • Agree, although it looks stupid to use an abbreviation and then add the expansion. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
The best method to disambiguate “megabyte” is to specify an exact number of mebibytes
  • Agree
  • Disagree Thunderbird2 (talk) 16:43, 28 March 2008 (UTC)[reply]
  • Disagree Fnagaton 16:48, 28 March 2008 (UTC)[reply]
  • Disagree This is an acceptable method. Tom94022 (talk) 22:44, 28 March 2008 (UTC)[reply]
  • Disagree Continued use of “mebibyte” as a ‘disambiguation’ only requires more reading. Greg L (my talk) 23:02, 28 March 2008 (UTC)[reply]
  • Disagree Who'd say "2 megabytes (2*1000000/1048576) mebibytes"? LeadSongDog (talk) 00:38, 29 March 2008 (UTC)[reply]
  • Disagree, even if you mean an approximate number, because there is no best
  • Agreed in some cases, where the binary values would be an exact, round number ("a flash drive with a capacity of 512 MiB"), absolutely. On the other hand, they would be terribly awkward in cases such as hard drive capacity, where the decimal values are the ones with the exact, round number ("a hard drive with a capacity of 200 GB"). However, decimal prefixes should be used only to represent decimal values, never binary ones. Seraphimblade Talk to me 14:57, 29 March 2008 (UTC)[reply]
  • Partially agree, it can be the best one. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Neutral Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
Specifying an exact number of mebibytes is an acceptable method to disambiguate “megabyte”
  • Agree Thunderbird2 (talk) 11:36, 29 March 2008 (UTC)[reply]
  • Disagree it would look very messy. Approximate number of mebibytes, maybe... SamBC(talk) 13:08, 29 March 2008 (UTC)[reply]
  • Comment It doesn't look messy when used for RAM, as in "Model X has 256 MB (256 MiB) of RAM". Thunderbird2 (talk) 14:42, 29 March 2008 (UTC)[reply]
  • Comment: Thunderbird2, this would be counter-productive and may eventually even cause MiB to become ambiguous as it suggests equivalence. I don't think it's clear whether people who accept "Model X has 268 MB (256 MiB) RAM", would also accept your example. Handling of citations may require different rules but if it's absolutely unacceptable to translate a quote, there should be a proper unambiguous footnote, instead of a potentially misleading insertion. I think some question to vote on is still missing: "Terms like Megabyte should be used consistently among all articles". Your example suggests that you are fine with continued dual meanings. --217.87.66.130 (talk) 15:57, 29 March 2008 (UTC)[reply]
    • Reply: I don't like the dual meaning of MB, but as of 2008 it is a fact of life. I don't like it that manufacturers of hard drives are punished for standing up for the original definition of of "megabyte", but that too, sadly, is a fact of life. I don't wish to give the impression that MB and MiB are synonymous though. Feel free to add a new thesis if you think that might help identify an area of consensus. Thunderbird2 (talk) 16:15, 29 March 2008 (UTC)[reply]
  • Comment, as above, the use of whichever value produces a good round number is encouraged, but decimal prefixes should never be used in a binary sense. Seraphimblade Talk to me 14:58, 29 March 2008 (UTC)[reply]
  • Disagree Using virtually unknown units causes more confusion. Fnagaton 16:04, 29 March 2008 (UTC)[reply]
  • Disagree, either “256 MB” or “256 MiB”, maybe “256 MB (binary)” or “256 MB2” but rather not “256 MB (MiB)” and certainly not “256 MB (256 MiB)” or “256 MiB (268 MB)”. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
Specifying an approximate number of mebibytes – e.g. 64MB (61MiB) – is an acceptable method to disambiguate "megabyte"
  • Question: Crissov, could you explain why you agree with this but disagree with the previous statement? As I understand, the example given in the statement is what you considered inacceptable in the previous case. --217.87.66.130 (talk) 18:21, 29 March 2008 (UTC)[reply]
  • Strongly Disagree Decimal MB should rarely if ever be disambiguated to MiB!!!! The only place I can think this appropriate would be where it is necessary to explain the apparent difference, say between an OS MB and an HDD package MB, but in that case it is probably better to disambiguate MB to common decimal units without prefixes. If this said:
Specifying the same number of mebibytes – e.g. 64MB (64MiB) – is one acceptable method to disambiguate "MB"
[Note the Wikilink in MiB]
I would strong support this. Tom94022 (talk) 19:12, 29 March 2008 (UTC)[reply]
  • Comment If you added "agree" then why do you support using a term that does not help to clarify the exact number of bytes? If as some of you were claiming the number of bytes is really important then using a term to round up or down is contradictory. Fnagaton 10:03, 30 March 2008 (UTC)[reply]
    • Reply It is good practice to round any measurement or specification to a suitable number of significant figures, reflecting the precision of that measurement or specification. There is no conflict between this good practice and the use of unambiguous units. Thunderbird2 (talk) 10:24, 30 March 2008 (UTC)[reply]
      • While that might be true for lengths and weights the same it not true for quantities of bytes. Unless you are now admitting that actually the number of bytes is not important? If you are then logically that then means you do not need to disambiguate the term at all since it is safe to leave it as only an approximation to convey to approximate sizes that are being talked about. So which is it? Is it really important to know the number of bytes? Or is the exact number of bytes less important? Fnagaton 10:42, 30 March 2008 (UTC)[reply]
        • I'm afraid I don't understand your point. The only difference I can see is that the number of bytes is a discrete variable, whereas lengths and weights are continuous. I don't recall ever having said that the exact number of bytes is important, although it may be for some purposes. What I have said on a number of occasions is that specifying the exact number of bytes is an acceptable way to disambiguate. The problem with the megabyte is not that it is imprecise, but that it is ambiguous. Thunderbird2 (talk) 11:01, 30 March 2008 (UTC)[reply]
          • You understand the difference between mathematical constructs and lengths/weights, yes? The former has a meaning which is concrete and the later is a form chosen from some arbitrary physical form. So by your own admission disambiguation in this case is not to increase accuracy? (This is because you do not increase accuracy by having an approximate number of disambiguation units.) Fnagaton 11:20, 30 March 2008 (UTC)[reply]
An acceptable method to disambiguate “megabyte” is to precede it with an adjective like "decimal" or "binary" ("decimal megabyte" or "binary megabyte")
  • Agree Thunderbird2 (talk) 17:36, 29 March 2008 (UTC)[reply]
  • Undecided a user would have to already know about the difference, and it would be harder to wikilink than using IEC prefixes. SamBC(talk) 19:54, 29 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
  • Disagree It is inventing teminology when it is not needed and usually not from the sources relevant to the article. Fnagaton 10:00, 30 March 2008 (UTC)[reply]
The best method to disambiguate “megabyte” is by consensus on an article by article basis
  • Agree I see no practical alternative. Thunderbird2 (talk) 10:00, 29 March 2008 (UTC)[reply]
  • Disagree We tried that before, some users (Sarenne) would take their POV to push IEC prefixes to each article creating even more trouble. Fnagaton 16:50, 28 March 2008 (UTC)[reply]
  • Comment I have seen this work in practice. If edits are made without consensus they can be reverted. Where is the problem? Thunderbird2 (talk) 22:36, 28 March 2008 (UTC)[reply]
  • Disagree As this leads to continued use of “mebibyte” as a ‘disambiguation’ that only require more reading. Greg L (my talk) 23:02, 28 March 2008 (UTC)[reply]
  • Disagree Just ducks the issue LeadSongDog (talk) 00:42, 29 March 2008 (UTC)[reply]
  • Undecided, although it's worth pointing out that this is effectively what we're left with "by default" if we can't come to consensus for the guideline; it would be bad to have a guideline indicating a consensus where there demonstrably isn't one. SamBC(talk) 13:13, 29 March 2008 (UTC)[reply]
  • Comment The guideline should not state there is a consensus where there isn't one, but there is a (small) number of points for which there is a clear consensus. These points can be reflected in the guideline. Thunderbird2 (talk)
  • Disagree, in terms of units of measurement, we need a clear, consistent policy for usage which applies consistently on a sitewide basis. Haphazard "consensus" by a few would-be owners of articles is not the way to go; that would create more ambiguity, not less. Seraphimblade Talk to me 15:01, 29 March 2008 (UTC)[reply]
  • Disagree, that’s what we have the MoS for. — Christoph Päper 16:41, 29 March 2008 (UTC)[reply]
  • Neutral Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
"Megabyte" should be consistently used to denote 1 million bytes in all articles
  • Disagree, that would be very difficult to do unless we can be completely sure of the intended meaning in every source, or reject any source that we couldn't be sure of in that way. SamBC(talk) 20:02, 29 March 2008 (UTC)[reply]
  • Comment, "should" isn't "must", so exceptions are allowed e.g., exact citations ("640 kilobyte ought to be...") or product names, but it's not meant to be as lax as "if it's about RAM,,, if it's about HDD capacity". This statement explicitly does not mention whether MB has to be disambiguated and if yes, in which way. Sambc, I'd say if it's not possible to figure out how a source uses these units, the editor should either mention this or the source shouldn't be used at all. --217.87.66.130 (talk) 20:43, 29 March 2008 (UTC)[reply]
  • Comment The trouble with this is that, whether we like it or not, the megabyte is an ambiguous unit. (That's one of the few points that gains 100% consensus here). I don't think it is the role of Wikipedia to go around redefining words. Thunderbird2 (talk) 21:57, 29 March 2008 (UTC)[reply]
Reply Self-standing MB is definitely ambiguous. As an example, it would be possible to add a disclaimer to each affected article, stating that Megabyte is used in accordance with IEC 60027-2 linked to an explanatory article. Just linking Megabyte might be insufficient if there are no inline disambiguations or similar. --217.87.66.130 (talk) 23:53, 29 March 2008 (UTC)[reply]
  • Disagree. In the real world 1 MB can mean both 1,000 KB and 1,024 KB. It is not the job of an encyclopaedia to define it; it should state, with suitable and sufficient references, what definitions are used.Pyrotec (talk) 22:03, 29 March 2008 (UTC)[reply]
Comment If you use 1 MB to denote 1,000,000 Byte, that's not a new definition at all. It is one of the accepted definitions. If you already see the need to state which definition is used, wouldn't you agree that it's most sensible to use the same definition among all articles? --217.87.66.130 (talk) 23:53, 29 March 2008 (UTC)[reply]
  • Disagree I thought long and hard about this. An encyclopaedia should certainly aspire to use units consistently, but the megabyte, like the poor old ton, is a lost cause. Thunderbird2 (talk) 23:05, 29 March 2008 (UTC)[reply]
Comment If you consider the Megabyte a lost case, would you consider Megaoctet as alternative? There are certainly a very few cases where it cannot be used because the bytes have more or less than 8 bits, in all other cases, byte and octet are synonymous. My standpoint is, cherry-picking KiB/MiB/GiB from IEC 60027-2 because they are not conflicting, is fruitless. The binary prefixes are a compromise for certain contexts like those represented by JEDEC. But(!) the important part of this standard is restoring (or establishing if you will) the original meanings of the SI prefixes for the byte unit. It is more important because it's the much more difficult. Unlike the new prefixes it causes conflicts. In my opinion, it is not a valid approach to use a part of the standard and violate it at the same time, certainly not in the same article. If that's the idea, even the status quo is better because we don't need redundant prefixes just to prove we could do better. That would, in fact, border on space-cadetism. --217.87.66.130 (talk) 23:53, 29 March 2008 (UTC)[reply]
  • Disagree, but usage should always be disambiguated Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
"Megabyte"/MB is widely used in non-scientific/non-specialist literature (magazines, advertisements, product specifications) to mean 220 bytes
  • Agree SamBC(talk) 20:02, 29 March 2008 (UTC)[reply]
  • Agree Thunderbird2 (talk) 21:59, 29 March 2008 (UTC)[reply]
  • Agree; but it is also used as 103 x 210 bytes.Pyrotec (talk) 22:08, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
  • Agree on technical merits, sure, it is, but then "cool" or "hot" is often used in such to mean "good" or "popular", and we would never, despite that, use those terms in such a way. This is a formal reference work, those are not, and so we use more formal terminology than ads and magazines. Seraphimblade Talk to me 08:17, 30 March 2008 (UTC)[reply]
"Megabyte"/MB is widely used in non-scientific/non-specialist literature (magazines, advertisements, product specifications) to mean one million bytes
"Mebibyte"/MiB is used very little in non-scientific/non-specialist literature


"Mebibyte"/MiB is, in fact, widely used in all or most areas of writing and publishing to which it is applicable
  • Disagree SamBC(talk) 20:02, 29 March 2008 (UTC)[reply]
  • Disagree Here is a blog from the British Computer Society's web pages gives a computer professionals' perspective on the IEC standard [3]. It is not widely known by computer specialists if this blog provides a representative viewpoint.Pyrotec (talk) 22:26, 29 March 2008 (UTC)[reply]
  • Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
"Mebibyte"/MiB et al are good units that should be encouraged, and wikipedia should "lead the way" in their use rather than follow the real-world use pattern
  • Disagree. That is not the job of an encyclopedia. If you look at Encyclopedia, its purpose is to collect knowledge and disseminate it, i.e. information should be provided about Mebibyte/MiB and about Megabyte/MB. It's function is not to promote the use of one set of units in preference to another (OK we have a preference for SI units, but this is not an argument over Imperial versus metric units, it is about counting, e.g. do we count in twos, or tens - or even hexadecimal).Pyrotec (talk) 22:21, 29 March 2008 (UTC)[reply]
  • Disagree. It's not our job to promote anything. It is, however, our job to be clear, precise, and unambiguous. Dpbsmith (talk) 22:47, 29 March 2008 (UTC)[reply]
  • Disagree Thunderbird2 (talk) 22:57, 29 March 2008 (UTC)[reply]
  • Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)[reply]
  • Not that simple, I don't think it's Wikipedia's job to either lead or follow. However, when a formal reference work is presented with one choice of terminology which is ambiguous, and one which is unambiguous, it should choose that which is unambiguous. Formal reference works routinely use terms which may not be immediately understood by the layperson. Seraphimblade Talk to me 08:19, 30 March 2008 (UTC)[reply]
Articles on technical/specialist subject should use Mebibytes, and more basic or general articles should use Megabytes

There is no basis for a policy that deprecates Binary SI units

Am I missing something, but since, (MOSNUM:Which system to use), requires that editors should use the units employed in the current scientific literature on that topic and since the IEEE Computer Society is one of the leading such publisher of such literature, deprecation seems to be in violation of stated policy and more the POV of a rabid editors such as Fnagaton. This whole thread started when Tbird tried to clarify the existing policy allowing Binary SI units since Fnagton had turned the policy on its head, misinterpreting the plain language of the existing policy to not allow Binary SI units. I for one will not support any policy that deprecates Binary SI units. Tom94022 (talk) 00:17, 22 March 2008 (UTC)[reply]

  • P-u-h-l-e-e-ze! Who are you trying to kid? Do you think the rest of us here are not going to read and parse the logic of what you just wrote? The goal in all technical writing is to clearly communicate to the intended audience with minimal confusion. Do you really expect us to believe that the typical reader of the computer-related articles here on Wikipedia are members of Institute of Electrical and Electronics Engineers or the International Electrotechnical Commission? That’s a metric ton of weapons-grade bullonium and you know it Tom. Other encyclopedias don’t routinely use the IEC 60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage for one reason only: because such symbols aren’t used in the computer industry or their packaging, manuals, or advertising, nor do any general-circulation computer magazines use them. Consequently, the terms are unfamiliar to the typical general-interest reader. This much is just too obvious.

    Finally, as to your characterization of Fnagaton as a “rabid” editor pushing a POV, I suggest you go cool off in a corner somewhere and come back when you have something to add that can remotely be considered as constructive. Greg L (my talk) 02:22, 22 March 2008 (UTC)[reply]

  1. Software and research papers use them.
  2. Fnagaton should have been blocked with Sarenne. — Omegatron 04:05, 22 March 2008 (UTC)[reply]
Your repeated misrepresentation, threats about blocking and personal attacks show that you are continuing use harassment against me instead of tackling the issue. The fact remains you are in the wrong so stop using personal attacks otherwise I will be forced to report you again. Fnagaton 11:05, 23 March 2008 (UTC)[reply]
Please be respectful toward other editors. Tom is correct that the IEEE-CS is one of the leading publishers of scientific articles related to communications and computing (the IEEE as a whole may even be the leading such publisher), and that (not society membership) is relevant to the standard set out in the "Which system to use" text that you yourself have previously cited. I do not know what units are the most common in IEEE-CS papers.
And while I am not singling anyone out, it is a factual statement that a number of editors have been pretty rabid about removing IEC units from the encyclopedia, and some of them have in fact misinterpreted or misrepresented the contemporary wording of MOSNUM to be more strongly anti-IEC than was intended. Virtually any time anything related to binary units is brought up on this page, we hear the refrain of "IEC units must be banned", and then an argument usually ensues. — Aluvus t/c 06:49, 22 March 2008 (UTC)[reply]
  • Omegatron, Regarding point #1, I’m sure that’s true. But you know as well as I do why that’s not enough. As for point #2, that’s water under the bridge and is no relevance to moving forward with developing a MOSNUM policy that makes better sense than what we currently have. Greg L (my talk) 04:13, 22 March 2008 (UTC)[reply]
Greg L, since when do "packaging, manuals, advertising or general-circulation computer magazines" constitute scientific literature? I don't believe the standard is the knowledge of the general purpose reader; my wife, for example, college educated and a competent computer user doesn't know the difference between byte and bit, much less MB vs MiB vs 220B. And given her college experience, she well knows kilo = 1,000. All technical articles run into this problem and need linkages and/or footnotes to help such users. If an editor chooses to use Binary SI prefixes either as first article or for disambiguation, IMO, a link is the best way to clarify the meaning for the "general purpose reader." BTW, I think what i wrote is rather straight forward and doesn't need any parsing, perhaps u should cool down. Also, since at least Omegatron, TBird2 and I don't support deprecating, there is no consensus to change the currently posted MOS, agree? Tom94022 (talk) 05:25, 22 March 2008 (UTC)[reply]
The SI system usually comes under consideration when debating policy here, but WP is under no obligation to follow it. SI is made for numerous modes and registers, whereas WP is purely online and for a wide range of readers. Tony (talk) 07:56, 22 March 2008 (UTC)[reply]
  • You’re taking the “scientific literature” term far too literally Tom. It means the real-world writings the typical Wikipedia reader will likely encounter elsewhere and that obviously doesn’t mean draft standards and policy papers from the International Electrotechnical Commission; that much is just common sense as it applies to “communicating with the intended audience.” The lead-in to the draft proposal laid out the premiss for the policy clearly enough: “The 1999 IEC proposal on binary prefixes (IEC 60027-2) … has not been widely adopted by the computing industry and trade magazines and is therefore unfamiliar to most readers.” In this context “real world” as it applies to our typical reader obviously means all the brochures, data sheets, advertisements, owners manuals, and magazines one encounters in real life.

    Note footnote #1 in the ‘Seagate’ example; I lifted that text verbatim right off the Seagate data sheet for that hard drive. That’s how the “real world” disambiguates the term “GB.” That’s what readers are exposed to in real life. Few knew here at MOSNUM when we permitted use of the IEC 60027-2 prefixes that Wikipedia would effectively be marching off into the snow proudly blowing our “Follow Me!” kazoos, only to find that no one else in the industry nor any other encyclopedia or magazine was inclined to even look out of their cabin windows at us on this one. Wikipedia is alone on this and it’s unwise to continue to embrace such a failed policy.

    Now, having read your argument above, as well as your “straight forward” [sic] words on topics as varied as describing another editor being “rabid”, I think you’ve made your feelings abundantly clear here. You believe explaining the magnitude of values using terms like “GiB” is a good idea and you won’t be changing your mind any time soon. I’ll assume we can mark you down in the “Don’t like this proposal” column. Fair enough? Greg L (my talk) 09:23, 22 March 2008 (UTC)[reply]

You can mark me down as opposing this proposal and any other that deprecates SI Binary Prefixes. By my count there are now four editors so inclined. BTW, you really do need to cool off, "... marching off into the snow proudly blowing our “Follow Me!” kazoos ..." - give me a break. 22:42, 22 March 2008 (UTC) —Preceding unsigned comment added by Tom94022 (talk • contribs)
  • I’m not at all upset up on this. Your unfounded suggestion that I am does not establish you as the wise, cool-headed voice of reason here Tom. I simply think your position on this is unwise and the current policy does readers of Wikipedia a disservice. Note that I haven’t written any computer articles here on Wikipedia so I don’t have a vested interest in this as an editor. I subscribe to several computer magazines and daily read on-line computer magazines. The first time I encountered the IEC prefixes was here on Wikipedia. This is obviously my personal opinion, but my reaction that first time was to to bury my head and say “Oh, geeze” to myself. Embarrassment. Greg L (my talk) 23:33, 22 March 2008 (UTC)[reply]
Tom is correct that your rhetoric and dismissive attitude are not helpful (nor are they new to discussions of this issue). It would be much more productive if you put less effort into denigrating opposing viewpoints and more effort into explaining how advertising is "scientific literature". Additionally, not having worked on any computer articles in the project is not the positive you seem to think it is; if anything, it suggests you may not have had to actually deal with this issue in a meaningful way and undercuts your "I am absolutely right" stance. There are certainly people whose opinion on this issue is colored by their experience editing a subset of Wikipedia's computing articles, but that does not somehow turn a complete lack of experience into a positive. — Aluvus t/c 01:55, 23 March 2008 (UTC)[reply]
  • We’ll have to agree to disagree on how one argues a point Aluvus. There is a big difference between attacking the individual and exposing the shortcomings in his arguments. That how debate is accomplished; you know that as much as I do. I can’t help it if my choosing to avoid authoring Wikipedia articles on computers doesn’t impress anyone; the point is, I’m am not coming into this debate with an agenda to protect prior work. As for “scientific literature”, as I stated before, I withdrew that verbiage from the proposal over 24 hours ago (see the below post) as it just detracts from the obvious point: the IEC prefixes are unfamiliar terms to the typical reader and only adds to confusion. Efforts to obfuscate on this, as others have done by rhetorically asking “what magazines?” (what parallel universe?) will prove unsuccessful in overcoming this obvious reality. Trying to “have it both ways,” as you pointed out, doesn’t work and continued use of terms like “GiB” doesn’t make Wikipedia look proffesional, it makes Wikipedia look foolish IMO. You previously stated that my latest proposal was the “least bad” one you’ve seen advanced so far. Does that mean you are disposed to support it in an up-or-down vote? Greg L (my talk) 03:19, 23 March 2008 (UTC)[reply]
You do not get to "agree to disagree" your way out of WP:CIVIL. And rhetoric about kazoos does not expose the shortcomings in any argument but your own. The entire thrust of your argument appears to be "it is obvious that using IEC prefixes is bad", but the very fact that there is disagreement here should indicate to you that that is not obvious to all parties. Numerous variations of that same tactic, often combined with the same dismissive attitude, have been tried on this page in the past, and they have consistently served to lower the level of the discourse. One of the primary reasons that discussions of this issue have repeatedly broken down is that people have dismissed out of hand any viewpoints they don't agree with, which makes it difficult or impossible to build genuine consensus. And as a final note, it is inappropriate to attempt to pressure me into voting in your favor, and also inappropriate to call a poll on a proposal that by all appearances is still in flux and has not been discussed. — Aluvus t/c 08:15, 23 March 2008 (UTC)[reply]
  • I don’t think I am being uncivil at all. If one reads WP:CIVIL (as I just did). It says “[Incivility] is calling someone a "crank" "moron" or "POV-pusher", among others.” It further specifically defines it as “personally targeted” attacks. I have consistently only gone so far as to ridicule some others’ arguments, not them personally. That is “debate.” I am now taking deep interest in your lack of taking a balanced position throughout this debate. It comes across as having a strong position on this matter while trying to appear that you aren’t. Tom94022 in his 00:17, 22 March 2008 (UTC) post said “[pushing a] POV of a rabid editors such as Fnagaton” (my emphasis). That was so clearly a prohibited and over-the-line, direct personal attack on another editor and was absolutely unwarranted. And I responded (politely) to it. Yet you attacked me for admonishing Tom about his personal attack! In fact, you wrote “And while I am not singling anyone out, it is a factual statement that a number of editors have been pretty rabid about…”. In other words, you called another editor rabid and hid behind the apron strings of civility by stating “I am not singling anyone out…” when it was obvious that the individual being targeted was Fnagaton.

    I’ve noted a strong tendency on this page for you to 1) argue about “how” issues are debated here rather than the substance, and 2) for you to attempt to craft language that looks balanced and measured but really isn’t. You accused me of being uncivil when I clearly haven’t and yet defended and even participated via proxy in the most extreme practices of it. I am done arguing with you about "how” people make their points here—particularly when you try to use slight-of-hand to engage in personal attacks yourself. I will no longer be baited by your diversions. Please stick to arguing on the points. 19:43, 23 March 2008 (UTC)

The nutshell description of WP:CIVIL is: "Participate in a respectful and civil way. Do not ignore the positions and conclusions of others. Try to discourage others from being uncivil, and be careful to avoid offending people unintentionally." When you write "P-u-h-l-e-e-ze! Who are you trying to kid? Do you think the rest of us here are not going to read and parse the logic of what you just wrote?" or "metric ton of weapons-grade bullonium" or "come back when you have something to add that can remotely be considered as constructive", that is not a civil or polite way to deal with people. Ridiculing arguments is not civil and is the crux of why this issue has still not been resolved. I do not claim to be balanced or neutral on this or any other disagreement, but I am damn tired of seeing months-long angry arguments about it that go nowhere or turn into wars of attrition. I will think on what I have previously written; I would encourage you to do the same. — Aluvus t/c 23:02, 23 March 2008 (UTC)[reply]
  • Aluvus, I am quite disgusted with all this arguing with you about "how” people make their points here since recent history on this page shows that you have a far from stellar record in the “civility” department by flat out stating that other editors have been “rabid” and pushing a POV. That is absolutely prohibited behavior. As I stated before, I am entirely disinterested in engaging in all this name calling and I will no longer be baited by these diversions. Please stick to arguing on the merits of the proposal. You seem to be suggesting that the only reason people oppose deprecating IEC prefixes all boils down to “Greg L is a poopy-head in his advocacy and if it weren’t for that, I might support his proposal.” While that might be the case, mark me down as a skeptic on that one. Why don’t you just admit that you like the IEC units and don’t agree with any policy that calls for them to be removed from Wikipedia? I would very much appreciate a statement like that than have to endure any more of your games. Now please take your parting shot below and make it a good one as I will no longer be responding directly to you; it is clearly unproductive and fruitless. Goodbye. Greg L (my talk) 01:49, 24 March 2008 (UTC)[reply]
Attacking me does not accomplish anything. People oppose deprecating the IEC prefixes because they think the IEC prefixes are useful. Your berating those people seems to have done little to change their minds. If anything, it has simply made them oppose you more strongly, just like every time someone else has tried the same tactic before. I have tried to encourage you to actually engage people in discussion, or at the very least to direct your rhetoric at me instead of other participants, so that this might finally be settled. Because I can assure you, if you continue to belittle opposing viewpoints and tell people they should "admit" that they disagree with you, the people with opinions on this issue will just dig in their heels yet again (some of them already have; did you notice?). That usually leads to a protracted, mostly silly fight that in turn leads (at best) to a problematic compromise built on weak consensus, and then a few weeks or months later there is a new spark and the cycle begins again. This has happened over and over again.
  • I for one am tiring of this belligerent, hysterical, personalised approach, Alvulus: I must ask you to desist and to show more collaborative spirit. As far as I can see, Greg has done a fine job in trying to find a solution to this issue, and has shown a good deal more talent and imagination than you, who've done nothing but inject negative sentiment into the discourse. I can't find a scrap of your previous post that I agree with, and as for the edit summary—that's just ramping up you hysteria. STOP IT, please. Tony (talk) 06:03, 24 March 2008 (UTC)[reply]
You have an opportunity to build a stronger consensus and a lasting policy; stop wasting it. — Aluvus t/c 05:34, 24 March 2008 (UTC)[reply]
I agree with Tony that the behaviour of Aluvus is completely unacceptable and disruptive. Aluvus is being uncivil. Aluvus should strike his comments from the page and apologise to everyone and specifically to Greg, Tony and myself. Fnagaton 15:37, 24 March 2008 (UTC)[reply]
  • All: I realize now that quoting “use what’s in the scientific literature” is an ineffective and unpersuasive argument so I deleted it from the proposal. It was pulling the thrust of the predicate off track. As you can see, it now focuses exclusively on the “well… duhhhh” point, which is that if it’s not recognized by the typical reader and isn’t used in the real-world popular press and even the computer industry, it’s clearly of no value in an encyclopedia.

    I also added proposed text that specifically addresses how to deprecate the IEC 60027-2 prefixes from existing articles. I added this because I saw in some of Fnagaton’s writings that this has been a hot-button issue. I don’t know if this is of any real value, but it’s a starting point to build off from (or discard) and is now available for comment. My main motivation for adding it was so that this proposed policy directly addresses the subject of deprecating existing articles and can’t be interpreted as applying only new ones.

    Aluvus: I much enjoyed your 06:29, 22 March 2008 (UTC) post in which you stated…

I consider this proposal less bad than many that have come before, and an improvement on the current guidance. That is only because I dislike the "split the baby in half" solutions, and because there is a possibility that this would actually settle the matter for more than a month.

Although a damn funny way to characterize it, I can see the truth behind it; I suppose that’s what makes it humorous. I hope you still support helping to put this issue to rest once and for all. Greg L (my talk) 09:53, 22 March 2008 (UTC)[reply]
Checking the history Omegatron made this change to the guideline without talking about it here first. The changes are clearly pushing his POV and ignores consensus. The user then started to edit war when his change was reverted and made personal attacks and threats about using blocks to try to make sure his version stayed on the project page. These bad faith actions are documented in the ANI report. 78.150.53.141 (talk) 12:35, 22 March 2008 (UTC)[reply]
I'm allowed to change the guideline without talking about it first. If you have a problem with my edits, you can then change them to make a compromise version that you agree with, or you revert them and then discuss your reversion. After discussion, we understand where each other is coming from and try to change it again, while working together. This is how editing works. See Wikipedia:Be bold and Wikipedia:Consensus. You don't just revert war everything back to your preferred version and claim that it represents community consensus.
And I seriously hope no one's trying to "deprecate" the standardized prefixes on WP. Please don't start that endless argument again. Sarenne was banned for pushing his POV all over the project, and you will be too. There is no site-wide consensus on use of prefixes, so they are decided on an article-by-article basis. In some articles they are appropriate and serve a useful purpose (List of device bandwidths, Floppy disk); in others it is acceptable to use the ambiguous units because they are familiar to that particular field (Commodore 64). — Omegatron 15:11, 22 March 2008 (UTC)[reply]
What do Omegatron's edits more than 3 months ago have to do with anything, Fnagaton? — Aluvus t/c 17:44, 22 March 2008 (UTC)[reply]
What do Omegatron's pathetic threats about "should have been blocked with Sarenne" have to do with this topic? They do not have anything to do with the topic of course, they are personal attacks and must stop.Fnagaton 11:58, 23 March 2008 (UTC)[reply]
Two wrongs do not make a right. — Aluvus t/c 23:02, 23 March 2008 (UTC)[reply]
Now you are using misrepresentation because what I have done is not wrong by any stretch of the imagination, so I demand you retract what you posted because it is untrue insinuation. What I have done is show why Omegatron is wrong and produced a better argument which helped result in the guideline being changed to something he doesn't support. You and Omegatron are in the wrong here as demonstrated by Tony's comment above. Fnagaton 15:34, 24 March 2008 (UTC)[reply]

The current wording is good, but needs some fixes

I made some small changes to neutralize the section, but there are bigger changes to be made that I'm obviously not going to be bold about:

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

The consensus is not to be a fanatic and change everything to your preferred style. There is no reason why you can't change one style to another if there's a good reason to do so, as long as you aren't revert warring or going against the consensus on the talk page of the article you are editing.

and follow the lead of the first major contributor.

Should be removed. This is inherently anti-consensus, as I've explained elsewhere. Without global consensus, you decide based on good reasons, not on arbitrary precedent.

These replacements for the historical units have gained only limited acceptance outside the standards organizations. Most publications

This is biased ("only limited acceptance") and implies a level of certainty that can't exist. How do you define "acceptance"? Most what publications? Do multiple copies of the same publication count? I'm pretty certain most hard drive manufacturer publications use the standard prefixes. Who tallied them all up? What about software? What about the myriad Linux servers hosting all of the web pages you view? I see IEC prefixes on a daily basis. Should we go with your personal experience or mine? — Omegatron 15:48, 22 March 2008 (UTC)[reply]

I support the changes just made by Omegatron. Thunderbird2 (talk) 16:02, 22 March 2008 (UTC)[reply]
I support the changes just made by Omegatron. Tom94022 (talk) 16:47, 22 March 2008 (UTC)[reply]
I oppose the changes —Preceding unsigned comment added by DavidPaulHamilton (talk • contribs) 06:29, 23 March 2008 (UTC)[reply]
I oppose the changes for the reasons stated below by DavidPaulHamilton: The changes to the main page split the baby in half by using prefixes that are unknown to the general population. Greg L (my talk) 18:42, 23 March 2008 (UTC)[reply]
And what specifically do you disagree with? Bearing in mind that the points he raises here and the changes he actually made are quite different, of course. — Aluvus t/c 07:22, 23 March 2008 (UTC)[reply]
The changes to the main page split the baby in half by using prefixes that are unknown to the general population. DavidPaulHamilton (talk) 09:29, 23 March 2008 (UTC)[reply]
The existing wording already did those things, so you have not provided any reason to oppose Omegatron's changes specifically. Omegatron's changes were minor wording tweaks that had no impact on what the guidance actually tells people to do. In what way was the previous wording superior? — Aluvus t/c 22:10, 23 March 2008 (UTC)[reply]
  • Omegatron: You’re setting an unnecessarily high hurdle when you challenge opponents of your view to enumerate every single publication on Earth that uses one style or another. Clearly, a common-sense test should suffice and any quick inventory of the general-interest on-line and in-print computer publications demonstrates that “GiB” isn’t currently being used and that’s why such terms are unfamiliar to most readers. The test shouldn’t be what policy best makes a few Wikipedia editors happiest, it should only be whether or not Wikipedia is best serving the interests of its readers.

    And please leave the formatting and style of the proposal alone. When you deleted all the horizontal rules and made sections within the proposal their own “====” article sections, it made it even harder to discern where the proposal starts and ends, which is already hard enough given the length of some of these threads. Greg L (my talk) 18:48, 22 March 2008 (UTC)[reply]

Oppose - Omegatron's changes to the guideline and those talked about here (as Aluvus said they are quite different) are not an improvement. A couple of direct questions to Omegatron. 1) Why do you make changes to the guildeine without talking about them first? 2) Are you interested in seeing a fair and balanced guideline? Fnagaton 11:00, 23 March 2008 (UTC)[reply]
Let’s try to find some common ground, and tackle this one step at a time. The first edit Omegatron made was an attempt to remove the POV from the opening sentence, which right now reads:
  • In computing, where binary numbers (powers of 2) are often more useful than decimal (powers of ten), the de facto standard for binary prefixes and symbols (collectively, "units") is to use kilo-, mega-, giga-, with symbols K, M, G, where each successive prefix is multiplied by 1024 (210) rather than SI's 1000 (103). To attempt to resolve this ambiguity …
This gives the unwarranted impression that the binary use is more common than decimal. I don't recall Omegatron's precise phrasing, so I'm going to attempt my own. How about:
  • In some fields of computing, binary numbers (powers of 2) are more useful than decimal (powers of ten). In others the reverse is true. As a consequence there are two different de facto standards for defining symbols K, M, G (representing prefixes kilo-, mega- and giga-, respectively), one in powers of 1024 (210), and the other following the SI prefixes convention using powers of 1000 (103). To attempt to resolve this ambiguity …
Constructive comments are requested from, and a happy Easter is wished to, all at MOSNUM. Thunderbird2 (talk) 13:36, 23 March 2008 (UTC)[reply]
I want Omegatron to answer the questions put to him first before I respond to your points Thunderbird2 because the conclusion from what you posted is contingent on what he writes. Fnagaton 16:40, 23 March 2008 (UTC)[reply]
Your first question is a red herring, as it always has been; no one is obligated to get permission on Talk before making minor changes. The second one should be easy for you to resolve yourself by assuming good faith. So no, nothing of any importance really hinges on those questions. If you have an opinion on what Thunderbird2 has written, you may as well get on with it. — Aluvus t/c 22:10, 23 March 2008 (UTC)[reply]
I'm asking Omegatron, not you Aluvus. Unless you are now admitting you and Omegatron are one and the same? As for your answers they are easily demonstrated to be wrong. Firstly look at the header of the project page "Edit this page through consensus, discussing proposed changes on the talk page first." Since the changes he made were not minor, as demonstrated by the fact that you are wrong when you say "no one is obligated to get permission on Talk before making minor changes". Secondly, assumption of good faith is not the catch all answer to everything and my question is a valid concern about what Omegatron wants to see in the guideline. So my questions stand for Omegatron to answer. As I say my responce to Thunderbird2 is contingent on what what Omegatron writes in reply. Depending on what he writes another couple of questions may also be needed. Fnagaton 15:13, 24 March 2008 (UTC)[reply]
For reference, this was actually the second edit he made, and the appropriate diff is here. — Aluvus t/c 22:10, 23 March 2008 (UTC)[reply]
Omegatron made three quick changes, not just the one you linked. Fnagaton 15:13, 24 March 2008 (UTC)[reply]

I was just reading the latest issue of the IEEE Computer Society magazine, Computer. They don't use the IEC binary prefixes. They still use Mbyte and Gbyte. I did a search of the IEEE publication database last year and the IEC binary prefixed are rarely used in IEEE magazines and journals. (I mean RARELY.) -- SWTPC6800 (talk) 04:12, 26 March 2008 (UTC)[reply]

Is there a link so that I can buy a copy? DavidPaulHamilton (talk) 08:40, 26 March 2008 (UTC)[reply]


Mebibytes are not hard to find:
Thunderbird2 (talk) 17:31, 26 March 2008 (UTC)[reply]
And also Intel, Dell, Freescale, IBM −Woodstone (talk) 20:03, 26 March 2008 (UTC)[reply]
With Google even the -rarest- examples are "easy to find". That does not say anything. Only the ration of acceptance is an indication Mebibytes gives just 20.800 hits, Megabytes gives 5.840.000 hits. Mahjongg (talk) 12:59, 27 March 2008 (UTC)[reply]
Mahjongg, it is unbelievable how someone could be completely missing the point after this lenghty debate. The Megabytes you are counting include a lot of text that uses the term "Megabyte" in accordance to IEC 60027-2 and that includes even text that was written long before this standard was published. Nobody here argues whether we should use "Megabyte" or "Mebibyte", we are discussing whether Wikipedia should use all of these terms in accordance to IEC 60027-2 and pre-IT standards or whether it should use the IT industry slang meaning of "Megabyte". Therefore it is absolutely pointless, useless and at best misleading to count use of "Megabyte" against "Mebibyte". It is also obvious that "Megabyte" and "Mebibyte" will be rarely spelled out, so that MB and MiB will be far more common in written language whereas "Megabyte" and "Mebibyte" are mostly used in verbal language hence Google statistics won't get you anywhere. --217.87.90.29 (talk) 14:07, 27 March 2008 (UTC)[reply]
That argument has already been refuted in the top most section of this page. It is fallacious to say "Megabyte" and "Mebibyte" when it is obvious that only Mebibyte is rare compared to Megabyte. As for trying to search for MB and MiB that generartes too many false positives with "Men In Black" for example. Fnagaton 14:13, 27 March 2008 (UTC)[reply]
The argument is kinda valid in that those measurements are all meaningless either way. I suspect that our real-world experiences, if we're all honest, lean heavily towards not generally using the IEC prefixes. I'm going to try a new approach to trying to figure out where everyone stands shortly... in doing so, I'm not going to try and change the proposal above or claim there's overall consensus about anything, just figure out what is actually still left to argue about. SamBC(talk) 14:27, 27 March 2008 (UTC)[reply]
Fnagaton, I wasn't suggesting to use some magic search terms that will show us the real reality. I was merely stating that Google can be used to bend the perceived reality in either way. For that we certainly don't need to show that the IEC prefixes are more common, something only a loony would claim, but simply that their use is increasing seemingly indicating progressive adoption. In other words, I was just pointing out that Mahjongg's comment was neither constructive nor helpful but showing a very superficial view on this issue despite the fact that he wouldn't have to read beyond this page to get the bigger picture and lot of pointers to verifiable information...if you catch my drift. --217.87.90.29 (talk) 14:29, 27 March 2008 (UTC)[reply]
Tell everyone here exactly how posting "it is unbelievable how someone could be completely missing the point" is constructive? Mahjongg's post is concise and to the point. Fnagaton 14:40, 27 March 2008 (UTC)[reply]
I'm not "missing the point", (and for the record, I just re-joined this discussion yesterday, since I have given up on it half a year ago, but was curious about it's status quo. Can't believe the Mebibyte pushers are still at it. This issue should have been resolved by now) I just tried to illustrate the futility of giving a few examples you can find on the net of publications that use this term. As you can find -anything- with Google on the net, even the most obscure subject. And if you use these finds to try to claim the term is "in common use", then you are intellectually dishonest IMHO. Did I make a "futile remark at this stage of the discussion"? Perhaps, but it seems most of the discussion here seems futile, as it seems to go on and on without resolving the issue.
By the way, it seems telling to me that the given examples are seemingly not coming from mainstream technical journals etc, but rather from "legal departments", and such, at least if I look at the names ending with "et al" etc. this seems clear to me. Which makes kind of sense, as only a legal department would use terminology that overrules common sense for the wish to use "watertight language". But most of the worlds "normal" population uses the more common terminology. Perhaps you could claim that in articles with a "legal" background the use of Mebibyte (etc.) is more or less acceptable, but not in the much more common articles of a technical, (not legal) nature. Mahjongg (talk) 14:57, 27 March 2008 (UTC)[reply]
In contrast to your previous comment this one was indeed helpful in certain way. --217.87.90.29 (talk) 15:11, 27 March 2008 (UTC)[reply]

Standardisation is a good thing

I was asked to come here and comment by Greg L, probably since I am an old software engineer and not a mathematician. But he is not going to like my answer:

I grew up and still live in Sweden, where as far as I know we switched to SI units for most measurements already in the 1800s, an switched to SI notation for date and time somewhere mid 1900s or so. Since they are not ambiguous and can more easily be handled by computers, such as sorting and converting them. The Japanese and many other countries did the same modernisation long ago too.

So when I write date and time I write 2008-03-23, 18:00. I do not write 23 March 2008, 6 p.m., or should that be 6 a.m.? And if I use the old Swedish notation 6 f.m./e.m. then I guess most of you have no idea of what that means, right? See, a.m./p.m. is even language specific! See the benefits of standardisation?

So basically, I disagree with Greg. I like the new SI units GiB for 230 bytes. Since it is less ambiguous. I just wish we had a non-ambiguous unit for 109 bytes too, but currently we don't.

When we use GiB in articles then we need to put a footnote or paranthesis explaining that 1 GiB = 230 bytes = 1,073,741,824 bytes, since as you people have mentioned here many readers do not know what it means. But if we use GB then we have to put a footnote anyway to tell which GB we mean. So there really isn't much difference. So I say we are an encyclopaedia and should go with the best possible notation, at least as long as it is reasonably easy to understand. (I would not like to see room temperature written in Kelvin...)

--David Göthberg (talk) 2008-03-23, 02:16 (UTC)

Okay, with the risk of starting a flame war: I feel I have to say something very unpleasant. I think Greg L or someone posing as him [is trying to "stuff the ballot" on this. (Perhaps to make Greg look bad? So it might be someone opposed to him. Conspiracies galore! Now it suddenly feels more like fun than unpleasant. #:))
Seemingly while he still thought I preferred GB over GiB "he" left this edit on my talk page. Note that he is asking me to come vote in his favour when the time comes, and asks me for others that might have the same point of view. And especially note that the edit is done by an IP user so will not be visible in Greg L's "user contributions", still he went to the trouble of manually adding his full signature.
Please try to stick to logical arguments instead of trying to stuff ballots on this, whoever you were that left that edit. Okay?
Although GiB vs GB is perhaps more a matter of personal taste than logical arguments so it is a tricky case. (Since the logical arguments there are goes both ways, so no side has a clear advantage.)
--David Göthberg (talk) 03:50, 23 March 2008 (UTC)[reply]
David, the issue here is context. If I told you my computer has 3 GB of memory, would you (or anyone on the planet, for that matter) believe that I am saying that I have 3,000,000,000 bytes of memory? No, of course not. "GB", in the context of memory, is always, 100% of the time, understood to be in powers of two.
Wikipedia's responsibility to the world is to present the world as it is, not as we as individuals want it to be. We as people with the goal of writing a great encyclopedia are naturally idealistic, but the content we produce must be pragmatic and realistic. This means that we don't push our views on our readers; this extends to what we as individuals may think the "right" unit of measurement is, or what the "right" spelling of a word is. The guidelines, as it stands now, encourages the use of the unit of measurement that's common within its field. In our computing articles, we tend towards KB, MB, etc.; this is very similar to how articles on American topics are going to present measurements gasoline in gallons and distance in miles. In terms of serving our most likely readers in any given topic, this works out very well, because it has the highest chance of understanding. -/- Warren 04:48, 23 March 2008 (UTC)[reply]
While that may be correct, in principle, I don't think it applies here. Advertising and other informal communications often use slang and loose, ambiguous terminology. On the other hand, we are a formal reference work, and owe it to our readers to be technically correct. We use words according to their dictionary definition, not according to their informal usage. In the case of technical terminology, the major standards organizations write the dictionaries, and they have stated unequivocally that "mega" means 106 and only 106, and that the only technically correct way of representing 220 with a prefix is to use the prefix "mebi". As with many words, informal and technically incorrect usage of words is common, but it is not appropriate for a formal reference work, even if common. "Representing the world as it is" would simply mean stating in the binary prefix article that in common usage, the decimal terminologies often are used to represent binary values. But we should not follow this example, because of the simple fact that it is not correct, based on the definitions of the terms set by those authorities tasked with defining them. We should not knowingly present incorrect or ambiguous information, even if the practice is a common one. Seraphimblade Talk to me 08:56, 23 March 2008 (UTC)[reply]
The "technically correct" argument is not the Wikipedia way of writing articles because "technically correct" is actually decided by real world consensus and Wikipedia does not always follow what a "standards organisation" says. Wikipedia wisely make the choice that real world consensus trumps standards bodies, see my talk page for an excellent example. Also your statement is not accurate because the JEDEC, which is a standards organisation, does state that mega and kilo use powers of two. So the only sensible option is for Wikipedia to use what is commonly used in the real world because that is the most widely understood, this means for the majoirty of articles that IEC prefixes should not be used. This is a natural function of real world use and wanting to be widely understood by the majority of people and has nothing to do with being for or against any particular "standard body" per se. Fnagaton 11:11, 23 March 2008 (UTC)[reply]
I repeat myself: The question is not whether IEC prefixes are used frequently, but whether they are used frequently in publications that try to be unambiguous, because that is what we (or most of us) want to be. The IEC symbols are certainly the most popular ones in these cases. (I have seen BB once, for billion bytes, but nothing else. Subscripts have been suggested here: GB16.) The IEC names are not as frequent as the symbols in my experience and they sound ugly, that is why I suggested the self-explanatory term binary megabyte (in contrast to decimal megabyte where necessary) instead. The added i does not seriously obfuscate the unit, it just gives more exact information to the knowledged reader while others would (hopefully) read it as if the i was not there.
I have never concealed my preference for simple and straight guidelines even if they were specific to Wikipedia. Allowing a binary meaning for SI prefixes in certain contexts – i.e. semiconductor storage capacity and perhaps file sizes – was already a step of mine towards compromise. I suggested to specify defaults in MOSNUM, so not every page needed explanatory footnotes. Footnotes, by the way, are not a desirable thing in neither encyclopaedias nor hypertext, (hyper)links are more appropriate and sufficient.
I started off by criticising Fnagaton’s proposal, but soon found that to be less explicit than writing a counter proposal, because his one was too anti-IEC, although overall sounder than I expected based on his hostile, uncompromising attitude exposed in Talk several times (with like responses of course). I tried to make it more general (to also apply to tons, pounds etc.), too, which probably lead to it being perceived as not precise enough. — Christoph Päper 20:29, 23 March 2008 (UTC)[reply]
You repeat yourself yet you are still wrong for exactly the same reasons I have already given. My proposal is not anti-IEC. Not once does my proposal say "do not to use IEC prefixes". I'll give you a chance though, if you can prove where my proposal is specifically "anti-IEC" then you'll get an apology. If you cannot then you admit you are wrong and I expect you to retract what you just wrote. My proposal uses the most clear and precise way to disambiguate prefixes which is to use mathematics to make it completely unambiguous about the exact number of bytes being used in a particular situation. It also does it in such a way without advocating any particular prefix system, therefore removing any chance that personal bias of the editor is in the guideline. Also I demand you retract you untrue allegations about "hostile, uncompromising attitude" because I present a clear argument and I do not resort to the kind of personal attack you have just demonstrated to try to score points. Fnagaton 15:54, 24 March 2008 (UTC)[reply]
You are right, your proposal does not say “do not use IEC prefixes”, because it does not mention them at all! That is pretty anti in my book. Instead you write “Editors must use the units/prefixes employed in the sources used by the article.” As I have shown that would only be a good recommendation, if those sources were disambiguating (inline), which most do not.
I repeated myself, because neither you nor anyone else has countered that point. The section #General IT prefix discussion ended with my notion that “real world consensus is that IEC prefixes are one way to achieve disambiguity where needed”.
Your constant calling people wrong and demanding retreats constitute the hostility, your unwillingness to accept IEC prefixes at all – direct quotes you cannot touch – constitutes the uncompromising attitude. It does not matter for the reception whether you perceive or mean it like that. — Christoph Päper 18:32, 24 March 2008 (UTC)[reply]
Not mentioning something is not "anti" that something, it is also not "for" that something. It is neutral, it is unbiased. So you admit you are wrong. When are you going to retract what you wrote? You are also wrong in your last paragraph, when people are wrong it is more polite to tell them as opposed to the kind of personal attacks you resort to. Also when someone writes something that is not true, like you have been doing, then they should retract it and there is no harm in pointing that out. You are making the mistake of confusing "uncompromising position" with "not accepting rubbish". It is easy to demonstrate you are wrong here because the fact is I made a proposal, then Greg comes along and makes another proposal. What do I do? I support his proposal. If I had an "uncompromising position" as you claim then I would not have supported it. You are therefore claiming and writing rubbish. Q.E.D. By repeating such baseless accusations you are also being uncivil, disruptive and making personal attacks. What you wrote has been countered or has nothing relevant to start with, for example when you wrote the "least space-taking solution..." post that uses entirely irrelevant POV which ignores what was already said before. It is easily demonstrated that the -bi prefixes are not the "most established solution" as you claimed. You are also using misrepresentation because what you wrote about "your unwillingness to accept IEC prefixes at all" is completely untrue, so I also demand that you retract that. I have no problem with IEC prefixes being used if that is the consensus as shown the the sources used in an article, the fact is for the majority of articles that is not thee case. Stop with the personal attacks right now, this is not the first time I've had to point this out to you. If you cannot be civil and debate the actual topic then I suggest you take a break and do not post here on this topic. As the flow of that discussion shows your "solution" is not a viable solution, for the reasons given at the time and by the fact that you made a comment 18 days (!!!) after the last post in the thread had been made and you did not even think to put a note on the involved editors talk pages, so there was little point going over what you kept on repeating. You will not get your own way on every single post that you make. Just so you are clear, telling someone they are wrong is not a personal attack. If you react badly to being told you are wrong then you have two viable choices. 1) Don't be wrong. 2) Don't post on Wikipedia. The choice you make, using personal attacks, is not a viable option. Fnagaton 19:03, 24 March 2008 (UTC)[reply]

There is a theme throughout this whole discussion that everyone knows that:

KB can mean 210bytes = 1,024 bytes, and that
MB can mean 220bytes = 1,048,576 bytes and that
GB can mean 230bytes = 1,073,741,824 bytes.

I doubt that this is true for the vast majority of the users of Wikipedia.!

  • The first point I would make is that I am an experienced programmer/electrical engineer and could not write the decimal equivalents of MiB or GiB without a calculator - to answer -/- Warren's 04:48, 23 March 2008 question above, when u tell me you have 3GB, I, absent a calculator, can only say you have about three billion bytes. IMO, most people don't have a clue how many bytes are in your PC, just a large number!
  • The next several points I will make, comes from an informal survey I did this weekend at a friend's Easter Brunch. There were 20 of us, ranging from a High School Junior to several retired teachers. All were computer users, about equally split between under 35 years old and over 55 years old. There was one other programmer and one MD. All were college graduates (the HS junior will do so). Here are the results of my informal poll leaving out the programmer:
  • About 5 of the attendees thought kilo = 1,000, even they were uncertain.
  • No one thought a kilobyte or a KB was 1,024 bytes. The five thought it meant one thousand bytes.
  • Exactly 2 (the MD and a high school principal) thought mega meant 1,000,000, neither was certain!
  • No one thought a megabyte or an MB was 1,048,576 bytes. the two thought it meant one million bytes.
  • My friends use a MAC, none of its three users could tell me how many bytes of memory nor the HDD size.
  • The programmer when asked in front of several members of the group, said mega meant million. When prompted, he said, of course, it could mean quote 220 unquote; however, he like me, could not state the precise decimal amount.
  • The final point I will make is that in settling the litigation Western Digital said in its motion supporting the settlement, "As noted above, Plaintiff admits that Western Digital is using the historically correct, industry standard definition of gigabyte"[1] In Wiki words, we have here a reliable source as to the common, historically correct definition of GB and by implication MB! While lawyer's are advocates, IMO, it would be unusual for there to be any gross misstatement in a defendant's motion supporting such a plaintiffs motion, so I find this statement compelling in resolving the many arguments posted hereinabove.

Standardization is a good thing and now that we have standards that eliminate ambiguity it seems to me we foolishly give up the opportunity to educate the Wiki public as to the issue when we deprecate (or ignore) them. To argue that we shouldn't use them because they are relatively unknown is a rather peculiar argument, how else can they become known? Following that argument to its end, we shouldn't use MB or GB either because most people don't know precisely what they mean. We the practitioners all understand the difference between MB and MiB, why should we withhold this? As David G says at the beginning of this section, why shouldn't we go with the best possible notation? Tom94022 (talk) 20:14, 24 March 2008 (UTC)[reply]

Except the JEDEC standards organisation and the memory chip industry have standardised KB/MB/GB using powers of two. I can also tell you what KB/MB/GB are in decimal, hex, binary and octal. No problem at all without using a calculator. Also without using a calculator I can perform arithmatic for those memory sizes with other typical power of two numbers that are very common in computer programming. I'm also a very experienced software engineer, I can for example tell you that 0xc000 is 49152 off the top of my head or for example 0x10000 / 0x400 = 0x40 = 64. To answer your first question: By the real world (not us as editors) adopting them over time if that is the will of the people producing the sources we must use without bias when writing articles. To answer your second question: Following on from your point we shouldn't be using the -bi prefixes because introducing extra terms will only go to confuse the people you polled even further. To answer your third question, because the real world doesn't use the notation very much, therefore it is not the best notation. It is POV to state what is the best notation. It is not POV to say "the real world uses this so we follow that example". Fnagaton 20:28, 24 March 2008 (UTC)[reply]
What is JEDEC? (That question is rhetorical, I know what it is.) It's no IEEE, no ANSI, no ISO. It certainly does not overrule a position that all of those major standards bodies have agreed to. Nor does advertising. We would not say that something is "smoking hot", even if advertising or other informal communication commonly and routinely did. To bring up JEDEC in the face of consensus among the major world standards organizations is ridiculous. JEDEC is just an industry consortium at best, the standards organizations have decades to centuries of history and experience. Also, JEDEC itself states that the usage is deprecated: "The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states "This practice frequently leads to confusion and is deprecated." (emphasis added) JEDEC is not advocating improper use of these terms, only acknowledging that it happens. They are, with this statement, implicitly accepting IEEE's standard and agreeing that the terminology in common use is ambiguous and undesirable. I believe, as above, that you are also confusing us with the average person. Upon asking several people today how many bytes were in a kilobyte of RAM, they replied "Well, a thousand, of course." A reasonably intelligent person who does not have a strong computing background would naturally assume that, because kilo means one thousand. On the other hand, asked how many bytes were in a kibibyte, they replied "Well...I don't really know." That's GOOD! Instead of automatically assuming they had the right answer when they actually had the wrong one, using the correct term made it clear to them that they don't know. If they needed to know, that would trigger them to look it up. Better to use a term someone is unfamiliar with (and thus will look up) than a term with which they are familiar with but that in this specific case they are likely to interpret incorrectly. Seraphimblade Talk to me 11:38, 26 March 2008 (UTC)[reply]
Your post still does not mean you can ignore the fact that the JEDEC defines those prefixes as powers of two. Also the JEDEC is a standards organsiation and trying to misrepresent it as "just an industry consortium at best" is your POV. Quoting the JEDEC main page it says "JEDEC is the leading developer of standards for the solid-state industry." which refutes your claim. Also the JEDEC does not state the standard is deprecated as you claimed. In actual fact the word deprecated is part of a quote from the IEEE in the note attached to the standard and is not part of the main standard text, this is because the notes are there for context and not actually part of the main standard definition. The main standard and the notes to the standard are two separate things and you are applying undue weight to the notes and not applying that weight to the main standard definition. The fact is the JEDEC still expect memory to use KB/MB/GB in the binary sense. Just so you are clear, the main JEDEC standard definition refutes what you wrote above. Fnagaton 12:02, 26 March 2008 (UTC)[reply]
The blog from the British Computer Society's web pages gives a computer professionals' perspective on the IEC standard [4]. Pyrotec (talk) 19:53, 26 March 2008 (UTC)[reply]
Fnagoton, yes, JEDEC's definition disagrees. So what? JEDEC is, compared to the venerable ISO, IEEE, ANSI, etc..., an upstart. You wouldn't care if I personally said "Binary prefixes are the right way to do this", and for good reason—I lack such authority. JEDEC might be able to claim some authority, but certainly not enough to overrule such a clear consensus among the major standards makers. We should footnote in the binary prefix article that JEDEC disagrees, but that's all. Your suggestion is much like those who argue that we should not use the mainstream scientific position as the major opinion because there are a few dissenters or the general public tends to misunderstand. ANSI, and IEEE, and ISO, are the largest, top standards bodies in the world. They have stated clearly that decimal prefixes are to be used for decimal numbers and binary prefixes to be used for binary numbers. Whether or not most people do that yet, the authorities on the matter have clearly and unambiguously spoken. We don't question that, we follow it. We use terms as they're defined, and the top authorities responsible for defining them have clearly and unambiguously stated what they mean. It's not our place to second-guess that or argue over it, it doesn't matter what we think. Seraphimblade Talk to me 21:21, 26 March 2008 (UTC)[reply]
Wikipedia doesn't always follow standards organisations even if you think they are "the top in the world", it follows real world consensus. See my talk page for an excellent example. Real world consensus in this case is to not use IEC prefixes in the majority of situations, you cannot refute that. So Wikipedia should not do so either, unless it is in a very small minority of articles which is what it says in the proposal. Just so you are clear, what you think is "a clear consensus among the major standards makers" has been overruled by the real world and their standard has failed to get widely adopted. The top authority is real world consensus, that is how Wikipedia operates. These facts neatly refute what you have been posting. Fnagaton 21:26, 26 March 2008 (UTC)[reply]
Of course I can refute that. (Really.) Last time I checked IEEE and ISO and ANSI are very real organizations, and really the ultimate authority on what technical terms mean. They quite really have defined decimal prefixes as decimal and binary prefixes as binary. So kilo really means one thousand, and kibi means 1024, and that really gets misused a lot. Most technical terms really get misused a lot. That really doesn't mean in real articles we shouldn't use the real meanings. In the real world, the authorities on things, not popular usage, define terms, in terms of their formal definitions for use in formal publications. And that's based entirely on real things from the real world. Really. Seraphimblade Talk to me 21:41, 26 March 2008 (UTC)[reply]
No they are not "the ultimate authority" they don't even enforce what you claim of course so since real world consensus trumps what they think then sometimes when they propose something which isn't followed then Wikipedia does not follow the organsiation either. Wikipedia follows real world consensus, this has been demonstrated before. I'm glad you posted WP:NOR since NOR refutes what you posted above because it says "Wikipedia does not publish original research (OR) or original thought". This means Wikipedia articles have to follow WP:Verifiability which says "The threshold for inclusion in Wikipedia is verifiability, not truth." This means an article that has sources which use the terms KB/MB/GB should not use the IEC prefixes since the article sources do not verify that those IEC prefixes are used. Just so you are clear, it is against WP:NOR to write force using IEC prefixes in articles when there is virtually no real world consensus to use those prefixes. These facts neatly refute what you have been posting. If you really think the standards bodies trump real world consensus then prove it, since you have not proven it so far. Fnagaton 21:26, 26 March 2008 (UTC)[reply]

When it comes to measurements, the government is the authority. If you offer goods for sale, and label them with the wrong units (as determined by the goverment) the weights and measures inspectors might come into your place of business, seize the offending goods, and write a citation requiring you to account for your misdeeds in court. If you engage in a transaction with another private party that involves measurements, and the other party thinks he has been cheated through improper measurements, he can sue you, and the court will decide who was right about the measurements. The voluntary standards from the IEEE, JEDEC, ANSI, and other non-profit private organizations have no authority unless they are adopted in a law or legally binding regulation, or they become so widely used that they become part of the language, just like all the other words that are used in contracts. --Gerry Ashton (talk) 21:56, 26 March 2008 (UTC)[reply]

"The voluntary standards" says it all and since they are not widely used that then means Wikipedia shouldn't use them either. Fnagaton 21:58, 26 March 2008 (UTC)[reply]
If we then want a government source, that is easy enough as well, given that the NIST has adopted the use as well, see [5]. So, at least in the United States, the official government body responsible for setting standards has also spoken. (This may be true in other countries as well, I live in the US so am most familiar with its government. Anyone with insight into other governments, please speak up.) Seraphimblade Talk to me 22:46, 26 March 2008 (UTC)[reply]
The NIST page cited by Seraphimblade describes what the IEC does. It does not create any requirement to use the IEC prefixes. It does not even say that NIST has adopted the prefixes for use in NIST's own publications (I don't know what, if any, prefixes NIST uses when describing the size of RAM.) --Gerry Ashton (talk) 22:53, 26 March 2008 (UTC)[reply]
Seraphimblade for the reasons given by Gerry posting that link is not proving your point of view that standards bodies trump real world consensus. Please try again. Fnagaton 22:55, 26 March 2008 (UTC)[reply]
Fnagoton, please kindly do not misrepresent me. My position is not that standards bodies trump "real world consensus", my position is that they are real world consensus. They are the bodies tasked with creating and defining technical terms. A consensus among standards bodies is "real world consensus", it is not separate or distinct or something different from it. It does not need to "trump" it, it is it! Widespread misuse of technical terms is common with almost all such terms. That does not mean that the terms do not actually mean what they were defined as, it simply means misuse is widespread. Seraphimblade Talk to me 23:57, 26 March 2008 (UTC)[reply]
I'm not misrepresenting you, actually you are misrepresenting what I wrote. This is because in this section at "11:11, 23 March 2008 (UTC)" I first used the term "real world consensus" and clearly stated "real world consensus trumps standards bodies" and "does not always follow what a standards organisation says". From this you may deduce that I mean "real world consensus" is not the same as a "standards organisation". Your later posts then attempt to contradict that by trying to claim the standard bodies are better (i.e. trump) what I said about real world consensus. So what I wrote is using the terminology I set down for this debate and what you wrote is self contradictory. So instead of "standards bodies trump real world consensus" you really mean "standards bodies are real world consensus", if you want to try to redefine real world consensus then so be it, but your POV is still not proven by your statements. And you've not spelt my name correctly either. Fnagaton 00:11, 27 March 2008 (UTC)[reply]
Apologize for the misspelling. I do indeed believe that the standards bodies set the real world consensus for what technical terms mean, as they are a definitive source tasked with making such definitions, just as other definitive sources such as a dictionary set the real-world consensus for what words actually mean, even if they're commonly used in a slang or other manner. I'm not stating that the standards bodies can override some type of "real-world consensus", I'm stating that they set it, and that trying to speak of "real world consensus" as something apart from the official definition of the terms by the authoritative bodies which do so is nonsensical. In the real world, standards bodies set the official definitions of technical terms. That is the real-world consensus, however widespread the misuse may be. Even you know what "kibibyte" means, so there's no lack of consensus as to its meaning. As to whether "kilobyte" means the same thing, since there's an ambiguity, we look to the authorities on the subject. What do they say? "No, it doesn't, kilobyte means one thousand bytes." That's not original research, as you accused earlier, it's quite well sourceable. It is not original research to state that 1 inch = 2.54 cm, that's perfectly sourceable and an entirely valid conversion. Similarly, it's not original research to claim that 1 KiB = 1.024 KB = 1024 B. That's simply a measurement conversion, and a perfectly source-based one, no original research is involved in that. Measurement conversions have never been considered original research, even if the original source used a different unit. Seraphimblade Talk to me 00:29, 27 March 2008 (UTC)[reply]


(Outdent) The entire computer industry follows the IEEE/ANSI standards for computer storage units. That is the standards adopted in the 1980s and 1990s that codified kilo, mega and giga as either decimal or binary depending on context (ANSI/IEEE Std 1084-1986). They have totally ignored the new IEC binary units.

If you look at the technical specifications on the Intel website for microprocessors you will find MB for megabyte. If you look at the technical specifications on the Samsung website for DRAM you will find Mb for megabit. When company like Dell signs a contract to purchase millions of dollars of microprocessors and memory, the specifications have the standardized binary units the industry has used for decades. I doubt that the contracts are written in Esperanto. -- SWTPC6800 (talk) 01:26, 27 March 2008 (UTC)[reply]

And I would also add that "the standards bodies set the real world consensus for what technical terms mean" is not true and would be better phrased without the word consensus - consensus would be a pretty subjective term in this context. Standards bodies set standards and guidelines in order to try and establish common usage and gain consensus. They do not start with consensus (unless you're referring to consensus within the group of people that form that particular standards body). In fact, its usually a lack of consensus on a particular topic that's driving them to create and promote their standard in the first place. --Marty Goldberg (talk) 01:45, 27 March 2008 (UTC)[reply]
Seraphimblade wrote "I do indeed believe that the standards bodies set the real world consensus for what technical terms mean, as they are a definitive source tasked with making such definitions, just as other definitive sources such as a dictionary set the real-world consensus for what words actually mean, even if they're commonly used in a slang or other manner." I disagree. Dictionaries generally document the meaning well-edited sources ascribe to words; they generally don't tell their readers how the language ought to be improved, or what words should be dropped because they're confusing. Standards bodies may very well pass standards that advocate change in the meaning of words, or they may invent brand new words; dictionaries don't do that.
Also, nobody is in charge of voluntary standards bodies. Anybody can start one, and it's really just a popularity contest that determines which ones are influential, which ones are marginal, and which ones go out of business. (In that sense, they are like dictionaries.)
Oh, and just to disclose my interests, I'm a member of IEEE and have contributed one sentence to an IEEE standard. --Gerry Ashton (talk) 02:54, 27 March 2008 (UTC)[reply]
Anyone can start a standards organization. The Secure Digital card memory for your camera is standardized by the SD Card Association. [6] The Universal Serial Bus ports on your computer are standardized by the USB Implementers Forum. [7] Neither is controlled by a government agency. -- SWTPC6800 (talk) 04:02, 27 March 2008 (UTC)[reply]
Seraphimblade you wrote "I do indeed believe that the standards bodies set the real world consensus for what technical terms mean" and "In the real world, standards bodies set the official definitions of technical terms. That is the real-world consensus". The two things are not quite the same. I will explain. The first quote means they set what the technical terms mean, it doesn't mean the world has to follow those standards. Sometimes the real world consensus, through common language use, is that the standards bodies are advocating something that is not popular. For example with IEC prefixes you cannot refute these prefixes are not popular despite the standards bodies advoating them for the last ten years. Real world consensus therefore is against what some of the standards bodies advocate. So while you are partially correct, they do set the terms, you are incorrect to try to claim they reflect real world consensus. In your second quote you again try to equate setting a definition with real world consensus, where no such link exists in the case of IEC prefixes. Lastly, when you wrote "It is not original research..." you're the forgetting "The threshold for inclusion in Wikipedia is verifiability, not truth." part of WP:NOR. Anyway I do have to agree with Gerry's point about dictionaries, they do not create new words at all, they do reflect common use in language. So Seraphimblade if after reading Gerry's comment you still believe "standards bodies set the real world consensus" then I want you to demonstrate exactly why. You can demonstrate you are correct by removing the feet and yards from the American Football article and getting your change to stay for at least a month, this is because according to the standards bodies you advocate the terms yards and feet are not to be used. If, as you claim, the standards bodies are real world consensus then you should face little problem is making this change to the article and seeing it stay that way. If you do not make the change then you're not going to demonstrate why your point of view is correct and I'm afraid you'll have to concede the point you've been making. Fnagaton 09:25, 27 March 2008 (UTC)[reply]

(outdent) I support and agree with the positions and arguments expressed by David Göthberg and by Tom94022.

For me this issue is very simple: There are some things in the computer industry for which decimal prefixes are used when the meaning is binary, and there are some for which decimal prefixes are used when decimal is intended, and this is confusing and ambiguous. The notion expressed above by e.g. Fnagston that "everyone knows what is meant" is false: The ambiguous usage of e.g. "GB" for both meanings leads some to believe that "everything in a computer is in powers of two". For example, I've had numerous people try to tell me that "10 megabit Ethernet" means 10 times 2 to the 20th bits/second, or that a "100 gigabyte tape" must hold 100 x 1024 x 1024 x 1024 bytes. (No, I don't have the decimal equivalent of 0x40000000 or even 0x100000 memorized either, even though I've been programming for decades, much of the time in various assembly languages.)

Heck, I even think that wherever confusion is possible (e.g. just about everyplace in computer contexts except RAM sizes), I think the standard "metric prefixes" should be replaced with something like "gidebytes" (GdB) where the original number was divided by a power of 10. Of course it isn't WP's place to push or even suggest such a thing.

In the meantime, though, the binary prefixes already exist, having been proposed and adopted by major, widely recognized standards organizations and professional societies. Using them wherever appropriate is less confusing in the long run, even if they are unfamiliar upon first encounter to most readers. QED (for me), using binary prefixes is what WP should do, even if it does mean that WP is taking a leading rather than a documenting role with respect to real world consensus. For me, that concern is less important than accuracy and precision. Jeh (talk) 16:13, 27 March 2008 (UTC)[reply]

Not when they are virtually unused and unknown and Wikipedia doesn't ignore real world consensus for the sake of accuracy or precision. It is more accurate to not use IEC prefixes in most articles and instead use some other form of disambiguation like stating the exact number of bytes. Fnagaton 16:18, 27 March 2008 (UTC)[reply]
One, regarding "virtually unusued," you could have said the same thing about metric measurements in the U.S. in the 1960s outside of scientific fields. Yet the right thing for science textbooks and encyclopedias, even those intended for the general public, at that time was to use metric measurements. Two, regarding "more accurate", that is simply wrong. You can argue a lot of points but you cannot say that it is "more accurate to not use IEC prefixes" where they are appropriate -- for example, 4 GiB RAM is exactly 4 times 2 the 30th bytes, is it not? Third, a usage such as "4 GiB" is no doubt seen by you as more obtrusive than "4 GB", but having to write "4 GB (4,294,967,296 bytes)" is far more obtrusive and awkward than either. Your suggestion that one should in such cases disambiguate by stating the exact number of bytes is also an admission that "4 GB" by itself was inaccurate, or at best ambiguous! Jeh (talk) 16:30, 27 March 2008 (UTC)[reply]
If Wikipedia was around in the 1960s then I'd expect it to reflect the real world consensus as my Physics and Mathematics textbooks do from that period of time and they use feet, inches and pounds. I can say it is more accurate not to use IEC prefixes because as I have shown before IEC prefixes can be confusing and mistaken that they are using decimal and not binary. Therefore to state the exact number of bytes is completely unambiguous. Stating the number of bytes need not mean writing out all of the numbers because it is common to use power notation instead. This is shown in the binary prefix conversion table. Fnagaton 16:51, 27 March 2008 (UTC)[reply]
Fnagaton, I wonder why you insist on using the term "real world" as if it was something in strong support of your position. As other people already wrote and you know: "The threshold for inclusion in Wikipedia is verifiability, not truth." The word "reality" is synonymous to the word "truth". Therefore "real world" is no valid argument. So it doesn't even matter that some people apparently have a different perception of reality than others. --217.87.90.29 (talk) 17:11, 27 March 2008 (UTC)[reply]
  • Jeh, terms like ppb and ppt are ambiguous so IUPAP proposed adoption of the “uno”. Thus, ppm would be 1 µU and ppt would be 1 pU. Notwithstanding that the uno was absolutely unambiguous and was a great idea, it didn’t catch on. What point would there be to using the unit of measure here on Wikipedia if the reader is expected to remember a unit of measure that will likely only ever be encountered here on Wikipedia? Manufacturers of memory don’t advertise “2 gibibyte SODIMM card” and general-circulation magazines don’t use the IEC prefixes either. No matter how meritorious and wonderful a new unit of measure is, encyclopedias and dictionaries never add them to their lexicon until they achieve a certain level of ubiquity in real-world use. There are sound reasons for this: to communicate with the intended readership with minimal confusion. Wikipedia is not immune from this common-sense rule. Greg L (my talk) 16:41, 27 March 2008 (UTC)[reply]
The cases are not at all parallel. We're not talking about a "new unit of measure" here -- the "unit" in question is still the byte.
The "uno" is not only a new unit, its expression in text looks completely different and so presents a visual stumbling block, or "speed bump." IMO, the beauty of the binary prefixes is that they look close enough, and numerically are close enough, to the decimal equivalents that the casual reader will just read them as if they were the decimal versions, and go on, and will get the close-enough meaning; no one has to "remember a new unit of measure" in this case.
In fact, if Fnagston is correct and "everybody knows" what's meant, they'll get the exact meaning! Of course, I don't think an encyclopedia should depend on "everyone knowing what is meant," and I believe that any arguments from that position are completely specious.
Otoh, if binary prefixes are used, then someone who wants technical precision will recognize that the use of the binary prefix indicates that, yes, the numbers preceding those prefixes were thought about and the right numbers are present (e.g. 4 GiB rather than 4 GB when the true number is 4.3 GB).
Regarding "minimal confusion": The computer industry's persistent use of decimal prefixes when the actual meaning is binary (and that is exactly what you are supporting, Greg, is it not?) is rather far from "communicating with minimal confusion". Indeed this ambiguity actively increases confusion, as demonstrated by the recent lawsuit against WD (the actual offender there was the operating systems that insist on reporting e.g. an 80,000,000,000 byte drive as "74.5 GB").
WP should not promulgate a confusing convention, no matter how widespread it is. Particularly not when a better alternative is considererd correct usage by recognized organizations in the field. Jeh (talk) 17:07, 27 March 2008 (UTC)[reply]
Jeh, the "computer industry" is not supporting either potential meaning of "mega" at all. There is no consensus about it in the IT industry. Even those who are members of JEDEC are only a fraction of the whole IT industry. It is therefore reasonable to follow a standard that is less well-known but accurate and in compliance with the rest of all other industries and sciences, as represented by IEC 60027-2, than following a so-called "de-facto standard" that isn't unanimously accepted, inaccurate and misleading in its own area. --217.87.90.29 (talk) 17:25, 27 March 2008 (UTC)[reply]
In the IEEE 100 standard kilobyte etc are defined as binary and decimal. Fnagaton 17:59, 27 March 2008 (UTC)[reply]
217.87.90.29: I agree completely. (I also added an extra indent colon to your graf, as is the convention here; hope you don't mind.) Jeh (talk) 17:47, 27 March 2008 (UTC)[reply]
  • To 217.87.90.29: If you aren’t going to register, why don’t you at least use an alias or “handle” (like “Gunther” or something); your arguments will carry greater weight that way (v.s. when you weigh in entirely anonymously).

    Let me ask you this: If you wrote an article on how the change in frequency on a crystal oscillator was 200 ppb/°C, would you approve if I went in and changed it to 200 pU/°C? Wikipedia could have a whole article dedicated exclusively to the uno. That’s because terms like “ppb” are ambiguous because “billion” denotes a different value in different countries. Uno, which is entirely unambiguous, can therefore be used to disambiguate terms like ppb and ppt (which usually means parts per trillion but occasionally means parts per thousand). We can start routinely using the uno and its unit symbol to denote all high-ratio (low value) proportional quantities in an “oh… didn’t-cha know?” fashion and link each use to an article on the uno. Thus, we will be in a position of helping to promote the adoption of a unit of measure that simply didn’t catch on.

    We shouldn’t now, should we? The uno is a good idea that failed to catch on and isn’t widely recognized. If it weren’t for the fact that I myself added the “uno” section to the Parts-per notation article, there would be even fewer people who know about it. Routinely using the uno in articles would mislead some impressionable readers who would run about with that ‘space-cadet glow’, using a term that only confuses others because it is so poorly recognized. The same goes for “kibibits” and the other IEC units of measure. They didn’t catch on. Our continued use of them here is a mistake. It’s been eight years and the IEC proposal still hasn’t caught on. Encyclopedias and dictionaries simply do not add new terminology to their lexicon until it has reached a certain level of ubiquity. Wikipedia is not immune to this common sense rule. Doing otherwise subverts the primary objective in technical writing: to communicate to the intended reader with minimal confusion.

    The only reason it’s been such an uphill battle is some of the “oppose” authors have been really, really prolific and there is a lot of hard work that must be undone. Either that, or they let Fnagaton do it for them. Both options are unpalatable to them so they’re fighting like hell to preserve the continued use of units that the typical reader doesn’t recognize and is unlikely to encounter anywhere else. Greg L (my talk) 18:01, 27 March 2008 (UTC)[reply]

Greg L, your mention of "space-cadet glow" is incredibly ironic. There was no need for kibibits in the first place but because we cared so much for the needs of our space-cadets, we added a few words to the vocabulary, so that they could stick to their habits and we get on with our work. If you prefer to count your shiploads of memory in 1024 large pieces, so be it, but please pick a proper name. I almost get the impression that people don't care so much about confusing the average reader as annoying our beloved space-cadets. Regarding "Uno", Jeh already said all I could have said about it. --217.87.90.29 (talk) 21:06, 27 March 2008 (UTC)[reply]
Anonymous editor from Germany: What are you talking about? Words like kibibits are real but uknown to the typical reader. Since Jeh and you’d don’t agree with this common-sense fact (or you do know but refuse to admit it), I’m not going to argue the point further with you. Greg L (my talk) 21:28, 27 March 2008 (UTC)[reply]
Pseudonymous editor from the USA: I wasn't denying that kibibit is a real word. I didn't even claim it's widely known or the opposite actually. It's probably not as unknown as you'd like to believe. A lot people writing here and elsewhere know the kibit but don't use it because they despise it. I'm surprised you know the typical reader. He's probably from the real world, right? I wonder does this typical reader only know the word "megabyte" or does he (or she?) also know what it means in any given context? What I'd also like to know, is the typical user a space-cadet or not? Once, I thought the typical reader reads Wikipedia articles to learn something but maybe the emphasis should be on "something" rather than "learn". --217.87.90.29 (talk) 22:12, 27 March 2008 (UTC)[reply]

To GregL:

1. Your assertion that the "typical reader doesn't recognize" the IEC prefixes is, one, unproven, and two, uncompelling to me even if true. My (yes, unproven) counter-assertion is that if someone is familiar only with "GB", "GiB" is very UNlikely to be very confusing: it looks similar enough to the imprecise "GB" that at worst they will likely think "oh, it means GB" and get approximately correct information... which is what they're getting from the decimal prefix anyway! Whereas, if correctly interpreted, the IEC prefixes provide precise meanings, something that cannot be said of the decimal prefixes when used with e.g. RAM sizes. Even to those unfamliar with the IEC prefixes, they will therefore provide no worse confusion than continued use of the decimal prefixes where binary would be correct.

2. The uno is a completely different and nonparallel issue. Reason: Unlike "GB" vs. "GiB", there is nothing in an uppercase U that suggests it means 1 part in 10 to the 9th, i.e. no obvious relationship to the "ppb" it tries to replace. This is NOT the case with GiB vs. GB. That is, in my opinion and as I have said, part of the genius of the design of the binary prefixes.

3. What you think encyclopedias and dictionaries "simply do not" do is your perspective, and not necessarily applicable here. Most reference books do not allow anonymous members of the general publicto make changes that are then instantly distributed to their readers; the rules here are very, very different.

4. The bottom line for me (and a point you have not at all addressed, and which I said before, but since you feel free to repeat points I have addressed, I see no reason not to repeat points you have not addressed) is this: The widespread usage of e.g. "GB" to mean 1,073,741,824 bytes is KNOWN to be confusing. Witness (again) the recent lawsuit against WD, in which even the court came to the wrong answer. An encyclopedia should strive to reduce confusion, not perpetuate it, let alone require it via its manual of style.

5. I think "the only reason it's a battle at all" is just about the opposite: you, Fnagston, and a very few others here are trying to force a change in the status quo. My view is that the guideline could stand exactly as it is; but I think it should be improved by actively encouraging the use of IEC prefixes, for reasons I have described already. Jeh (talk) 20:21, 27 March 2008 (UTC)[reply]

  • Given that you don’t even agree that “the typical reader doesn't recognize the IEC prefixes”, there is no further point debating with you. You’ve voted and I accept that. Greg L (my talk) 21:06, 27 March 2008 (UTC)[reply]

I agree that the IEC prefixes are probably (but not proven) initially unfamiliar to most WP readers. The reason I find this uncompelling -- even if proven -- is this: I strongly doubt that for most readers this unfamiliarity survives about half a second into the first encounter. The approximate meaning (that is, close to the same thing as the corresponding SI prefixes and units, with which they share two out of three letters) is almost always completely apparent from context. That is the beauty of their design, a point that the "Uno" does not share. Jeh (talk) 21:59, 27 March 2008 (UTC)[reply]

I wonder how many people noticed that The Pirate Bay, many other BitTorrent index sites and related software have been using the new prefixes from IEC 60027-2 for quite some time. It has to be millions of people, maybe hundreds of millions over the years. --217.87.90.29 (talk) 02:52, 28 March 2008 (UTC)[reply]
The gender neutral pronoun s/he or (s)he also shares 2 letters. This monstrosity was more widely used than MiB before it was flushed down the toilet. -- SWTPC6800 (talk) 00:50, 28 March 2008 (UTC)[reply]
Your point being...what? --217.87.90.29 (talk) 01:30, 28 March 2008 (UTC)[reply]

I would also like to reply to Fnagaton, above, regarding verifiability. It is trivial to verify the definitions of the binary prefixes. "Verifiable" simply means that one can verify the information through a reliable source, and that a citation can be provided allowing for anyone with reasonable access to reference material to do so. One need only cite the standards bodies' definitions to fulfill this requirement. If the meaning of the binary prefixes were unverifiable, I'd be the first to stand against their usage, but this is simply not the case. Even those who are against their usage are clearly aware what they mean, and we can certainly provide verification of that fact through reliable sources. Such verification is indeed provided in the binary prefix article. Seraphimblade Talk to me 09:52, 29 March 2008 (UTC)[reply]

No, adding new sources that most readers don't understand is not promoting verifiability because this involves citing the sources used in for the article. What you are advocating is pushing virtually unknown prefixes into an article which then causes more confusion to the reader. So adding a cite to the relevant standards body is not all that is needed to saitisfy verifiability. Fnagaton 16:15, 29 March 2008 (UTC)[reply]
I think you need to go read the verifiability policy again. I daresay most readers would not understand the main source I used in writing salt tectonics, but that does not render the information unverifiable. "Verifiable" simply means "one can go verify it." In this case, the conditions (the average person would have reasonable access to the sources cited, and the source is reliable) is satisfied. You can argue that we still shouldn't use it, but verifiability is easily satisfied here. Seraphimblade Talk to me 08:23, 30 March 2008 (UTC)[reply]
No, you are wrong. The goal of disambiguation and verifiability is to make it easier to understand what something means in an article and that goal is not helped by using terms that the majority of readers don't recognise and don't understand. You need to read the verifiability policy again in the context of disambiguation because it is clear it means that you should make sure the article sources can verify what is in the article by using the sources relevant to the article. This does not mean adding extra sources (to IEC or SI sites for example or wikilinks to IEC prefixes) to push your POV that the (virtually unknown and little understood) IEC prefixes are somehow better used for disambiguation. The IEC prefixes are not the best choice for disambiguation and that is clear from the comments on this page. Fnagaton 09:51, 30 March 2008 (UTC)[reply]

Years

Start of discussion moved from Lightmouse talk page
You had best stop un-bracketing years until you get some consensus. I'm reporting this to WP:ANI. Baseball Bugs What's up, Doc? 12:59, 20 March 2008 (UTC)[reply]

You were already blocked once for this activity. STOP IT. Baseball Bugs What's up, Doc? 13:03, 20 March 2008 (UTC)[reply]
Right I don't know what is going on here but please stop for now. Contribute to the discussion on the AN/I but stop delinking the dates. Theresa Knott | The otter sank 13:10, 20 March 2008 (UTC)[reply]
As I understand it, the place to debate policy on dates is Wikipedia talk:Manual of Style (dates and numbers). Feel free to raise it there. Lightmouse (talk) 13:13, 20 March 2008 (UTC)[reply]
First rule: Don't cop an attitude with an admin. Baseball Bugs What's up, Doc? 13:17, 20 March 2008 (UTC)[reply]
That's fine I don't care. Lightmouse I do not wish to debate the policy. I only wish to make sure that you actually have concensus for your changes. Can you point me to the discussion that shows this please. Theresa Knott | The otter sank 13:20, 20 March 2008 (UTC)[reply]
At the very least, the user did not get consensus from anyone to clobber the "year in baseball" template entries. Baseball Bugs What's up, Doc? 13:41, 20 March 2008 (UTC)[reply]

Lightmouse, you continued making controversial edits after you've been contacted abouts this. I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years. Please respond there. MaxSem(Han shot first!) 14:02, 20 March 2008 (UTC)[reply]

Baseball Bugs, I am not sure what 'cop an attitude' means but that phrase along with the word 'defiant' used elsewhere sounds like an accusation of incivility. I have no incivil intentions in my responses. I try to be polite and expect the same from others. Please assume good faith.
There are popular misconceptions about date links so it does not surprise me that it is being questioned. I would prefer not to describe the policy here. Quite apart from anything else, you may not feel comfortable with what I say about it. There are plenty of other editors there that have extensive experience with this issue at Wikipedia talk:Manual of Style (dates and numbers). I would be happy to see you there. I hope that helps. Lightmouse (talk) 14:36, 20 March 2008 (UTC)[reply]

End of discussion moved from Lightmouse talk page

  • Hard to discern what this is about. If Lightmouse is delinking trivial chronological itmes, such as 1998 and 1970s and 20th century, I applaud it. He has the weight of MOS behind him. Read the guidelines, please.Tony (talk) 02:57, 23 March 2008 (UTC)[reply]
I randomly selected about 25 of Lightmouse's recent edits of this nature, and they all seem well within current date policy to me. -/- Warren 04:25, 23 March 2008 (UTC)[reply]
I have the impression that Lightmouse was, as usual, implementing MOSNUM consensus, when an admin over-reacted to a change that was not to his liking. The discussion of the entire non-incident is archived here. Thunderbird2 (talk) 15:31, 23 March 2008 (UTC)[reply]
I've just noticed that Lightmouse has not done any editing since posting the avove message. I hope he is just taking an Easter break. Thunderbird2 (talk) 15:36, 23 March 2008 (UTC)[reply]
I have been watching the discussion. I appreciate the contributions made by all. I would appreciate your further assistance in getting my AWB approval reinstated. See the statement above by MaxSem (I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years) and my request for reinstatement at Wikipedia_talk:AutoWikiBrowser#Please_reinstate_approval.
Lightmouse (talk) 11:03, 24 March 2008 (UTC)[reply]

Scientific notation (aka Standard Form) discussion

There's a discussion at the main MOS talkpage about the prescribed formatting of exponential notation/scientific notation/standard form. Just to make sure interested folks know. SamBC(talk) 22:02, 21 March 2008 (UTC)[reply]

Delimitnum revisited

I am no mathematician, but I am a crazy software engineer and researcher that like to think outside the box. Or rather look at problems from many angles, like for instance backwards.

So {{delimitnum}} did get a "deadly failure". (See discussion in an earlier section.)

So lets do it the other way around. Instead of chopping up a number using maths and put in commas etc, instead lets put the number together only using strings and no maths.

Here is a basic example:

{{dnum|1|.|123|45|x|10|25|kg}}

Which would render something like this :

1.123 45 × 1025 kg

And a monster example:

{{dnum|-|1|500|000|.|123|45|(30)|x|10|25|kg}}

Which would render something like this :

−1,500,000.123 45(30) × 1025 kg

Template:Delimitnum

Such numbers should be pretty simple to input since the user only has to input normal dashes "-" and a normal "x", not the special maths symbols. I let them input the base 10 too, since that makes the input more readable and is more flexible. Oh and this of course means that inputting "+" and "000" is no problem either, they will not be dropped when the number is rendered, since it isn't a number that is rendered but rather a string.

I think I know how to code up such a template. The only maths involved here would be to detect that the string "(30)" is not a number, since it seems you guys don't want any spacing between the 45 and the (30). But if you allow a spacing there the template code gets much simpler.

With spacing I of course do not mean "spaces" but the narrow spacing trick mentioned before that makes the numbers copy-and-pasteable to other programs.

Would such a template be useful?

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

  • David, it’s great to hear from someone who’s really interested in what {{delimitnum}} has to offer. As you’ve no-doubt witnessed at the Delimitnum sandbox, using math-based parser functions within a template is a recipe for banging one’s head against a wall. Your proposal sounds like it would be perfectly workable. As you may also have seen on the initial proposal, here on Archive #94 of Talk:MOSNUM, the delimiting is done with <span> tags. That itself shouldn’t be a problem except that spans following the digit 1 are specified slightly narrower so they have the same visual appearance. The magic word-based version of {{delimitnum}} will use character-based parser functions as you are proposing. With any luck, we should have it within about a week. Since it will used character-based parsing, it will be imune from rounding issues. For instance, {{delimitnum|1.1200|25||kg}} will return 1.1200(25) kg, not 1.12(25) kg.

    Where I could really use some support right now is on an issue of computer nomenclature. It involves abandoning the use of terms like “250 GiB file size” and proposes to adhere to the better-recognized units (e.g. “250 GB file size”). What do you think about this position statement and this specific MOSNUM policy (in light green)? Greg L (my talk) 00:23, 23 March 2008 (UTC)[reply]

Ah okay. So the {{delimitnum}} magic word is not that far away. Right, then no use in spending time on making a template for it. I noticed some days ago that you were banging your head in the wall with {{delimitnum}}, just had to think for some day what to say.
Ok, I'll take a look at the GB vs GiB issue although I have to admit I dislike style issues. I am a software engineer, not a stylist. But I guess in the GiB issue you need some engineers.
--David Göthberg (talk) 01:21, 23 March 2008 (UTC)[reply]

Silly, I always forget to ask this, been thinking about it for days: Greg L: Why didn't you use MediaWiki TeX to render the numbers? It does have text output for simpler formulas. Or does it render the text to bad?

--David Göthberg (talk) 01:30, 23 March 2008 (UTC)[reply]


  • David, the biggest advantage of the upcoming magic word is it will automate the job of a grouping the digits. Many users will simply forget that you don’t leave a single dangling digit, like 1.234 456 8. No matter what the editor inputs, the {{delimitnum}} magic word knows to parse as follows:

2.1
2.12
2.123
2.1234
2.12345
2.123456
2.1234567
2.12345678
2.123456789
2.1234567890
2.12345678901
2.123456789012
2.1234567890123

Regarding the use of MediaWiki TeX, I do if it’s absolutely necessary, such as for

But for straightforward numeric equivalencies, like this:


…I use either hand coding or the {{delimitnum}} template to avoid the change in text associated with <math>, which interrupts the reading flow. Regards. Greg L (my talk) 02:54, 23 March 2008 (UTC)[reply]
1: Ah, I didn't know about how to handle those dangling digits. We delimit numbers differently in my country (Sweden). So yeah, automating it is nice. He, come to think of it, that puts that magic word into trouble, since preferably it should be able to delimit numbers in the right way on all the different language Wikipedias. That coder has a big task ahead of him... Or of course, he could be "lazy" and just do English delimiting and the other languages have to do hand delimiting. Ehm, perhaps I should code a {{dnum}} template for my language instead.
2: I think you might have misunderstood what I meant by using MediaWiki TeX. The default is that it outputs text, not images, for simpler "formulas". So it doesn't interrupt the reading flow as you thought. Perhaps you have set TeX to only show images in your Wikipedia user preferences?
--David Göthberg (talk) 03:19, 23 March 2008 (UTC)[reply]
  • Regarding your point #1 above, Americans don’t usually delimit the fractional side of the significand. Professionally done work does and the only proper way I know originally came from the ISO and is done as illustrated here at the NIST and here at the BIPM (SI Brochure: 5.3.5 Expressing the measurement uncertainty in the value of a quantity). Here is the NIST’s last two-digit grouping, their 3-digit and their four-digit last group.

    As for your point #2, I don’t understand. I’ve set my Wiki prefs to “Recommended for modern browsers” and it shows the above example as large symbols. You seem to be suggesting that simple formulas show as straight text. Please provide an example. I am inclined though, to continue to use hand-coded text or use of magic words and templates, as I am certain what the appearance will be for all readers irregardless of their browser and user prefs. Greg L (my talk) 05:02, 23 March 2008 (UTC)[reply]

  • P.S. If by “ differently in my country” you mean, the Euro-way: narrow spaces on both sides of the decimal marker, and the decimal marker is a comma, not a full-stop, then yes, it’s done differently in America. And that’s the convention the en.Wikipedia standardized upon: comma delimiting to the left of the decimal marker, which is a full a full-stop. The magic word does not even pretend to change any of that; advocating to do so just would never happen. All it does is add much-needed narrow-space delimiting to the fractional side of the decimal marker. Greg L (my talk) 05:25, 23 March 2008 (UTC)[reply]
2: Ah, the point is moot. I tested my user settings for math (MediaWiki TeX rendering). As I remembered I can get it to show as HTML for simple formulas and as PNG when more complex. But in both cases it doesn't delimit numbers. So 123456789.123456789 just shows up like this when using TeX: So doesn't help us at all. (Of course, I might be using TeX the wrong way.)
1: Well, the way I learnt to delimit numbers in school in Sweden is like this:
  • English: 1,234,567.123 456
  • Swedish1: 1 234 567,123456
  • Swedish2: 1.234.567,123 456 or was it 1.234.567,123456
My bank statements and my Swedish MS Windows use Swedish 1, and that is the more common way we do it. I have mostly seen Swedish 2 in really old printed matter, as in early 1900s and older.
I also took a quick look at the Swedish Wikipedia, and there MediaWiki TeX clearly is set to use the decimal comma ",".
See what I mean with that the delimitnum magic word will need localisation if to be used in other language Wikipedias? I am not advocating to change the delimiting in English Wikipedia, why would I? But magic words are part of the MediaWiki software and as such is supposed to work on all language Wikipedias. And that is why I mentioned it since you seem to be in contact with the dev that is coding that magic word.
--David Göthberg (talk) 06:07, 23 March 2008 (UTC)[reply]
  • Yes. I understand enough about the details of the magic word to know that it should be almost trivial to customize it for any language. The hard part is all the parsing logic and the rules governing span width. I was familiar with Swedish1 (and a variant that delimits the same way on the fractional side too). I didn’t know about Swedish2. I like Wikipedia because it is such an awesome way to learn. It’s my bed time. Bye. Greg L (my talk) 06:14, 23 March 2008 (UTC)[reply]
Yeah, I agree. Since using narrow spaces seems to be the most popular in most languages it should be trivial to switch between using a decimal "." or ",". And narrow spaces is anyway the delimiting that has the lowest risk of misunderstanding. Anyway, sleep well. Bedtime for me too I think.
--David Göthberg (talk) 06:26, 23 March 2008 (UTC)[reply]
It certainly can be done. {{Formatnum:}} is language dependant. Jɪmp 04:00, 28 March 2008 (UTC)[reply]

Units

Which system to use

* For US-related articles, the main units are US units; for example, 23 miles (37 km). * For UK-related, the main units are either metric or imperial (consistently within an article).

* For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).

Let us end the confusion by adopting the Metric first, Colonial/Imperial second rule (Option 3). It will make editing easy when the U.S. metricates. I must also add that some items like broadcast antenna heights are always listed in meters and the current rule is a very ambiguous burden to subjects such as these. SirChan (talk) 17:18, 25 March 2008 (UTC)[reply]

I agree - it does seem confusing and unnecessary to make a special exception from the general "use SI units" rule in this instance. Verisimilus T 21:07, 25 March 2008 (UTC)[reply]
I diagree. There is no guarantee that the US will ever metricate, and for US articles it makes sense to have the nationally preferred system of measurement listed first. Cheers, Rai-me 22:48, 25 March 2008 (UTC)[reply]
To Verisimilus: The American has to tilt their head to read the Colonial units on a non-US or international article, the Brit might have to change mindsets every time he reads an article, and the others have to tilt their heads in order to read the metric units in a US specific article or might not have an appropriate metric value in a British article.

To Rai-me: My mom has a maxim, "Always be prepared." The U.S. government has stated since 1866 that this is the preferred system but has been busy with other matters. Metrication has been increasing in recent years--just look at bottled water! This is on the internet; any English-speaking person can find out information about something U.S. or U.K. specific. (To all:) These rules are Byzantine! I might as well include Julian dates in articles also to accommodate historians and Eastern Europeans. SirChan (talk) 02:30, 26 March 2008 (UTC)[reply]

By your mother's philosophy, should we also create an article for the 2096 Summer Olympics to be prepared? Wikipedia is not a crystal ball. It is very unlikely that the US will metricate completely at any point in the near future. Whether the US government has stated that the metric system is the preferred system or not has no bearing on this situation. What matters here is what readers will understand, and for Americans, that is obviously imperial units over SI ones. Metrictaion may be increasing slightly (bottled water is actually still mostly in imperial units - soda bottles, however, are in litres), but the system used by far the most often is imperial. I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best. Wikipedia is optimized for readers over editors, so the guidleines should remain as is. Cheers, Rai-me 01:35, 29 March 2008 (UTC)[reply]
By the same token, it is very much true that many measurements in U.S.-related articles were originally made in metric units. The present rule is ludicrous. Original units should be first; for articles related to the United States, that will often mean English customary units—but that is by no stretch of the imagination an invariable truth, nor something to aspire to in our MoS. Gene Nygaard (talk) 03:47, 29 March 2008 (UTC)[reply]
I am not arguing that we should continue to use the "imperial (metric)" system because it was used first in American-related articles, and shouldn't be changed now. The rules are not, nor should be, the same as those outlined in WP:ENGVAR. The present rule is no more "ludicrous" than the rule to use US$ for American articles, £ for British articles, € for French articles, etc., and not US$ throughout. It makes sense to use the system in an article that is used by the readers of the country relating most to the article topic, so the status quo should not be changed. -- Rai-me 17:06, 29 March 2008 (UTC)[reply]

Ton vs. Tonne

    • Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).

The tons are very confusing especially in this international context (the Internet). In the U.S. a "ton" is the aforementioned short ton while in the rest of the Anglosphere, the "ton" is the aforementioned long ton. Someone might unknowingly, incorrectly use "tonne" because it is similar to "ton." I'd rather use Megagram over tonne and put the type of unit when talking about the non-metric tons (e.g. Imperial Ton, U.S. Ton).SirChan (talk) 02:55, 26 March 2008 (UTC)[reply]

The problem is that megagram is not all that familiar a term to most. Jɪmp 04:01, 28 March 2008 (UTC)[reply]
The comfort of a familiar "word", even when you (whether referring to the editor adding the information, or "you" as readers of Wikipedia in general) don't have the foggiest idea what it means, is an illusionary goal. I'd say we should just outlaw all "tons" of any sort on Wikipedia. Use megagrams, teragrams, and the like for metric units of mass; use meganewtons and the like for the metric units of force; use megawatts and the like for the units of power, joules with appropriate prefix for the units of energy, use pounds for the English units of mass, Btu per hour for the English tons as units of power, cubic feet for the English tons as units of volume, etc. Gene Nygaard (talk) 03:54, 29 March 2008 (UTC)[reply]
One of the key concepts of the metric system is, if you know what mega- means, and you know what gram means, then you know what megagram means. I think most people know what mega- means; I'm not so sure about gram. --Gerry Ashton (talk) 04:24, 29 March 2008 (UTC)[reply]

Sea of blue

The template name {{nowrap}} is linked four times (on every occurrence) in the section Non-breaking spaces. I would like that we do as we teach, so I would like to fix that. That is, only have the first occurrence linked and the other as normal text. Easy enough to do, just use {{tlf|nowrap}} instead of {{tl|nowrap}}, which will render like this: {{nowrap}}. Any one that disagrees?

--David Göthberg (talk) 18:41, 27 March 2008 (UTC)[reply]

So fix it. Nobody's going to worry about as minor an edit as that. If anyone even notices, they'd probably wonder why they hadn't noticed such a glaring oversight. Jɪmp 23:30, 27 March 2008 (UTC)[reply]
Well, personally I think that any edit to the MOSxxx pages should be discussed first (except really minor things like fixing some spelling etc). And even though tradition and recommended style is to not wikilink a word many times in one page or section, tradition up until now has been to wikilink template names on every occasion in documentation. So I don't like to just be bold and make an edit to the MOSNUM that goes against tradition.
Of course, the reason people have been wikilinking the template names all the time might have been that up until now they did not have a simple way to write a {{template name}}. But now we have the brand new {{tlc}}, {{tld}} and {{tlf}}. They produce output like this: {{name|parameters}}, {{name|parameters}} and {{name|parameters}}.
Anyway, I did the edit to the MOSNUM since it seems no one disagreed.
--David Göthberg (talk) 18:21, 28 March 2008 (UTC)[reply]
  1. ^ [http://www.wdc.com/settlement/docs/document20.htm
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=202027283"