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

Binary Prefixes-A compromise?

(Please don't break up the body of this text with comments. I do want your opinions, but I want to be able to read them. Commenting in the "Discussion" section would be much appreciated.)
So, we've been batting this back and forth, and still no progress at all, right?
Well, maybe that isn't entirely true. I could be misinterpreting, but it appears that the sides aren't quite as divided as it first seemed.
I know that some want internal consistency above all else, but, face it: That's not going to happen.
Article titles aside, there will always be some instances of "check" instead of "cheque" (even though "cheque" is entirely unambiguous), inches and centimetres (even though most standards suggest metric), liters and litres (even though it's pretty ballsy to use your own spelling for a unit you don't officially use). These things will never be entirely consistent. Even if one's more ambiguous than the other, common usage will force itself through. Even if one is suggested by different standards bodies, common usage will force itself through.
This is why we have IgnoreAllRules.
"If the rules prevent you from improving or maintaining Wikipedia, ignore them."
For example, the Megabit article has now been changed to IEC. Formally, it said that an 8 Mbit cartridge held 1 megabyte, and that a 4 Mbit cartridge held 512 kilobytes. This was helpful, in that it easily explained the descriptions used in the day. It now says that "an 8 Mibit cartridge held 1 MiB of data". However, though technically accurate, this new revision entirely misses the point. The point was to explain what an "8 megabit" cartridge of the day could actually store. Changing the units fundamentally changed the usefulness of the section. Now, there are three solutions to this problem:

1. Delete the section entirely. This was intgr and Sarenne's suggestion. Since the section isn't pretty for IEC, it should just be deleted. I don't like this solution, as it means less notable information would be allowed on wikipedia, just so it wouldn't get in the way of MoS.
2. Change all the occurrences of Mbit to actually having quotes around them. But this would make the article somewhat ugly.
3. Realize that there are valid "exceptions to the rule" when the rules hurt the article.

The two views

Here are the two views, as I currently see them:

KiB/MiB

• Internal consistency within wikipedia is paramount.
• Sticking to a single manual of style (whatever it is) is the best way to reduce edit-wars and promote said consistency.
• It's generally best to reduce ambiguity whenever possible.
• Several organizations have already accepted IEC. We don't use furlongs or cubits. It's growing, not shrinking.
• Wikipedia is descriptive, not prescriptive. It is the job of standards organizations to prescribe standards, and they have done so. It would be prescriptive use on Wikipedia's part to make a decision that these aren't the "right" way to do it, it is descriptive use to use the standards the way they are defined.

KB/MB

• Wikipedia is descriptive, not prescriptive. Yes, the IEC describes them as MiB. But, in this context, you're using MiB to prescribe how RAM capacity should be expressed. You're going against the de facto standard.
• Sometimes, even in the binary sense, conventional prefixes are easier to read, and easier to understand; especially when it lines up more consistently with the cited sources.
• Historically, it's silly to express values for older hardware in units that didn't even exist at the time. Yes, the article on Noah's Ark eventually includes feet and metres, when it's specifically helpful to do so, but the article starts out in cubits. Who the heck uses a cubit these days?!? Wikipedia. When appropriate for the article.
• I'd like the option of discussing changes to an article if there's debate, rather than being wikilawyered to death.
• I think that common sense, and the best interest of whatever article I'm editing, should trump a single sentence of a single sub-guideline, of a guideline. Otherwise, what's the point of IAR?

I know that people on both sides would disagree with some of those, and want to add their own, but I think I have the rough idea here.

Stop-gap Solution

I'll concede that there are places where IEC prefixes can be handy. If I had an article where both 2^20 and 10^6 megabytes were being used... I'd be very tempted to break out the ol' mebibytes, simply to make it easier to write, and easier to read. (A little bit of unfamiliar terminology is better than a lot of confusion, or a lot of clarifications in brackets!)
To that end, I'm not suggesting that people be disallowed from using the IEC prefixes. No, in spite of being the preferred standards of some organizations, they are not the standard. But, still, that's really more of a style issue to me. And I hate seeing "check" instead of "cheque" a lot more than a few mebibytes.
The only problem that I have is with the suggestion that I'm not allowed to address these concerns on individual articles. But, that's silly for any style-preference. And it's especially silly when the supposed "official" convention is directly contrary to the massively and globally preferred convention. To that end, here is my suggestion...
Changing:

If a contributor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should be accepted.

to

If an editor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should not be reverted without a specific supporting reason, and discussion on that article's talk page.

That is, still keeping the parts about, "The use of the new binary prefix standards in the Wikipedia is not required, but is recommended for use in all articles where binary capacities are used." You want to recommend them? Fine. Leave it there for when editors are creating new articles.
(I changed "contributer" to "editor", because the old phrasing has already raised the issue: 'drive-by' IEC-pushers. Technically, all of Sarenne's edits can be reverted on-site in articles where he's made no other edits, because he isn't technically a "contributer" to those articles. It's best to just nip this one in the bud, and use a more generic term.)
On the other hand, if an interested editor notices that a change to IEC made the article worse, then they at least have the option of trying to make a case for a revert. Does that mean the revert will be successful? Nah. They'd have to present a reason. On the other hand, it'd also require that people trying to change to IEC be willing to provide at least a minimal follow-through, and respect regular contributers of those articles. Is it ideal? No. But the current situation is worse.
Please note that this problem will never go away. But please also remember that the current incarnation will always have problems:

1. Even if the change isn't made, people can still "Ignore All Rules". This change is only proposed to remove the appearance of having that right taken away.
2. "Contributer" can always be used to revert changes to IEC. (Of course, you could just change that single word, but even that'd be marginal improvement.)
3. Note "it may be appropriate to change 512 MB RAM to 512 MiB RAM where it is important to do so." People can always claim that "it isn't important to do so" anyways.

My point is that there will always be disputes. I'd just prefer if those disputes were about the content rather than about small excerpts of sub-guidelines of guidelines. Bladestorm 21:22, 24 April 2007 (UTC)

Discussion of this proposal

(Again, please posts comments here, rather than in the middle of the above text)

• I realize this wouldn't fully satisfy either side (I'll forego the obvious, "if nobody's happy, then you're doing something right!" cliche), but I'm just looking for something that both sides can grudgingly accept as better than the total alternative to their position. Bladestorm 21:22, 24 April 2007 (UTC)
• It may also be a good idea to change, "it may be appropriate to change 512 MB RAM to 512 MiB RAM where it is important to do so." to remove the "where it is important to do so". It's conceptually redundant, and really only provides fodder for quibbling. Bladestorm 21:22, 24 April 2007 (UTC)
  • I can see you've put a lot of thought into this, and I think this is a productive line of discussion. The balance to be struck is between making this guideline too insistant and leaving it too open-ended. The problem with allowing for reversion "where there is a specific reason" is that it gives anyone an excuse to remove IEC prefixes for any one of the valid "specific reasons" that have been argued here. Scenario: editor changes an article to use IEC prefixes in appropriate contexts wherein there are no tricky adjective issues, another editor comes along and reverts them explaining that the general uncommonness of the IEC prefixes is a specific reason to remove them. Edit war or this entire discussion ensues on talk page, and we're back to square one (this played out a few times before we had the guideline, which is exactly what led to the strong wording). As much as I wish people wouldn't laywer over exact wording of guidelines rather than the spirit of them, that's precisely what often happens when two sides disagree on an editorial issue like this one.
  • Therefore, I think that we ought to think about the exact situations in which there might be exceptions to using the IEC prefixes. I think the adjective situation you mentioned is one important case; it's true that it is/was common to refer to "X-megabit" cartridges as a name as much as a description of capacity. Unfortunately I think we may end up back at our earlier arguments because there is a fundamental rift between those who believe IEC prefixes should absolutely NOT be used in articles whose sources don't use them, and those who utterly disagree citing consistency and unambiguity. That's become the crux of this argument at the moment, unfortunately your compromise does nothing to address this, and I cannot think of a good way to make both parties happy in that particular regard. I would be much more apt to a "decide on a per-article basis" solution if it weren't for the fact that this guideline exists in its current form because that DIDN'T work well before. It's really a sticky wicket, every bit as much as the US vs UK English issue (though I don't suggest that the issues are similar enough to use the same solution)... I don't mean to throw a monkey wrench in your noble attempt at a compromise, but frankly I just don't see how the two opposing views at the heart of this matter can be reconciled. -- mattb 22:31, 24 April 2007 (UTC)
    • Edit: To be clearer, I don't object to your proposed wording changes, but I don't think it assuages the current issue. It doesn't resolve the issue of which prefixes the Commodore 64 or Power Mac G4 articles should use, and those will still be points of contention between the two camps. -- mattb 22:49, 24 April 2007 (UTC)
      • Well, to be honest, if there are only a few specific articles where it wouldn't help, then I think that it should be at least an option to develop consensus for that article. I know you wouldn't like that kind of inconsistency, but I truely believe that, when there's a conflict, a discussion and evaluation of consensus for a single case, in a single article, is always in the best interests of that article. And, in a sense, that somewhat touches upon my whole point. I think that the MoS is a very good tool, but it really shouldn't be the final say in anything.
      • As for concrete examples where the exceptions would apply, other than megabit, DDR SDRAM comes to mind. I don't care how the ram in a computer/game console is expressed (I mean, I do care, but not enough to argue over it). But I do care about the glaring oversight in that article. RAM specifications/characteristics are not typically expressed in mebibytes. Maybe they should be. Maybe they will be. But, for now, they aren't. And the fact that the article acknowledges JEDEC specifications, and includes related links... well... that's just inappropriate. So, while although I don't care if the Wii has 24 MiB of graphics memory, I think an article on the memory type itself should closely follow the conventions of the source information. (Again, since you're essentially quoting a 'descriptive' property; ie. indicating how people describe the capacity.) But, to be honest, I'd prefer to try this approach before resorting to a list of exceptions. Because I'd prefer having to avoid re-examining the exceptions every time someone has a new dispute. Bladestorm 23:17, 24 April 2007 (UTC)
• I'd go for that solution. (Generally, you shouldn't be reverting anyone without discussion anyway, except blatant vandals, so I've no problem with clarifying that.) I do have an issue with the OWNership tone of the above, though. Anyone making a factually-accurate, non-vandalism edit to an article is a contributor to that article. Period. A person who's made five thousand edits to an article has no "right" or "claim" to deciding on its content over and above the person who only edits it once. Seraphimblade ^{Talk to me} 22:35, 24 April 2007 (UTC)
  • Well, I'd argue that simply changing from one style preference to another in an article, and doing nothing else, doesn't really mean you've "contributed" to that article. (If I decide to change "check" to "cheque" in an article, and nothing else, have I really "contributed" to it?) You're right that 'OWN'ing articles is certainly a contributing factor to the conflicts. (on the other hand, is it possible to 'own' a style preference? food for thought) To be honest, my desire to change "contributer" to "editor" isn't a reflection of how I personally feel, so much as an attempt to cut off a potential source of conflict. Since "editor" is at least equally good, and doesn't provide fodder for conflict, I consider it mildly preferable. :) (Similar to why I'd prefer to remove the "where it is important to do so" part as well.) Bladestorm 23:17, 24 April 2007 (UTC)
• I'm not a fan of guidelines that don't actually guide anything. That's as bad as removing the entire issue from the guideline. --SLi 23:06, 24 April 2007 (UTC)
  • Well then, I guess the first thing I'd ask you is: Do you really believe that? That it'd be just as bad as removing the issue entirely? It still suggests IEC. It still explicitly establishes that people need to defend their choice of common usage. It's just that it acknowledges that everyone needs to defend their position when a conflict arises. Don't forget that this is already true. IAR always applies, in spite of MoS saying, "it should be accepted". In the end, I truly believe that a guideline should be just that: A guideline. A trusted example of how it's best to write articles in the general case. Exceptional cases will always require exceptional treatment. This is just an attempt to force it into a discussion of the topic rather than an edit-war based on interpretation of policy. Bladestorm 23:17, 24 April 2007 (UTC)
  • Paradoxically enough, guidelines with somewhat "softer" language sometimes are much better observed than those which are "strict". In this case, what we're saying is "Yes, you're welcome to object to the binary prefixes if there's call for it in a specific case, but you need a better reason than "I don't like them" or "They're uncommon." I think, actually, that may make the guideline more likely to be widely followed. Seraphimblade ^{Talk to me} 23:30, 24 April 2007 (UTC)
  • In July 2005, 29 people voted on a guideline to "encourage the use of the IEC prefixes". It carried 20 to 9. This January a campaign started to force the IEC prefixes and we found out that a significant number of contributors don't agree with this style "guideline" How many MOS topics generate discussions can be measures in megabytes/month? There is no consensus. Is "internal consistency" the sixth pillar of Wikipedia? The binary prefix style guideline is not consistent with higher level guidelines and official policy.
  • Getting people to create content is difficult. Insisting people use some esoteric jargon doesn't help. Insisting that a guideline must be strictly enforced or people won't use the IEC prefixes should tell you something. -- SWTPC6800 02:28, 25 April 2007 (UTC)
    • There's no point in arguing about our respective self-serving views. Internal consistency is in fact extremely important to many editors, seen to be (at least by myself) critical to the primary goal of this site; producing a high quality encyclopedia. You're not likely to convince people that internal consistency is of secondary importance by offering your take on policy any more than I'm likely to convince you that using the IEC prefixes isn't evil by offering mine. -- mattb 03:12, 25 April 2007 (UTC)
      • Matt, I was responding to the positions of Seraphimblade and SLi (above) that anyone can just totally disregard the opinion of the major editor and the guideline must be forceful. You are rightly protective of the articles you work on. The IEC prefixes are not evil, they are just inappropriate in some cases. -- SWTPC6800 04:01, 25 April 2007 (UTC)
        • As was pointed out earlier the "major editor" of an article doesn't own it. While I understand the desire to protect what you've written, that's totally the wrong attitude. If the binary prefix guideline were ever revoked, I'd personally remove them from the articles I've written. -- mattb 04:06, 25 April 2007 (UTC)
        • (EC) Swt, kindly do not misrepresent my position. I actually stated, right here above, that allowing the occasional exception, if someone could put forth a good reason as to why it's required in a specific case (say, for example, there's a legitimate reason to doubt that the value in question really is binary), is a good idea. That's really always the case anyway-even policies can be ignored for good cause. "Good cause" is important, though. In this case, we do need some form of internal consistency, as using the binary prefixes for binary values in some places and the decimal prefixes for them in others may make it appear we're stating the ones represented decimally really are decimal. That would be even more confusing than consistently using decimal prefixes. If you can show that a binary prefix is inappropriate in a given case, it shouldn't be used, simple as that! But a better argument should be offered than "I don't like the things" or "I'm the major contributor to this article, so I decide what edits are acceptable." Everyone has exactly the same right to edit any article on Wikipedia, whether it's their first edit to it or their five hundredth. Seraphimblade ^{Talk to me} 04:32, 25 April 2007 (UTC)

• There are two issues here.
  • The first is the "internal consistency" argument, which isn't that strong because currently in Wikipedia we have seen examples of articles that use different measurements as their primary source. These measurements have also been and in some cases continue to be ambiguous and even the SI says only use the metre, yet those other measurements are still used. Not one person who promotes binary prefixes has answered that question properly, not one person can show where it has been answered properly in the past either, despite challenges to provide that evidence, not one person. I know some claim to not want to answer it because it is a loaded question, it is not really a loaded question. It is however a question that has an answer that some people are not going to want to give and this is because it demonstrates something which is contrary to their belief. The "internal consistency" argument has therefore not been demonstrated to an adequate extent and this is because it doesn't really exist in practise. What does exist in Wikipedia is consistency with terms used in reliable sources.
  • The second issue is the edit warring, bad feeling the changes to using binary prefixes generates in articles, this is not a small problem and it is not a minority of articles.
• I think there is only one clear option that will help both issues, this option is the same as the solution found for using measurements, which is to use the terms found in the majority of reliable sources used for each article. All this means that binary prefixes can be used in articles that can show their reliable sources using those prefixes. This also means that those articles that have reliable sources mostly using non-binary prefixes then do not use binary prefixes in the article. This also means that if in the future a majority of newer reliable sources using binary prefixes exist for a particular article then that article can be changed to use binary prefixes. This is the most natural method of change, it doesn't force binary prefixes to be used however it does leave the option to use them if in the future binary prefixes are more commonly used.
• Note this doesn't mean someone can try to use the fallacious argument of "why don't we use cubits for the Pyramids?" and this is because the majority of modern current research and hence the reliable sources for the Pyramids now use the metre. Note it also doesn't mean someone can use the fallacious argument of "but kilobyte means different things argument" and this is because the modern context is that the JEDEC standard defines those terms. You don't see articles in Wikipedia refusing to use yards just because in the past those measurements meant different lengths, for example. So in the same context you wouldn't try to use the "different things" argument for kilobyte etc. Fnagaton 09:42, 25 April 2007 (UTC)
  • The "meter" argument is answered easily. A foot, a yard, or a mile all represent a fixed, unambiguous length, and always have. A gallon or quart represents one fixed quantity. A megabyte does not. Seraphimblade ^{Talk to me} 09:48, 25 April 2007 (UTC)
    • You are wrong, for the reasons already mentioned above. To briefly reiterate the point, the yard was not always fixed and did mean different lengths depending on the country, state, county etc. The JEDEC standard defines KB,MB,kilobyte, megabyte etc so the megabyte and kilobyte are fixed quantities. Also the SI says only use metre, yet you have not answered the question why some articles do not use the metre. As demonstrated many times before the facts refute what you have written. Fnagaton 09:52, 25 April 2007 (UTC)
      • True, "yard" was at one point ambiguous. It now is not, it represents three feet. If we were using a historical source which was known to use a different version of the yard, however, we would certainly not just say "yards" because that's what the source says. We would instead clarify or disambiguate. In the case of (KB/MB/GB), the terms are still ambiguous to this day. If we're referring (to go a ways back in time) to a "512 MB hard drive", we are not referring to the same quantity as if we refer to "512 MB of RAM." In the case of the RAM, we are also not logically referring to the quantity. In the standard metric system, the "mega" prefix indicates one million.
      • Also note that JEDEC, while it may define standards, is not really a standards body. I can define a standard. I define that the "snargleblatt" is a unit of measuring distance, and shall measure exactly 1.5312 miles. But I'm not a standards body, so that really doesn't matter. On the other hand, IEC, SI, ANSI, and IEEE are standards bodies, and all of them define and endorse the binary prefixes for use with binary values, just like they state that a yard is three feet and a kilometer is one thousand meters.
      • As to why we do not use the meter in all cases, it is better, when possible, to provide round numbers. When we say that a football field is 100 yards in length, however, that is not an ambiguous figure. It's 300 feet, or 3600 inches, or 91.44 meters. There is no ambiguity in that measurement. However, in converting to binary prefixes, we do not lose "number roundness". (Indeed, I would be against changing, for example, hard drive capacities to binary capacities, where we would lose number roundness. It is indeed better to represent hard drive capacities with the round decimal values, say "200 GB".) However, in other cases it is the reverse-to properly represent binary capacities using the decimal values, we would lose roundness that way. (For example, 512 mebibytes would actually be 536.870912 megabytes, not a very nice number at all!) So, in that case, we should also use the unit giving us the nice round number, and in that case, that unit is the binary one. Seraphimblade ^{Talk to me} 10:14, 25 April 2007 (UTC)
        • Again the facts refute what you say and you have presented nothing new. To demonstrate how your point is wrong I can cite sources that say yard but actually use a version of yard that differs from the one defined by SI, this means you now have to remove yards from all Wikipedia, yet you have not done so. The round numbers argument is therefore fallacious since it is claimed binary prefixes should be used to be consistent regardless of the sources used. The JEDEC standard defines terms for use in the solid-state industry, this means computer memory. Using the terms that are used by the majority of reliable sources is not ambiguous. The JEDEC is a standards organisation and for you to repeatedly claim otherwise is misrepresentation. I can see why you think you're right but you are wrong because you are missing several subtle points and you're also dismissing evidence that you have given no good reason to dismiss. Fnagaton 10:22, 25 April 2007 (UTC)
        • Seraphimblade, if you can get the U.S. government to back the "snargleblatt", I will start working it into articles. The FTC thinks JEDEC is the standards organization for semiconductor memory.-- SWTPC6800 22:43, 25 April 2007 (UTC)
          • How about NIST, a US governmental agency that actually has something to do with science and technology? You're still riding on the assumption that the JEDEC's usage of common terms implies mandate or even endorsement. I'd hold off on arguing that interpretation until they email us back. -- mattb 23:49, 25 April 2007 (UTC)
            • No you have it the wrong way round, you're trying to imply that terms defined in a standards document are not part of that standard. Fnagaton 09:34, 26 April 2007 (UTC)
              • Binary prefixes are also defined in the standard and, like it has been said many times, the standard states: "The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage", so IMO it's not prescriptive (because the standard gives an alternative) and you'll have to wait for the official answer if you think it is prescpritive. Sarenne 10:01, 26 April 2007 (UTC)
                • You are making the same mistake. Binary prefixes are included as a footnote and not part of the main definition. You are making an assumption (that the kilo-,mega- terms are not prescriptive) when you have provided no evidence to support that assumption. Until such time you can point to a phrase that specifcally says "do not use these terms" you cannot logically assume that. You are welcome to your opinion but it would be wrong to present it as fact. In the absence of any evidence you must then look towards the secondary sources and the vast majority of those sources use kilobyte, megabyte etc. Fnagaton 10:14, 26 April 2007 (UTC)
                  • Why do you think they added "are included only to reflect common usage" if they wanted the definitions to be prescriptive ? According to me, this a huge evidence...Sarenne 10:23, 26 April 2007 (UTC)
                    • Only in your opinion and that is not fact. You should look at the larger body of evidence from documents produced that follow the JEDEC standards, those documents use kilobyte, megabyte, KB, MB etc. Fnagaton 10:33, 26 April 2007 (UTC)
                      • They use them, that's all. Sarenne 10:56, 26 April 2007 (UTC)
                        • No that is not all, they are defined in the standard document produced by a standards organsiation that is relevant to the specific industry. It is illogical for you to dismiss that or to make assumptions without explicit evidence. As already shown above the standards document is prescriptive. Fnagaton 11:07, 26 April 2007 (UTC)
                          • For the last time, the standard indicates that the definitions "are included only to reflect common usage". According to me that's an explicit evidence and if according to you that's not, then you'll have to wait for their answer. Sarenne 11:19, 26 April 2007 (UTC)
                            • No, you are still repeating the same mistake as shown above. You are still making assumptions without explicit evidence. The facts refute what you have been posting, for the reasons already given. Fnagaton 11:51, 26 April 2007 (UTC)

This is getting out of control

The claim above that "JEDEC, while it may define standards, is not really a 'standards body'" shows have far this discussion has drifted into original research. According the http://www.jdec.org "JEDEC is the leading developer of standards for the solid-state industry." Absent reliable sources that say they are lying, that is pretty definitive.

In addition, standards bodies are primary sources. WP:OR says "Primary sources that have been published by a reliable source may be used in Wikipedia, but only with care, because it's easy to misuse them. ... Any interpretation of primary source material requires a secondary source." The interpretation here is not what the IEC prefixes mean, but the extent to which their adoption by various standards bodies mandates their use in Wikipedia. WP:OR goes on to say " Wikipedia articles should rely on reliable, verifiable, published secondary sources wherever possible."

Overwhelmingly, the secondary sources which are the bedrock of Wikipedia, have not adopted the IEC prefixes. That has two implications. First, as a tertiary source, we should give great weight to secondary sources near unanimous judgment against the use of the IEC prefixes in publications intended for a general audience. Second, the fact that the secondary sources do not use the IEC prefixes units makes it hard for readers to verify information presented in Wikpedia articles that have been edited use them. The edits being disputed here are based on the notion, as expressed by one supporter of the present guideline, that the editors who make them are "presumably more knowledgable" than our readers. This is inconsistant with NOR and with WP:Verifiability which begins "The threshold for inclusion in Wikipedia is verifiability, not truth." V and OR are pillar principals of Wikipedia. A guideline that contradicts them is simply not valid.

I, and I think others who are concerned about the current wording of the guideline, are acting in good faith to try and find a more broadly acceptable solution. I was under the impression that we were trying to agree on wording for a proposed poll. Lately there have been comments that call that into question. If we cannot have a constructive discussion here, which I think is the most appropriate forum, then other dispute resolution mechanisms may need to be invoked. --agr 16:19, 25 April 2007 (UTC)

Well said, I am also trying to work towards a poll but when some of the other editors here write things which are obviously not true (e.g. remarks about JEDEC or the ad hominem) then I have to take that to mean they are not interested in working towards getting this resolved by using proper debate. To that end I have also been thinking along the lines of other dispute resolution procedures. Fnagaton 16:46, 25 April 2007 (UTC)

Very well. We're discussing specificity here, so calling me on a lack of it is fair enough. I already alluded to the fact that anyone (including you or me) can set a standard. However, there are certain bodies recognized worldwide for setting of all standards. Not just for a specific industry, not just in a specific country, but across the board. ANSI, IEEE, IEC, and SI are all such bodies. And they all endorse the binary prefixes. Even if JEDEC specifically disagrees with them (which has been called into question as well), JEDEC's opinion simply does not outweigh widely-recognized international standards bodies, many of which existed before the PC ever did. However, to me, it doesn't look like JEDEC's even specifically saying "The standards bodies are wrong." They're simply saying "A lot of the time, the decimal prefixes are used to represent binary values." I don't see anything to indicate that JEDEC endorses or recommends that practice-simply that they state it does happen. Seraphimblade ^{Talk to me} 00:04, 26 April 2007 (UTC)

The terms are defined in the standards by the JEDEC who are the standards organisation. To try to dismiss the fact that those terms are defined simply because you disagree with them being used is illogical. As mentioned above you should be looking at the reliable sources relevant to the articles and using their example as to what terms to use. Fnagaton 09:32, 26 April 2007 (UTC)

Are you stating that the aforementioned organizations (ANSI, etc.), as well as NIST, aren't standards organizations? It's certainly sourceable as to what their definitions of the standards are, and they are clear-decimal prefixes for decimal values, binary prefixes for binary values. Seraphimblade ^{Talk to me} 09:35, 26 April 2007 (UTC)

No, what I am saying is that the terms KB,MB etc are defined in the JEDEC standard and for you to try to imply that terms defined in a standard are not endorsed is illogical, it is even more illogical when you apply that reasoning selectively to terms that you don't like. What you should be doing is to understand that standards organisation can and do differ, which is why Wikipedia should not concentrate on those primary sources. What should be done, as already explained above, is to use the terms used by the majority of reliable sources that are relevant to the topic being written about in an article. This is done elsewhere in Wikipedia. Fnagaton 09:54, 26 April 2007 (UTC)

To add to above, if you wished to, you certainly could request a mediator. I think that might be very helpful at this point, and I'd certainly be willing to participate. Seraphimblade ^{Talk to me} 00:06, 26 April 2007 (UTC)

Just to make something clear here: Can I get a quick "yes" or "no" (informal) as to who does or doesn't approve (even if grudgingly) of my proposed change? Bladestorm 17:14, 25 April 2007 (UTC)

With all due respect Bladestorm I don't think your proposed "Stop-gap Solution" will help the issue much so I cannot support it. A user could still come along and make the change to binary prefixes in say the Commodore 64 article, it would then get reverted giving the reason "the majority of reliable sources do not use binary prefixes" and then the user who made the binary prefix change could still just dismiss that as in their opinion any reason "is not good enough". There needs to be more clarity. Specifically I think the parent MoS guideline where it says "use the original style of the first major contributor" coupled with some wording like "use the terms used in the majority of reliable sources" would fix the issue. Fnagaton 09:32, 26 April 2007 (UTC)

• Shrug* I understand your argument and see how you might feel that way, but I (and plenty of others) simply disagree with it. I think you're bending policy to serve your views, which is fine, but trying to insist upon your interpretation won't win over other parties. I don't agree with your classification of application of this guideline as original research, and I stand behind my assertion that the editor who makes these sort of changes is usually more knowledgable than the average reader. The confusion that has played out over this many times in the past is evidence enough to back my statement as reasonable. We may well be beyond the point where further discussion will do us any benefit, but I should warn you that escalating this to higher levels of dispute resolution will drag it out even longer. Even at higher levels of dispute resolution, nothing will be accomplished if we can't present both sides of this in a terse and dispassionate manner, free from our own interpretations of policy. This tit-for-tat bickering and bringing up the same tired arguments will lead to nothing but making this talk page longer. Regarding Bladestorm's change, I don't oppose it, but I don't think it solves anything so I don't support it either. -- mattb 17:21, 25 April 2007 (UTC)

Re: "I think you're bending policy to serve your views" : Stop right now trying to second guess motives, you are wrong to do so. Plenty of others also disagree with your position and the sweaping edits made to articles that don't need it, as demonstrated by the figures above.Fnagaton 09:32, 26 April 2007 (UTC)

I don't approve. It's too ambiguous and opens a can of worms on what's a good enough reason. Depending on how it's interpreted, it might allow people to disrupt internal consistency for some very poor reason. --SLi 14:10, 26 April 2007 (UTC)

Appoach in the style of conversions

Has it been proposed to take the same approach as for conversions? State one unit and in brackets indicate the other one. In this specific case the two units could have the same spelling, so a qualifier would be needed. Examples:

• a memory chip of 512 MiB (described as 512MB)
• a memory chip described as 512 MB (512 MiB)
• a disk of 512MB (488 MiB)

This usage would show that an editor has done an interpretation and still allows verification with sources. Both proponents would see their preferred units. For readers unfamiliar with MiB, the MiB could be linked the first time in an article. −Woodstone 09:59, 26 April 2007 (UTC)

For those articles where the majority of reliable sources do not use binary prefixes. I would grudgingly accept the second and third options because it maintains the style used by the majority of reliable sources relevant to the article "512 MB" in the context that it was written in and has the binary prefix term in brackets which should placate those who want to use them. The first option is not acceptable because it does not maintain consistency with reliable sources. If new articles can cite a majority of reliable sources using binary prefixes then of course those articles can use binary prefixes. Fnagaton 10:08, 26 April 2007 (UTC)

If sourcing is all you'd like, the question is settled. I've actually begun work on a template which contains the ANSI, IEEE, IEC, SI, and NIST endorsements of the binary prefixes. So, every article can have a ton of reliable sources on them, simply by subst'ing a template. Seraphimblade ^{Talk to me} 11:31, 26 April 2007 (UTC)

No, relevant reliable sources, i.e. sources that discuss the specifc topic in the article. That means using the terms used by the majority of reliable sources, which means using kilobyte, megabyte, KB and MB. Fnagaton 11:54, 26 April 2007 (UTC)

I fail to see how sources that discuss capacities fail to be relevant to the use of such terms of capacities. Still, the "dual listing" style would be alright by me, that would solve the ambiguity issue, and that's all I really care. (And I couldn't care less which one's first.) Seraphimblade ^{Talk to me} 12:02, 26 April 2007 (UTC)

The sources you propose are not the majority of relevant reliable sources. It goes back to the minority primary self published sources versus the majority of accepted secondary sources argument. Which was presented above. Fnagaton 12:08, 26 April 2007 (UTC)

Sources most relevant to the articles are the ones that contain the actual numbers cited, not just the definition of the unit. Those are the ones against which verification is possible. However the interpretation of the units is often not obvious from those sources. Therefore, providing a well founded interpretation is a valuable service to the reader. The unit MiB (etc) is not ambiguous and does not need a qualifier. If also a unit MB (etc) is given, with the same value, it needs a qualifier like "described as", to avoid creating a conversion conflict. −Woodstone 13:01, 26 April 2007 (UTC)

Adding terms such as MiB is inconsistent with the sources provided, to allow the reader to easily verify the terminology used in the article with the majority of relevant reliable sources the text should be left unchanged as much as possible. As other articles in Wikipedia demonstrate they use the terms used in the source as part of the text (without a "described as" qualifier) and then add the term not used in the source in brackets. For example the article on American Football says "360 feet (109.7 m)" it doesn't say "109.7 m (described as 360 feet)" even though technically the later complies better with the SI standard it's not used because it is inconsistent with the sources used in the article. Fnagaton 13:52, 26 April 2007 (UTC)

Look, those arguments about JEDEC prescribing something it doesn't and the footnote not being worth anything and we having to use meters in American football articles have been answered a million times and are really so ridiculously different from the issue here that repeating them again and again makes no sense. Don't you have *anything* new at all to say that hasn't already been debunked so many times? I tried to stop arguing with you about issues that have been explained already too many times and you still don't get them, but I can't help the frustration. I'd hope others would do the same unless they really see a chance in putting them in so clear words that you wouldn't just repeat your argument which amounts to "but... JEDEC and American football! That stupid footnote is just a footnote, it doesn't matter! That's WP:OR, no matter it has been explained to me a gazillion times it's not!". Sorry, just extremely frustrated... :( I'm starting to wish there was a way in Wikipedia to programmatically ignore someone in talk pages. --SLi 14:39, 26 April 2007 (UTC)

No you are wrong, answers may have been given previously but those answers either tried to dismiss the facts or contained assumptions without evidence to support that position, therefore the answers were not proper answers, therefore the questions are still open and need to be answered properly with valid evidence and valid argument. You are also dismissing the new points by misrepresenting what has actually been written on this page. The facts refute what you have written and all this has been explained above in great detail. Fnagaton 14:57, 26 April 2007 (UTC)

These are all ok, I can find no reason to oppose them. Also I couldn't care less about which one of these is used. I only want the ambiguity gone. --SLi 14:28, 26 April 2007 (UTC)

There's no need to modify the guideline to apply this proposal. Furthermore, I think it is useless to add the "described as" information except if there is a particular historical reason. I don't think it is a relevant information in the general case. The conversion of decimal to binary units (3rd example) should also be "optional" and I don't think it is necessary to add it in the guideline because it is already included in WP:UNITS. Sarenne 15:46, 26 April 2007 (UTC)

I suspected you would write something that and I'm not surprised to see it. Your post is understandable because you have made hundreds of edits and you would be faced with either seeing them changed or having to change them yourself. However look at the other replies from those supporting binary prefixes, they don't seem to mind which option is chosen. I have to say since they don't seem to mind then why do you? Rejecting the compromise (where the binary prefixes are added in brackets after the terminology used in the sources) would mean it is more likely to cause more problems. Fnagaton 16:01, 26 April 2007 (UTC)

I think the "described as" is important. It makes no sense to say 64 kB (64 KiB), for example. Or did I misunderstand what you said? --SLi 15:51, 26 April 2007 (UTC)

I meant that "described as xx MB" is often not relevant (it adds very little information), not only "described as". You're right, it makes no sense to say 64 kB (64 KiB).Sarenne 16:02, 26 April 2007 (UTC)

Adding "described as" isn't included in other conversions, so I don't see a reason why it should be added here. It adds extra fluff. The sources show what it was "64 KB" for example, putting in the binary prefixes in brackets afterwards "64 KB (64KiB)" removes what you see as any ambiguity. A compromise that fixes both problems as far as I can see, i.e. it keeps the original wording/terminology from the sources and you see binary prefixes. Fnagaton 16:01, 26 April 2007 (UTC)

There's no way you are going to get support for that. It's as obscure as and as wrong as saying 2 (3) without any explanation. #3 is very much ok though, and preferable to only listing the size in MB. Also please note that "64 kB (64 KiB)" is not at all what Woodstone proposed. --SLi 16:06, 26 April 2007 (UTC)

What I wrote is the same as #3, just using a memory size as the example. For example "The Commodore 64 has 64 KB (64 KiB) of memory." , "the disk is 512MB (488 MiB)". The first example shows that the 64 KB used in the sources is the same as 64 KiB. The second example does the conversion. Both the examples include the binary prefix term you want to see, both examples use the wording found in the sources. A realistic compromise. I have to say at this point if you cannot accept that compromise then I'm going to have to agree with Bladestorm in calling for a third party to arbitrate since I think this current compromise is the closest we are likely to get to an agreement. Fnagaton 16:17, 26 April 2007 (UTC)

I agree it would probably be the best option to get help from a third party. --SLi 18:32, 26 April 2007 (UTC)

I'm done with the binary prefixes debate

Dearest fellow editors. This debate has raged for weeks without any progress being made. Every attempt made to settle on a clear statement of both views has failed and decayed into more bickering. Attempts at reconciling fair and dispassionate descriptions of both positions for a vote have all failed and decayed into more bickering. Personally, I have seen no new or compelling arguments, just new takes on the common usage perspective (you're entitled to disagree and I understand how you could, I'm just stating my opinion here). I'm hereby dropping out of this discussion altogether since I don't think another twenty pages of dialog will get us any closer to a solution that everyone is happy with. It is at the point where both sides are insisting that their way is the correct way, and no progress will be made with these attitudes. With significant numbers of people on both sides of this table, I see no consensus to change the guideline as it was adopted (you're also entitled to disagree, again my opinion).

This has gone on too long and I simply have nothing further to say about it. I'll be watching but not participating. Have fun. -- mattb 14:13, 26 April 2007 (UTC)

Clear statements were provided above. I thought we were waiting for clarification letters from JEDEC.--agr 14:45, 26 April 2007 (UTC)

I have not received a clarification email from the JEDEC yet. I did get an inital reply though, which said it was being forwarded to an expert. Fnagaton 14:48, 26 April 2007 (UTC)

I received the same response to my initial email. I'll post the results if I ever get a reply. -- mattb 15:01, 26 April 2007 (UTC)

Fair enough mattb, hope to see you on the flip-side. I have to say though that while some points may appear to be the old "common usage" argument it's not really since I think there have been new arguments presented that were not discussed in such detail. For example, but not strictly limited to, the role of the JEDEC and the standard, the real world test of the guideline which in turn demonstrated several problems, the argument of using secondary sources where possible. These are all new bits of evidnece and argument. I therefore think it would be presumptuous to try to dismiss a position by saying "it's the old common usage argument" without first understanding that these new points have been introduced. Looking back at the initial discussion before the guideline was introduced (years ago) I probably would have even voted for the binary prefixes to be used. However after seeing them used in articles and in places where they shouldn't be I think that now the use of the binary prefixes certainly goes beyond the spirit of the inital discussions that lead to the guideline and hence goes beyond the spirit of the guideline itself. That's why now and with this new information I have to oppose to blanket use of binary prefixes. Fnagaton 14:48, 26 April 2007 (UTC)

mattb, I'm starting to wish I had the same patience as you to keep out of argumentation that goes in circles. To me too (I've been reading your statements re: RfA) Wikipedia is luckily a less important aspect of my life and I don't feel too strongly about things here going one way or the other, not meaning that I like things going the wrong way. I don't know why it's so easy to ignore a troll in Usenet news or IRC and go do something else for a while but here I keep coming back (although lately less) to this discussion (although lately luckily much less!). Thanks for your contribution to this discussion, anyway. --SLi 14:59, 26 April 2007 (UTC)

Time for a third party

Okay, so I guess matt is right: We aren't really getting anywhere. My middleground proposal was rejected. The strictly IEC approach is clearly rejected. The strictly common use is clearly rejected. Basically, every option has been rejected. (although, I must say that I strongly oppose the phrasing, "I see no consensus to change the guideline as it was adopted". There is definitely no consensus to keep it either.) Anyways, I think we need a third party solution here. Mediation? Options? Because I think the one thing that everyone can agree on here is that we are not going to agree to a solution here. So, what are the options? Bladestorm 15:06, 26 April 2007 (UTC)

Hold on a sec though, I think there is almost last minute compromise judging on the last few comments on using the terminology in the majority of relevant reliable sources and placing the binary prefixes in brackets, an example from the Commodore 64 article would be "Tramiel dictated that the machine should have 64 KB (64 KiB) of RAM".

Whoa. I'm fine with that. K. Holding on. Bladestorm 15:52, 26 April 2007 (UTC)

Ok, seems we now agree we don't agree and need a third party. --SLi 18:33, 26 April 2007 (UTC)

If the compromise version is disagreeable, I suppose it'd need mediation. It's quite alright by me to do the parenthetical notation, this seems to address the main concern of those against using the prefixes (inconsistency with cited sources), while also addressing the concerns of those for (removal of ambiguity, compliance with standards bodies.) I personally think it's an excellent solution. Seraphimblade ^{Talk to me} 09:44, 27 April 2007 (UTC)

Which parenthetical notation do you agree with ? Fnagaton's or Woodstone's ? Sarenne 09:53, 27 April 2007 (UTC)

Woodstone's top one strikes me as the least ambiguous, but really, if we can put an end to this damn thing, and still make sure the concerns are resolved, I'll go with whatever does so. Seraphimblade ^{Talk to me} 10:03, 27 April 2007 (UTC)

The last option is the only acceptable one for me. It would mean that the phrase "The Commodore 64 has 64 KB of memory." would translate to "The Commodore 64 has 64 KB (64 KiB) of memory.". The other options change the consistency with the sources too much and introduce the "described as" wording which is extra fluff, we don't see lengths having the "described as" qualifier in the American Football article for example. That is to say, since the sources use KB etc then they need to be the primary value used in the article with the binary prefixes following in brackets. Fnagaton 10:10, 27 April 2007 (UTC)

The "last option" is not the option that you propose. "512 MB (488 MiB)" is a unit conversion, "64 KB (64 KiB)" is an interpretation (without explanation) that adds confusion. With your solution, it will be possible to see 512 MB (488 MiB) and 512 MB (512 MiB) in the same article. According to me, that's inconsistent. In the American Football article, it's a conversion. Sarenne 10:21, 27 April 2007 (UTC)

No, my example uses the same style as option number three and the American Football article. In that article the first unit is the unit used by the sources, feet, which is then followed without any qualifier by the metre length in brackets. For proof of this look at this quote "American football is played on a rectangular field 360 feet (109.7 m) long by 160 feet (48.8 m) wide." and show where there is extra wording? Exactly, there isn't any. My example does not add confusion because the KB and KiB would be linked to their respective pages. My example adds less confusion that the other two options because it doesn't add extra fluff text and it uses the style and terms used in the relevant reliable sources in the article text. It makes it clear to the reader that KB/MB are used in the sources with the binary prefixes in brackets. Fnagaton 10:30, 27 April 2007 (UTC)

"360 feet (109.7 m)" is a conversion, "64 KB (64 KiB)" is not so if you really want to indicate that "KB" is the term used in the sources (IMHO it's very often useless), you have to add "extra fluff". Sarenne 10:38, 27 April 2007 (UTC)

Not really. "64 KB (64 KiB)" is a conversion between two units that produces the same numbers, that's all. In most cases it will be a similar conversion. So really there isn't that much ambiguity (just like using yards which were once many different non-standard lengths they are now fixed) and so there isn't a need for binary prefixes. Congratulations on realising that binary prefixes are not needed. :) Fnagaton 10:56, 27 April 2007 (UTC)

If "it produces the same numbers", it's the same unit. Sarenne 11:12, 27 April 2007 (UTC)

You are one of those who wants to use binary prefixes, so I'm compromising by showing an example of how you can still use them while also showing how you can in return compromise by using the example shown by the majority of reliable sources. i.e. "64 KB (64 KiB)". The example I gave produces the least amount of change, without adding fluff, without adding confusion and takes into account both sides. Since I've compromised then it would be niggardly for you not to compromise to this realistic solution. Fnagaton 11:23, 27 April 2007 (UTC)

IMO it adds confusion so it's not an acceptable compromise. Sarenne 11:40, 27 April 2007 (UTC)

Well I think adding extra fluff confuses the issue rather than makes it clearer. The idea being that the less change the better in this instance. Fnagaton 11:47, 27 April 2007 (UTC)

(lose indent)
In the case of feet and metres there is no ambiguity, as both units are (nowadays) uniquely defined. Just adding the conversion is clear and always leads to the same number. In the case of MB this is not the case, as M may be a binary or decimal prefix. As expressed above by Sarenne, one article could contain instances of both 512 MB (488 MiB) and 512 MB (512 MiB), leading to confusion. Therefore some qualifier is needed to show that the editor was aware of the ambiguity. Qualifying the ambiguous unit (K/M/G) is the most logical, as proposed initially. However a reversal is possible, adding the option in the third line:

• a memory chip of 512 MiB (described as 512MB)
• a memory chip described as 512 MB (512 MiB)
• a memory chip of 512 MB (actually 512 MiB)
• a disk of 512MB (488 MiB)

−Woodstone 11:18, 27 April 2007 (UTC)

The "actually" doesn't help since it is actually "512 MB" and this is a fact as would be shown by the sources. The choice of word is overly point of view. Length and currency conversions don't have "actually" in them, do they? Unless you would be willing to accept "512 MB (using the neogolism 512 MiB)"? I thought not. ;) Fnagaton 11:23, 27 April 2007 (UTC)

I think the difficulty isn't the situations where K/M/G are being used in the binary sense, but where they are being used in the decimal sense. We need a way to indicate that. I think the simplest method is to use explicit numbers (2²⁰, 10⁶, etc.) I have no problem with using the IEC units parenthetically where the K/M/G meaning is binary, but I don't think they should be used where the meaning is decimal. So what I am suggesting might look like this

• 512 MB of RAM (2²⁹ bytes or 512 MiB)
• 80 GB hard drive (80 X 10⁹ bytes)

--agr 11:49, 27 April 2007 (UTC)

Wouldn't that be a bit too heavy to include that much extra text for every use of KB/MB/GB? Fnagaton 11:53, 27 April 2007 (UTC)

If "actually" sounds POV to you, let's look for a better word; exploring:

• a memory chip of 512 MB (meaning 512 MiB)
• a memory chip of 512 MB (MiB)
• a memory chip of 512 MB (=MiB)
• a memory chip of 512 MiB (or MB)
• a memory chip of 512 MiB (=MB)

−Woodstone 12:33, 27 April 2007 (UTC)

I would accept this option for the cases where the numbers are the same:

• a memory chip of 512 MB (MiB)

Fnagaton 22:00, 27 April 2007 (UTC)

Woodstone's suggestions work for binary meanings. But what about decimal meanings? If K/M/G are used in different ways throughout an article, I don't see an easy way around the extra text. If they are used consistently within an article, then maybe the first occurrence might be:

• 512 MB of RAM (1 MB =2²⁰ bytes or 1 MiB throughout this article.)

or maybe if there are only a few exceptions:

• 512 MB of RAM (1 MB =2²⁰ bytes or 1 MiB throughout this article, except as noted.)

--agr 14:48, 27 April 2007 (UTC)

The decimal use does not pose much of a problem, because it is a proper conversion between standard units:

• a disk of 512MB (488 MiB)
• a memory chip of 512 MB (=MiB)

This way every reference becomes unambiguous, and can contain the value from the source. −Woodstone 15:22, 27 April 2007 (UTC)

I'll try replying to some things together here.

But, anyways, I think it would help to remember that two of the major sources of disagreement here are for articles about single types of technology (eg. ram), and much older systems (eg. C64). In articles like C64, it doesn't really matter how you would express the decimal KB, because it's a non-issue, isn't it? Similarly, it doesn't matter how you'd express both MB and MiB in an article about, say, SDRAM, because that, too, is a non-issue, isn't it? The only place where it could come up is in articles about full systems which may be using both types of units. In that case, you may want to consider simply letting them say 300GB hard drive and 2GiB of RAM. Then, all you need to worry about is cases where they have one or the other, in which case 64KB(64KiB) is not confusing to anyone capable of reading at all. Bladestorm 15:39, 27 April 2007 (UTC)

• As someone who is technically knowledgeable about the issue and who believes this is all a tempest in a teapot, may I make a simple “third-party” suggestion? Why not take an approach similar to that used with English/Imperial and SI units of measure, giving the SI unit with the IEC conversion following parenthetically – but with a link in the parenthetical note, as is used with wikilinking currency: “xx MB (IEC: nn MiB)”? Why this way? Well, the firestorm above is all a debate meaningful only to techno-freaks who already understand the issue and don’t need Wikipedia to figure it out or, for that matter, need a basic reference like this encyclopedia. The average reader who is likely to resort to Wikipedia to better inform themselves would expect to find the units they’re most familiar with, which would be SI. Seeing something like the format I’m suggesting would almost certainly bring them the surprise of learning that there even is more than one official form of units; the further benefit is that they are now only a single click away from learning more about what may someday become the dominant usage. And isn’t that what Wikipedia is all about – learning for everyone? Askari Mark (Talk) 17:44, 27 April 2007 (UTC)

Why not reduce it to simply linking the acronym? Thus we get “xx MB (nn MiB)”. If the reader is unsure, they click the link, get the answer (including mention of IEC), and return. Less clutter is a goal too, but with all the information available. Shenme 18:04, 27 April 2007 (UTC)

That would be perfectly fine by me, although I'd still recommend including the "IEC" link in the first mention in an article. That way it gets recognition the first time a reader sees it, and even if they don't check it out then, after seeing several times, it'll begin to have "name recognition" and draw the reader to learn more. Askari Mark (Talk) 22:34, 27 April 2007 (UTC)

Maybe this should be a separate section, but it may have been suggested before, so I'm asking - it might be another way forward. I keep seeing people talking in global terms. But that falls down when talking about what to do with a passage that talks about memory cache vs. one that talks about prices for disk storage in the 1990's. Would it help focus attention on the chief problem — how to unambiguously impart information to the reader — to identify a few key example phrases/sentences and how they should be handled?

"No one will ever need more than 640 KB"

it's a quote (fictitious), so you don't touch it, though later you might explain the context

By 19xx the average price fell to $0.25/MB (10⁶)

qualify so that usage is unambiguous for the reader

And so on. I'm afraid what I'd have to agree with is that no one usage will fit all situations. My bias is to include both standards, the one familiar and the other unambiguous, because that should help the reader. But... in both my above samples you wouldn't want to alter the text.

If the only guidance you can propose is 'global', you won't ever successfully 'fit' all the actual situations. Has that been the problem for the last few months? Would coming up with a few core guiding examples be a way forward? Shenme 18:32, 27 April 2007 (UTC)

I think it's a good idea. A related approach might be to come up with a few representative articles for which we could try out some proposals. I'd suggest Commodore 64 as a typical historic article and MacBook as a current model. --agr 19:18, 27 April 2007 (UTC)

Sounds like a good one to me. Seraphimblade ^{Talk to me} 22:02, 27 April 2007 (UTC)

Well it's been quiet for the last 24-48hours and it looks like there is consensus amongst the active editors here for something in the style of “xx MB (MiB)” compromise. Fnagaton 23:57, 30 April 2007 (UTC)

What's the rush? Give it some time. -- mattb 00:05, 1 May 2007 (UTC)

It would be a compromise indeed – in the worst meaning of the word. Some people used to complain about the “i” in “XiB” and now you want to bloat the defacto ambiguous “MB” to “XB (XiB)”? That is – please excuse my loss of manners – plain stupid. Five characters each time for nothing. Christoph Päper 20:19, 2 May 2007 (UTC)

I read this stuff twice and I'm still not sure what is being proposed (but I think I have a clue). If it means using GB in four different senses (10^9, 2^30, 1000*1024*1024, 1000*1000*1024) and always explaining it, well, I oppose confusing readers that way, especially as I believe there would be consensus for using the IEC prefixes (which need to be explained, yes) if a truly representative sample of interested Wikipedia editors would be polled. And as was in the previous poll. --SLi 02:20, 28 April 2007 (UTC)

I think what's mainly being proposed here is "Why can't we do both?" And why can't we? Quite often, parentheticals are used to disambiguate units if there is any possible ambiguity. Basically, we'd just put the binary prefix as a parenthetical after the old-style one. I think it's a great idea, still eliminates ambiguity, and still satisfies those who wish the old-style prefixes to appear as well. Seraphimblade ^{Talk to me} 10:04, 28 April 2007 (UTC)

I think it is a good compromise. Fnagaton 13:55, 28 April 2007 (UTC)

In this particular case, the symbol of the unit itself is used to disambiguate (that's its essence). If I didn't know the binary prefixes I would be confused by something like 64 KB (64 KiB). I'd ask my self : why do they use two names for the same unit ? Why didn't they choose one ? It still eliminates the ambiguity but it adds confusion. Then, I cannot agree with this compromise because I don't think it improves the encyclopedia. Sarenne 18:08, 28 April 2007 (UTC)

No, it is more likely a user reading an article that uses KB/MB/GB would see KiB/MiB/GiB and would think "they should have used the style used in the sources". A user expecting to see KB and then only seeing KiB is more likely to be more confused, not less as you claim. Not using the terms used in the sources adds confusion, which means your edits cause more confusion than they are trying to fix. We don't need you specifically to agree, we just need consensus. Fnagaton 18:42, 28 April 2007 (UTC)

Of course you don't need my approval but you need opinions about proposals if you want to build a consensus. A click on MiB is really confusing, you're right... Sarenne 19:12, 28 April 2007 (UTC)

An article that doesn't use the terms found in the majority of the relevant reliable sources is confusing. Fnagaton 19:18, 28 April 2007 (UTC)

It's not the terms themselves that are confusing, but their different uses. Confusion is unlikely to arise if the reader doesn't need to know which megabyte is meant. --SLi 19:21, 28 April 2007 (UTC)

You're wrong, only using binary prefixes does cause more confusion where article sources don't use those terms.Fnagaton 19:28, 28 April 2007 (UTC)

I too can (grudgingly) accept that compromise, although I think it's quite confusing, but it's definitely less confusing than using the different megabytes alone (although I still think there would be a majority consensus for using the IEC units alone, I see the value in trying to work into a compromise that the other side can accept too, especially if that means we won't have these discussions again and again to the eternity :) --SLi 01:10, 1 May 2007 (UTC)

(Outdent) If living for eternity meant I had to discuss this occasionally that would be a small price to pay. ;) Anyway back on topic... What I'm wondering is some specifics at this point. For example, the first mention of MB in an article should it have MB and MiB linked? I think yes. What about if the article mentions kilobyte (instead of the using the shorter KB) should that have kibibyte linked after it in brakcets? Again I think yes this compromise calls for that to happen. What do you think? Fnagaton 09:05, 1 May 2007 (UTC)

It's already considered good practice to link the first usage of any nontrivial term in articles. -- mattb 23:40, 2 May 2007 (UTC)

Prefix K/M/G used in binary sense is not an SI prefix

In computer contexts, the prefixes K/M/G are sometimes used in binary sense. Although these prefixes are spelled similar to the SI prefixes they are themselves not SI prefixes. I had mentioned this several times in the discusion, without being contradicted. I had adapted the manual of style to reflect this distinction. However this has been reverted without any discussion. I fail to see how these changes can be controversial. A prefix M meaning 1048576 is simply NOT an SI prefix.

I quote the section here, with strike out for removed words and bold for added ones.

Do not change all SI prefixes to IEC prefixes in computing contexts, only those that are actually being used in a binary sense. If you do not understand the difference, do not change anything; using the more accurate units incorrectly is worse than using the less accurate units correctly. For example, do not change a "160 GB HDD" to "158.69 GiB" (still less "160 GiB"), but it may be appropriate to change 512 MB RAM to 512 MiB RAM where it is important to do so. (Notice that the number does not change because the SI prefix "M" was used in a binary sense. Both usages are acceptable, but the MiB reference is not ambiguous.) If IEC binary prefixes are used within an article, do not also use SI prefixes in the binary sense; only standard SI prefixes should be used in the same article.

Do not change SI prefixes to IEC prefixes within directly quoted passages. Link them to the appropriate unit or include a more exact measurement in brackets.

−Woodstone 11:33, 28 April 2007 (UTC)

I agree, this is purely factual and should not be controversial. Sarenne 17:49, 28 April 2007 (UTC)

Ok, looks good. I took them for something they were not, sorry. --SLi 20:01, 28 April 2007 (UTC)

Well, "M" is an SI prefix. It's just being used incorrectly. — Omegatron 13:47, 4 May 2007 (UTC)

In my take there are two prefixes, both written as M. One is the SI prefix M meaning 1000000, the other is a prefix used only with bits and bytes in some contexts and means 1048576. It is not the SI prefix used incorrectly, it is a different prefix that has a name that leads to confusion. There is a third prefix Mi, that also means 1048576, but is not confusingly named. −Woodstone 14:15, 4 May 2007 (UTC)

Except to the vast majority of professionals using KB, MB, GB isn't confusing. Also to the non-professional person but those who have had or do have home computers it's not confusing since the terms KB, MB, GB when applied to computer memory are widely understood to be from that computing context. Fnagaton 14:41, 4 May 2007 (UTC)

Perhaps it does not strike you as confusing, but it certainly is for me (I am an IT professional and heavy PC user). For memory chips the guess at meaning might be often correct, but for disks and bus speeds it is certainly not very clear. Does an instance of M mean 1000000 or 1024000 or 1048576? One never knows for sure. As a reader of wikipedia I would be very glad if a knowledgeable editor has investigated it and shows me the conclusion unambiguously. −Woodstone

Units of measure are rarely confusing to the people that use them. As a nuclear engineer about the Röntgen sometime. I'd argue that unit usage should be consistent and serve the lay reader, not people like you and I who already know this issue backwards and forwards. -- mattb 15:24, 4 May 2007 (UTC)

Lay readers of Wikipedia are all computer users and 99% of them use computers with Microsoft or Apple operating systems. Neither OS uses the IEC binary prefixes. The manuals that come with them don't, The aftermarket books lay readers buy don't. Computer magazines they read don't, How does using the IEC prefixes on Wikipedia help lay readers, exactly? Oh I forgot. Accuracy. Lay readers really care about the few pecent discrepancy between the different K/M/G usages. So articles like Macbook have been edited to say, as the current revision does, that MacBooks come with hard drives that are "60 GiB, 80 GiB or 120 GiB." Who cares that Apple's literature says they are 60 GB, 80 GB or 120 GB? Wikipedia must give our lay reader unambiguous data. No source is given for these improvements to Apple's specifications. But we have knowledgeable editors who do the right thing. Except for one tiny problem. IT'S $%@&ing WRONG!!!!! I'm typing on an 80 GB MacBook. According to Apple's disk utility it has 80,026,361,856 bytes of storage. Not 80 x 2^30. How many other errors have the binary prefix knowledgable editors introduced into Wikipedia? How will we ever know? If ever there was an argument for sticking to published sources, this is it.--agr 18:38, 4 May 2007 (UTC)

Interesting. That's the first introduced IEC binary prefix error I've seen... One for the record books for sure. Those hard disk capacities should surely be given in GB. So I guess you can count one instance of editor confusion due to the IEC prefixes. Anyway, I've explained the issue to the editor who added that table. -- mattb 18:52, 4 May 2007 (UTC)

Mmm, agr, you are lucky! Have they changed disk utility since OS X 10.3? Because mine says "Total Capacity : 27.9 GB (30,005,821,440 Bytes), though I'm sure the salesman said 30 GB.... bit confusing, eh? The good news being that the corrected MacBook article now shows GB which at least links to an explanation for the uninitiated. ... dave souza, talk 19:45, 4 May 2007 (UTC)

Great. For the record, the error was introduced on April 15 and was fixed shortly after my posting (thank you). Matt, how are you going to "explain the issue" to the other 10,000 or so active editors on Wikipedia, not to mention the irregulars? I think it is very significant that this error was introduced by a well-intentioned editor who was just cleaning things up. The moment you untie Wikipeda from its moorings of verifiability, you create the possibly of it drifiting into these kinds of error. We cannot presume editors are more knowledgeable than their sources.

So here is another example of a problem created by this controversy. The Commodore 64 article currently says it " it offered 64 kilobytes (64 × 2¹⁰ bytes) of RAM " That's not correct, I believe, but the error was introduced as part of an edit war over the use of kibbibyte that apparently started March 1. The article previously said "64 KB" and left it at that. --agr 19:47, 4 May 2007 (UTC)

What is not correct according to you ? kilobytes ? 64 × 2¹⁰ bytes ? I'd be happy to replace kilobyte with kibibyte but, because even an admin is edit warring, I'm waiting a bit :)Sarenne 19:58, 4 May 2007 (UTC)

My apologies. I withdraw my comment about the C64. There is nothing wrong with the current version. In fact it is an excellent solution. --agr 20:36, 4 May 2007 (UTC)

Kilos and kibis

I found the whole section on kilobyte vs. kibibyte overly verbose and rather confusing. It reads like as if somebody is trying to prescribe behavior that most users don't understand. Perhaps we can clear this up? >Radiant< 09:27, 7 May 2007 (UTC)

Here's a brief version of the history behind this. During the 1980s (the 8-bit computing era), "kilobyte" was defined in essentially all cases as 1024 (2¹⁰) bytes. That's because, due to the way memory chips are designed, they almost always have a capacity that is a power of 2. At the time, the term was not at all ambiguous and was clearly understood by everyone in the field. The same was true of megabyte (1048576, or 2²⁰, bytes). In the 1990s, hard drive manufacturers deceptively began to use "megabyte" in the decimal sense — that is, 10⁶ bytes — even though this clashed with common practice in the computing field. Since operating systems displayed the binary value, this led to a few lawsuits when people saw that their "500 MB" hard drive only showed up as 476.8 MB in Windows 95.

In 1999, the IEC tried to "clear up" the confusion by issuing new standards. Unfortunately, they did it backwards. Instead of standardizing upon common industry usage, they instead reserved "kilobyte", "megabyte", and "gigabyte" for the hard drive bastardizations, and insisted that the common binary values use neologisms — "kibibyte", "mebibyte", and "gibibyte." These silly new terms were promptly ignored by the overwhelming majority of the IT industry. A quick glance at the packaging of any modern-day PC product, or a search through popular hardware sites such as Newegg, AnandTech, or Tom's Hardware Guide, indicates that everyone in the industry (or nearly everyone) still uses the same terms that were used in the 1980s and in the same manner. Likewise, virtually all software (including Microsoft Windows) still displays sizes in the traditional binary sense, ignoring the new prefixes. As such, the IEC's 1999 efforts should be seen as a failed standard.

Unfortunately, MoS aficionados (most of whom are not subject matter experts) insist upon using the unpopular IEC neologisms, even when (as is the case for 8-bit machines) all reliable sources use the standard terms. This clearly violates the principle that Wikipedia should be descriptive, not prescriptive. It serves no useful purpose and only confuses editors and readers. The section encouraging the use of these neologisms should be removed from the MoS entirely, and the use of terms should be left up to the judgment and discretion of editors on individual articles, relying upon reliable sources and common usage. *** Crotalus *** 10:06, 7 May 2007 (UTC)

Good explanation. I've struck the section for now, we should replace it with something much shorter and less instruction creepy, and preferably matching common usage rather than in prescriptive form. >Radiant< 10:51, 7 May 2007 (UTC)

Without the wish to enroll the discussion once again (there’s still enough of it left on this page as of today and the rest I archived just yesterday), that explanation is incomplete and therefore not good.

If information science and technology was an isolated field, nobody would care much about the units used therein, but they share (diffuse) boundaries with other sciences and technologies (e.g. electrotechnics), where metric units, including decimal prefixes (e.g. MHz), are being used. Misunderstandings are the result which would have been avoided if the SI prefixes never had been used in a binary sense. The IEC and other standardisation bodies try to correct that error, but people like their habits once acquired.

The current MoS rule is there to promote unambiguous usage throughout Wikipedia, accepting the fact that sources often use the prefixes in a different sense, one that is context-dependent. There’s neither a consensus to change nor how to change that section, so please refrain from doing so. Christoph Päper 12:44, 7 May 2007 (UTC)

• Er, no. You can't use an allusion to existing consensus to stop us from discussing the matter. Fact is that the paragraph is very verbose (e.g. potentially WP:CREEP) and I'm wondering whether it reflects actual practice, rather than what some people would like practice to be. >Radiant< 13:54, 7 May 2007 (UTC)

• Radiant, have a look at the pages upon pages of discussion upon this. The above is correct. The decision was not made as any "neologism" or "bastardization". Rather, after consideration, the standards bodies, quite properly, decided that metric prefixes have meanings, and should only have one. Kilo means one thousand, mega means one million, and so on. That's true of a kilometer, a kilogram, or, as they decided, a kilobyte. However, as it was clear that some form of binary prefix was going to be necessary, they developed a standard-that thing standards bodies do. Since then, it's been endorsed by ANSI, IEEE, SI, NIST, all of the major ones. The correct, unambiguous term for 2²⁰ bytes is a mebibyte, or MiB. The fact that many people would "get" the incorrect terminology from context doesn't mean we should use it. Seraphimblade ^{Talk to me} 14:03, 7 May 2007 (UTC)

• Yes, I get that part, but the thing is that just like we can't enforce American vs. British English, we can't practically enforce this either. The manual of style is supposed to reflect how articles are written, not how whomever wrote the MOS page would like them to be written instead. >Radiant< 14:26, 7 May 2007 (UTC)

I would like to support Radiant!'s action in deleting the binary prefix guideline for now. Here are my reasons:

1. The previous MOS binary prefix guideline has been highly contentious and has produced several edit wars.
2. Those who opposed it, including myself, believe it conflicts with core Wikipedia policies, including V and NOR, because it encourages editors to add their interpretation to what cited sources say. Proponents say this is ok because Wikipedia editors are more knowledgeable than most readers. I don't think that view is one we should support.
3. The underlying problem is of minor importance. The different interpretations of the prefixes k/M/G differ by a few percent. The computer industry has lived with these ambiguities for over 50 years. It shows no sign of adopting the IEC binary prefix solution.
4. There are other, less disruptive ways of dealing with the ambiguity problem. With the old guideline removed, it may be possible to reach a true consensus on a more suitable approach for Wikipedia. --agr 16:10, 7 May 2007 (UTC)

I disagree, to address the reasons above:

1. NOR has produced plenty of edit wars, and there are plenty of people who disagree with or attempt to act against it. That's no reason to scrap it. We wouldn't scrap our policy against vandalism even though a whole lot of people vandalize.
2. Those who support it, including myself, find original research on the other side-that "Well this is really more widely used so we should use it too, and besides, a lot of people would understand anyway," rather than "It is what the standards bodies say it is, and they say decimal prefixes mean decimal and binary prefixes mean binary." It's not original research to paraphrase. For example, if we standardize on the use of "laptop", but one company calls their laptops "portables", it would not be original research to paraphrase that to our standard and call them laptops.
3. The binary prefixes may not be most widely used now, but they certainly are used.
4. That may be, but until such time as we can agree on such a solution, the old one (which was put into place by overwhelming consensus) should remain in place. No consensus to change a policy or guideline means no change is made. Seraphimblade ^{Talk to me} 16:29, 7 May 2007 (UTC)

Except that the JEDEC, which is the standards organisation covering computer memory, defines kilo and mega in terms of bytes to mean 1024 and 1024*1024 bytes. Also there appears to be a consensus compromise to put binary prefixes in brackets and to use the terms used in the majority of the reliable sources, which would mean using kilobyte and megabyte in the article text. Also you have not properly answered the question why you are not removing the term yard from the article on American football, for example. This is despite the SI standards authority, the same one you want to rigidly follow for kibibytes, saying not to use yards and only use metre. That question, by the way, has been asked many times but not once answered properly which is why I have to ask it again. If you wanted to demonstrate that your personal opinion is not illogical you should at once alter that article to remove references to yards, but you have not therefore you have demonstrated exactly why your personal opinion is inconsistent. Fnagaton 17:12, 7 May 2007 (UTC)

I answered that for you before. Yard, while its use may indeed be deprecated, remains a term with a constant and unambiguous value. It is three feet, or thirty-six inches, whichever you prefer. We certainly should preferentially use terms which give us good, round values. I would, for example, not be for converting hard drive capacities to binary, they're done in decimal, so let's just leave "160 GB hard drive" as such. Also, JEDEC does not endorse such use. In one paper, they acknowledged that it happens. There's a tremendous difference between saying "You should do it this way and only this way" and "Hey, be careful to distinguish between decimal and binary when you're reading metric-prefixed terms, decimal prefixes are frequently used to represent binary." JEDEC's "endorsement" was the second variety. (And if it were not so, that would still be largely immaterial, the above-mentioned organizations set standards for the entire world, in all fields of practice. JEDEC does not.) As to use in brackets, that would work for me! I don't care so much how we express correct, unambiguous values, as that we do so. But if the consensus is to do that, let's just change that, rather than whacking whole sections. That was my issue with Radiant's action. There is certainly no consensus that the whole section ought to be removed. Seraphimblade ^{Talk to me} 17:22, 7 May 2007 (UTC)

That is not a proper answer for the following reasons. 1) You are ignoring the fact that the yard has been inconsistent in the past, as previously demonstrated. 2) You are also ignoring the fact that the JEDEC defines kilo and mega in the context of bytes and your stuff about "endorse" is your assumption where you don't supply proof, so you are under misrepresenting the facts. Your assumption is also refuted by the quotes I made of the standard before. 3) The "whole number" argument is fallacious since the SI standard does not make exceptions for the yard in that circumstance. 4) Since it is a fact the yard was ambiguous and now you claim it is not ambiguous due to it being defined in a standard then logically you have to concede the term kilobyte and megabyte are also no longer ambiguous. Q.E.D. So you have not answered the question properly, instead you have again written things which have already been refuted. So try again. As for the consensus that the section be removed, I add my support that the section be removed. Fnagaton 17:41, 7 May 2007 (UTC)

