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

JEDEC finally responds

So I finally got a response from the JEDEC on whether their standards require usage of the unit notation that they use. Here is the full text of my question and the JEDEC response:

http://www.prism.gatech.edu/~gtg774w/jedec_question.txt

I won't even offer my own interpretation since I believe Mr. Mann's response is very clear. -- mattb 22:15, 21 May 2007 (UTC)

"We certainly recommend conformance with symbol standards of JEDEC..." - The symbols defined in the JEDEC standard are K/kilo/M/mega for values of 2^10 and 2^20, then says "... IEEE, IEC, and NIST" because those other three seem to propose units opposite to the ones defined in the JEDEC standard, a contradiction. However it's also strange that he says "such usage is voluntary" given that JEDEC standards documents say "No claims to be in conformance with this standard may be made unless all requirements stated in the standard are met." To be honest I don't think your question was made in a very good way, it lead to too much confusion about what you really needed to find out. Fnagaton 00:36, 22 May 2007 (UTC)

Well it's not "very clear" to me.

We certainly recommend conformance with symbol standards of JEDEC, IEEE, IEC, and NIST, but in the long run, such usage is voluntary.

If not for that "JEDEC" at the beginning of the list, it would make sense, but the JEDEC "symbol standard" seems to conflict with all the rest (which is why some people keep bringing it up). Unless he's talking about a different "symbol standard" document...

Thanks for being the squeaky wheel, though. — Omegatron 01:01, 22 May 2007 (UTC)

Well then I encourage you (either of you) to pose your own wording of the question to the JEDEC rather than bothering with second-guessing Mr. Mann's response. I feel that his response is clear enough to show that the JEDEC standards do not require usage of any particular unit convention, contrary to the implication brought up several times here. This is the main point I was seeking to elucidate. -- mattb 01:03, 22 May 2007 (UTC)

I'm not second guessing Mr. Mann's response I am pointing out where it doesn't make sense. Also here's where your point has a problem, no standard in the world "requires usage" of any units, not one. It's not like they are police with guns pointed at your head. All standards are voluntary but the standards do "recommend/require conformance" if people are going to claim conformance with a standard. Fnagaton 01:09, 22 May 2007 (UTC)

