Wikipedia

Wikipedia talk:Manual of Style (dates and numbers)/Archive B8

< Wikipedia talk:Manual of Style (dates and numbers)
Latest comment: 16 years ago by Fnagaton in topic Proposed change to wording of "Binary prefix" (1/3): initial proposal and discussion

Proposed change to wording of "Binary prefix" (1/3): initial proposal and discussion

Latest comment: 16 years ago189 comments28 people in discussion

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)

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

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)
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)
  • 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)
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)
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)
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)
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)
"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)
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)
"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)
  • 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)

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)

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

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)

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

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)

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)

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)

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)
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)
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)
(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)

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

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

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)

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)
  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)
  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)
  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)
  5. Support As Rilak says mirroring real life is a good reason. DavidPaulHamilton (talk) 13:00, 24 March 2008 (UTC)
  6. Support For the sames reasons others above expressed. --Marty Goldberg (talk) 21:48, 24 March 2008 (UTC)
  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)
  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)
  9. Support Wikipedia should follow the practices of the real world. -- SWTPC6800 (talk) 03:27, 26 March 2008 (UTC)
  10. Support. Very reasonable proposal. Is a long standing issue and I agree with Greg L entirely. カラム 07:33, 26 March 2008 (UTC)
  11. Support. Its all been said above. Pyrotec (talk) 19:34, 26 March 2008 (UTC)
  12. Support Wikipedia should not be used to change the publics perception, but should mirror it. Mahjongg (talk) 23:55, 26 March 2008 (UTC)
  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)

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)
  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)
  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)
  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)
  5. Oppose deprecation of unambiguous IEC prefixes. The arguments in favor of deprecation are fallacious. Tom94022 (talk) 15:04, 24 March 2008 (UTC)
  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)
  7. Oppose as per Tom94022. Jeh (talk) 20:27, 27 March 2008 (UTC)
  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)
  9. Oppose. IEC prefixes should be acceptable.-gadfium 18:36, 1 April 2008 (UTC)
  10. Oppose - No valid argument has been made to ban standardized prefixes from the site. Some editors personally dislike them, while others personally like them. Neither matters, since Wikipedia policy is not made by majority-rule ILIKEIT votes, but by discussion and good reasons. If we can't all agree on a site-wide guideline, then there is no consensus and the decision is made on an article-by-article basis. (And yes, both the standards and the colloquial definitions are used in the "real world", just like they are here.) — Omegatron 04:13, 6 April 2008 (UTC)

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)
  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)
  3. Comment Omegatron, I’m astonished that you would include this in the statement accompanying your vote above: (“Neither matters, since Wikipedia policy is not made by majority-rule ILIKEIT votes, but by discussion and good reasons.”) While you’ve been on a break from this page, there has been a huge amount of discussion below trying to find common ground—to no avail I might add as there is still no consensus. Further, you panned the very notion of voting and then added your vote above. That is so not a smooth move and amounts to nothing more than playing every have-it-both-ways game in the book in a desperate attempt to keep the current policy from changing. It’s doubly ironic given that you used a simple majority vote (not a Wikipedia-style consensus) as the rationale to ram through the current policy! (See Archive 22). And that was with a hell of a lot less discussion than has now occurred here. As an involved administrator, you should have known better than to pull that stunt back then (no clear consensus). This current chaos and bickering is the result of that shortsighted move. Were you an administrator at that time? And now you seem to be hidding behind the apron strings of an argument that the current policy—adopted without a proper consensus—should now be grandfathered in and should enjoy the protection of a consensus to keep it from being overturned. Sorry, it doesn’t work that way. You subverted the way things were supposed to be done in the first place and this current mess is the result. Greg L (my talk) 06:36, 6 April 2008 (UTC)
    I feel as though I need to wipe flecks of e-spit off my face. It's obvious that you're very angry at me, though I'm not sure what I've done to deserve this. There was no consensus in Archive 22, just as there is none today. There was a significant majority in favor of using IEC prefixes wherever binary measures are used, and a significant minority opposed to their use everywhere. So someone made the guideline say they are "recommended but not required". Now there is even less consensus, so the guideline says that it should be decided on an article-by-article basis, like the variants of English, which I am pretty much fine with. Although I'd personally like to see standard prefixes used consistently everywhere, I recognize that others see it differently and I'm not ramming anything into anything else or trying to force my personal opinions on anyone. There are basically two opinions here:
    1. 9 out of 10 usages of SI prefixes are decimal, as per the standards, with a few sub-fields of computing an obscure, inconsistent, non-standard exception. We should use units consistently everywhere since we are writing a general-purpose encyclopedia, not a computer science textbook.
    2. 9 out of 10 usages of "KB" are binary, as anyone who has looked at a file size in the last two decades knows. This is the way it's always been, and everyone in the field knows when it has a decimal meaning (those lying hard drive manufacturers!) and when it has a binary meaning. The IEC prefixes are unnecessary pedantic prescriptivism, and should be banned from the face of the Earth. Also, they sound funny.
    How do we reconcile these? They're both well-founded opinions, but differ depending on the perspective you start from. As an engineer, I start from the perspective of SI prefixes being used consistently everywhere else; megaohms, kilowatts, milliseconds, kilometers, megajoules. This perspective isn't even about IEC prefixes, but about using SI prefixes correctly. IEC prefixes are just a convenient invention for facilitating this, so that we can say "512 MiB of memory" when it makes more sense than "536.9 MB". How many streams of 16-bit, 48 kHz audio can you fit down a 12 Mbit/s USB connection? How many 2-minute 128 kbps MP3 files can you fit on a 100 MB hard drive? None of these measurements are binary. People interested in computers typically start from the perspective they learned in their first computing classes with 5.25" floppies. In their field, in the last two decades, the usage is relatively consistent, and they don't see a need for disambiguation or standards. Especially not neologism standards invented purely to solve a non-existent problem. Their colleagues don't use the new standard, and they have no intention to either.
    The last few years this talk page has just been the same arguments over and over again. How do we come to an agreement on this? — Omegatron 07:59, 6 April 2008 (UTC)
  1. He's pointing out how you subverted process to force through your changes back then, also again recently you tried (and failed) to subvert process to force through your changes without talking about them first. He's then pointing out that your continued attempts at subverting process have been unwelcome and have not improved MOSNUM or Wikipedia for that matter. Fnagaton 09:55, 6 April 2008 (UTC)
  1. Omegatron you wrote "There was no consensus in Archive 22" yet you were using the word consensus to defend having your version of the guideline according to the archives "There have been many votes and discussions about this and the consensus is always the same." and "If we find that a particular consensus happens often, we write it down as a guideline"[1]. I'm also going to quote Omegatron from an earlier post he made when it was clear the vote didn't go the way he wanted "Please read false dilemma, Polling discourages consensus, Wikipedia:Polling is not a substitute for discussion, m:Polling is evil, etc. — Omegatron"[2]. I think I'll also make this choice quote "Bickering forever will not show any consensus and won't overturn the current guideline. -- mattb @ 2007-04-15T23:39Z" which seems to be an attempt to try to say "without consensus the guideline doesn't change". So Omegatron, with your admission that your guideline did not have consensus all your previous arguments in the archives that relied on "consensus" are now refuted. Fnagaton 10:30, 6 April 2008 (UTC)


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)
  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)
  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)
  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)
    • 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)
      • "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)
        • 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)
          • No, it's called "being neutral and unbiased" and "following the example set by the sources used". Fnagaton 20:56, 24 March 2008 (UTC)
            • 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)
              • 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)
                • 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)
              • 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)
                • 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)
  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)
    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)
    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)
    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)
    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)
  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)
  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)
  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)
  9. Comment I do not support Woodstones proposal because it supports a particular POV. Fnagaton 20:59, 24 March 2008 (UTC)
    • 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)
    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)
  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)
      • 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)
        • 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)
          • "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)
          • 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)

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)

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

  • 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")..." [3] Again I will have to use a ;) at this point. Fnagaton 19:55, 25 March 2008 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)

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

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)

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

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)

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

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


  • 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)
  • 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)
  • 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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_B8&oldid=1198217090"