If, as Seraphimblade suggests, binary prefix proponants would accept a solution based on using the original units from sources, with a parenthetical clarification of exact meaning as appropriate. then we should write that guideline and adopt it instead of bickering over the old one.--agr 18:31, 7 May 2007 (UTC)

I think it is clumsy to say something like "64 KB (KiB)". Instead, let's be exact: I would recommend "64 KB (64 × 2¹⁰ bytes)" for the first instance, and assume this clarification is sufficient to cover the article. Or, since many of the original sources on 8-bit machines simply use "K" rather than "KB", we could go with "64K (64 × 2¹⁰ bytes)". Or better yet, we could leave this contentious issue out of the MoS entirely and trust the editors of individual articles to use what is appropriate for those specific articles, based on standard Wikipedia sourcing policies. *** Crotalus *** 19:30, 7 May 2007 (UTC)

At the time, the term was not at all ambiguous and was clearly understood by everyone in the field. The same was true of megabyte (1048576, or 2²⁰, bytes). In the 1990s, hard drive manufacturers deceptively began to use "megabyte" in the decimal sense — that is, 10⁶ bytes — even though this clashed with common practice in the computing field.

This is completely unfounded. "K" has been ambiguous since the 60s, and drum and disk storage has always been measured in decimal.

and preferably matching common usage rather than in prescriptive form.