Is your implication that a product and related documentation must use the same unit prefixes used by JEDEC standards in order to conform? (this is exactly the question I asked) If that's the issue, I'll just follow up with Mr. Mann and seek clarification. However, I think you're nitpicking the word 'require' since he is obviously talking about requirements in the context of JEDEC standards, not in the context of pointing guns at anyone's heads. (P.S. not all standards are voluntary, but that's neither here nor there) -- mattb 01:16, 22 May 2007 (UTC)

How about this, can you phrase the question you'd like to have explicit clarification on, and I'll pose it to him since we already have a running email dialog? -- mattb 01:19, 22 May 2007 (UTC)

Fred Mann works (maybe retired now) for TI and has served on JEDEC committees for over 30 years. He is currently the chairman of JEDEC committee JC-10; Terms, Definitions, and Symbols. In the mid 1980s his pet project at TI was the new logic symbols the appeared in the TTL and CMOS data books. He even got them to be IEEE Standard 91-1984.[1]

At the time I was on a couple of JEDEC committees and worked with TI engineers who would comment about Fred's crusade for the peculiar logic symbols. The new symbols never became popular. If you look at a current TI data sheet you will find the traditional symbols for buffers and such.[2]

An endorsement from Fred Mann about a peculiar binary prefix that is an IEEE standard but nobody uses is ironic. -- SWTPC6800 01:35, 22 May 2007 (UTC)

Interesting thoughts. Do you propose we ignore JEDEC's stance on the matter of unit prefixes, then? :) -- mattb 02:05, 22 May 2007 (UTC)

All current computer memory modules conform to JEDEC Standard 21 because of the Serial Presence Detect method. A small SPD ROM on the memory module holds all of the parameters necessary to configure the processor and motherboard for optimum memory performance. This has been used for a decade and is in the latest DDR3 modules.

Memory makers have to register their products with JEDEC to reserve a spot in the table. It also means motherboard and processor manufactures have to follow JEDEC Standard 21. JEDEC Standard 21 uses KB (as 1024), MB and GB. When you buy a memory module it is labeled in MB or GB. It doesn't use IEC prefixes.

The binary prefix fans have focused on a footnote in JEDEC Standard 100 that mentions the IEC standard. [3] JEDEC memory standards never use the IEC prefixes. The companies that sell memory modules never use IEC prefixes. Yet the kibibyte crowd insists that there is a dispute on what JEDEC uses, or even if JEDEC is relevant. The world uses KB (as 1024), MB and GB to measure RAM sizes. -- SWTPC6800 03:01, 22 May 2007 (UTC)

And? — Omegatron 03:37, 22 May 2007 (UTC)

Actually I was rather more interested in NIST, IEEE, ANSI, and IEC. You were the one who brought up JEDEC, if memory serves. It's still not clear to me how this is any different from the common usage argument. You keep reiterating ad nauseum what the world uses. Thanks, we all feel very enlightened. If it makes you happy we can drop all mention of any organizations' recommendations/endorsements/de facto usage/whatever; they (IEC, BIPM, IEEE, NIST, ANSI, etc) were only originally included in response to claims that nobody supported their usage. I care only about the merits of using the prefixes, and professional organization endorsement is just a side point included for the sensibilities of others.

What struck me as bizarre about this JEDEC thing from the start is that you seem so determined to point out that one particular organization utilizes common practice as if their usage alone provides the entire justification for the common usage or somehow invalidates the stylistic recommendations of other organizations. Common usage doesn't need validation, we already know what it is and realize the merits of using the most familiar notation. Nobody has ever argued against what common usage is or that high profile organizations use it, so it seems so incredibly quixotic to me that you'd vehemently insist that the JEDEC's common usage is so novel or persuasive. -- mattb 05:11, 22 May 2007 (UTC)

You seem to think that a profession organization is one that endorses the IEC binary prefixes. JEDEC, Intel, Micron, Dell, Western Digital, The New York Times, PC Week, and the IEEE Computer Society must be examples of organizations that do not care about unambiguous communications with their readers and customers.

If you know what the world uses why do you insist that Wikipedia ignore it. -- SWTPC6800 14:41, 22 May 2007 (UTC)

You're putting words in my mouth. I never questioned that the JEDEC is a professional organization. Just because they "don't care" doesn't mean we shouldn't as well. The world uses a lot of crappy notation that we aren't obliged to use, so your point is utterly ignored. -- mattb 00:40, 23 May 2007 (UTC)

Because it's wrong and ambiguous? — Omegatron 14:50, 22 May 2007 (UTC)

No it's not wrong and it's not ambiguous, at least not to the extent you're trying to portray the situation. Fnagaton 14:54, 22 May 2007 (UTC)

Wait, you're making the claim that "megabyte" is not an ambiguous term? Are you trying to be obtuse just for the sake of it? If so, you're doing a wonderful job. -- mattb 00:40, 23 May 2007 (UTC)

Hail a Strawman. Fnagaton 10:14, 23 May 2007 (UTC)

Just as a curiosity, not that I intend to get back to arguing in circles, the more I read this discussion the more I think there should be a name for the logical fallacy of dismissing the opponent's valid argument by claiming it's a logical fallacy. In Fnagaton's case I would have needed that quite often ;) --SLi 20:38, 28 May 2007 (UTC)

Matt did not make a valid argument. He attempted to state in different terms what I had already written, setting up a straw man. Fnagaton 10:34, 29 May 2007 (UTC)

No wonder you see straw men everywhere if you think that any rephrasing of your argument is a straw man. But I understand you, it's so nice to yell "straw man!" (without pointing out where the other person misunderstood you) when you realize your argument doesn't hold. --SLi 12:35, 29 May 2007 (UTC)

No you are wrong. My argument does hold. The "argument" presented by Matt doesn't hold. Matt tried to present what he wrote as my argument. What Matt wrote and what I wrote are not the same. Hence Matt used a straw man logical fallacy. If you actually read what I wrote and compare with what Matt wrote the difference is obvious. Fnagaton 13:01, 29 May 2007 (UTC)

I'm not trying to decide whether your argument holds or not, I'm attacking your funny practice of dismissing arguments by claiming logical fallacies everywhere. To me the difference is not obvious. You wrote: it's not ambiguous. Matt wrote: Wait, you're making the claim that "megabyte" is not an ambiguous term?. And then you scream straw man. Throughout this discussion you have used this strategy to avoid responding to quite valid points. --SLi 17:58, 29 May 2007 (UTC)

Now you're using ad hominem, that is attacking the person instead of attacking the argument. I also note your attempt to misrepresent what I wrote by only quoting a tiny part of the whole sentence. Again the "points" previously brought up that you seem to think have been dodged are not valid because they rely on incorrect assumptions or misrepresentation instead of actually tackling the real issue. Now then, are you actually going to contribute something other than logical fallacies? Fnagaton 18:22, 29 May 2007 (UTC)

Suggestion to follow the convention used by the first author

The reason I removed this is because it ignores the relevance of rewrites. For example, I rewrote central processing unit in its entirety. The original article utilized some common usage (MB and such ilk). My rewrite uses IEC prefixes. With the current wording, it could be argued that I should change the CPU article back to the convention used by the first author simply because he got to it before me, which I do not believe is the intent behind the phrasing. What's more, I feel that the text could just as easily be extended to any other article since the IEC prefixes only started being used after many core Wikipedia articles were written. If that's the case, why not just replace the entire section with the line "don't use IEC binary prefixes"?

Could someone point me to where it was agreed upon that the American/British spelling differences solution should be recommended for binary prefixes as well? I don't recall there being any consensus on adding this text, only a few people suggesting it. -- mattb

I think you should use GB not GiB in that article since GB is the correct term to use as noted in the majority of reliable sources relevant to that article. You could replace the section with "don't use IEC binary prefixes" if you want, but I don't agree with that since if some new chip does somehow use binary prefixes in the majority of its documentation then the article should. I reverted your change because I think it removes an important part of Radiant's change which does need to be said. It's been like that for a while and I think you (and everybody else) should leave the guideline alone until mediation has been done, like the reason you gave for no changes being made to it on 16:10, 10 May 2007. Radiant made the change to capture to spirit of the consensus that was being discussed a while back. I believe, though you will have to check with Radiant directly, that Radiant has had a lot of experience with dealing with similar guideline problems and saw the example set by the style guideline cited as fitting this situation rather nicely. Fnagaton 00:47, 22 May 2007 (UTC)

1. What mediation? 2. "It's been like that for a while" is exactly the reasoning that you have vehemently argued against. It's been like this for several days; I just haven't noticed it until now because I've been busy. 3. What "spirit of the consensus"? I looked back through the dialog and found two or three people mentioning the issue, but no consensus whatsoever that the British/American variant treatment should definitely be applied here.

1. Search for mediation in the index on this page and you will find it. 2. No it's not the same thing. 3. The guideline was changed after a lot of discussion and the current text captures the spirit of those discussions, if you were busy or away then I suggest you talk to Radiant about the changes made so you can catch up with the current situation. On a separate note I've also noticed a couple of single use anonymous edits in the guideline history to remove that text. With the single use anonymous bot like edits on several other articles putting back binary prefixes I do hope the guideline page isn't going to get the same problem. Fnagaton 11:22, 22 May 2007 (UTC)

1. I did search for mediation. There has been talk of it, but no action. This text was not discussed and I'm asking that it be discussed now. You cannot refuse to discuss it simply because "it's been there for a few days". I also ask that you don't offload this onto Radiant. He's welcome to comment here if he wants, but hiding behind one of his edit comments as an excuse not to discuss this won't fly. -- mattb 00:48, 23 May 2007 (UTC)

It's in the name gathering stage. I'm not "offloading" onto anyone, I'm telling you who to ask because that's who you need to ask. Fnagaton 19:19, 23 May 2007 (UTC)

My request still stands for you to show where this was actually discussed. No offense intended to Radiant, but nobody's experience (my own included) in contentious stylistic matters is sufficient to replace discussion. If that discussion has already taken place, please show it. If not, let's discuss it.

No, see above. Fnagaton 11:30, 22 May 2007 (UTC)

You're refusing to discuss? -- mattb 00:48, 23 May 2007 (UTC)

No, I'm telling you were to go to find out what you need to know. Have you done that yet? Fnagaton 19:19, 23 May 2007 (UTC)

Your suggestion as regards the article doesn't address the point of why I mentioned it. In any case, myself and others have always disagreed that sticking to the unit convention article sources should take prescedent over unambiguous units (this is, after all, the crux of the current disagreement), so you didn't exactly find common ground on that one (but you know this already). -- mattb 01:13, 22 May 2007 (UTC)

However consensus is against you. Fnagaton 11:30, 22 May 2007 (UTC)

You've nicely made up a consensus or at least extended weak consensus on related matters to this point. I have never seen any agreement that mirroring sources trumps internal consistency. Show where this was agreed upon. -- mattb 00:48, 23 May 2007 (UTC)

I've not "made up" anything, you can sit there with your assumptions about what you remember as being consensus but the facts do show that your point of view is not that of the consensus. I also remind you to be civil because your ad hominem and insinuations do not help you. Fnagaton 19:19, 23 May 2007 (UTC)

I thought that the reference to the "style guide on national varieties of English" was indeed a reasonable compromise, as it avoid absolute and is in sync with the idea that wikipedia should reflect what the world is not what it 'should' be.

Indeed. Part of the reason was to add weight to the guideline text to stop the mass bot like editing of articles to use binary prefixes by a single editor. Fnagaton 11:30, 22 May 2007 (UTC)

oh and yes 'What mediation?' indeed. Is there a mediation going on ? - Shmget 01:52, 22 May 2007 (UTC)

There's mediation planned and names are being gathered. :) Fnagaton 11:30, 22 May 2007 (UTC)

Even without mediation, the comments from editors outside this debate on the Village Pump and Administrators' noticeboard/Incidents have clarified some of the points that are in contention here.

• Disruptive or aggressive editing of articles to enforce the Manual of Style is never OK.
• The Manual of Style is not set in stone and when it loses consensus it no longer applies. You do not have to reach a new consensus to overturn it.
• If you have to repeatedly tell more and more editors that something has already been decided, you probably don't have consensus.
• Wikipedia is not and does have to be consistent across all articles. Each article should be consistent.

SWTPC6800 04:23, 22 May 2007 (UTC)

That's well and good, but none of it addresses why the American/British variant treatment should be used in the binary prefixes case. Nor does it explain where the text was discussed for inclusion. Can we stay on topic rather than preaching about what we already agree upon? -- mattb 05:15, 22 May 2007 (UTC)

Again, see above. Fnagaton 11:30, 22 May 2007 (UTC)

I did, you're once again refusing to show where this was discussed and implying that there was some agreement that you have yet to explicitly show. -- mattb 00:48, 23 May 2007 (UTC)

No, you're misrepresenting what I have written because I'm not refusing anything. I am not going to speak for someone else because that is dishonest, no matter how many times you ask me to. I told you who to ask to find out the answer. Fnagaton 19:25, 23 May 2007 (UTC)

Now there have been more anonymous edits to remove the same text block. *sigh* Just stop it, whoever you are, at least have the courage the edit using your usual login. Fnagaton 13:20, 22 May 2007 (UTC)

OK It's now clear an anonymous sockpuppet is being used to make changes to the project page. Can an admin please protect the page from edits by anon/new users. Fnagaton 14:22, 22 May 2007 (UTC)

Feel free to file a request at WP:RFP. I don't think that the level of anon vandalism on this page is nearly sufficient to merit protection, so I won't protect it. However, someone at RFP might. -- mattb 00:48, 23 May 2007 (UTC)

Well as predicted and now demonstrated (I revert, another anon IP springs up to do the edits with some used previously to attack other pages, I revert, another springs up) there's now a lot of anonymous open proxy edits on a whole bunch of articles. So I put in a multi-page request detailing the pages that have been affected. At least one good thing has resulted from my "battle" against this anon proxy user, that is it gives a good list of proxy IP addresses and more evidence to use against the user who is doing it. Fnagaton 18:29, 23 May 2007 (UTC)

More systematic changes

Okay, so some folks are now going back and systematically changing prefixes in articles from IEC back to common usage, possibly using the new "defer to the first author" justification. How is this any better than what Sarenne caught so much flak for doing? Didn't we agree that we wouldn't make masses of edits to articles until this was resolved? Is it right to go and start making the masses of edits again as soon as the guideline text is changed a bit? What is the point of all this talk about not making mass changes if that's exactly what users do as soon as the text shifts slightly in their favor?

This is sheer madness. -- mattb 00:52, 23 May 2007 (UTC)

I don't see any "mass changes" anything like the mass disruptive edits made by the user Sarenne, I do see changes in specific articles where it is obvious those systems do not use binary prefixes or where editors have expressed their objections to using binary prefixes. Those changes are better because they have consensus, i.e. the don't rely on interpretation of a guideline that no longer has consensus. Therefore those changes have been made to improve Wikipedia. I thought we agreed the edit warring has to stop? What would be sheer madness is if someone (or more likely the anonymous editor from an open proxy) now reverted those changes back to binary prefixes because that would be edit warring. Fnagaton 10:12, 23 May 2007 (UTC)

Although I've just noticed a batch of anonymous reverts. This time by a Wanadoo France user. Fnagaton 10:57, 23 May 2007 (UTC)

There are these [4] changes as well, which led me to find a wonderful edit war going on with the Atari articles which have now been locked. - X201 11:32, 23 May 2007 (UTC)

If I were an admin I would look long and hard at the IP logs since I think it would then become clear that a specific user from the same block of IPs who also has a history of similar binary prefix changes is sometimes using an anonymous proxy to make their changes but has occasionally forgotten to use their anonymous proxy before editing. A block of IPs would need checking because a lot of ISPs these days assign IPs dynamically from their ranges. Also if I were an admin I would put a request in to get specific OS, browser and cookie data which can also help narrow down people who do use an anonymous proxy but use the same machine. Fnagaton 13:11, 23 May 2007 (UTC)

I did revert some of sarenne change too... But, at your express request, 2 days ago, I have stopped for now, pending some stabilisation/mediation here. Shmget 13:55, 23 May 2007 (UTC)

Would it be feasible to get semi-protection (no anon account edits) on all the articles where the anonymous proxy single use account has edited? Fnagaton 14:03, 23 May 2007 (UTC)

Template with CSS proposition (withdrawn, css/content issue)

• Considering that IEC notation are standardized, but still to this date rarely used in the real world.
• Considering that there exist a large body of source that do not use IEC notation
• Considering that it is probable that IEC notation will become more and more common
• Considering that the transition will probably last many more years

I propose the following solution:

Using template {{KiB|nnn}}/{{MiB|nnn}}/{{GiB|nnn}}/{{TiB|nnn}} see Template:KiB for exmeple

with the appropriate addition in common.css:

/* -- Usual + IEC -- */

span.kib:after { content:" KB (KiB)"; display:inline; }
span.mib:after { content:" MB (MiB)"; display:inline; }
span.gib:after { content:" GB (GiB)"; display:inline; }
span.tib:after { content:" TB (TiB)"; display:inline; }

Then a user that want to see only IEC notation can add in his USER/monoblock.css

span.kib:after { content:" KiB"; display:inline; }
span.mib:after { content:" MiB"; display:inline; }
span.gib:after { content:" GiB"; display:inline; }
span.tib:after { content:" TiB"; display:inline; }

And a user that want to see only usual notation can add in his USER/monoblock.css

span.kib:after { content:" KB"; display:inline; }
span.mib:after { content:" MB"; display:inline; }
span.gib:after { content:" GB"; display:inline; }
span.tib:after { content:" TB"; display:inline; }

I believe that this solution has the following advantages:

• Render edit war un-necessary. Since one can freely chose his favorite representation, there is no rational reason to edit war on it anymore.
• Allow for a long term transition. IEC notation have been standardized almost a decade ago, still their adoption is very slow. Until they are in widespread use, usual notation are still what most reader use and understand. But this template system will allow, in a few year, to transition to IEC-only by default, if and when IEC notation are pervasive.
• Allow for strict standard conformance right away, for the readers that feel so inclined.
• As a bonus, allow for strict traditional use for the readers that are allergic to IEC notation.

Note: we could also create template for hard drive size, where the notation mixed would be something like 100 GB (95.37 GiB) for mixed notation, where the GiB value would be automatically calculated. I haven't written it yet, but I believe it is doable.

Note2: If this is adopted, it might even be possible to have a user preference setting for this, to avoid the nasty cut and paste of css. - Shmget 19:33, 24 May 2007 (UTC)

Note3: Pending the process of getting the CCS changes in place, we can define the template as {{KiB|nnn}} = "nnn KB (KiB)" and change it back to the version using CSS as soon as the infrastructure is in place - Shmget 20:40, 24 May 2007 (UTC)

Have you even tested the template? It seems to reference "diplay" [sic]. I'm pretty unconvinced that this IEC byte unit notation is going to become more common. It also seems to me a bad idea to have content that depends on CSS. People still use non-CSS HTML rendering tools (especially for automated stuff), and the expectation is you might lose formatting, but not actual *words*. So I don't think using "content:" in a good idea. Perhaps more fundamentally, I'm not convinced this should be user-selectable. jhawkinson 18:47, 25 May 2007 (UTC)

yes I tested it, but I didn;t catch that typo, (fixed now). You are right, content in CCS is a bad idea, I didn't realize that. I'm unsure about the future of the IEC notation, but I am sure that there are very divided opinion about it, so finding a way for the two/three camps to each have it 'their' way without forcing the other to comply to their respective ways seems appealing to me. I'll be looking for another way - Shmget 19:08, 25 May 2007 (UTC)

Template for byte quantities

The current WP:MOSNUM, regarding binary prefix, recommend to "stay with established usage, and follow the lead of the first major contributor to the article." and also suggest that "The use of parentheses for binary prefixes "Example: 256 KB (KiB)". As WP:MOSNUM state , "There is currently no consensus as to whether common binary prefixes or the IEC-recommended prefixes should be used in Wikipedia articles.". That lead to chronic edit war and lengthy arguments. The acceptance of the IEC notation has been slow, both in the industry and in the public at large, and it is reasonable to think that is will still take significant time, years in not decades, before the usage is settled.

This proposal attempt to eliminate few of the most commons objections raised during the debates on this topic. These are, in no particular order

• Wikipedia is an encyclopedia and therefore exactitude and precise standard conformance are paramount
• Wikipedia is the reflect of the world as it is not as it 'should' be.
• Legacy hardware have all their reference materials written using usual notation therefore IEC notation are confusing
• Non-specialist user is confused when seeing S.I prefix used with a different value than their expected meaning

and of course, at the end of the day, a lot of the arguing is motivated by a very strong force : personal taste.

The following templates Template:KiB Template:MiB Template:GiB Template:TiB are proposed. They take 2 positional parameters. The first one is the size itself, a number. the second is an optional unit.

For example: If an editor has no preference he would defer to the template, which should reflect the then current consensus. In this current version of the tempalte version that would give: {{KiB|16}} -> 16 KB (KiB)

If an editor whish to use the traditional notation, he would use {{KiB|16|KB}} -> 16 KB

A benefit of the few extra characters is that it make apparent to any other editors that the editor knew that KB was a binary prefix in this context, and that he belive that it still should be represented as traditional notation.

But the main feature of these templates is that they are wirtten in such a way that a user can customized his environment in order to see these units in his favorite representation.. Indeed, thanks the good work of User:Mike Dillon, a small piece of javascript can be used by any user who want to see only his favorite notation.

for example:

var byteSuffixes = {
    "kib": "KiB",
    "mib": "MiB",
    "gib": "GiB",
    "tib": "TiB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only IEC unit displayed or

var byteSuffixes = {
    "kib": "KB",
    "mib": "MB",
    "gib": "GB",
    "tib": "TB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only traditional unit display.

Note that it will not impact the place where the unit HAS to be one way or the other for the article to make sens, like for instance in binary prefix, since only the text using the template will be impacted.

The proposal is as follows:

• That these templates be mentioned in WP:MOSNUM
• That on pages relating to legacy hardware/software, the main editors be encouraged to use them in order to indicate the consensus on the page and to clarify to other editor that the choice of unit is purposeful and not an oversight.
• That editors in general do not fight the usage of such templates, so long as their introduction do not change the normal appearance of the page (that is without any javascript helpers)
• That the existence of the technique based on javascript be mentioned so that users that have a strong opinion on the matter can satisfy their preferences.

The current form (the way it present the unit) of the Template is not necessarily part of this proposal. The only characteristic of the template that is part of the proposal is the use of the class attribute in order to make the javascript substitution technique works cleanly. -- Shmget 03:52, 26 May 2007 (UTC)

Call it curiosity

It occurs to me that some of these binary prefix arguements could just as easily be applied to entirely unrelated problems. For example, some americans say, "check", when they are referring to what I'd call a "cheque". Similarly, "checking account" instead of "chequing account", etc. etc.
Irrefutably, "cheque" and "chequing" are absolutely far less ambiguous of terms than "check" and "checking". The latter requires knowing the context before you can determine the meaning; the former does not.
So, just wondering, how many of you would support an absolute policy where "check" and "checking", when used in that context, could never be used in wikipedia? And that any changes to "cheque" or "chequing" had to be accepted?
For what it's worth, "cheque" is the only correct spelling, as far as I'm concerned, but I still wouldn't want a policy requiring its use. Bladestorm 18:09, 29 May 2007 (UTC)

This issue is dealt with quite adequately in Wikipedia:Manual of Style#National varieties of English and Wikipedia:Manual of Style#Disputes over style issues; in short, both American and British spelling are acceptable. This would be a much more reasonable course of action than to force the generally unknown newly invented prefixes, which would be not unlike forgoing American and British spellings both in order to require Finnegan's Wake spellings on Wikipedia. —Centrx→talk • 05:09, 30 May 2007 (UTC)

Different binary template

I've come up with a different method for a binary prefix template. Input is in exact bytes value, and parser functions output the quantity in binary (the "i" is optional), SI, and exact. The template isn't ready for production use at all since the decimal place needs to manually adjusted and the CSS classes aren't implemented to hide the other output. See User:Dispenser/Binary Units for a working example. —Dispenser 22:28, 20 June 2007 (UTC)

Should MOS use MB or Mbyte

The Wikipedia campaign to "encourage the use of the IEC prefixes".[5] is based on the assumption that the world will someday abide by the IEC 60027-2 / IEEE 1541 standard. A study of current reliable sources shows no significant movement to use these standards. Of the three defined styles for binary prefixes, the IEC prefixes are a distant third.

Some who are advocating for the IEC prefixes claim that accuracy is more important than "common usage." With their miniscule presence in reliable sources you need to totally ignore common usage to justify the IEC prefixes. Wikipedia should not be used as a soapbox the push these esoteric units on the readers.

A review of technical specifications and brochures of manufactures of computers, peripherals and components show universal use of KB, MB and GB to describe the capacity of disk storage and memory (RAM). The Western Digital Caviar SE16 has 500 GB of disk storage with a 16 MB cache (RAM buffer.) [6]

A review of the general and technical press shows that MB (megabyte) is the most popular followed by Mbyte. The MiB (mebibyte) usage is very rare. The Kbyte, Mbyte, Gbyte is the traditional IEEE style and is still the most popular in IEEE magazines and journals. The IEEE Computer Society still uses this style.[7] A few technical magazine publishers also use this style. [8] [9]

The IEEE Annals of the History of Computing deals with K as a kilobyte unit by referencing the first use to Kbyte. Here is a sample from a recent article. "Japanese memory chips first achieved a significant market share at the end of the LSI era, with the introduction of the 16K (16-Kbyte) DRAM generation."

The rest of the article just used K. "Still, it was not the 16K but rather the 64K generation that would determine world leadership in DRAM production."

Mollick, Ethan (July-Sept. 2006). "Establishing Moore's Law". Annals of the History of Computing, IEEE. 28 (3). IEEE Educational Activities Department: 62–75. {{cite journal}}: Check date values in: |date= (help)

Some of the IEC prefix advocates insisted on uniformity in all articles on Wikipedia. The truth is Wikipedia is not consistent and the American/British variant spelling is often given as an example. With binary units the choice is MB or Mbyte; the MiB spelling is used on an isolated remote island.

The IEC binary prefixes attempt to fix a minor problem that the world has learned to live with. Supporters of the IEC 60027-2 / IEEE 1541 standard hope that Wikipedia can be used to promote its acceptance. It is not the place of Wikipedia to "encourage the use of the IEC prefixes." Here is an example of another IEEE/IEC standard that did not achieve widespread usage. -- SWTPC6800 06:15, 27 May 2007 (UTC)

You'll have to forgive me, but I find it genuinely hilarious that you would begin this sort of monologue by admonishing others for using Wikipedia as a soapbox. Is there any particular point you are trying to get at? — Aluvus t/c 06:43, 27 May 2007 (UTC)

A talk page is an appropriate place to get on a soapbox to try to fix a problem. Forcing your uncommon views on Wikipedia main pages is prohibited by WP:SOAP. The point is that the IEC binary prefixes are rarely used in the real world. Wikipedia should not be used to fix this deficiency. -- SWTPC6800 16:19, 27 May 2007 (UTC)

Here is a proposal on a binary prefix style. A Wikipedia wordsmith can put it into correct form.

Wikipedia follows the common usage for binary units and does not have a preferred style. An article should use the units given in the reliable sources for the article. If multiple styles of units are in the sources, the article editors should select the predominate unit and use it consistently.

An article on the new DDR3 SDRAM may choose 512 MB or 4 GB while an article on the history of dynamic RAM may describe a memory as 4 K or 16 K. Readers could easily verify the facts in the reference sources cited. -- SWTPC6800 17:18, 27 May 2007 (UTC)

I don't believe that it is generally true that "Readers could easily verify the facts in the reference sources cited." If the source is printed material, the reader might not have easy access at all. If the source is another website, the site might have changed or moved or otherwise might not be accessible. Of course, footnotes might overcome much of this worry. Jɪmp 23:51, 27 May 2007 (UTC)

If the original sources (from around 1978) used 16K DRAM you could Google 16K DRAM and find the original documents or a similar one. If the Wikipedia style changes the units to 16 KiB, the Google search will turn up different set documents. (Mostly Wikipedia articles.) -- SWTPC6800 02:23, 28 May 2007 (UTC)

SWTPC6800's point about being consistent with the reliable sources relevant to a subject are very important. Wikipedia is an encyclopaedia and a reference work that is intended to be searchable. To be able to be found during the types of searches someone may do the articles must use the terms the user is expecting to use. What this means is that a user who has some old books about their 64 K or 64 KB computer will be doing searches using the terms used back in those days (64K or 64KB or KB or kilobyte etc) and the user would be expecting to find other articles. This argument is precisely why the article on American Football uses yards even though yards are not allowed under the metric standards. And yes this is a common usage argument but the common usage argument is stronger than any of the standards based arguments simply because elsewhere in the majority of Wikipedia the common usage argument is actually put into practice. For the avoidance of any doubt that is to say in the majority of articles in Wikipedia you do not see the encyclopaedia using minority seldom used terms (even if they have been invented by a "standards body") in preference to the commonly used terms. Again for the avoidance of doubt in the majority of Wikipedia articles you see common usage trump the use of terms that are seldom used. Those who support binary prefixes could try to argue that it is not "technically correct" but those arguments are entirely irrelevant since the majority of articles in Wikipedia show that not using binary prefixes is the right thing to do and is of a greater benefit to Wikipedia as a whole. Wikipedia articles are not about being "100% technically correct" because if that were the case those supporting binary prefixes must remove yards from the article on American Football or remove the furlong from Horse Racing, but they do not. The Wikipedia articles are about being accurate and relevant resources to the subjects they are related to and to be accurate and relevant resources the articles must use the terms found in the majority of reliable sources because it is those terms that are most likely to be used by users. The articles in Wikipedia therefore have to accurately reflect common usage. This same point, in different terms of course, was also mentioned by others in the Village Pump. Scroll down to the end of this section to see the Village Pump summary that supports this. Fnagaton 11:34, 28 May 2007 (UTC)

Using the example given by SWTPC6800 above I believe this text below reads slightly better. I propose this text below is added to the guideline:

• Wikipedia follows common usage for binary units and does not have a preferred style. An article should use the units found in reliable sources relevant to the article. If multiple styles of units are used by relevant reliable sources the article editors should select the predominate unit and use it consistently.

In addition to the above proposal I also propose this text from the current guideline is removed "When in doubt, the best guideline is the one laid out in our style guide on national varieties of English: stay with established usage, and follow the lead of the first major contributor to the article." I propose the removal of this text because if in the future the majority of reliable sources do happen to change then the article text can change.

Fnagaton 11:57, 28 May 2007 (UTC)

I think that Fnagaton's wording above could be the entire style entry for binary prefixes. We should remove the promotional language endorsing the IEC standards. It is not Wikipedia's mission to prop up failing standards. Remember, the IEC prefix adoption and usage is in third or forth place in the reliable, published sources. The Kbyte, Mbyte and Gbyte units are far more popular in existing and new documents than the KiB, MiB and GiB units. There is no column in the table for this popular binary unit. -- SWTPC6800 17:20, 28 May 2007 (UTC)

I second Fnagaton's proposal, and SWTPC6800's comment. -- Shmget 22:11, 28 May 2007 (UTC)

Third. --Marty Goldberg 23:07, 28 May 2007 (UTC)

If you read current IEEE magazines and journals you can see they do not enforce the IEC 60027-2 / IEEE 1541 standard on their content. (Very little MiB, lots of Mbyte.) Why should Wikipedia compel this peculiar style when the sponsor doesn't? -- SWTPC6800 05:08, 29 May 2007 (UTC)

WP != IEEE. Just an observation. We could change all astronomy articles to refer to AU and other such literally "out of this world" units, if we wanted to keep step with journals like Science, but part of our "job" here is to traslate geekspeak into language that everyday people can understand. In the months and months of this "what this this standards group says vs. what that standards group says" debate I think at least some sight has been lost of this. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:19, 29 May 2007 (UTC)

Gahhh... What a ridiculous nightmare. (Referring to the whole thing; people seem to be outdenting, so I'm just starting one-:-deep with a meta comment or two or twelve. I'd never seen MiB in my life until about maybe four years ago (and I'm a computer professional!), at which point I thought it was either a typo, or a foreignism (which, in a sense, it darned sure is). But "Mbyte"? Please. Yes, of course I've seen it before, but it looks ridiculous and is about as sensible as "the shop'ng center" or "my hous'" Or (an actually common, stupid example) "Jun. 2007". I don't care what standards body, with it collective head...<ahem> in the sand... is coming up with this stuff on their multi-martini lunches, but enough is enough. That's so barely close to not an actual abbreviation as to not even bother with.

This is a general-purpose, general-readership encyclopedia. It needs to use terms and symbols that non-engineers, and non-subscribers to $2500/yr standards documentation, will understand. "Everyone knows what '500–MB' means", basically. They don't really, in the deepesting sense and depending upon context, but that's what we are here for. If the difference between a MB as defined by some standards body to be divisible by 10, and a MB defined by others 1024K not 1000K, has no impact on an article, so what? When and where it does, explain it one way or another in the prose. Don't make our readers, many of whom may be poorly educated, technologically inexperienced, and/or non-native English speakers, have to try to contend with a (for some) obscure set of abbreviations, which are sometimes weren't even from English to begin with; the French have been setting ITU abbreviations for ages; unless you're French, WTF is "bis" supposed to mean?).

'bis' is latin for 'twice', 'again', used commonly in English as a prefix 'bi' (bipolar, bicarbonate,...) ... amusingly using latin contraction are not particularly a 'French' habit. English use 'i.e.' (id est - also latin, for 'that is') where French typically use 'c.-à-d.'. -- Shmget 19:25, 29 May 2007 (UTC)

Rather than argue about which designation is more proper, go with whatever symbolic representation people are seming to grasp, and treat it as symbolic, period, just like an ankh or whather. People can memorize things, but the averge WP reader is not going to actually learn the difference between "someone's idea of a 'megabyte', about which there's going to be a defintional fight", and the competiting idea. Nevermind subjecting them to third symbol, which looks more like a pretend-word written by a three-year-old.

I've been studiously avoiding taking a position on this for months (yes, I've been watchlisting that long; after my abortive overhaul attempt, on various matters of MOSNUM problems, in...Feb.? I think... I've just been reading, hoping this MB/MiB things would just sort itself out. Now its MB/MiB/MByte. What, are we on our way to the Battle of the Five Armies or something? Full circle: Everyone, even my 81-year-old grandmother (I'm not exaggerating at all) knows what "MB" means (linguistically; she has no idea what a megabyte really is; she thinks it means that the computer is very large and heavy); but she can at least read it aloud. As much as I really, really hate the fact that the hard drive instrustry has been abusing the ambiguity to bilk people of out money for years for disks quite considerably less capacitious than they were expecting, that is not Wikipedia's fight. I'm quite keen on a article when it has to differentiating between KB and KiB and noting that KB in many contexts is ambiguous, but, well, so what? We are (most of us) here to write articles. Prose, that explains things. We're good at that. Maybe through more efforts of ours, this whole KB/KiB thing will be far less confusing to the kids who are now entering junior high school/middle school/whatever it's called when you get out the little children's school in your part of the world. But lets not force Mbytes and MiBs on anyone in any context in which the distiction is not crucial. End long-coming rant. I sleep now.

Of the three defined styles for binary prefixes, the IEC prefixes are a distant third.

1. What? What defined styles? Where are you getting usage information?
2. We don't care about common usage, anyway, as we have said a million times. This is a general-purpose encyclopedia, and needs to use symbols that are useful and meaningful to everyone, not loose jargon. "People familiar with computer science will know what we mean in each context" is not good enough. — Omegatron 17:34, 29 May 2007 (UTC)

1. The style as defined in the majority of relevant reliable sources for an article.
2. The "We don't care..." is firstly trying to speak for others and secondly indicative of the lack of rigorous argument presented by those wanting to push binary prefixes onto Wikipedia. The useful and meaningful symbols are those presented in the majority of relevent reliable sources, unfortunately for you it's not binary prefixes. Fnagaton 10:54, 30 May 2007 (UTC)

Unfortunately for me?? What do I have to do with this? Are you trying to serve the reader or are you just trying to win an "us vs them" fight regardless of whether it makes the encyclopedia better? I don't use IEC prefixes in daily life, either; it's not important. I say "1 gig of memory" like everyone else. But we need to use prefixes consistently in an authoritative reference work, when the "original sources" mean completely different things in different contexts. Sticking to standards is the easiest, sanest, most logical way to do this. — Omegatron 12:18, 30 May 2007 (UTC)

You started the "us vs them" with the "We don't care..." putting yourself squarely in the frame, unless you now want to retract your statement? As for the "sticking to standards" argument, that's already been refuted numerous times by many people, see the WP:VP links I gave above for examples. The consensus is against your position. Fnagaton 12:28, 30 May 2007 (UTC)

That sounds like an argument not to use words that only computer science jargon aficionados know. Also, the manual of style has no compulsory power to force editors to use words that almost all of them never use. —Centrx→talk • 19:40, 29 May 2007 (UTC)

1. It's an argument not to use words that have different meanings from one computer science jargon aficionado to another.
2. Of course it doesnt. So why are you all fighting so hard to have this recommendation removed? — Omegatron 12:18, 30 May 2007 (UTC)

1. Your argument is irrelevent for the reasons already given in the large section above (the consensus and the actions demonstrated in Wikipedia as whole with the WP:VP). Fnagaton 12:28, 30 May 2007 (UTC)
2. Because it's WP:CREEP and open to incorrect interpretation as demonstrated by the actions of User:Sarenne. Fnagaton 12:28, 30 May 2007 (UTC)

I used the IEEE 100, "The Authoritative Dictionary of IEEE Standards Terms", for Mbyte and MB. I know that IEEE 1541 modified that it but the classic definitions are still widely used. The MiB is defined in IEC 60027-2.

Mbyte Megabyte. Indicates 2²⁰ bytes.

megabyte Either 1 000 000 bytes or 2²⁰ bytes.

Notes:

1. The user of these terms shall specify the applicable usage. If the usage is 2¹⁰ or 1024 bytes, or multiples there of, then note 2 below shall also be included with the definition.

2. As used in IEEE Std 610.10-1994, the terms kilobyte (kB) means 2¹⁰ or 1024 bytes, megabyte (MB) means 1024 kilobytes, and gigabyte (GB) means 1024 megabytes.

SWTPC6800 02:06, 30 May 2007 (UTC)

I don't want to force Kbyte on Wikipedia; I was just point out another common prefix. I know Wikipedia is not the IEEE nor is it the IEC.

The articles should have the style of the reference documents. This allows readers to search for additional information. The IEC binary prefix experiment that has been run on Wikipedia has polluted the encyclopedia. If an item was originally described as a 64K DRAM soft error the reader can search on those terms to find more original documents. A search for 64 KiB DRAM soft error turns up an entirely different set of documents. If someone strips the original prefixes from the Wikipedia articles the information is lost to most readers. -- SWTPC6800 03:26, 30 May 2007 (UTC)

Note: this is an example of the reader taking words and phrases from an article then doing a Google search. Switching from K to KiB dramatically changes the search results. There are no quotations involved. -- SWTPC6800 17:11, 30 May 2007 (UTC)

Why would anyone use IEC prefixes in this context? You're quoting an error message, no? — Omegatron 12:19, 30 May 2007 (UTC)

In the late 1970s when 16K and 64K DRAMs were in production (or design) it was discovered that alpha particles caused soft errors. One source of the alpha particles was the IC packages. The problem caused changes in package materials and chip designs. -- SWTPC6800 13:55, 30 May 2007 (UTC)

I think omegatron's question was, "why would anyone change '64K DRAM soft error' to '64KiB DRAM soft error'", when such an error message would presumably be treated as a quote. Bladestorm 15:09, 30 May 2007 (UTC)

It's not an error message as such, that is to say it's not really a message that has been quoted from somewhere, rather it is a problem. For example "Balding rubber tyre" or "mathematical error". Soft error Fnagaton 15:18, 30 May 2007 (UTC)

The text is not a quote of an error message; it is about a common design defect in early DRAM memory systems. When all occurrences of K or KB are changed to KiB to improve the accuracy of Wikipedia; the readers lose search access to the source documents. -- SWTPC6800 15:29, 30 May 2007 (UTC)

Fair enough. But, in that case, wouldn't it be treated similarly to a proper name? Don't get me wrong, I agree that it absolutely should remain, "64K DRAM soft error". It's just that this doesn't really seem to be the same issue. If I'm not mistaken (and I very well might be), the main issue here is whether units used in normal prose need to be changed; and, if so, to which notation. But isn't this really a separate issue entirely? And, for that matter, isn't it something that all parties involved can agree wouldn't be changed either way? Bladestorm 15:38, 30 May 2007 (UTC)

Talking about binary unit I think we have left out very real possibility. Drop the ICE prefix and use KB*, MB*, and GB* whenever a manufacture suddenly decide to use SI unit with link to their appropriate articles explaining why base-10 units are being used in a system with all base-2 units. Here is an example: The new Model A 100 GB* hybrid-hard drive has 16 MB DRAM Cache and 512 MB* of non-volatile flash memory. —Dispenser 16:36, June 1, 2007

A review of technical specifications and brochures of manufactures of computers, peripherals and components show universal use of KB, MB and GB to describe the capacity of disk storage and memory (RAM).

Do you even understand what this debate is about? Of course they all use KB, MB, or GB. Those are the only abbreviations that existed. The meaning of those abbreviations is the important point. "Common usage" has always been ambiguous. These units have different meanings and different abbreviations depending on what decade it is and what device, company, and software you're talking about. This is why we "don't care about it". The issue is whether we should encourage a consistent standard between articles to reduce confusion, which almost everyone agrees with.

The idea that we would use some contrived Wikipedia-specific abbreviation like MB* because the international standard is "too new" is ludicrous. — Omegatron 17:19, 1 June 2007 (UTC)

Your repeated use of the word "ambiguous" as some kind of mantra is the ridiculous thing here. The current units are not contrived and the preponderance of evidence is against your point of view. Not to mention consensus is also against your point of view. Fnagaton 18:50, 1 June 2007 (UTC)

I have a storage device of unknown type which is described as having 1 GB of storage. Now, please tell me precisely how many bytes it contains. You can't; it is ambiguous. Omegatron described "MB*" etc. as contrived. — Aluvus t/c 23:25, 1 June 2007 (UTC)

What is contrived is that example and the continued denial of consensus. Fnagaton 10:37, 2 June 2007 (UTC)

That example is a pretty straightforward demonstration of the ambiguity. It is not in any way contrived; I fear you are attempting to misrepresent things. A 1 GB hard drive and a "1 GB" stick of RAM are unlikely to contain the same amount of actual space. If you have a "1 GB' storage device of unknown type, it is ambiguous what that actually means unless you have further contextual information. I am not sure how "denial of consensus" can be "contrived", but I am impressed at how you managed to use that device to avoid acknowledging that you were incorrect. — Aluvus t/c 01:57, 3 June 2007 (UTC)

Can I play to? I have a ton of an unspecified substance, now please tell me precisely how many how many onces it contains.... and your point is ?

You have the following SQL DDL : "CREATE TABLESPACE .... MAXSIZE 4G...", how big can my tablespace be ? Should SGBDs break backward compatibility of every existing DDL to please the Marketing department of the harddrive manufacturers ? You must take a memory dump of a 4GB of RAM system, how big will be the dump file ? how big, at least, should be the partition you put it on, how about the disk... how many CD do you need to store it ? That is a fun game, but that is not the point. The point is that in real life there is no ambiguity at all, exept when dealing with the storage industry who can't seems to get any consistancy, floppies, CD in one unit, hard-drive DVD in another, and more recently they are trying to bring the mess into memory-chips based storage... The mess is their own doing, but for some reason they expect the rest of us to change our units to post-rationalized they punny marketing ploy -- Shmget 04:17, 3 June 2007 (UTC)

I'm confused. Why say "there is no ambiguity at all" while simultaneously providing several examples that demonstrate there in fact is an ambiguity? Your list is in fact a very good example of the wackiness that arises from that ambiguity. Whose fault it is does not matter; the reality right now is that "MB" might mean 1 of what, 3 different things? These multiple potential meanings are what make the term ambiguous when additional information is not available. — Aluvus t/c 04:57, 3 June 2007 (UTC)

Yes you are confused because nobody as far as I can see has said "there is no ambiguity at all" because what is being said is that what you see as amibguity is actually not that severe because the issues are well known and documented. Also what you see as ambiguity is also irrelevant since that is not the issue as already explained at great length previously (Read my post at 11:34, 28 May 2007 (UTC) above). By the way I have this device that is labeled as 256MiB and it contains 257433600 total physical raw bytes. This means, following your contrived example to its logical conclusion, that MiB is also ambiguous. Fnagaton 08:31, 3 June 2007 (UTC)

I quoted Shmget, who did in fact write "there is no ambiguity at all". I am amused you're still attempting to push the "contrived" angle; it's not accomplishing anything. As to whether the ambiguity of common usage is relevant, it's pretty obvious that other people do consider it relevant, and your previous "explanation" did not convince them otherwise. Perhaps you can provide a better one? — Aluvus t/c 09:54, 3 June 2007 (UTC)

No you are wrong because you made a partial quote and took it out of context which is dishonest. Your contrived example doesn't actually support your point especially so since you failed to refute what I wrote above. Actually, that is the last straw. Until you retract your statement and apologise to Shmget for misrepresenting what he wrote you're not going to get any more replies from me on this topic. Also do not attempt to reply to me in the future until you apologise and make amends for your actions. Fnagaton 11:51, 3 June 2007 (UTC)

Well, I suppose that was easier than actually demonstrating why the ambiguity being discussed is irrelevant. Sigh... — Aluvus t/c 01:34, 4 June 2007 (UTC)

The websites don’t include the asterisk for some reason like they do on the packaging so its completely ambiguous. Anyway the comment was meant as a half serious joke.—Dispenser 19:26, 1 June 2007 (UTC)

They must be relying on this other 'standard' : Caveat emptor... but if you read carefully and follow the links to the specs, you will end-up finding the fine print that explain that, in some part of their specs, a MB/GB is not really a MB/GB as you know it (presumably since it there is not explanation in the same spec, when they are used in the so-called 'binary' sens), but a special MB/GB, defined with a footnote, an hybrid between the megabyte of memory chips, file size and floppy disk's size and the megabel of the SI standard. -- Shmget 20:45, 1 June 2007 (UTC)

Using K, KB and kilobyte to mean either 1000 or 1024 based on context is not only common usages but is written into many standards. For decades the IEEE Std. 100, "The Authoritative Dictionary of IEEE Standards Terms", defined kilobyte as either 1000 bytes or 1024 bytes, depending on context. Semiconductor memory is normally connected to a binary address bus so the industry standards use kilobyte as 1024. Disk storage has no binary size constraint so disk specifications use a kilobyte as 1000.

Just because some standard's geeks came up with kibibyte to fix the "problem" doesn't mean the world will follow. The IEEE and IEC wanted the world to draw AND gates and other schematic symbols as square boxes in 1984 but the world did not follow. [10] The 1991 version of the standard incorporated the common usage symbols for small gates. This standard has very limited adoption after twenty years. -- SWTPC6800 14:32, 2 June 2007 (UTC)

Time to fix the wording

The previous binary prefix style (April version) clearly does not have a consensus. The current version is still disputed. Do we just remove the entire style?

Maybe it should be replaced with something simpler. Like this:

Wikipedia follows common usage for binary units and does not have a preferred style. An article should use the units found in reliable sources relevant to the article. If multiple styles of units are used by relevant reliable sources the article editors should select the predominate unit and use it consistently.

I know some will reject this and want a more prescriptive wording. Propose it. We should avoid the instruction creep of the old version.

The existing wording reads like an advertisement for IEC standards. The original vote was "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts." It is not Wikipedia's job to sell a standard. The outside world selects the winning standard or standards. We should remove the table that sells the IEC proposal. We can just point out the binary prefix page without the endorsement of any particular standard. -- SWTPC6800 01:11, 31 May 2007 (UTC)

It's not going to be a surprise that I like this wording. ;) I know the proposed wording is basically a mixture of existing guidelines such as WP:NPOV, WP:NOR, Disputes over style issues. It could be argued the binary prefix guideline could therefore be removed completely but to be honest I believe not having a binary prefix guideline will again lead to one person taking it upon themselves to change all prefixes against the wishes of the majority. So it's probably better to have a short binary prefix guideline. I also agree with SWTPC6800 about the "advertisements for IEC" because the existing wording is just too pushy. Fnagaton 09:53, 31 May 2007 (UTC)

The original vote was "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts."

But Wikipedia does not work by majority rule. The consensus wording decided from that poll was "The use of the new binary prefix standards are not required but are recommended". That one user abused this and was banned for it does not invalidate the consensus. If you think the wording encourages abuse, change the wording (as I've already done). But the use of consistent units has broad support and will continue to be recommended. — Omegatron 17:35, 1 June 2007 (UTC)

You say "Wikipedia does not work by majority rule" and then you cite a poll to support your argument? You say[11] that because it is the Manual of Style "you are not required to follow its recommendations" as justification for making the Manual of Style contradict actual practice and call anyone who disagrees with you "disrupting the project"? You seem to wilfully misunderstand the actual issue, that the recommendation of using binary prefixes is wrong, and to ignore the fact that as a recommendation the Manual of Style does have effective power in causing people to write in a certain way and to resolve disputes in conformance with it. Insofar as the Manual of Style being merely a "recommendation" is justification for your edits, the Manual of Style would be null, but it is not, and you must actually justify why the binary prefixes should be recommended. —Centrx→talk • 17:44, 1 June 2007 (UTC)

and the '2005' wording you wanted to introduce also claimed that "These standards are commonly followed, but are not yet ubiquitous.". This is still complete non-sens even today... so in 2005!!!. These standard are NOT even remotely 'commonly followed'. you can still count on your fingers the softwares that allow you the 'option' to display things using IEC notation. Not a single spec sheet of nay manufacturer use that notation, not the ships founders, not even the hard-drive manufacturers.... -- Shmget 17:46, 1 June 2007 (UTC)

In other words, they were not commonly followed in 2005 and they are not commonly followed in 2007, and neither case are they approaching ubiquity. Saying so then and saying so now is a falsity that promotes a particular point of view. —Centrx→talk • 17:57, 1 June 2007 (UTC)

Well I reverted for two reasons. 1) The text doesn't have broad consensus. 2) The text was added back by a known Tor exit node. I added a note about it here on Omegatron's talk page. Fnagaton 18:23, 1 June 2007 (UTC)

Also Omegatron you owe me an apology for trying to claim my revert was in any way an attempt at "disrupting the project". I'm not the one who made a change without proper consultation, you did. I'm not the one who is putting back edits by known Tor exit nodes, you are. There is a reason your point of view is meeting such a large amount of resistance. You seriously need to think about your actions. Fnagaton 18:26, 1 June 2007 (UTC)

More likely(?) the tor user was Sarenne. — jesup 04:15, 2 June 2007 (UTC)

He is saying that Omegatron reverted to a version of the page that the tor user reverted to, not that Omegatron was using tor. —Centrx→talk • 04:29, 2 June 2007 (UTC)

You say "Wikipedia does not work by majority rule" and then you cite a poll to support your argument?

Yep. As you'll recall, the poll results were:

• 20 support: "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts"
• 1 support: "The MoS should encourage the use of the IEC prefixes only in highly technical contexts"
• 6 support: "The MoS should discourage the use of IEC prefixes anywhere "
• 0 support: "Don't mention"
• 2 support: "No more votes"

So we reached a consensus wording that said SI standards for decimal and IEC standards for binary are "not required but are recommended". It was added on July 9, 2005, the wording tweaked a little, and everyone was relatively happy. Some articles used them, some articles did not.

Then Sarenne claimed it as justification to be disruptive and was (rightly) banned. But now a handful of people are responding by revert warring, disrupting articles, and trying to change the section to match their own personal viewpoints to the exclusion of all others.

Sorry, but that's not how it works. Do you think everyone who participated in the original discussion has suddenly changed their minds and support the removal of this recommendation? Why don't you ask them?

This is still complete non-sens even today... so in 2005!!!. These standard are NOT even remotely 'commonly followed'.

How many hard drives are produced each year with standardized SI prefixes? How many DVDs?

how many CD's, hom many memory chips, how many files in how many filesystem ? -- Shmget 06:49, 2 June 2007 (UTC)

How many web servers run the Linux kernel?

oh please!

Linux-2.6.19-gentoo-r5:$ wcgrep '[0-9du ][MG]B[ \n)]' | grep print | wc -l
Linux-2.6.19-gentoo-r5:$ 80
Linux-2.6.19-gentoo-r5:$ wcgrep '[0-9du ][MG]iB[ \n)]' | grep print | wc -l
Linux-2.6.19-gentoo-r5:$ 20

and out of these 80 messages, 3 were a false positive ( nothing to do with megabyte), and just one used MB in the 'hard-drive manufacturer sens: in /drivers/ide/ide-disk.c:971), the 76 other uses are MB as in 1024*1024 bytes. oh! and more than half the MiB/GiB print are in the MTD drivers. (guess why).

so much for commonly followed!!! Furthermore, try du -h, ls -lh or any coreutils function that produce 'human readable' unit and try to guess what these K/M/G means there... Yes, in coreutil was added fairly recently a --si option to alter the meaning of these unit, but still not IEC symbol here either way, and certainly no change to the existing behavior (no Coreutil will not break Posix compliance to please Sarenne :-) ). You would have better luck to mention the Gnome System Monitor who does indeed display IEC notation for memory, but

for file in `wcgrep -l "iB"` ; do sed -i -e "s/iB/B/" $file ; done

on the source tree, take care of that in a hurry. (there is 3 hit in src/util.c, the rest are all the translations of these 3 messages in all supported language)

BTW if you wonder how things are evolving:

Linux-2.6.15-gentoo-r1:$ wcgrep '[0-9du ][MG]B[ \n)]' | grep print | wc -l
Linux-2.6.15-gentoo-r1:$ 79
Linux-2.6.15-gentoo-r1:$ wcgrep '[0-9du ][MG]iB[ \n)]' | grep print | wc -l
Linux-2.6.15-gentoo-r1:$ 19

-- Shmget 06:49, 2 June 2007 (UTC)

What units do these use? How do you define "common usage", anyway? If you disagree with that sentence's use of "not yet ubiquitous", feel free to reword it, but revert warring the whole section to your own wording is not helpful or acceptable.

I'm not the one who made a change without proper consultation, you did.

You've completely rewritten a section to represent your own viewpoint without any kind of consensus on the talk page. Omegatron 00:55, 2 June 2007 (UTC)

You are wrong, the consensus is demonstrated by the more recent vote, you know the vote that came out overwhelmingly in favour of removing the version you prefer. The current version is the version that has consensus. The version you prefer does not have consensus. Fnagaton 10:52, 2 June 2007 (UTC)

I'm not the one who is putting back edits by known Tor exit nodes, you are.

Oh really? — Omegatron 00:55, 2 June 2007 (UTC)

Yes really, the proof is on your talk page. You still owe me an apology for your misrepresentation. Fnagaton 10:52, 2 June 2007 (UTC)

Perhaps instead of summarizing votes you should summarize the reasoning on each side. I actually don't see any hard drives that use the new prefixes; they are using the old prefixes in the same fashion they used prior to the existence of the new prefixes, specifically with the purpose of misleading customers. There is also almost non-existent usage on Google Books, Google Scholar, and industry magazines. So, where is the "common usage" (let alone the usage that would indicate progress towards ubiquity). Also, objection to this issue pre-dates Sarenne's edits, which only demonstrate the fact that people do and will use the manual of style as a guide for making edits. —Centrx→talk • 04:14, 2 June 2007 (UTC)

Omegatron has incorrectly cited an old vote when there is a much newer vote that proves consensus is the opposite of his point of view edit on the project page. His edit has now been reverted since it is obvious it does not have consensus. Fnagaton 11:52, 2 June 2007 (UTC)

What new vote? When did Wikipedia become a democracy? — Omegatron 15:21, 3 June 2007 (UTC)

He is saying that Omegatron reverted to a version of the page that the tor user reverted to, not that Omegatron was using tor.

Oh, I see. Yes, I did revert to a version of the page that the tor user reverted to. I did not use Tor myself.

how many CD's, hom many memory chips, how many files in how many filesystem ?

Those don't follow the standard, do they?

What a shocker. Standardized CD specification do not follow 'the' standard created more than a decade after ?

So, where is the "common usage"

What? The common usage is a mixture of two different styles. I don't think you can put any kind of meaningful numbers on how much of the common usage follows SI and how much does not,

Sure you can, and I just did earlier. In the Linux kernel there is ONE and just ONE message that use MB in the 'hard-drive manufacturer sens', and 76 occurence where MB is used in it's common 1024 KB sens. -- Shmget

but it's pretty obvious to anyone that both styles are part of "common usage".

Omegatron has incorrectly cited an old vote when there is a much newer vote that proves consensus is the opposite of his point of view edit on the project page.

How many times do I need to say that Wikipedia is not a democracy? Please please please read that page. Votes are irrelevant except to judge how many people support a particular viewpoint. Votes don't decide policies or guidelines. Votes (or polls, more precisely), are only used to gauge opinion and then form a consensus based on everyone's opinion, not on majority rule.

And where is this "newer vote", anyway? — Omegatron 17:22, 2 June 2007 (UTC)

You were the one who started by citing numerical votes. —Centrx→talk • 17:28, 2 June 2007 (UTC)

You didn't answer my question. Where is this newer vote? And when did Wikipedia become a democracy? Guidelines aren't decided by votes. They weren't in 2005, and they aren't now. Disrupting a guideline with incessant stubborn discussion, revert warring and personal attacks until everyone who disagrees with you ducks out or leaves the project is not consensus.

On the other hand, it is very easy to create the appearance of a changing consensus simply by asking again and hoping that a different and more sympathetic group of people will discuss the issue. This, however, is a poor example of changing consensus, and is antithetical to the way that Wikipedia works. Wikipedia's decisions are based not on the numerical fact of how many people showed up and voted a particular way. It is based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the previous consensus - not simply on the fact that today more people showed up supporting position A than position B.

A good sign that you have not demonstrated a change in consensus, so much as a change in the people showing up, is if few or none of the people involved in the previous discussion show up for the new one.

— Omegatron 15:21, 3 June 2007 (UTC)

Centrx did alreday answer the question and you already know what vote because you voted in it. Yet again you ask a question where you already know the answer. You are the editor who is revert warring and you are the editor making personal attacks when your edits have been reverted due to lack of consensus. The change in consensus has been demonstrated. The fact is you are repeatedly denying the truth of that change in consensus. Your repeated denial of the truth doesn't work. Fnagaton 17:18, 3 June 2007 (UTC)

Again you are missing the point entirely by throwing up irrelevant red herrings. Centrx is right with his earlier comment you do "wilfully misunderstand the actual issue", you are in effect playing the game of ignoring the facts. Fnagaton 17:29, 2 June 2007 (UTC)

"Ignoring the facts"? Of what? Please show everyone, below this comment, a list of the facts that I am ignoring, and why these facts are relevant to this discussion. — Omegatron 15:21, 3 June 2007 (UTC)

Ignoring the facts like: The consensus that is against your position and yet still making changes to the project page when there isn't consensus. Then edit warring to put your changes back. Then writing lies about the editors who revert your edits. Then asking questions where you already know the answers in an attempt to appeal to ignorance. Centrx and I are having to bring to your attention your behavior, that should cause you to stop and think. Your behavior is why I mentioned on your talk page that you should take a break from editing to consider your actions. Fnagaton 17:04, 3 June 2007 (UTC)

Omegatron has been involved with this binary prefix style from the beginning.[12] There may be some ownership issues at play here. He strongly believes that the IEC style is in the best interest of Wikipedia. It appears that many more editors think that matching reliable, published sources is more important. (I personally think that Omgatron is a valuable contributor to Wikipedia.) -- SWTPC6800 17:01, 3 June 2007 (UTC)

For starters, saying everyone who disagrees with you is trying to "disrupt the project" for "personal" reasons is inflammatory and plainly false. Saying that there is "broad consensus" for recommending IEC prefixes is also rather blind given the major disagreements with it here. There is also substantial unequivocal evidence that the IEC standards are not "commonly followed", whether in 2005 or 2007, and they have not been "widely adopted". The fact is: most published sources and most people in general do not use these prefixes at all. It is also strange of you to cite the numbers of a poll as though it is relevant and then, when a newer poll that contradicts your own position is mentioned, to say that polls are irrelevant. The poll to which Fnagaton is referring may be [13], in which all but two support wording that specifically does not "recommend that the SI and IEC standards be followed". —Centrx→talk • 17:18, 3 June 2007 (UTC)

SWTPC6800 was the one that brought up the 2005 poll in this instance. Omegatron attempted to place that poll in context and explain that the wording that was placed into the MOS was the result of discussion and consensus following the poll, not the numerical result of the poll. If I am not mistaken, Omegatron has reiterated that Wikipedia is not a democracy several times already (including in reference to the 2005 poll), only to be shouted down. It is unfortunate. — Aluvus t/c 01:47, 4 June 2007 (UTC)

Not accurate because Omegatron (and others) previously kept on referencing the old "consensus" (i.e. the old poll) when trying to shout down those who spoke out against using binary prefixes. The inconsistency is that Omegatron cites the old poll/vote when it suited his cause and then would try to claim other later polls/votes are not relevant (mostly by posting Wikipedia is not a democracy) when those polls/votes do not support his cause. It is illogical to do that and of course it is just balderdash to keep on trying to cite "Wikipedia is not a democracy" given his previous actions. Fnagaton 09:16, 4 June 2007 (UTC)

Fnagaton, this is where I assume your misunderstanding lies: “referencing the old "consensus" (i.e. the old poll)”. Omegatron was not referencing the poll as consensus, but the text that was written after that poll, taking its result into account. It is a huge difference between building a consensus and selecting one alternative (like some are trying to do currently). A compromise is sometimes similar to consensus, but not the same thing at all, by the way. Christoph Päper 14:33, 4 June 2007 (UTC)

No there is no misunderstanding from me, Omegatron and others have been referencing the vote/poll as "consensus", I say "consensus" because I read through the vote that Omegatron keeps on referencing and actually the results of that poll are inconclusive and don't show the consensus Omegatron seems to think it does. This is because many of the comments in the early poll have caveats that were not reflected in the resulting guideline text. This also means Omegatron isn't referencing the actual consensus, he is trying to push his own point of view and this has been demonstrated by his recent edits to the project page that got reverted. Fnagaton 14:53, 4 June 2007 (UTC)

Although I do disagree with Omegatron on some aspect of this particular issue, I must say that, for the ones I have seen on other topics, his edits are reasonable and measured. The particular feud on this article, may indeed be fueled by a long participation on this topic and a good faith impression about what the 'consensus' on this topic is or was.

I disagree that the strong wording in support of IEC was ever consensual. It is most likely that the MOS was not monitored very closely by most editor with expertise in the field, as illustrated by the reaction of many of them, when forced to look at the MoS due to the action of notorious activist. But one thing is clear: Neither in the real world nor in Wikipedia are the IEC notation anywhere close to be 'commonly' used or even accepted. I can imagine the XiB notation being eventually accepted, especially in documents that need to straddle two worlds, but I can't imagine, in my lifetime, being able to say 'tebibyte' or 'gibibyte' without feeling like an extra in a Buck Rogers episode. Time, and the real world will tell if that standardization effort will have more success than the one regarding the logic gates, in the interval, it should not be the role of Wikipedia, and even less of the MoS to 'lead the charge'. The mere fact that the MoS actually contain an explanation of what are binary prefix (the whole first paragraph, is a good indication, in itself, of the lack of acceptance of these notations. If an editor need that introduction to understand the situation, he probably is not ready to edit that kind of material. A reference to the appropriate article should be enough to get them started. I'd favor to drop the first paragraph and the infobox, and to wikify 'binary prefix' and the first mention to the IEC recommandation in the second paragraph (that would become the first). the last part listing the 'measure that use this or that' should also be in the appropriate topical page, not in the MoS. -- Shmget 22:45, 3 June 2007 (UTC)

I have a question and an observation. Q: the current wording has "IEC-recommended." Is it correct to say that the IEC encourages the use of these prefixes? Is there a distinction between defining the prefixes in a standards document versus encouraging their use? Observation: many of the links to IEC prefixes on Wikipedia are coming from PDFbot, which adds them when it adds the sizes of PDF files. I'm not sure if this is cause for concern (I mentioned it over on User talk:Dispenser#PDFbot binary prefixes, but I thought I should point it out. jhawkinson 03:17, 5 June 2007 (UTC)

Yes the IEC recommends you use kibibyte (KiB) but virtually no one in the computer industry or publishing industry uses it. Since 1984 the IEC has recommended that people draw AND and OR gates as square boxes, nobody does that either. A small group of IEC enthusiast here at Wikipedia is promoting this failing standard. The world is going to start using it any day now. Wikipedia just has to keep pushing it. -- SWTPC6800 03:50, 5 June 2007 (UTC)

Binary and SI prefixes (MS topic)

I sorry to bring up this flame topic again but I feel that it needs to be addressed. The Xbox 360 uses DVD-9s which hold 8.5×10⁹ (9.0×10⁹ or 7.92 GiB if not using EFMPlus) of data. The problem now here is is the Microsoft reserves a bit of space on the disc. This is quoted as 7 GB [14], but if you look at all the other information it becomes clear that MS is using binary units in all contexts (there was a better source that state the total disc capacity was 7.9 GB). Now the problem comes in stating this in the article. Obviously, stating it as

...Only 7 GiB out of the 8.5 GB is available to developers...

is unaccepted by the majority of editors as this is "correct" to GB. But the question is how to make it clear to the reader which unit we are referring to? Since we have two different usages out of the horses mouth. —Dispenser 00:50, 20 June 2007 (UTC)

How about using the terms found in the reliable sources relevant to the article and disambiguate using parentheses? It is worth noting that some of these games sites are not really reliable sources because for things like the exact measurements for storage values tend to be overinflated to score points against rival console vendors, are sometimes inaccurate marketing rubbish or vary depending on exactly what protection is used. The really reliable sources tend to be covered by NDA. Fnagaton 08:30, 20 June 2007 (UTC)

I don't understand the question, but there seem to be so many options. You could give the amount of space that is reserved (is that 942KB?), you could use consistent units ("only 7GB out of 7.9GB"), you could use a fraction or a percentage. It seems odd, btw, to use "only" if you're talking about a 12% difference; is it really significant?. jhawkinson 16:44, 20 June 2007 (UTC)

The PS3 fanboys like to tout that blu-ray holds more. So the 1 Gig or 1.5 Gigs wasted becomes important to them. So we should convert the units then? —Dispenser 22:08, 20 June 2007 (UTC)

Clarify standards used for binary prefixes

The use of KB (kilobyte) and MB (megabyte) for binary values is more than common usage, there is 50 years industry practice codified in ANSI/IEEE and other standards. Kilo (K) as 1024 and Mega (M) as 1,048,576 were defined over 20 years ago in ANSI/IEEE Std 1084-1986. KB, MB and GB (as binary prefixes) are defined in IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, 2000.

The computer industry sponsors standards organizations and adheres to published standards. In addition to traditional groups like the IEEE Standards Association and JEDEC there are many other ad hoc standards groups such as Universal Serial Bus [15], PC Card [16], and Serial ATA [17]. The industry has just ignored the IEC 60027/IEEE 1541 binary prefix standard. In 1984 the ANSI/IEEE Std 91-1984 and IEC 60617-12 standards recommended that everyone start drawing schematic symbols of AND gates as a square box with an ampersand in it. Changing something that the industry thinks is working is very difficult.

There is no obligation to use the IEC and ANSI/IEEE binary prefix standard. Every IEEE standard has these disclaimers. "Use of an IEEE Standard is wholly voluntary." "The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard." After the ASME vs Hydrolevel antitrust case [18] was upheld by the Supreme Court[19] standards organizations are abundantly cautious about imposing their standards.

I have been trying to measure the adoption of the IEC binary prefixes in the computer world. I looked at the IEC binary prefix use by news, technical and reference publications; manufactures of computer components, semiconductors, and computer systems; operating system and application software; retail sales of computers and software; and other standards organization. The only significant usage is in elite standards groups. I would have the say the adoption of the IEC binary prefixes is minuscule and static. See Talk:Binary_prefix#IEC_binary_prefix_adoption

An interesting point is that the flash memory card and hard disk drive manufactures use MB to mean 1,000,000 bytes as the IEC recommends. Both groups have been sued for misrepresenting the capacity of the products. The plaintiffs acknowledged the IEC standard exist but stated the computer industry ignores them. Companies that use MB as 2²⁰ have not had legal problems.

I propose that we add a new paragraph to the binary prefix section clarifying that the "common" binary prefixes are defined by ANSI and IEEE standards. This paragraph would go between the existing first and second paragraph.

Use of the prefixes kilo, mega, etc., and the symbols K, and M, etc to specify binary multiples is based on 50 years of industry practice and has been codified in ANSI/IEEE standards for 20 years. The predominate use of these prefixes by technical publications, computer hardware and software companies is reflected in IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, 2000.

-- SWTPC6800 23:43, 10 July 2007 (UTC)