Careful here. The MoS and other guidelines should be descriptive, not prescriptive. It should document the way things are done, not try to change the way things are done.

But the things that we're documenting are the way things are done on Wikipedia, not the way things are done in the outside world. The MoS does tell people how to do things, like favoring SI units and IPA pronunciations, but that's just to document the results of all of the disputes we've had on those subjects, to prevent those disputes from reoccurring over and over again on every talk page. We use these standards because we've found them to serve our encyclopedic purposes, regardless of how popular they are in the outside world.

The whole point of the MoS is to document which outside world methods we've adopted for our own internal use. In this case, the outcome of all the discussions is to use SI prefixes as specified by international standards, so we've documented it on the MoS. There will always be a handful of people who disagree.

You might want to read the pages and pages and pages and pages and pages and pages of discussion on the subject before striking the section again. — Omegatron 20:01, 7 May 2007 (UTC)

Shit, it started yet again. I wonder whether it would also have if I had refrained from commenting.

If you, Fnagaton, want to compare this issue with English vs. metric units, try ton. You can safely use it without qualifier when talking about rough numbers, because both Engish tons are in a 10% margin of the metric ton. – If it was for me we would, of course, only allow units from the SI and those accepted for use with the SI. Anything else was only to be used (additionally) where it was the “defining source unit”. Alas, there are too many people writing here who are concerned about the incompetence of their fellow citizens, i.e. very few say “I don’t understand metric”. I would also standardise on one spelling (any one would do).

I thought everyone knew that a standard may contain informative, i.e. non-normative parts. JEDEC is concerned with a narrow field of computer and information technology only, problems arise for instance when traditional RAM technology is derived for solid state storage, or with swap files on harddisks, or when a certain amount of data is first stored on a disk, then transmitted, then stored in RAM. Ain’t CDs and DVDs talked about with different meanings of mega? Wikipedia is concerned with every field of human knowledge.

Readability competes with accuracy sometimes and the former usually should win when secondary information in parentheses is considered. That means I oppose “123 XB (XiB)” in favour of “123 XiB”. JFTR, I am still close to give up on the English Wikipedia altogether, because community-derived solutions tend to be fouler compromises here than elsewhere, this being especially noticable in the MoS. — Christoph Päper 20:53, 7 May 2007 (UTC)

Proposed new guideline for binary prefixes

After the long dsicussions it appears that there is a possible consensus around keeping the units as found in the sources, followed by a disambiguation to clarify what unit is meant in each case. I have tried to write a concise text for the project page. History of the guidelines, and the involved bodies can be put in a normal article and referenced. They do not really belong in the guideline. −Woodstone 20:43, 7 May 2007 (UTC)

Wording for project page

Multiple-byte units
Decimal Value Metric 1000 kB kilobyte 10002 MB megabyte 10003 GB gigabyte 10004 TB terabyte 10005 PB petabyte 10006 EB exabyte 10007 ZB zettabyte 10008 YB yottabyte 10009 RB ronnabyte 100010 QB quettabyte	Binary Value IEC Memory 1024 KiB kibibyte KB kilobyte 10242 MiB mebibyte MB megabyte 10243 GiB gibibyte GB gigabyte 10244 TiB tebibyte TB terabyte 10245 PiB pebibyte — 10246 EiB exbibyte — 10247 ZiB zebibyte — 10248 YiB yobibyte — — —
Orders of magnitude of data

Binary prefix archives

0 Old discussion 0.1 Non-base ten numbers 0.2 Unit Disagreement, MiB vs. MB 1 Archive B1 1.1 Binary prefixes 2 Archive B2 2.1 Binary Prefixes (again) 2.2 Binary prefixes vs Historical accuracy 2.3 Two questions from sports article 3 Archive B3 3.1 Binary prefixes vs JEDEC Standard 4 Archive B4 4.1 Two quick notes 5 Archive B5 5.1 Pulling it together 6 Archive B6 6.1 Binary Prefixes-A compromise? 7 Archive B7 7.1 I'm done with the binary prefixes debate 7.2 Time for a third party 7.3 Prefix K/M/G used in binary sense is not an SI prefix 7.4 Kilos and kibis 8 Archive B8 8.1 Proposed new guideline for binary prefixes 8.2 Actual comments about the proposal 8.3 Addendum 8.4 Enough of this 9 Archive B9 9.1 Mediation 9.2 Mischaracterization by Crotalus 9.3 About the current wording 9.4 Backup of Sarenne's user Contributions 10 Archive B10 10.1 Merging computer unit articles 10.2 Going to run some experiments 10.3 Proposal 10.4 Binary prefixes: A challenge 10.5 Please move the dominant topic to its own page elsewhere 11 Archive B11 11.1 What constitutes "consensus" on the Manual of Style? 11.2 Consensus ? 12 Archive B12 12.1 JEDEC finally responds 12.2 Suggestion to follow the convention used by the first author 12.3 More systematic changes 12.4 Template with CSS proposition (withdrawn, css/content issue) 13 Archive B13 13.1 Template for byte quantities 13.2 Call it curiosity 13.3 Different binary template

In certain cases in computing, large quantities of bits or bytes are expressed in powers of two instead of powers of ten. These are expressed by binary prefixes, which are commonly written and pronounced identically to the SI prefixes, but each successive prefix is multiplied by 1024 (2¹⁰) rather than 1000 (10³).

Using the prefixes kilo-, mega-, giga-, etc., and symbols like KB, MB, GB, etc., in the binary sense can cause confusion.

Although the JEDEC standards body endorses the use of K/M/G prefixes in the binary sense for memory chips, other international standardisation bodies have defined and recommend a set of binary prefixes, with names and abbreviations derived from the SI prefixes: kibi- or Ki, mebi- or Mi, gibi- or Gi etc.

Editors are not required to specify which interpretation should be given to a prefix from referenced sources, but should accept a disambiguation that is added by other editors. Preferred way of disambiguating is:

• decimal use of prefix, convert to binary value:
  • disk space of 500 MB (466 MiB)
• binary use of prefix, indicate the standard symbol of the unit:
  • memory space 500 MB (=MiB)

Comments to the proposal

Add your opinion here, indicating if you support or oppose the change proposal. Feel free to comment on the wording as well.

• Support the change as proposed. −Woodstone 20:43, 7 May 2007 (UTC)

  Shouldn't the "MB" and also "KB"/"GB"/"megabyte"/"kilobyte"/"gigabyte" etc also be linked to their correct disambiguation page? Fnagaton 21:08, 7 May 2007 (UTC)

  Thinking about it more... I'd also change it to read: "Using the prefixes kilo-, mega-, giga-, etc., and symbols like kB, MB, GB, etc., in the binary sense can cause confusion however just using binary prefixes where article reliable sources do not use binary prefixes can also cause confusion." - To try to balance it out more, or I propse removing the section of text altogether since it is probably PoV.

  Removal of this part "International standardisation bodies have defined and recommend a set of binary prefixes, with names and abbreviations derived from the SI prefixes: Kibi or Ki, Mebi or Mi, Gibi or Gi etc." - Unless you want to add the relevant JEDEC reference to balance it. Fnagaton 21:21, 7 May 2007 (UTC)

  How about phrasing: Although the standards body JEDEC endorses the use of K/M/G prefixes in the binary sense for memory chips, other international .... Of course the first occurrence of KB, MB, GB can be linked. −Woodstone 22:17, 7 May 2007 (UTC)

  I would be happy with that change if you want to make it in the proposed text above, or I can? Fnagaton 22:25, 7 May 2007 (UTC)

  Have you received word back from the JEDEC on this issue, or does your position still reflect your contested interpretation that usage implies endorsement? The statement as it stands is easily verified by the handful of major standards organizations who explicitly and without interpretation endorse usage of the IEC prefixes. Putting your interpretation of the JEDEC's usage (not commenting on whether that interpretation is right or wrong) on the same level as the documents of organizations who explictly recommend using the prefixes is remiss. Your contesting of this sentence hinges on whether your interpretation of the JEDEC's documentation practice is correct, which is yet to be determined unless I've missed something. -- mattb 02:06, 8 May 2007 (UTC)

  It is a fact that the terms are included in the JEDEC standard and not as a footnote but actually in the main standard definitions. The text I quoted from the start of the JEDEC standard is clear meaning that they enforce and therefore endorse their standard. Without any contradictory evidence the conclusion is therefore that the JEDEC endorses the language used in their standard. It's not my interpretation, it's the facts. It is however your assumption, without evidence to support that assumption, where you claim one tiny part of the JEDEC standard is somehow not actually in their standard or worth less than the other parts and it is illogical for you to continue to claim that. As such I think it is fair to include Woodstone's suggestion. I went along with your attempt to contact the JEDEC but really now there has been adequate time to find some evidence with explicit wording that's supports your interpretation. Fnagaton 09:20, 8 May 2007 (UTC)

• Oppose, but I could accept the second bullet to resolve otherwise unresolvable edit wars. There’s no usecase, that I see, for the first bullet. Woodstone’s wording is ,partially better than the current text, though. — Christoph Päper 21:28, 7 May 2007 (UTC)
• Support the second bullet, I suppose, if we must (though I'd prefer with no = sign, just "528 MB (MiB) of memory.") I really see no need for the first-the SI/metric prefixes are properly used in the case of decimal values, I see no real need to also use the binaries there. Seraphimblade ^{Talk to me} 21:38, 7 May 2007 (UTC)

  Do you mean the first bullet text ("500 MB (466 MiB)") should just be "500 MB"? Fnagaton 21:57, 7 May 2007 (UTC)

  I see no other easy way of indicating that the MB is really meant in the decimal sense. −Woodstone 22:17, 7 May 2007 (UTC)

• Conditional support. Rather than using the neologisms, it should be possible to instead put a specific clarification in parentheses, like this: "64K (64 × 2¹⁰ bytes)". I maintain, however, that a controversial issue like this doesn't belong in the MoS in the first place. *** Crotalus *** 21:45, 7 May 2007 (UTC)

  Settling disputes like this to make the site uniform is exactly what the MoS is for. — Omegatron 23:15, 7 May 2007 (UTC)

  This Manual of Style makes the encyclopedia easy to read by establishing principles for its format. It is a style guide. The following rules do not claim to be the last word on Wikipedia style. One way is often as good as another, but if everyone does things the same way, Wikipedia will be easier to read and use, and easier to write and edit. These are not rigid laws: they are principles that many editors have found to work well in most circumstances, but which should be applied with flexibility. In this vein, editors should strive to have their articles follow these guidelines.

I think Radiant correctly identified the problem as Wikipedia:Avoid instruction creep. "This page would be better if everyone was supposed to do this" -- SWTPC6800 02:30, 8 May 2007 (UTC)

• Support the text as it is currently (only just!) because it is better than what is in the MoS right now. However I'd still like my earlier comments [1] to be discussed and those changes integrated if possible. Fnagaton 21:53, 7 May 2007 (UTC)
• Conditional support if it stops drive by edit wars. Would this allow the use of the single letter prefix K or M? I am thinking about quotes and paraphrased descriptions of the Altair 4K Dynamic RAM board or the IBM PC 640 K memory limit. (Both items were significant to Bill Gates.) I would not have a problem with a notation explaining that the article or section is using the historical convention of the product or event. -- SWTPC6800 21:57, 7 May 2007 (UTC)

  Quoted passages shouldn't be changed as I seem to remember this relies on a different MoS guideline. Fnagaton 21:59, 7 May 2007 (UTC)

  I was thinking about paragraphs that mix cited quotes with a paraphrased description. Under the current guideline the paraphrased text would have to use KiB. -- SWTPC6800 22:11, 7 May 2007 (UTC)

  Paraphrased is a bit of a grey area. Under this proposed guideline I suppose technically the text would use the original term with the binary prefix in brackets, which is better than only using the binary prefix. Fnagaton 22:15, 7 May 2007 (UTC)

  Why is that better?? What problem are you solving by writing "16 MB (MiB)" instead of "16 MiB"? — Omegatron 23:12, 7 May 2007 (UTC)

  The fact that the reliable sources do not use binary prefixes and that causes the article text to be inconsistent with the sources. Also the fact that binary prefixes are not used by the majority of sources. Fnagaton 23:15, 7 May 2007 (UTC)

  So what if they aren't used in the original sources? Why is this a problem? — Omegatron 23:17, 7 May 2007 (UTC)

  Read all my comments going back to the start of this issue on this talk page for the exact reasons why. Here is not the place to try to bring it all back out again. Suffice to say that the very fact there is this vote shows there is a problem. Fnagaton 23:19, 7 May 2007 (UTC)

  Summarize it. — Omegatron 01:02, 8 May 2007 (UTC)

  The conclusion is that it is wrong to only use binary prefixes in an article where the majority of relevant reliable sources do not use binary prefixes. If you want the much longer version with all the supporting arguments leading to that conclusion then read all my previous comments because there is not enough space here to summarise all the arguments again. Here is not the place to ask the same questions that have already been answered. Fnagaton 09:10, 8 May 2007 (UTC)

  You haven't given any good reason for this. You're just reiterating that it's wrong to use binary prefixes when the original sources don't. Why is this wrong? How does this degrade the quality of the encyclopedia? — Omegatron 00:51, 9 May 2007 (UTC)

  Read all my comments going back to the start of this issue on this talk page for the exact reasons why. There is not enough space here to go into any great detail since the actual answers comprise of hundreds of words. Fnagaton 22:11, 9 May 2007 (UTC)

• Oppose - Why in the world would you convert decimal units to binary ones? We're here to provide reliable information, not confuse the hell out of everyone. This isn't like writing "5 ft (1.5 m)". It's either a binary measurement or not. Either write it with a binary unit or not. Do you even understand what this discussion is about? — Omegatron 23:12, 7 May 2007 (UTC)

  I could imagine that somebody would like to know if 490 files of 1 MB fit on a disk of 500 MB (no conversion or interpretation given). Stating that the files are 1 MB (=MiB) and the disk 500 MB (466 MiB) would clarify this. −Woodstone 11:57, 8 May 2007 (UTC)

• Support - While I hate the idea of widening or condoning the use of XiB anywhere, I vastly prefer this wording to the current state of affairs, and I realize that no proposed wording here could completely (or even mostly) satisfy anyone and garner the support of even a small fraction of the participants, let alone the wider community we're supposedly making guidelines for. — jesup 04:19, 8 May 2007 (UTC)

• Support. The current situation obviously doesn't command consensus. This looks like a way forward. Stephen Turner (Talk) 09:41, 8 May 2007 (UTC)
• m:voting is evil. It is a shame that several editors here are intent on blocking consensus and compromise by pigeonholing this issue into a binary straitjacket vote. No good will come of this. I suggest that people join the constructive discussion below, rather than the pointless vote above. >Radiant< 12:12, 8 May 2007 (UTC)

  I don't think applies in this specifc situation because we have debated this issue a lot, found a potential compromise, now it's time to try to bring it together into policy. At some point there has to be consensus, this is what we are trying to do. Fnagaton 12:16, 8 May 2007 (UTC)

  Fnagaton is right. With all due respect, have you neglected to note the tens of pages of discussions above, spanning many weeks? (months if you look into the archives) Voting has been delayed on the very premise that voting is evil for as long as possible, but I understand that folks are getting tired of debating and ready to see some attempts at a decision. -- mattb 12:19, 8 May 2007 (UTC)

  In point of fact this debate started yesterday, so the "months of discussion" is an extreme hyperbole. >Radiant< 12:21, 8 May 2007 (UTC)

  It isn't hyperbole at all. This is just a new proposal that follows quite literally weeks and months of debate. Look back through the archives before brushing off my statement as hyperbole. You've stepped into the middle of a huge debate, and while I admire your courage in doing so, I must point out that those of us following it for a long time have already debated every imaginable point. We know where we stand and where our differences lie. -- mattb 12:31, 8 May 2007 (UTC)

  No Radiant, according to my history the discussions leading up to this point had already been started by beginning of April at the very least. Like Matt said there have been many discussions lasting many weeks, indeed months. Fnagaton 12:34, 8 May 2007 (UTC)

• History of the binary prefix style guideline. The style was adopted in July 2005; "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts" won 20 of 29 votes.[2]. Thing were quite until January 14, 2007 when a new user, Sarenne, changed MacBook Pro to use MiB and GiB. The edit war soon came to MOSNUM were Sarenne found support. Several editors told whoever complained about the binary prefixes issue was already decided and the consensus required their use. See User_talk:Sjenkins7000 talk page. The pattern of MiB edits with the complaints directed to MOSNUM has continued on a hundred articles. There have been more than twenty editors vigorously criticize the binary prefix standard but they have been told that the consensus supports MiB. You can start reading the MOSNUM talk page archives starting in January and find over a megabyte (mebibyte) of comments. The proposals to change the style guideline stated in April. -- SWTPC6800 16:15, 8 May 2007 (UTC)

• Support Using the KiB notation for 1024 byte, especially for articles describing older computers, is clearly wrong and confusing. Also using this notation is NOT mainstream (yet), as (for example) can be found here [3], and one of the fundamentals of wikipedia is to use the terms that are in "common usage" only. For example, the article IPhone, does not direct to the Linksys iPhone, but to Apples IPhone, even though Linksys IPhone was on the market earlier, because the common usage for IPhone is the Apple one. Mahjongg 12:13, 9 May 2007 (UTC) P.S it came to my attention that my understanding of -what- i was oopsing was wronf. So i changed my meaning to "support", I have nothing (much) against the KiB notation, as long as it is prudent for the article, just not for older computers. To explain why I oppose using the KiB notation in articles about older computers, let me give an ad-absurbitum example using a little thought experiment; What if someone tried to convince the world that "Abrahaim" should be equivalent to the biblical name "Abraham" because some people think it is necessary to distinguish it from other non biblical "abraham's", and that from now on we should use "Abrahaim" when we mean "Abraham in a biblical sense". You can imagine the resistance that would bring! with that in mind It's no surprise that the terminology kiB is NOT in common use today, even after half a decade of lobbying! Therefore I support the proposal that in articles describing older computing technology we continue to use the kB notation, and mention in the start of the article that, "because of historical reasons we continue to use the old teminology, where kB means 1024 byte, in this article".Mahjongg 15:00, 9 May 2007 (UTC) P.S. Also see my "discussion" with User:Sarenne at my talk page User talk:Mahjongg#Binary prefixes for some more arguments.Mahjongg 00:28, 10 May 2007 (UTC)

• Support It is highly distressing to me that a retro 8-bit computer article would use the KiB notation, which is counter to industry practice to this day, let alone all of the documentation I use to this day on my 8-bit systems. I also support castrating Sarenne from future acts of Wiki terrorism and MoS fundamentalism.—Preceding unsigned comment added by TopaTopa (talk • contribs)
• I support this proposal as it stands, but I would support it more strongly if it explitly mention that the Ki, Mi, etc prefixes are still not commonly used in the non-academic computign world, and are by no means universially useds in the academic world either, and their use without disabiguation or l;inking is likely to cause confusion, rather than avoiding it. it shoudl aslo add that where confusion or ambiguaity are not likely the binary prefixes are not required.(copied from section below) DES ^(talk) 23:20, 9 May 2007 (UTC)

• • there is soemthign wrong with section editing here, the editor seems to be ignorign at least one section header. Perhaps there is an unclosed html or wiki tag soemwhere. DES ^(talk) 23:20, 9 May 2007 (UTC)

Okay, I fixed it. Mahjongg 13:26, 10 May 2007 (UTC)

Actual comments about the proposal

The above section is apparently an attempt to make a policy through majority vote - but Wikipedia doesn't work that way. Voting is evil, so we should instead discuss the proposal, and reword as necessary. This section is for discussion. >Radiant< 11:25, 8 May 2007 (UTC)

• This is a definite improvement. Like the AD/CE debate and Brit/Am English, this is not something that can be prescribed wikiwide. Perhaps we should add a note reflecting that. >Radiant< 09:58, 8 May 2007 (UTC)

Umm I don't agree with blocking it off like that. We have been discussing this topic for quite some time. We've been working towards a consensus compromise. Now we are at the stage of discussing or voting on the change proposal text. Wikipedia does work like that, you know working towards getting consensus etc. Insisting on blocking it off without talking about it is bad (tm). Fnagaton 11:42, 8 May 2007 (UTC)

It is not at all uncommon in wikipedia to gather an overview on the satus of a proposal by voting. I have removed the block. −Woodstone 11:51, 8 May 2007 (UTC)

• What block are you talking about? I have not blocked anyone. If you would please familiarize yourself with policies & guidelines, how to create policy, m:voting is evil and the very {{proposed}} template, you'll see that proposals really are not decided by voting upon them. The point is that this stifles discussion and polarizes the issue between two versions, as evidenced by the fact that Fnagaton has already asked me on this page to "vote in" the changes before fixing problems in those very suggested changes. This is a poor approach, and it hampers consensus forming. >Radiant< 11:54, 8 May 2007 (UTC)

Actually you're wrong, I did not ask you to "vote in" I asked if you had voted because your comment was ambiguous. Fnagaton 12:48, 8 May 2007 (UTC)

The blocking off of the discussing/vote text above. We are talking about it. We are voting on the changes to see where the consensus is. The stifling of discussion is frankly caused by you blocking it off when there isn't good reason to do so. Fnagaton 12:03, 8 May 2007 (UTC)

• No, I'm explitly asking that people talk about it rather than simply make a binary support/oppose. Please read WP:CON with respect to the differences between a consensus and a headcount. The stifling of discussion is caused by the false assumption that this is a yes/no issue that cannot have a comrpomise in the middle. >Radiant< 12:07, 8 May 2007 (UTC)

We have already discussed various compromises, if you look at the history. The previous time this MoS entry was changed there was a vote on the text to use. We are again at this stageso we are voting on that text. it's a step back to block off the vote and I'm going to have to insist you remove the block off text template since you don't have consensus to keep it there. Fnagaton 12:10, 8 May 2007 (UTC)

• I think this proposal is a step forward, but it needs work and more careful deliberation. It's too soon for a vote. I realized tempers are quite frayed here, but if we can't have a reasoned discussion, then I think it is time to ask for mediation.--agr 23:54, 7 May 2007 (UTC)
• I too believe this is getting closer to a resolution, but this text still misses the core issues (per Omegatron). I do feel it's reasonable to ask an editor who is changing prefixes to binary equivalents to provide justification for the accuracy of doing so if there is a reasonable doubt (that is, the one requesting verification isn't doing so simply to be combattive). However, I simply disagree with the argument that misuse of SI prefixes should stand just so we can mirror source text ("misuse" expresses my opinion yadda yadda, don't pester me about it). Furthermore, I simply hate the parentheses solution. Echoing Omegatron's comment, this is just superfluous and messy. (yes, I am very well aware of why it was proposed this way, so there's no need to explain it further to me) I'm not going to vote on this one since it confuses the issue of why the IEC prefixes are even useful (providing the "OS-reported" capacity of a hard disk isn't the reason; it's about unambiguity). -- mattb 02:00, 8 May 2007 (UTC)
• My reading of the proposed style is that a prefix would only need to be "disambiguated" once in a paragraph (or two) that used that prefix several times. It may need to be "disambiguated" several times in a very long article. This would clarify the numeric value while preserving the readability. -- SWTPC6800

  Wouldn't the current MoS regarding disambiguation apply? Fnagaton 10:06, 8 May 2007 (UTC)

• "These are expressed by binary prefixes": But usually they are in fact not expressed by binary prefixes.
• "Using the prefixes kilo-, mega-, giga-, etc., and symbols like KB, MB, GB, etc., in the binary sense can cause confusion.": Using the binary prefixes causes more confusion than using the common, understood prefixes the differences between which generally have little or no impact on the reader's understanding of the article. —Centrx→talk • 20:36, 9 May 2007 (UTC)
• I support this proposal as it stands, but I would support it more strongly if it explitly mention that the Ki, Mi, etc prefixes are still not commonly used in the non-academic computign world, and are by no means universially useds in the academic world either, and their use without disabiguation or l;inking is likely to cause confusion, rather than avoiding it. it shoudl aslo add that where confusion or ambiguaity are not likely the binary prefixes are not required. DES ^(talk) 21:41, 9 May 2007 (UTC)

  Thanks for the support, perhaps move it above so it doesn't get lost in this section (which is likely to get huuuuge!) and leave the body of the larger comment here? :) Fnagaton 21:54, 9 May 2007 (UTC)

Support any proposal that uses original reference style for memory amounts. If only the energy absorbed in this folly could have been applied to, say, correcting spelling mistakes. If certain editors can confidently change kB to kiB without reference to original sources, that indicates that the context is perfectly clear and so there's no need to change the prefix anyway. A superstititious reverence for numerical accuracy is not required here, since in reality the stated capacities are only approximations to the actual usable space anyway...seems foolish to worry about "640 k" of RAM when 100+k of it are not accessible for the user, as a hypothetical example. --Wtshymanski 00:17, 10 May 2007 (UTC)

Addendum

As I read on somebody's talk page, it may be a good idea to state that articles about hardware or software that predates 1998 should never use "kibibytes" because back then, the term had not been invented yet. >Radiant< 11:20, 8 May 2007 (UTC)

This argument has been brought up and answered several times. The meter wasn't invented in ancient Egyptian times, but we don't prohibit its use on related pages. Uniformity and unambiguity trumps tradition, or so the line of reasoning goes. I don't think you'll get good support on this point (but I could be wrong). -- mattb 12:14, 8 May 2007 (UTC)

Would agree there as well. I don't know what when a standard was introduced has to do with its use once it's in place. Light was around a lot longer than any measures of either meters or seconds, but we still express its speed in meters per second. Seraphimblade ^{Talk to me} 13:16, 8 May 2007 (UTC)

Thats an invalid argument because there are still tons of publicly available books and magazines about these older computer systems available that still use kB to mean 1024 Bytes, and using kB now for 1000 (as a consequence of using KiB for 1024) is just not compatible with these old documents and will cause confusion. so unlike your egyptian example where no conflict could arise by doing this, a big conflict will arise if we do this -without further expanation on the page- Mahjongg 10:48, 10 May 2007 (UTC)

Indeed, meter per second is the SI standard unit for speed. But articles about cars on Wikipedia use km/hr. Why? Because per hour speed measurements are universal in the industry and that is what the general public is familiar with. Go try adding m/s to those articles, even parenthetically.--agr 14:57, 8 May 2007 (UTC)

km/hr is accepted by BIPM for usage with SI, actually. -- mattb 15:41, 8 May 2007 (UTC)

I could be picky here and say mph, but I won't. ;) I would like to say the yard in American Football is a better example of inconsistent standards use. Fnagaton 15:47, 8 May 2007 (UTC)

That's probably a better example, though I still don't think it perfectly fits this situation. -- mattb 15:57, 8 May 2007 (UTC)

km/hr is not SI. The only SI unit for speed is m/s. The hour is listed under "Non-SI units accepted for use with the SI." So is the nautical mile and the knot (1852/3600 m/s). If I went around changing articles that are in m/s to knots would that be acceptable? The point is we use units that are appropriate to a given field. See, for example flight level which describes the standard altitudes flown by aircraft in the western world in feet, not meters, because that is the accepted usage. Assigning binary meanings to K/M/S is accepted practice in the computer industry. We should follow accepted practice in the industry and add explanations where appropriate. The IEC binary prefixes may be helpful in those explanations, but should not be the primary unit used if that is not what the sources use.--agr 16:24, 8 May 2007 (UTC)

Right, the hour is accepted for use with SI. Bastardizing SI prefixes is not accepted for use with SI. -- mattb 16:52, 8 May 2007 (UTC)

The IEC binary prefixes are not SI either. "It is important to recognize that the new prefixes for binary multiples are not part of the International System of Units (SI)..." [4] Your use of the term "bastardizing" shows how POV this push for binary prefixes is. You seem to believe that armed with a few of standard organization recommendations, your opinion of what is proper usage superceeds that of an entire industry and every major print publication in the world. --agr 17:27, 8 May 2007 (UTC)

IEC prefixes are accepted for use with SI, like the hour. Nowhere did I claim they are part of SI. I also assume that other editors are intelligent enough to realize when I'm expressing an opinion so I don't have to explicitly disclaim them with "this is just an opinion". Of course I have a point of view, as do you and every other editor here. I have at many occasions acknowledged the validity of other points of view, so going off on my expressing my own viewpoint is ridiculous. -- mattb 18:24, 8 May 2007 (UTC)

I propose that we use the "IEEE Computer Society Style Guide." Revised (October 2006) edition. The IEEE Computer Society Style Guide Committee's mission is to clarify the editorial styles and standards that the Society's publications use.[5]

K: 1,024, the binary thousand (25 Kbytes, 25-Kbyte memory); also used as temperature designator for Kelvin scale, as in 273 K. However, when used as $10K (with no space) “K” means 1,000. The use of “K” when referring to monetary quantities is discouraged.

KB: kilobyte; use Kbyte (25 Kbytes, 25-Kbyte memory)

Kb: kilobit; use Kbit or spell out, but use Kbps for kilobits per second

Kbyte: kilobyte (25 Kbytes, 25-Kbyte memory)

SWTPC6800 02:07, 9 May 2007 (UTC)

Why not the IEEE "Information for IEEE Transactions, Journals, and Letters Authors"?

• "kilo (k): SI prefix for 10³. The prefix kilo shall not be used to mean 2¹⁰ (that is, 1024)."
• "kilobyte (kB): kB $\triangleq$ 1000 B"
• "mega (M): SI prefix for 10⁶. The prefix mega shall not be used to mean 2²⁰ (that is, 1 048 576)."
• "megabyte (MB): MB $\triangleq$ 1 000 000 B"
• "giga (G): SI prefix for 10⁹."
• "gigabyte (GB): GB $\triangleq$ 10⁹ B"
• "tera (T): SI prefix for 10¹²."
• "terabyte (GB): GB $\triangleq$ 10¹² B"

We can appeal to authority til the end of time, but what matters in this discussion is the style that best serves Wikipedia's readers; a style that is consistent from one article to the next and doesn't rely on application-specific jargon. — Omegatron 02:45, 9 May 2007 (UTC)

After edit conflict: No offense to anyone intended, but using "$10K" to mean 10⁴ is not only incredibly obtuse and nonsensical, but manages to be even more obscure and marginal than the IEC prefixes while at the same time flying in the face of well-accepted unit convention (space between value and unit). With all the hullabaloo raised due to injection of some 'i's into byte capacity units, I can't imagine that many people would agree that changing the DVD-R article to use $4.7GB (presumably the next logical step following this convention) is a remotely good idea. Interestingly, the "style guide" you linked (which rather seems to be masquerading as a glossary) isn't very helpful on this matter, since it defines "giga" as a "standard prefix meaning one billion" without any exception. [6] I have to say that I agree with this latter definition, but I fail to see how this bizarre page is going to help us at all. This is a wonderful example of how, as Omegatron pointed out, appeals to authority can be counterproductive. Most people who care about such things as standardization seem to think BIPM does a good job with SI, and I for one prefer to stick with that unit convention since a lot of work has gone into making it sensible and consistent. -- mattb 02:54, 9 May 2007 (UTC)

We should use whatever term the source uses, with specific clarification in parentheses for the first such use if necessary. This allows an elimination of ambiguity while still following the same specifications used by all reliable sources, and avoiding unpopular neologisms. For instance, in the Commodore 64 article, the first mention could say something like: "The Commodore 64 has 64K (64×2¹⁰ bytes) of RAM", and in future references to memory, just use "K" by itself, under the assumption that one such disambiguation is enough. The majority of sources from the 8-bit era simply use "K" rather than "KB", although some do use the latter, so it could be justified. What cannot be justified is a made-up term that absolutely no-one used then and almost no-one uses now. *** Crotalus *** 03:41, 9 May 2007 (UTC)

I was just pointing out that not everyone at IEEE got the word on kibibytes. By the way, $10K is a monetary value, ten thousand dollars. The binary prefix side of this dispute repeatedly cites the authority of the IEC[7]. In order for a standards organization to be relevant it must acknowledge the rule of kibibytes. The whole binary prefix push is based on an appeal to authority, not on what the technical world actually uses. -- SWTPC6800 03:39, 9 May 2007 (UTC)

That may be why some people supported the guideline originally, but the the reason it was first proposed (and the reason I supported it and continue to) was purely for its merits in disambiguating byte capacity units. Who cares what my favorite organization uses? Wikipedia's guidelines are its own. All this dreck about what organization recommends which prefix is just an aside; mostly a defense against the "Wikipedia is on its own" argument. My comment was only intended to point out that in general, most editors seem to think it a good idea to follow SI convention where possible. If there is any authority that does a very good job of maintaining self-consistency and generally keeping the scientific world straight, it's BIPM, and I have no problems appealing to that authority since it is so widely respected.

P.S. - Using the short-hand abbreviation "K" for "2¹⁰ bytes" in Wikipedia articles is horribly sloppy, no matter how many Commodore users threw it around. Jargon used without any consideration to the rest of the world is no basis for good journalistic practice (care to guess what I use the terms "PR" and "BOE" to mean? Hint: I'm not a manager or a banker). The only place shoddy usage like "64K" has on Wikipedia is in describing objects that include said usage in their name. You've neatly pointed out one great case in which maintaining absolute consistency with article sources is a terrible idea. -- mattb 04:06, 9 May 2007 (UTC)

You're missing the point. Essentially no one in the IT field, then or now, uses the neologisms. It doesn't matter whether they're recommended by the IEC, SI, or Pope Benedict XVI. Computer hardware manufacturers use the traditional terms. IT workers use the traditional terms. Virtually all reliable sources use the traditional terms. This isn't like with metric measurement units, where the United States is an outlier in the world community and the metric terms are commonly used in many contexts even within this country. This is a complete rejection of the IEC's foolish attempt to change common usage. It is not the place of Wikipedia to force the IEC's standards down everyone's throat. It's our job to report what reliable sources say. In any case, if you think we should spell out "kilobytes" rather than use the abbreviation "K" on 8-bit articles, that's fine; there are enough sources to support such a usage. If you think that term is too ambiguous, then as I suggested a parenthetical disambiguation can be added to the first such usage in each article. What is not OK is to use terms that weren't used then and aren't used now. *** Crotalus *** 04:14, 9 May 2007 (UTC)

Funny; I'm an IT professional and an OS developer (NetBSD), and I do, in fact, use the terms in discussion with my colleagues - and not in jest, either. (Calling the prefices neologisms is also very, very not NPOV.) --moof 03:05, 10 May 2007 (UTC)

How would you express the memory size of the Control Data Corporation 6600 mainframe computer? CDC 6600 Wordlengths, characters You may have to use a shoddy term like 128 K words. -- SWTPC6800

Things have gotten way out of control on this issue. User:Sarenne got in an edit war with User:Fnagaton, and was blocked for WP:3RR. He/she was then unblocked soon after, upon promising not to continue the edit war. Instead, Sarenne then went on a spree, adding "binary prefixes" to over 100 articles, with no discussion. I can only interpret this as an attempt at revenge. I've had to waste nearly an hour reverting these changes, which I consider to border on vandalism. This issue is going to have to eventually go to mediation; I haven't seen any progress in discussion on this page. The section should be removed from the MoS entirely since recent discussion makes clear that it has no consensus at this time. *** Crotalus *** 05:20, 9 May 2007 (UTC)

Even glancing at User Talk:Sarenne it is obvious that the block was for editing a user talk page (in order to reinstate a question), and that the promise was to stop editing the user talk page in question- which is exactly what happened. That hour of yours was literally wasted; the current wording of the MOS, whether you personally like it or not, is against you. To wit: "If a contributor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should be accepted." If this is out of control (and I am not going to argue otherwise), then accusing others of vandalism, of being motivated by revenge, and otherwise assuming they are not acting in good faith is not a good way to get things under control. — Aluvus t/c 07:23, 9 May 2007 (UTC)

That section is currently marked as disputed, because there is clearly no consensus for its inclusion. This isn't about me. The fact is that this section of the MoS was created without ever consulting the editors who work on the articles in question. To put it bluntly, it was implemented behind our backs. I'd rather actually be working on the articles instead of fighting off drive-by editors who know NOTHING about 8-bit systems, yet insist on imposing unpopular neologisms on them. You can't claim consensus to alter articles unless you involve the regular editors of those articles. More to the point, this MOS page, like every other, says: "The guidelines here are just that: guidelines are not inflexible rules." If these guidelines don't reflect actual practice or current consensus, then they are wrong and need to be changed. And WP:AGF states that we are not required to assume good faith in the face of evidence to the contrary. Sarenne gets in an argument with Fnagaton and then immediately thereafter goes on a spree of edits calculated to piss other people off? (Remember, Fnagaton has been on the side of standard prefixes, and the prefix issue was the subject of the argument in the first place.) Sorry, but I have a very hard time assuming good faith here. *** Crotalus *** 07:34, 9 May 2007 (UTC)

By what means did you determine how much someone else knows about 8-bit systems, or what their actions were "calculated" to do? Again, you will do a lot more to help the situation if you do not make these kind of accusations. If you disagree with Sarenne's edits, or consider them counter-productive, say so. But trying to brand them as vandalism is not helping. — Aluvus t/c 07:58, 9 May 2007 (UTC)

Well, I disagree with Sarenne's edits and consider them counter-productive. And the basis for my statement is that, as far as I can tell, Sarenne's only edits to articles on 8-bit systems have been to insert the prefixes. There are no actual improvements to these articles and no evidence that Sarenne knows anything about 8-bit systems. The edits could as easily have been done with a bot. Again, I think that if you want to make policy for a set of articles, you have to engage the editors of those articles, not come up with a false "consensus" in one of Wikipedia's many obscure corners. Note that the alleged consensus fell apart as soon as people affected by the changes started speaking up. *** Crotalus *** 08:16, 9 May 2007 (UTC)

Crotalus has called the situation correctly. The user Sarenne demonstrated such bad behaviour (especially the edits on my talk page for which he was 3RR blocked, seven reverts despite multiple warnings!) that the user has lost any good faith as far as I'm concerned. This is because repeatedly reverting someone's talk page like that is far too much like stalking. Fnagaton 10:27, 9 May 2007 (UTC)

I'm sorry but I don't need to show you if I know something (or not) about 8-bit systems to be able to spot SI symbols being used in a binary sense and to change them to binary prefixes, like it is still recommended by the MoS. I still thinks that it improves the encyclopedia and that's the only reason why I'm doing it. I will not answer your and Fnagaton's bad faith accusations.(If you are able to program a bot that can distinguish M meaning 1024*1024 from M meaning 1000*1000, bravo). Sarenne 10:39, 9 May 2007 (UTC)

Crotalus, you are aware that articles are not owned? You have no more say over what goes in an article that you've edited 500 times than a guy who's edited it once. None, zilch, nada, the two of you are on the same footing. There seems to be a nasty habit of thought around here that "Well I edit this article a lot, so I should get veto power over what goes into it." Doesn't work that way, and here's hoping it never does. Seraphimblade ^{Talk to me} 12:05, 9 May 2007 (UTC)

Regarding "ownership": [8] "it would be wrong to switch simply to change styles, although editors should ensure that articles are internally consistent. If it has been stable in a given style, do not change it without some style-independent reason." Trying to claim the MoS allows changing binary prefixes, especially now lack of consensus has been demonstrated, is in itself a style issue so the parent MoS terms apply. Fnagaton 12:37, 9 May 2007 (UTC)

Fnagoton, I'm not even discussing the MOS issue here. Crotalus seems to be implying that those who simply come along and edit an article once count less as contributors than those who edit it 500 times, or that those editing only a specific part of it count less as contributors than those doing more general work to it. That is a nasty, pernicious attitude around here (not just on the part of Crotalus), and needs to be stopped wherever it rears its ugly head. Seraphimblade ^{Talk to me} 12:41, 9 May 2007 (UTC)

I know where the idea of ownership comes from, it's the guidelines where they mention contributor and copy editor as two different distinct actions, where the contibutor to an article has more weight than a copy editor. Fnagaton 12:44, 9 May 2007 (UTC)

There does seem to be a problem of ownership. A small handful of editors claim absolute ownership of the Binary Prefix section of the Manual of Style. After months of dispute they still claim the issues is decided and cannot be changed. They also appear to be condoning [9] a meatpuppet to enforce their view. -- SWTPC6800 15:04, 9 May 2007 (UTC)

Are you accusing me of being a meatpuppet ? Sarenne 15:10, 9 May 2007 (UTC)

No, you don't get it, User:Swtpc6800(SWTPC=South West Technical Product Corportaion, I remember them) is actually accusing User:Seraphimblade to be -your- meatpuppet. His claim is that him giving you a barnstar was a political decision, nothing else. Mahjongg 16:21, 9 May 2007 (UTC)

I think we should avoid calling people meatpuppets. I believe all the participants in this discussion are independent actors who are sincerely expressing their views on the mattter at hand.--agr 16:36, 9 May 2007 (UTC)

Indeed, wild accusations like that are the best way to destroy any productive talks. Not that this has been very productive thus far... -- mattb 19:32, 9 May 2007 (UTC)

Eh. I've been called worse, doesn't particularly bother me. And yes, holy hell, I'll happily give a barnstar to anyone who actually bothers to read and follow the Manual of Style. We could use a lot more of that. Seraphimblade ^{Talk to me} 20:52, 9 May 2007 (UTC)

Our 8-bit computer expert, Sarenne, just change the TRS-80 Model 100 line floppy disk storage size from 90K to 90KiB. Neither is correct. He also edited the article in a way that hid a citation link that would show the correct size. -- SWTPC6800 02:43, 10 May 2007 (UTC)

If neither is correct, change it and stop reverting KiB to KB if you know that "90 KB" is not correct ! Sarenne 10:28, 10 May 2007 (UTC)

The whole binary prefix push is based on an appeal to authority, not on what the technical world actually uses.

The IEEE mandating the use of a certain style in certain documents is both authority and what the technical world actually uses.

• Authority: It's not just the IEC. BIPM (SI), NIST, IEEE, ISO, ANSI, SAE, and other acronyms have either adopted the SI/IEC standards or have documents that recommend the same thing.
• What the technical world actually uses — Omegatron 01:49, 11 May 2007 (UTC)

Enough of this

The last time there can reasonably be said to have been "consensus" for the binary prefix MoS section was way back in 2005, when a vote came out 20-6-2 in favor of the neologisms. Ever since then, this "guideline" has been the subject of strong opposition; see Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_39#Proposing_a_major_change_to_binary_unit_prefixes_policy, Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_65, and Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_66. Notably, it has mostly been the Manual of Style regulars who support the use of the IEC neologisms, while the actual editors of the articles strongly oppose them. This is a strong indication that the Manual of Style is being used inappropriately.

There hasn't been any vote since 2005, both because Wikipedia generally doesn't work that way and because the proponents of binary prefixes have very successfully filibustered any attempts to alter the status quo.

Enough. Unless someone can show me that actual consensus exists for this section now — not back in 2005 — then I am going to remove it. I'm tired of having to waste time protecting articles from drive-by style police instead of actually working on improving them. If I'm going to get this guideline shoved in my face, I want to see evidence that it actually has widespread support among Wikipedians — and not just the tiny coterie of Wikipedians who regularly edit the Manual of Style pages. *** Crotalus *** 20:42, 9 May 2007 (UTC)

Crotalus, it takes consensus to change something. No consensus defaults to status quo. Seraphimblade ^{Talk to me} 20:48, 9 May 2007 (UTC)

This is faulty reasoning, because the "status quo" is causing a great deal of damage across Wikipedia, including edit wars. More to the point, if you want to claim jurisdiction over all of Wikipedia, you need to show current consensus, not just a lack thereof. It's not convincing to say "I can change prefixes all over Wikipedia, no matter what the article maintainers think, because there was a vote in 2005 and I've managed to stop there from ever being another one since then." *** Crotalus *** 20:58, 9 May 2007 (UTC)

I've asked for clarification on the "status quo" argument at the Village Pump policy page. *** Crotalus *** 21:13, 9 May 2007 (UTC)

It looks like "Proposed new guideline for binary prefixes" is building consensus quite nicely. Perhaps give that a little longer to see what happens? In my opinion it is a proposed guideline that is vastly better than the current disputed guideline so, again in my opinion, it's worth trying to get it promoted to be a guideline first. Then perhaps we can all think it over and then if need be later on discuss any further changes. Fnagaton 21:14, 9 May 2007 (UTC)

Hold your horses. Do you think any of us like debating this for weeks on end? The fact that you're frustrated doesn't give you the ability to declare what consensus is or is not. Like Fnagaton said, keep working on a better guideline that everyone can be happy with. -- mattb 21:36, 9 May 2007 (UTC)

-Off topic- Dude, that's twice now you've agreed with something I've said, we're meant to be disagreeing here... I'm getting scared (that I may be talking sense!) ;) Fnagaton 21:51, 9 May 2007 (UTC)

Friend, I have nothing against you personally, even if I do disagree with your position on the matter at hand. -- mattb 21:52, 9 May 2007 (UTC)

it takes consensus to change something. No consensus defaults to status quo.

No it does not. No consensus = no consensus. — Omegatron 01:41, 11 May 2007 (UTC)