Jump to content

Talk:Binary prefix/Archive 16

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10←Archive 14Archive 15Archive 16Archive 17Archive 18

Go live 2?

Handy link to >> sandbox <<

Ok, the split and rearrange of section 3 (now 3 and 4) suggested by Woodstone is done. It does not look exactly as Woodstone suggested because I discovered that somewhere along the way a comment end got lost, resulting in the "adoption by IEC and NIST" section head and a paragraph or two on either side being eaten. These are now restored, so there's some text there now that Woodstone might not have been expecting. Jeh (talk) 11:00, 22 February 2010 (UTC)

I've gotten rid of the beginning "terminology" section and set up a "notes" section called "Definitions" instead. Only the definitions that are unique to this article or require a special emphasis on a point remain; the rest are handled by wikilinks. Jeh (talk) 21:40, 23 February 2010 (UTC)
I agree with Jeh that the list of definitions has served its purpose for us and after having made the article consistent has become too heavy and even superfluous. I made a few small tweaks in the sandbox. I see no objections to going live with the current state (after executing the embedded remarks for its implementation). Further tweaking can be done on the real thing. −Woodstone (talk) 05:52, 1 March 2010 (UTC)
thanks! Jeh (talk) 19:17, 1 March 2010 (UTC)
Minor comments (these are not comments on the changes in the sandbox per se, but general ideas for improvement):
  • [Lead] The phrase "But hard drive manufacturers use…" in the paragraph starting with "The computer industry commonly uses" perpetuates the misleading claim that it's only hard drive manufacturers who use the SI prefixes in their SI sense, when in fact the computer industry itself uses the same prefixes, in units like "megabit per second" and "kilohertz". (The article is about prefixes, not just kilobytes etc.)
  • [Lead] "while new notations such as kilobyte". Perhaps "new terms" or "new units" would be better, since "notations" is not (commonly) a word.
  • I don't think starting with the history section is maximally useful to the readers. It is great that we have all this obscure information, and it certainly belongs in the article, and starting with the history section would even be the proper order in a scholarly work, but on Wikipedia, it will quickly put off anyone who tries to read beyond the introductory section.
  • Why was the "very nice table" (two sections above this one, on this talk page) removed from the article? It is quite informative and certainly belongs in the article. Similarly, I think it is wrong to put the table for the IEC prefixes so prominently next to the lead, since the article is not about just the new prefixes, but about the two (decimal and binary) usages.
Overall, the sections seem to have been rearranged into the "logically correct" order, sometimes perhaps rather than the order in which it would be convenient to read. Is this a good thing? :-) But I think it's ok to "stop polishing the cannonball" as you said. Shreevatsa (talk) 06:59, 1 March 2010 (UTC)
Shreevatsa, I've addressed your first, second, and fourth points. The table in the lede is now the template table that shows both binary and decimal prefixes. Re. the "very nice table," I have restored it but I believe the column group now labeled "conventional prefixes" is a problem. Perhaps that column group should be eliminated completely? Or, should the exact values of the corresponding SI prefixes be included in a new column?
fwiw, I removed the other two tables because I thought the info was repetitive... but it's obviously trivial to restore them.
Re. the sequencing, my view is that the history section motivates the sections that follow. If someone just wants the essentials, they're in the lede. If they want to skip the history and go right to the detailed discussion of IEC prefixes, that's what the ToC is for, no? It seems to me that putting a history section first is pretty common for WP articles. Jeh (talk) 19:17, 1 March 2010 (UTC)
The article looks great. You are right about the history section. At first I thought that not enough of the essentials were in the lede, but now I think it's fine. BTW: you have a done an amazing job on the article, and it is much better now than ever. Thank you very much! :-) Shreevatsa (talk) 20:38, 1 March 2010 (UTC)
Thanks. Given that praise I feel I should stress that about 90% of the actual writing, and 99% of the references, were already there; most of my work was in rearranging the text and in rationalizing the terminology. Jeh (talk) 22:10, 1 March 2010 (UTC)
Ok... with great trepidation, I did the requisite C&P and pressed "save page." Thanks for all the input, everyone! Jeh (talk) 02:20, 2 March 2010 (UTC)

Miscellaneous to-do list

  • The reference at the end of the first paragraph of the Binary prefixes#IEC standard prefixes section is weak as it merely consists of IUPAC noting IEC's proposal, but it is apparently the only thing we have. Would be better to have a ref for the actual proposal. (The link here is not really correct until the sandbox goes live.) Jeh (talk) 21:48, 26 February 2010 (UTC)
  • Great that it's moved. :-) One more todo: I think the changes introduced some inaccuracies w.r.t. uppercase and lowercase 'k'. The SI prefixes use k, M, G, etc., but (some!) computer usage had a convention of using K for 1024 and k for 1000 (this used to be in the article, it's worth a mention). The new prefixes are Ki, Mi, Gi, etc., all uppercase. When writing out the units, though, it's always lowercase: 1 megabyte, 1 mebibyte. It will take a little care to fix this without changing any historical usages, however they may have been spelt. Shreevatsa (talk) 02:31, 2 March 2010 (UTC)
    • Ah yes. Ok, I tried one placement of that. It could also go earlier right after "thus the first binary prefix was born". re. rectifying the rest of the article for that usage, yeah... but I'm kind of worn out on this article for now, someone else needs to do some work. Jeh (talk) 04:15, 2 March 2010 (UTC)

Other Prefixes?

Does anyone know if there are equivalents for the other prefixes? Are there plans to make them? Frankjohnson123 (talk) 20:07, 16 July 2010 (UTC)

Which other prefixes? Shreevatsa (talk) 20:21, 16 July 2010 (UTC)

Reason for lack of adoption

Universally, the reason that technology workers (and the marketing apparatus that aims products at them) is reluctant to use the binary prefixes is because they sound ridiculous. This might or might not be a "good" reason, but the reality is that if you sound like you are affecting a fake stutter every time you rattle off specs people will not take you seriously. Sure, if a critical mass of people adopted it then it would stop sounding silly, but until then there is a long, long climb.

An enormous amount of this article is spent bemoaning the lack of adoption, and except for a snippet regarding Knuth the greater issue is not addressed; this makes the article seem very out of touch. It's not like there is some sort of mystery regarding the reason people don't use these terms; anyone who has ever said them out loud has noted the problem. —Preceding unsigned comment added by 64.22.160.1 (talk) 18:03, 7 April 2011 (UTC)

"An enormous amount of this article is spent bemoaning the lack of adoption" - really? I see one sentence in the lede, a few sentences under "other standards bodies," and a couple of sentences under the "Current practices" section, noting their lack of adoption or use. This is in an article of about 77 (decimal)kB (in ASCII). That does not seem to me to be excessive.
By the way, those points (few though they are) are made because when this version of the article was being worked on, a couple of editors were concerned that it should not give the impression that the IEC prefixes were enjoying any more adoption than they actually were. To do so would violate WP:UNDUE. You can read the whole history in the talk archives if you like. That still seems to me to be a valid reason to retain the statements that are here.
On the other hand, if there is anything here indicating that a WP editor (as opposed to someone being quoted or cited from a reliable source) is "bemoaning" anything (rather than acting as a dispassionate reporter), please point it out. Or better yet, change it yourself. Such would quite clearly be a non-neutral point of view. I'm really not seeing it, but maybe I'm too close. Jeh (talk) 23:17, 7 April 2011 (UTC)
As for what "anyone who has ever said them out loud" knows, that claim is of course considered WP:OR by WP's rules. If you can find additional reliable sources citing that point, then by all means, go ahead and quote or paraphrase them (with citations). But WP articles are not supposed to contain content sourced only by "what everyone knows" (annoying though that is at times). Jeh (talk) 23:19, 7 April 2011 (UTC)
I agree with what "64.22.160.1" was saying about "bemoaning" so I've removed the parts of the lede that are not directly supported by the ref tags. See the talk section "Removing a part" below for a more complete list of reasons why. Basically as you say Jeh it would be WP:UNDUE and WP:OR to include claims that are not supported by reliable sources.Glider87 (talk) 10:17, 8 April 2011 (UTC)

Removing a part

I had to remove the claims about Linux and MacOS using IEC prefixes because the cited ref did not support the claims. For example it stretches the truth to try to claim the GParted is either "Linux" or "MacOS". It isn't of course, it is only a small part of the distribution. When running Ubuntu it displays file sizes using KB/MB with powers of two. So I don't think the ref can be taken seriously as meaning "Linux" or "MacOS" as such. The cite itself is a self published link and not suitable for a reliable source. It is WP:OR to try to claim a self published link can be used to mean "Linux" and "MacOS". If some really reliable sources for the claims that the whole or majority of Linux and MacOS use IEC prefixes can be produced then similar claims can be put back. I also think it is WP:UNDUE to try to claim one ref to a single tool means anything more than "GParted uses IEC prefixes in some distributions". It certainly doesn't support the claims as they were written. Glider87 (talk) 09:40, 8 April 2011 (UTC)

Agreeing with the IP in the talk section above I think there needed to be some balance brought back to this article, especially the lede where some claims had grown beyond the refs supplied. Glider87 (talk) 10:20, 8 April 2011 (UTC)

I agree with your edit but not that you corrected any "bemoaning." To "bemoan" means "to express discontent or sorrow over some specific circumstance." I see no expressions of any degree of unhappiness with the lack of IEC adoption as the IP stated; only citation of the fact. I suppose someone who is an irrationally vehement IEC opponent could read any mention of the lack of IEC adoption as "sorrowful", but the words aren't here to support that interpretation.
What you did remove were unsupported claims of IEC usage and I just can't see how such claims could be construed as "bemoaning," or even neutrally describing, the lack of IEC adoption.
Still, I agree with your edit re usage in the EU (the ref doesn't really support the claim) and re MacOS X: MacOS did not change to using IEC for file and disk sizes. What they did was to change from using traditional binary prefixes (that is, KB, MB, etc., used in the binary sense) to SI prefixes (KB, MB, etc., used in the decimal sense). Someone else will have to consider the gparted/Linux point. Jeh (talk) 10:46, 8 April 2011 (UTC)
My use of "bemoaning" was because when reading the article as it was I could see how "64.22.160.1" could use the word "bemoaning", especially in the lede. I mean I took the use of "bemoaning" from "64.22.160.1" to mean that the editor thought the lede was a bit unbalanced. So I tried to correct the balance a bit. However I'm not going to try to second guess the precise definition of bemoaning "64.22.160.1" had in mind, I will just agree with the general sense of what I thought the editor meant and that I could also see some unsupported claims. If "64.22.160.1" comes back again I would welcome comments from the editor about the updated lede. :) Glider87 (talk) 10:59, 8 April 2011 (UTC)

Lede cleanup

Minutia like specific standards orgs and operating system examples don't belong in the lede. I moved that stuff into the appropriate sections; see the edit comments. Jeh (talk) 05:30, 9 April 2011 (UTC)

EU has required IEC since 2007?

I'm very concerned about this claim. Both refs offered are dead links. There was a third ref, that link is dead too, it was supporting the claim "will become an EU standard" and is obsoleted by the claim of actual adoption, so I deleted it completely. I can find no other reference that supports the claim that the EU requires the use of IEC prefixes. I've personally been in computer megastores in a few different EU countries recently; I specifically looked for IEC usages on e.g. system boxes and advertising, but found only the ubiquitous "GO" (giga-octets). As such we have no way to verify that the offered refs support the claim. Yes, there are frequent references to various IEC standards in other EU docs, but I've found no examples of EU standards citing ISO/IEC IEC 80000-13:2008. Jeh (talk) 05:30, 9 April 2011 (UTC)

Websites and Government agencies

There is a list in the article (Binary prefix#Websites and Government agencies) that needs an introduction. What is this list illustrating? And what qualifies the items for inclusion? Is it organizations that use the new prefixes? Is it organizations that have strongly condemned the new prefixes? Is it organizations that plan to convert gradually. Without visiting the references, the section is quite puzzling. Indefatigable (talk) 15:13, 20 April 2011 (UTC)

Rational for Binary Prefixes

There is really no reason for this difference besides it just being convention to use powers of 2 in computing. The computer itself does not account for the number of bytes on the disk as being in powers of 2, but someone a long time ago decided to count items on a computer disk in this manner. As such, the use of "powers of 2" in defining prefixes is only a convention for labeling the number of bytes a file contains. Altering this convention to agree with English could have been done at any time; however, for some reason it just stuck this way for a lot of the computing industry (including Apple).
Topher Kessler
August 28, 2009

Snow Leopard changes how file and drive sizes are calculated

Anyone care to opine as to how this material from a reliable source should be worked into the article? I suggest with some wordsmithing it should appear in the introduction. Perhaps something as simple as:

The computer itself does not account for the number of bytes as being in powers of 1024, but someone in the 1980s decided to report memory, file and HDD size in this manner. As such, the use of powers of 1024 as a prefixe is only a convention. Altering this convention to agree with English could have been done at any time as Apple did in 2009; however, for some reason it just stuck this way for much of the computer industry.

Tom94022 (talk) 23:43, 3 June 2011 (UTC)

In my view, this vague speculation about the reason for powers-of-2 based prefixes is not worthy of mention in the article. My experience is that in the 1980s, for personal computers, the application programs such as word processors could not load part of a file into memory, and swap various parts of the document to and from disk as required. Thus, the file size had to be compared to the amount of free RAM on the computer to decide if the file could be worked on or not. Since RAM is usually built with a capacity that is a power of 2 in order to take full advantage of the address lines on the RAM chip, it is natural to do RAM calculations based on powers-of-2, and that convention was extended to files, and sometimes disk space in general.
An additional reason is that a full sector of disk space is read or written in any interaction between the processor and the disk. Since the RAM buffers that store the data to be written or read are power of 2 for the same hardware reasons already mentioned, that is an additional motivation to think of disk capacity in powers-of-2. I don't have time to locate a source that would confirm my experience. Jc3s5h (talk) 16:36, 4 June 2011 (UTC)
I am glad you admit you have no reliable source for your recalled experience; I doubt if you will find one. Your description of how memory allocation worked is simplistic at best because the calculations within the computer were done in binary with out any prefixes at all other than blocking which could be different in the file and in memory and AFAIK never used any variant of blocks of 210n bytes, n>0. So an accurate description of memory allocation actually supports the statement that binary prefixes are "only a convention". The issue is not whether file and or memory allocation algorithms used powers-of-2, they were all binary - the issue is did they use powers-of-1024, they didn't! The most common file physical block size of course is 512 and the default cluster sizes for Windows range from 4 KiB to 64 KiB - note the absence of 1 KiB as a common block size. Whether algorithms calculate in blocks or bytes they must then be translated into a user understandable convention, KiB or KB, its all a convention and an inconvenient one in the case of binary prefixes. Tom94022 (talk) 17:36, 4 June 2011 (UTC)
The table you linked http://support.microsoft.com/kb/140365 doesn't use KiB, it specifically uses KB an since such use is still in the majority of material you should as well when writing about what it says. Glider87 (talk) 13:17, 9 July 2011 (UTC)

SI prohibiting binary usage revert

As regards the revert of the statement that SI prohibits binary usage of the SI prefixes... While it's not exactly BIPM, NIST's version of the rules ("Guide for the Use of the International System of Units (SI)") includes the following in the description of the prefixes: "Note: Alternative definitions of the SI prefixes and their symbols are not permitted. For example, it is unacceptable to use kilo (k) to represent 210 = 1024, mega (M) to represent 220 = 1 048 576, or giga (G) to represent 230 = 1 073 741 824." Page 19, section 4.5, table 5 of: http://physics.nist.gov/cuu/pdf/sp811.pdf Rwessel (talk) 18:37, 19 June 2011 (UTC)

The BIPM version of the brochure says, on page 121, in the note on the right side of the page, that "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits)." A suitable statement can certainly be included in the article, but should be phrased so as not to overemphasize the strength of the so-called prohibition. Also, the entity that is prohibiting/discouraging/whatever binary meanings should be specifically cited.
A problem with the NIST brochure is that when it was written, it did not have the force of law, and so is a mixture of definite statements and advice. Later it was recognized by the US Secretary of Commerce as the official interpretation of SI in the US, but since it is a mixture of definitive statements and advice, it is hard to tell to what extent it could be enforced against a company engaged in commerce which defied it.Jc3s5h (talk) 19:28, 19 June 2011 (UTC)
Since Microsoft, a US company, still use KB to mean 1024 bytes and the litigious nature of the US system and that they have not been prosecuted then it looks like there isn't "a force of law" behind those kinds of statements. Glider87 (talk) 13:20, 9 July 2011 (UTC)
So if you are not caught, according to Glider, you haven't broken the regulation. I think Glider misses the point since the requirement is on the government not the individual company. Microsoft can do what it wants but it might be in trouble none the less. The interesting language apparently from The Omnibus Trade and Competitiveness Act of August 1988 [Public Law (PL) 100-418] is:

each Federal agency, by a date certain and to the extent economically feasible by the end of fiscal year 1992, use the metric system of measurement in its procurements, grants, and other business-related activities, except to the extent that such use is impractical or is likely to cause significant inefficiencies or loss of markets for United States firms . . .

This makes me wonder why Apple since OSX hasn't attempted to disqualify Windows PC suppliers from bidding for US Govt laptop contacts on the basis of the biders flagrant and continuous violation of the public law thru the use of Windows. There are probably no civil or criminal penalties, but loss of business might hurt. Hmmmm, if I have a few moments maybe I will send a note of this subject to Apple's VP of laptop marketing with copies to similar folks at Dell, HP and Microsoft. Or maybe someone from Apple is watching this dialog. Tom94022 (talk) 22:59, 10 July 2011 (UTC)
I see little evidence that law is enforced, but if it were, it says "metric system of measurement", not "SI". One can also argue that specifying the number of bits a device can store is counting, not measurement. Jc3s5h (talk) 00:17, 11 July 2011 (UTC)
Anyone who has time to check the usage in modern university level textbooks? My impression is that kbit means 1000 bit in many books (at least in my country), while KiB still is not very common. Mange01 (talk) 10:02, 4 August 2011 (UTC)

Time for a voting?

At universities we teach students that 1 kbyte=1000 byte and 1 kibibyte = 1024 byte since several years back. See any newly printed textbook. Linux and OS-X now use the same terminology, just as Swedish Wikipedia. But enwp is still quite conservative in this matter. Why is that? I tried to replace kbyte by kibibyte/KiB or redefine kbyte as 1000 byte in several articles a couple of years ago, but my changes were reverted.

How many years will we have to wait for enwp to follow established standard in newly printed literature? I think it is time to forbid the old kbyte definition and thus avoid all confusion. Perhaps the time for acceptance is here now, after the Linux and OS-X transition on the matter? Would it be realistic that such a suggestion would win a voting? At which Wikipedia page should such a voting take place? Mange01 (talk) 20:30, 4 June 2011 (UTC)

The place for this discussion is really MOSNUM. I think the restrictions should be relaxed so unambiguous terms can be used in articles such as the various disk storage articles to avoid confusion, but not in general, since we want to avoid abominations such as a Pentium with 2 GiBytes of main memory. Good luck, the IEC Binary Editing Police will not like your suggestion. Tom94022 (talk) 21:23, 4 June 2011 (UTC)
While it's good to know that the binary prefixes are being used in schools, until that migrates to the real world (where usage still approximates zero), I think avoidance in general is going to be the rule. Rwessel (talk) 04:20, 5 June 2011 (UTC)

Can u give us some citations to recent text books that use IEC Binary Prefixes? FWIW, I did a search at Amazon books and found no hits. Tom94022 (talk) 21:33, 5 June 2011 (UTC)

The problem is that computing has used both binary and decimal units from very early on in the history of computing. That is the reality. Usage of unambiguous terminology is then a matter of education. How popular the binary prefixes are amongst the general populace is not the issue. The issue is education about the distinction between binary and decimal prefixes and the fact that there is a nomenclature to make that distinction. Wikipedia should not be blamed for making the distinction, nor should the distinction be edited out. --Jargonautica (talk) 05:31, 1 August 2011 (UTC)
Wikipedia doesn't report the world how someone wants it to be. Wikipedia reports the world how it is right now. The point is the world has not widely adopted the IEC prefixes in current literature so Wikipedia doesn't use them either. Glider87 (talk) 23:15, 2 August 2011 (UTC)
Using something is not the same as reporting about it. Palpalpalpal (talk) 19:49, 30 August 2011 (UTC)
No, it isn't. And there is not a restriction against reporting on IEC prefixes, nor even on reporting on the usage of IEC prefixes. Indeed, this very article reports on all of the usages its various contributors have been able to find. There is also not a restriction on using IEC prefixes in an article that is about IEC prefixes, or in any other article as long as most of the sources for that article use IEC prefixes. (see WP:COMPUNITS) I am glad to hear that the unambiguous IEC prefixes are enjoying increased use in Sweden, but as far as English-language sources are concerned, they are, so far, rare... and those are the sources used for English WP articles. So, in answer to Mange01's question: How many years will we have to wait for en wp to commonly use IEC prefixes? Until use of IEC prefixes is common in the literature used by en wp as sources, that's how long. Jeh (talk) 21:30, 30 August 2011 (UTC)

Yet another definition of K

As anyone noticed the TV definition of K where 4K appears to mean about 4,000? Could we be heading into another semantic war as TV's grow to 8K and beyond?  :-) Tom94022 (talk) 17:47, 28 January 2012 (UTC)

It's not really a unit, more a class name. Rwessel (talk) 06:52, 29 January 2012 (UTC)
Agreed, but isn't that what today's conventional binary prefixes were back in the days when 4K RAM was large :-)? Tom94022 (talk) 00:11, 30 January 2012 (UTC)
Not so much. In the 4K era, it would usually have been called "4000" or "4096" characters or words. A decade later, when the "K" usage became popular, it clearly was a abbreviation of an actual measure - IOW, you could buy a machine with 32K, and then expand it in 16K increments to 256K, and you'd usually specify the actual size as "80K". While 4K TVs are an emerging standard (although I'm not sure how relevant they'll be for most of the world in the next decade), and 8K appears to be at least getting some discussion, there's not going to be a whole to of growth in those numbers, without a significant change in what "TV" is. For monitors, there's more push for higher resolution (especially in some applications, like medical imaging), but there the current approach (size plus resolution) seems to work well enough. Another relevant example might be cameras – the “8MP” camera has roughly 8 million pixels, nobody expects an exact count, except in the specs (although to an extent, that attitude got the disk drive makers in trouble). Basically I don't think it's worrying about right now. Rwessel (talk) 06:03, 31 January 2012 (UTC)

Funny Sounding

Perhaps the article should mention that there is an informal trend to pronounce and expand Ki Mi Gi Ti Pi Ei Zi Yi as kili megi gigi teri peti exi zetti yotti. This can be verified by a web search on the first few expansions. It may be that people who see the symbols in the context of information capacity in bytes, e.g. KiB MiB GiB, but have not seen or heard the words kibibyte, mebibyte etc, simply assume these pronunciations, i.e. kilibyte, megibyte, gigibyte (with the last "i" pronounced as the vowel in the word "bee", or as the last "i" in "milli"). It may be that others, like myself, first learning of the "funny sounding" pronunciations, try to come up with something better, and settle on these as the obvious solution. These pronunciations avoid the problem of sounding as though you have a speech impediment, or sounding like Johnny English after he accidentally injects himself with muscle relaxant, "kibibyte flibble". D.keenan (talk) 00:01, 7 February 2012 (UTC)

I suspect the web search is mostly indicative of spelling errors. I don't think there's any such "informal trend", given that there is very little trend toward adopting the IEC prefixes in any pronunciation. WP must follow reliable sources (and a count of web hits does not count). If you can find some for this claim, no problem; otherwise, problem. Jeh (talk) 01:05, 7 February 2012 (UTC)

You can eliminate most cases of spelling error by searching on, for example, "kilo mega kili megi" (without the quotes), and not allowing the search engine to "correct" the spelling. Then randomly read some of them to verify that they are what I say they are. Whether it's a "trend" or not is beside the point. I contend that it has already reached notable levels of usage relative to the level of usage of kibi mebi etc. D.keenan (talk) 04:57, 7 February 2012 (UTC)

Sure, if someone disagrees with you, assume they don't know how to use a search engine. Search counts still aren't a RS, and what you read into a random selection of the hits certainly is not. Jeh (talk) 07:23, 7 February 2012 (UTC)
While I personally think they are funny sounding I think to be notable to Wikipedia standards some reliable sources would need to be found that comment on how "they are funny sounding" in the particular way described above. A search engine result isn't a reliable source, if you need this explained why then please ask on my talk page and I'll be happy to help. If you, D.keenan, can find articles in notable publications then please post them here for discussion or be bold and go ahead with some changes.Glider87 (talk) 09:35, 7 February 2012 (UTC)
We already have the "Dissent" section, which notes (with a ref) that none other than Donald Knuth called the actual IEC prefixes "funny sounding." However I find nothing, let alone anything from a WP:RS, that comments on a trend toward misspellings like "kili" and "megi", certainly nothing that claims that such misspellings arose from people thinking the official IEC prefixes were "funny sounding." To me it just looks like a bunch of copied misspellings--not exactly an unknown phenomenon on the net. Jeh (talk) 18:07, 7 February 2012 (UTC)
By the way, D. Keenan: the hit counts I'm getting appear to be specious. I searched exactly as you suggested. Here is one of the links on the first page of results. But I can't find "kili" or "megi" anywhere on that page. kibi and mebi, yes. Jeh (talk) 18:20, 7 February 2012 (UTC)
Jeh, I agree the hit counts are nonsense. "Megibit" does appear on the page you link above, but it is clearly a typo. This post to the Conlang (constructed languages) forum, also from the first page of the Google search, shows someone proposing "kili" and "megi" precisely because he thinks "kibi" and "mebi" are "silly". Several other forum posts consistently use "kili", "megi" and "gigi" with no use of "kibi", "mebi" or "gibi" in a way that suggests they have never seen or heard the latter, and have simply assumed the former based on the symbols alone (Ki, Mi, Gi). Or as you say, they may all have copied these from the first person to make this "mistake". I note that the Ubuntu policy, referenced in the main article, completely avoids any full-spelling of the prefixes. D.keenan (talk) 14:03, 8 February 2012 (UTC)
So is it not enough that this usage is there for anyone to see? Must it first be commented on by a WP:RS before it can be mentioned in an article, even in the "Dissent" section? D.keenan (talk) 14:03, 8 February 2012 (UTC)
Yes. Please read WP:V and WP:RS. This is Wikipedia, not the Urban Dictionary. Jeh (talk) 15:21, 8 February 2012 (UTC)

US-centric

There are a couple of places in the current document where sweeping statements are made that may be generally true in the US but not universally so. In particular, as noted elsewhere in the document, computer products for sale in the EC are generally required to use the binary prefixes (there are a couple of exceptions, for instance manufacturers can use SI prefixes as long as they state on the packaging and in instruction manuals how many bytes the term 'MB', etc, represents).

62.255.172.253 (talk) 17:49, 29 February 2012 (UTC)

They may be "required" but I've yet to see it. I've traveled quite a bit in many EC countries. As a lifelong techie I tend to visit electronics stores, and I've yet to see a binary prefix used on anything. And as someone interested in the topic, I think I'd have noticed them. (See for example saturn.com What is more interesting about this is that the IEC specifies abbreviations like "GiB" but in France, for example, and perhaps other places, they not only don't use "Gi", they don't use the "B" either; they use "o", for "octets." (See http://www.darty.com/nav/achat/informatique/ordinateur_bureau-bureau/index.html ) It seems to me that these EC regs are followed about as often as the IEC recommendations are here. In any case, if you have particular edits in mind feel free to make them and cite your sources, but I think a neutral presentation will have to point out that the IEC prefixes aren't used in practice much in the EC. Jeh (talk) 19:32, 29 February 2012 (UTC)

vebi? meci?

user:JordanKyser22 has added entries for vebi and meci to Binary prefix#Specific units of IEC 60027-2 A.2 and ISO/IEC 80000. These are for 2**90 and 2**100, and reference corresponding decimal prefixes veca and meca. I'm not aware of these as SI (or IEC) prefixes, although I can't see the latest standards revisions. I'm intending to just revert this, unless someone can actually point to a source. And if these are real, the table at the top needs to be updated as well. Rwessel (talk) 01:39, 23 March 2012 (UTC)

Non Standard Prefixes? (Prefii?)

Apparently "brontobyte" and "geopbyte" are used, probably unofficially (not IEC), for 1,000 yottabytes and 1,000 brontobytes, respectively (see Gluster [1] for an example, "Whats A Byte" [2] for definition). It seems to me that wikipedia should mention these prefixes (prefii?) and any others that may exist (within reason, of course). I don't have a wikipedia account (but maybe I should set one up) but wanted to suggest this casually.

Larry Ploetz, lploetz@gmail.com, larry@stanford.edu, larry@tairgroup.org (I would appreciate any feedback or information about updates on this page WRT bronto- and geop- prefixes, and to know if anyone gets this message at all) 171.66.69.231 (talk · contribs) 18:39, 25 May 2012 (UTC)

I see no evidence that these are serious. Numerous additional prefixes have been made up, and unless they become an SI or IEC standard, or actually become significantly used, they're not notable. Rwessel (talk) 19:12, 25 May 2012 (UTC)
Agree with Rwessel. This is Wikipedia, not the Urban Dictionary. Btw, sections don't get their own references list. Also btw, in the future, please sign your talk page contributions by putting ~~~~ at the end. Thank you. Jeh (talk) 19:28, 25 May 2012 (UTC)

Problem references on textbook and scientific research papers

The lead section ends with this statement on KiB/MiB adoption:

"However, as of 2011 adoption of the new terms has been slow and usage has been limited in the marketplace and in the press,[2] with notable exceptions such as Linux operating systems, several textbooks[3] and scientific research papers.[4]"

References 3 and 4 are Google searches. (Using Swedish language Google!) Google searches are not a reliable source. See Wikipedia:Search engine test. This has also been covered on the Reliable Source Noticeboard . These claims need a third party source that has evaluated the publications. Google search is a primary source, a book that states that KiB/MiB are the dumbest idea ever will show up in this list. -- SWTPC6800 (talk) 23:22, 25 June 2012 (UTC)

Better references would be good (in particular, using the english language google), but the google searches are useful - while not useful to show wide coverage, they are useful in showing the inverse, sparse use. It a case of having to prove a negative, there can be no reliable way of showing something isn't being talked about. Tarl.Neustaedter (talk) 02:52, 25 July 2012 (UTC)

Aside

I really wish we didn't have to use these stupid words. What's wrong with something like 20kB2

preceding added 10:09, 19 February 2013 by‎ 92.234.100.82, attribution by rwessel
First off, the subscript 2 would really need to go on the "k" and not the "B". In either case, you've not saved yourself anything in the written form (quite the contrary, the subscript 2 is likely to be harder to enter than a lowercase "i"). And how would you pronounce it, and how would that actually be better than "kibi"? In any event, you don't have to use them, almost nobody does. Rwessel (talk) 10:55, 19 February 2013 (UTC)

justification for "undiscussed, unexplained, unjustified change"

The purpose of an encyclopaedia article is to provide the reader with encyclopaedic information about the subject of the article. Wikipedia is an encyclopaedia. Therefore a Wikipedia article should provide its reader with such information, or suggestions on where else to find such information. Advice to editors is not encyclopaedic information and therefore does not belong in the article. Dondervogel 2 (talk) 22:24, 28 July 2013 (UTC)

Wikipedia also provides information for editors. Particularly in a case like this, where it's a fairly obscure construct, it's worth pointing to an associated Wikipedia policy for editors who may be trying to figure out an odd usage. I'd suggest it belongs at the top of the article, not in the talk page. Tarl.Neustaedter (talk) 22:35, 28 July 2013 (UTC)
Actually, IMO "mv advice to talk page" was sufficient justification and explanation for moving editorial advice to the talk page. There is nothing more odd or obscure about Binary Prefixes than any other technical subject so I see no need for this pointer, particularly in the article itself. Since it is now being discussed (and justified and explained in more detail) in I am going to remove the advice from the article while we discuss whether it is appropriate or not. Tom94022 (talk) 22:51, 28 July 2013 (UTC)
We should avoid advice as being unencyclopedic, but we should definitely have a "for Wikipedia policy on..." link at the top. --Guy Macon (talk) 23:06, 28 July 2013 (UTC)
Replying to Dondervogel: Granted that such a thing would never appear in a print encyclopedia, but this is not a print encyclopedia. It is not just the difference in medium. The salient difference is that the line between readers and editors is nowhere near as distinct here as it is in a print encyclopedia. Indeed, any reader can become an editor at literally the click of a mouse. And it is not as if anyone is arguing for the inclusion here of the complete text of WP:COMPUNITS. This is but a single-sentence hatnote providing a pointer to related information for editors, it is hardly obtrusive to the general reader, and it may be of help to editors. In fact, I've seen a few cases where new-ish editors changed other articles to use IEC binary prefixes, citing this article in their edit summary. That has diminished since the hatnote was added. (It still happens, but IMO, not as much.)
Nor does the hatnote belong on the talk page, since by a strict interpretation of WP:TALKPAGE, an article talk page is for discussion about improving the article. Guidelines about use of IEC binary prefixes elsewhere on WP are not relevant to improving this article, so why would anyone look here for them? (Actually, I'm not all that rigorous about these things. Now that I think about it, I see no reason why the hatnote shouldn't be on both the article and here on the talk page.)
To Tom94022: I am reverting your change to the article, so as to restore the hatnote. Per WP:BRD, my first reversion (which was the "R" in BRD) is properly being followed by discussion. This hatnote has been on the article for a long time; it should stay until there is consensus to remove it. Jeh (talk) 23:09, 28 July 2013 (UTC)
Two big reasons why Jeh was right to restore the hatnote: First, both Wikipedia's search and Google search usually return the article even if you are searching for the Wikipedia guideline. Try typing "Dispute resolution" into the search box at the top of this page. Second, hatnotes to guidelines or policies are found on hundreds and hundred of pages (Dispute resolution, for example), and thus the decision to not use hatnotes this way needs to be done at the encyclopedia level, not on the individual article level. --Guy Macon (talk) 03:46, 29 July 2013 (UTC)
WP:MOSNUM is (rightly) full of advice about when or how certain units should or should not be used. Should all articles describing such units contain such a non-ecylopaedic self-reference? Seems like a slippery slope. Dondervogel 2 (talk) 06:46, 29 July 2013 (UTC)
This is indeed a slippery slope. More than 99% of the readers are not editors. The articles should remain strictly encyclopedic. They should not be muddled with WP internals. −Woodstone (talk) 07:06, 29 July 2013 (UTC)
Here are some examples I tried:
* Deletion has a hatnote pointing to Wikipedia:Deletion policy.
* Manual of style (redirect to Style guide) has a hatnote pointing to Wikipedia:Manual of Style.
* Dates (redirect to Date) has a hatnote pointing to Wikipedia:Manual of Style/Dates and numbers.
* Formatting (redirect to Format) has a hatnote pointing to Wikipedia:Manual of Style.
* (mentioned above) Dispute resolution has a hatnote pointing to Wikipedia:Dispute resolution.
* Administrator has a hatnote pointing to Wikipedia:Administrators.
and so on. There are probably hundreds of these, as Guy Macon said. (Actually, Special:WhatLinksHere/Template:Selfref shows a few.) Now it may be your point all of these are non-encyclopaedic self-reference, and articles should not be thus "muddled with WP internals", but if so, then this is a project-wide thing to discuss; it's not specific to this article. Shreevatsa (talk) 09:17, 29 July 2013 (UTC)
Exactly. And, by the way, I think that project-wide discussion should happen, because "X% of the users are not editors" isn't a bad argument. I am not completely convinced, but the argument has merit. It just doesn't belong here, and certainly nobody should be editing articles as if we as a community had somehow agreed and decided that the hatnotes should go. --Guy Macon (talk) 09:36, 29 July 2013 (UTC)
It seems to me that it makes sense to consider two separate questions:
  1. Should non-encyclopaedic material appear on Wikipedia generally?
  2. Should non-encyclopaedic material appear on Binary prefix?
I agree that question #1 is outside the scope of this talk page, but unless there is a Wikipedia requirement to include non-encyclopaedic material (I am not aware of one) the second question is clearly within scope. In my opinion the presence of non-encyclopaedic material on other articles is not a reason for including such material here, and therefore the answer to #2 (again, my opinion) is an emphatic "no". Dondervogel 2 (talk) 16:49, 31 July 2013 (UTC)
In this particular case, the hatnote is useful. The distinction between GB and GiB is not widely understood, and pointing editors to a policy statement of how to use them is productive. Tarl.Neustaedter (talk) 17:05, 31 July 2013 (UTC)
By the same reasoning, the articles on hyphen/dash/minus should contain a link to WP's style guide (now only one of them does), just to name some of hundreds of candidates. In my view this would lead to a lot of clutter for the vast majority of readers. Where would be the right place to discuss this in general? −Woodstone (talk) 17:31, 31 July 2013 (UTC)
Village Pump? Dondervogel 2 (talk) 17:41, 31 July 2013 (UTC)
As a general comment, there's stuff on every WP page that is of no interest to the 99% of WP users who are not editors. Perhaps most notably the "Edit" button. Also a number of the items in the nav bar on the left. In any event, the hat not is not particularly obtrusive, and there's ample other similar usage. I see no compelling reason to remove it, and I think that these link *do* help editors, especially when looking for more obscure stuff - how exactly would someone find their way to WP:COMPUNITS, for example? Several obvious(?) searchers didn't get me there. Perhaps it would be nice to be able to move such links under "Tools" in the nav bar. Rwessel (talk) 18:01, 1 August 2013 (UTC)

In Wikipedia:Manual of Style/Self-references to avoid I found:

"Mentioning that the article is being read on Wikipedia, or to Wikipedia policy or technicalities of using Wikipedia should be avoided where possible."

Is this not enough to remove the item discussed? −Woodstone (talk) 17:46, 31 July 2013 (UTC)

Your worry about hyphen/dash/minus is an example of the Slippery slope fallacy.
No, the guideline you cite is not enough, not with the ample precedent of exceptions. Note that the top of that page says "Use common sense in applying it; it will have occasional exceptions. This is reinforced by the phrase you quoted: "where possible." This is clearly a guideline, not policy, and even policy can be ignored in special cases (see WP:IAR, which is itself a policy). The usage here is no more a problem than the very widely used "seealso" template. Jeh (talk) 18:07, 31 July 2013 (UTC)
I'm a little puzzled by the intensity of this discussion. It seems to me that the policy of separating WP: space from main article space is appropriate. All the counterexamples listed above seem to relate to article names that could be interpreted to be WP policy by someone who happens to be searching in the wrong namespace (though why we should support such a confusion is beyond me) or are are disambiguation pages (where greater flexibility might be reasonable) – mostly both. To suggest that an article that decribes something that could be to (from the reader's perspective) referred to in a WP policy (in this instance binary prefixes) should be a candidate is stretching the already-stretched blurring of the boundary somewhat further: there are no comparable examples. I support Dondervogel 2 and Woodstone on this. — Quondum 18:33, 31 July 2013 (UTC)
There was an enormous amount of controversy about the use of binary prefixes on Wikipedia, and the painfully won consensus is documented at WP:MOS. So yes, it is quite likely than someone might come here to find out about Wikipedia's policy. Also even readers who come here without such an interest might be tempted to edit Wikipedia articles to add the new prefixes, and pointing them to the relevant MOS section will save everyones time and aggravation. I think the hatnote is in the best interest of the project.--agr (talk) 20:28, 31 July 2013 (UTC)
No-one is challenging the consensus. The rest of your argument is unfortunately supposition. — Quondum 03:40, 1 August 2013 (UTC)
The Wikipedia guideline is to avoid this kind of self-reference "where possible". It is clearly possible to do so here, so I see no need further discussion. Dondervogel 2 (talk) 12:06, 1 August 2013 (UTC)
Did you miss the part where "avoid where possible" is itself just a guideline? Do you understand the difference between guidelines and policy? I think your summarily declaring the discussion closed and removing the subject selfref is grossly heavy-handed. There is obviously no consensus here to support your edit. Jeh (talk) 16:48, 1 August 2013 (UTC)
I'm also somewhat puzzled by the intensity of the discussion. The use of hatnotes is well established for cases where a reader might legitimately be looking for something else. Someone looking in Wikipedia for binary prefixes stands a good chance of being an editor looking for guidance on how to use them. Wikipedia isn't a refuge of puritan rules-at-all-costs content, it's a collection of pointers to useful information. Why the urgency to remove the hatnote? Tarl.Neustaedter (talk) 17:54, 1 August 2013 (UTC)
There is little call for the hatnote to be removed or added until consensus is reached, but the behaviour in removing and re-adding it is taking on the character of a faction-based edit war. There is clearly no consensus here, so I'd suggest that this talk page is evidently not the place to resolve it: it should be resolved on the MOS talk page or even an RfC. Pre-emptive behaviour on the part of editors when consensus has not been reached is liable to antagonize; the existing reverts are probably enough for a warning under WP:3RR considering that it is clear that there is no consensus and discussion is under way. — Quondum 18:36, 1 August 2013 (UTC)

For all the reasons stated above and in addition WP:undue I support removing the hatnote. Since this is a binary decision it is highly unlikely that consensus will ever arrive, right now by my count there are 6 editors in favor of removal (me, DV2, Macon, Woodstone, Quondom, Khrose) and 4 against (Jeh, TN, Rwessel, agr). In the spirit of compromise may I suggest we remove the hatnote and add a link to the style guide into "Further reading" or a new "See also". Tom94022 (talk) 01:18, 2 August 2013 (UTC)

Why would a "seealso" be preferable? The Wikipedia policy pointer isn't additional information on the subject, it's a redirect for editors who might have found the wrong page.
I'll further comment; I, like many other Wikipedia editors, am a long-time computer professional. The subject of SI prefixes on bytes is a long-standing controversy, and policies on it vary from organization to organization. I first ran into it as an emotional controversy while sitting on the Infiniband committees in the '90s (when IEEE insisted we stop using MB to represent 2^20 bytes), and have repeatedly run into different policies from different organizations. My current employer has the policy of mis-using the SI prefixes (TB=2^40 Bytes), because it's what marketing uses, and marketing is more right than engineering standards.
The point of this is that for any endeavour, you need to find the policy for that specific organization to figure out what the symbols mean and how to use them. Wikipedia is no different and searching for that policy is likely to lead one to this page. This page has no policies (nor should it). Tarl.Neustaedter (talk) 01:45, 2 August 2013 (UTC)
I have stated before that your premise ("searching for that [WP] policy is likely to lead one to this page") is supposition. Do you have any way of showing that this is the case? Ignoring, for now, whether the argument has merit given this premise. — Quondum 02:50, 2 August 2013 (UTC)
As a quick example, searching for "kibi" would get you here, but nowhere near WP:COMPUNITS. Rwessel (talk) 02:53, 2 August 2013 (UTC)
While I don't want to counts votes too closely, particularly in the absence of unambiguous statements of position, I don't think you can count Guy Macon and Shreevatsa (who you didn't count at all), in the remove category, although they both appear to suggest that they might support a project-wide removal. As I mentioned, I think I could support placing that sort of link in a less prominent section, although I'd have to argue that should be done consistently on a project-wide basis (and thus impact the fair number of other paging using the same sort of hatnote). Rwessel (talk) 02:53, 2 August 2013 (UTC)
Consensus on WP is not arrived at by counting "votes." See WP:CONSENSUS. Anyway, I thought we were headed toward starting a project-wide discussion. That seems to have been lost in the shuffle. Jeh (talk) 03:54, 2 August 2013 (UTC)
Here I find myself agreeing with Jeh. I have posted a note on the MOS page that Woodstone found. Dondervogel 2 (talk) 05:15, 2 August 2013 (UTC)
I thought it would better be placed on the WP:SELFREF guideline page. In particular I think the guideline needs some better wording than "where possible," and I think it needs to clarify whether hatnotes are covered by the guideline. To me this case seems little different than "for ...see" hatnotes within article space. It does not seem at all concerned with "unencyclopedic" text. Rather, its main concern—the justification for the guideline's existence—is that WP pages should still be usable if they are exported and made available in some other form (such as a printed page, or a web site that does not have all of WP available to link to). It does note that the {{selfref}} template is an acceptable way to denote such references so that they can be automatically removed during the export process... Is there any objection to my starting a parallel discussion on these points at WP:SELFREF's talk page? Jeh (talk) 08:17, 2 August 2013 (UTC)
I think it's best to avoid 2 parallel discussions, but feel free to move my post from MOS to SELFREF if you think the latter is a better forum. Dondervogel 2 (talk) 12:14, 2 August 2013 (UTC)
I've already replied where it is. I'll leave it there and post a pointer at selfref. Jeh (talk) 23:03, 2 August 2013 (UTC)
Oh duh me. It IS at the selfref page. I was thinking the discussion was at MOSNUM. Go on about your business, nothing to see here. Jeh (talk) 23:07, 2 August 2013 (UTC)
Minor clarification: Re: "Guy Macon ... appears to suggest that [he] might support a project-wide removal", I would only support that if there was a clear consensus to do so. I would also support changing Wikipedia to pig-latin if there was a clear consensus to do so. While arriving at that consensus, you can count me as strongly opposed to removing the hatnote (from this page or from all pages) and to the pig-latin idea.
The hatnote should stay (see WP:TALKDONTREVERT and WP:BRD), there being no clear consensus for removing it, and those who want it gone should create an RfC on the appropriate policy page. And everybody on both sides needs to stop edit warring now. See WP:EW. --Guy Macon (talk) 04:18, 4 August 2013 (UTC)
Please also include me (a long-term but lazy page watcher) as one of those opposed to any change without an RfC that demonstrates a clear need to remove the hatnote. Johnuniq (talk) 05:58, 4 August 2013 (UTC)

I just did a careful read of WP:SELFREF. The sort of self references it talks about are not what we are discussing. The primary concern is insuring that third parties can use Wikipedia articles. In particular, it has a section on tools for self referencing which suggests using Template:Selfref. If you click on that link you will see instructions for using that template including, as an example, EXACTLY the type of cross reference that is in this article's disputed hatnote. I would suggest we change the hatnote to selfref and end this discussion here.--agr (talk) 15:59, 4 August 2013 (UTC)

Strongly support the above suggestion, and you get an "Attaboy" for that nice bit of research. --Guy Macon (talk) 17:26, 4 August 2013 (UTC)
The hatnote on this article already uses the selfref template, and did before this discussion started. Jeh (talk) 19:11, 4 August 2013 (UTC)

revert by Jeh with comment line that is unconnected with the revert itself

Jeh accompanies a revert of this edit "The IEC suggests that the binary prefixes be adopted in fields of science outside information technology [1]" with the explanation "that's not what WP:NOTABLE means". What is not notable about the IEC encouraging use of its prefixes outside the field of IT? I do not see the connection. Dondervogel 2 (talk) 12:46, 21 October 2013 (UTC)

Sorry, I used the wrong term. The relevant policies are WP:FRINGE and WP:UNDUE. "Kibihertz" is most definitely on the fringe. In fact, usage of IEC binary prefixes with bytes and bits is so uncommon that even that is arguably in "fringe" territory; many WP editors have in the past argued that this article already gives WP:UNDUE weight to the IEC binary prefixes. This puts the usage of "kibihertz" at the level of a few tiny fibers that came out of the fringe after a brisk combing. As for the IEC, they have not made a recommendation for the use of kiibihertz. Anders Thor did write "Of course, the new prefixes may also be useful outside the field of information technology" in an offhand remark while describing revision 2 to IEC 60027-2, but that language does not appear in IEC 60027-2 itself. So, no, I don't think it warrants mention. If it must be mentioned then I will insist on wording to the effect that it's not actually part of IEC 60027-2 recommendation and that actual usage is also exceedingly rare. Jeh (talk) 17:47, 21 October 2013 (UTC)
I hate to say this, but changing kilo to kibi is beginning to resemble a cult much like the existing "change Linux to GNU/Linux everywhere" cult, the "change to UK English everywhere" cult, the "change to USA English everywhere" cult, and the "fix redirects that are not broken cult. In all four cases, if someone makes the change in one place they are very likely to have made the same change in many other places --Guy Macon (talk) 19:22 21 October 2013 (UTC)
I'd disagree on kibibytes (and MiB, GiB, ...) being fringe; it has been specified by numerous standards bodies as the appropriate terminology for a common measurement, as a fix for an increasingly problematic ambiguity. But *nobody* has identified any of the binary prefixes as being appropriate for anything *except* counting bytes. KibiHertz is indeed fringe. Tarl.Neustaedter (talk) 20:17, 21 October 2013 (UTC)
@Jeh: Yes, I agree kibihertz is very rare, and if that is considered fringe, fair enough. But the reverted edit was related, as you rightly observe, to the suggestion that the binary prefixes are not reserved exclusively for bits and bytes. You might consider the remark "offhand" but that is an opinion that Thor is unlikely to have shared himself. Did he not even make the statement in a published letter?
@Tarlneustaedter: Nobody except Anders Thor.
Dondervogel 2 (talk) 20:37, 21 October 2013 (UTC)
We're talking about the last sentence of a short note, the primary purpose of which was to briefly describe Amendment 2 and the IEC binary prefixes defined therein. So in the context of the note, yes, it looks like an offhand remark to me, particularly as IEC 60027-2 does not contain any such wording. Re. "nobody except Anders Thor", it would appear that for all practical purposes the remark has been ignored for fourteen years... so I agree with that assessment. Jeh (talk) 01:06, 22 October 2013 (UTC)
There is no reason for IEC 60027-3 (or its successor ISO 80000-13) to mention other uses because those standards are exclusively about the terminology of information technology. Frequency scales are a natural alternative stomping ground for binary prefixes because of the predominance of the octave resulting in the progression (1 Hz, 2 Hz, 4 Hz ... 1024 Hz). They even offer precisely the same potential for clearing up the confusion that exists between decimal and binary versions of third octaves. I am not suggesting the article should include that last point because it would be considered OR, but pointing out that a prominent figure like Anders Thor encouraged other uses and that other uses (in the form of the kibihertz, at least in patent applications) do exist, seems to me to be of sufficient interest to warrant inclusion in the article. But if others prefer to impoverish it I will not fight that. Dondervogel 2 (talk) 06:34, 22 October 2013 (UTC)

Prefix "prepended"

This page has my MB and Kb all excited. How are these prefixes? They never precede the quantity they identify. Exempli gratia "GiB 120." At least in English it's 120 GB.

AFAIK, and I'm sure the standards organisations have found, scientifically, the reason this doesn't work, but capitals denote bytes to miniscules' bits. 1MiB = 1MB, 1Mb = 1000b.

And what's "prepended?" I looked this up, NEVER having heard of it before, and I read it's some slang that appears to mean prefixed or the like. It's getting to be like the urban dictionary here with all the "i" in data suffixes and made up words like "portmanteau" and "prepended." Come back to the real world.

75.170.21.249 (talk) 06:49, 16 November 2013 (UTC)

The prefixes k, M, Ki, and Mi are attached before (prepended to) the units b (bit) or B (byte). Makes sense, doesn't it? −Woodstone (talk) 07:11, 16 November 2013 (UTC)
And just to emphasis that this is not some invention with the binary prefixes, these are called "prefixes" in standard SI. See International_System_of_Units#Prefixes and Metric prefix. Of course those are decimal prefixes, but no one ever calls them that (except when contrasting them to the binary prefixes). Rwessel (talk) 07:49, 16 November 2013 (UTC)
"Prepend" is standard English, per Oxford Dictionaries Online. Your not having heard of a word before doesn't mean it's slang. And "portmanteau" is actually an old word, less used today, same source. Jeh (talk) 09:46, 16 November 2013 (UTC)

Removal of vital article status

I have no objection to that. I just wonder - why was it listed under Science - subsection Physics? Jeh (talk) 03:31, 20 February 2014 (UTC)

FWIW, it was actually under Physical sciences / Measurement / Units of measurement / Quantity / Data, along with bit, byte and baud. Certainly I could see an argument that those be moved to somewhere in Technology / Computing and Information technology, although it's not all all clear cut. Rwessel (talk) 05:42, 20 February 2014 (UTC)
Oh. I was just going by the template: {{Vital article|level=4|topic=Science|class=B|subpage=Physics}} Jeh (talk) 05:47, 20 February 2014 (UTC)

Exactly what was wrong with "customary binary prefixes"?

This term solved a problem. It was not arrived at by whim. There was considerable discussion on this point, resulting in clear consensus. as part of the rewrite that a number of us collaborated on in early 2010. In its place we now have the less informative phrase "computing binary prefix", sometimes "computing binary interpretation", sometimes "computing industry's binary interpretation". All because Kbrose declared "do not invent another term" (not inventing anything, we were simply qualifying an existing term, and more important, using the resulting phrase consistently) and then Dondervogel2 declared "there's nothing customary" about them. Of course there is, they've been in use for decades; if using SI-derived prefixes with binary interpretation is not "the custom" in e.g. the RAM industry, what else would you call it?

In any event, I object to the recent edits in this area. "Customary binary prefix" had a clear consensus from a number of editors, from both sides of the "WP should/should not use IEC prefixes" argument. And it's been standing that way for four years. It should not be overturned simply by a few edits. Jeh (talk) 04:10, 18 March 2014 (UTC)

Dondervogel2 continues to edit in this area before reaching consensus here. "JEDEC binary prefix" is not a suitable term to replace "customary binary prefix" as their usage long predates JEDEC's official notice of them. Jeh (talk) 14:01, 18 March 2014 (UTC)
Think of my edit as a bold proposal. The reason why I think "customary prefix" is not a good term is because it is the decimal prefixes that are customary, not the binary ones. In all instances to date (kB, MB, GB, TB), the decimal interpretation was used before the binary interpretation, and the trend continues today because hard disk drives usually have a larger capacity than random access memory. Dondervogel 2 (talk) 17:44, 18 March 2014 (UTC)
They were customary within the computer business for a couple of decades. We're trying to change that, and meeting the same resistance we get from changing any other custom or tradition, Would you prefer "traditional"? Tarl.Neustaedter (talk) 17:52, 18 March 2014 (UTC)
I have reinstated "customary binary" where previously used. In all cases I think "customary binary" can be replaced with "binary". For example "customary binary interpretation [of MB, GB ...]" would become "binary interpretation [of MB, GB ...]". Any objection? Dondervogel 2 (talk) 18:50, 18 March 2014 (UTC)
I would agree that the term "customary prefixes" would be problematic, but the usage we're talking about using "customary binary prefixes". Rwessel (talk) 19:13, 18 March 2014 (UTC)
Ddv2: I think you're missing the point of just why we stuck "customary" on the beginning of "binary prefixes" in the first place. If you'll review the previous discussion (linked above) you'll see that we needed a way to succinctly refer, collectively, to "prefixes borrowed from SI but used as binary prefixes". That phrase is fine to use once; I do not want to read it every time such prefixes need to be referred to. We already had "SI prefixes" and "IEC prefixes"; We needed a similarly succinct term. The term "binary prefix" is not specific enough, as it could refer to either an IEC prefix or "prefix borrowed from SI but used as binary prefixes". The alternate phraseology you (Ddv2) are proposing does not address how to refer to such prefixes as a group; and indeed, "KB, MB, GB" are not (just) prefixes anyway. I do not think that adding the term "interpretation" is helpful either. When "KB" is used to refer to 1024 bytes, the "K" is, like it or not, a binary prefix, just as much a binary prefix as Ki would be in that context, and I think it is helpful to the reader if that point is made. We felt that the term should furthermore imply that such usages were common (which they certainly are) and widely accepted by many in the industry (ditto). "Customary" seemed to be the best fit. The objection that "it's the decimal interpretation that's customary" is overridden by the use of the word "binary" in the phrase "customary binary prefix". Jeh (talk) 21:58, 18 March 2014 (UTC)
Tarl.N: We previously rejected the word "traditional" as it can have either a pejorative or complimentary connotation, depending on the reader. Although I personally don't like the "customary binary prefixes" it is not this article's place to express judgments. "Customary" was the most neutral term we could come up with. And nobody has had a problem with it for four years. Jeh (talk) 21:58, 18 March 2014 (UTC)

There is no need to create a succinct term for metric prefixes when used with binary meaning, and WP should not create the impression that such a term exists, as nowhere else is such a term proposed or used, IIRC. The temptation of many WP editors is to invent new terms to explain something, which is wrong. There should and are only a few places in the text where the distinction is needed and those can be elegantly rewritten so that the meaning is clear. My try certainly showed that. Certainly, customary binary prefixes is a terrible expression, as there is nothing particularly customary about the use, except for rather narrow application areas. Kbrose (talk) 07:18, 19 March 2014 (UTC)

I have just made a 5-step proposal to address this (see 5 most recent edits). Because it affected several sections it was easier to just do it than to try to imagine how it would look in advance. Easy to revert if not considered an improvement. Dondervogel 2 (talk) 11:26, 19 March 2014 (UTC)
kbrose: I think you're mistaken. We have "IEC prefix" and "SI prefix". Good writing calls for a parallel, and similarly succinct, term. "Prefixes borrowed from SI but used in the binary sense" or similar is a ridiculous thing to have to insert, and to have to read through, at multiple places in the article. Using an invented term is a perfectly common and valid pedagogic technique, particularly when a) there is no generally accepted term already and b) every usage was ref'd to the definition footnote which began "As used in this article, the term...". I feel that your edit in this area, compounded by Ddv2's further edits, removed essential informative connotations of the term, and also made the phraseology more awkward.
As for "Nothing particularly customary about the use", I have no idea how you can say that. This very article documents, with references, the decades-long use of customary binary prefixes for main memory (and standardization by JEDEC) and in operating systems and other software. Now, my personal opinion (like Ddv2's) is that this usage should never have happened, but it is not this article's place to deny facts: This usage is most certainly customary, and the prefixes used this way are clearly binary prefixes. It is true that this usage is confined to the computer industry, but that would be why the very first two words of this article are "In computing...". Jeh (talk) 14:49, 19 March 2014 (UTC)
Ddv2: Did you have an objection to the original phrasing (before kbrose's undiscussed edit)? If not, why not go back to that? Jeh (talk) 14:49, 19 March 2014 (UTC)
None in principle (though I don't like the term "customary binary interpretation" and similar) but in practice there have been a number of genuine improvements made since then. It might be less effort to accept where we are as a starting point (with or without my recent 5-step proposal - up to you), make a list here of the things that need fixing, and then agree on how to fix them. Dondervogel 2 (talk) 15:05, 19 March 2014 (UTC)
I am not proposing throwing away the genuine improvements, only restoring the usage of "customary binary prefixes" to the pre-kbrose state. Jeh (talk) 15:36, 19 March 2014 (UTC)
Am happy with that as starting point for further improvements. Dondervogel 2 (talk) 15:45, 19 March 2014 (UTC)

No, I am not mistaken. In fact the article is doing just fine without that term now. A further invention of the article was that a metric prefix when used in binary sense, becomes by definition a binary prefix. This is simply not so. There is no evidence for that in the majority of documentation about these issues. Such a definition is simply an invention by WP editors. Binary prefixes are those defined by IEC and ratified all over the world, and reliable references make that clear. The terms IEC prefixes and SI prefixes are obviously good usage, as that indicated where the definition came from. I agree that the term ISQ does not follow that model, and should not be used, something is hardly ever known by the entity that last used it. Kbrose (talk) 22:37, 19 March 2014 (UTC)

I don't think it's "doing just fine." The phraseology is awkward. It is a massive speedbump on the road to learning.
You would not agree that prefix letter borrowed from SI and used in a binary sense becomes in that usage a binary prefix? It's a prefix, and it most certainly is not decimal. If it isn't a binary prefix, then what is it?
What if we went to a previously-considered term: "JEDEC binary prefix"? We leaned away from that because the use of K to mean 1024, etc., long predates JEDEC's inclusion of that usage in their standards documents. However a footnote definition such as we currently have for "customary..." could explain that small issue. This would also be consistent with the template at the top of the page. I would even support "JEDEC prefix", again with a footnote to explain it. Jeh (talk) 23:09, 19 March 2014 (UTC)
In your last edit summary you write
metric prefixes are never called binary no matter what usage
Well, it is true that a prefix is either one or the other, but I maintain that a prefix used to denote a power of 1024 is a binary prefix, no matter what other uses may exist, even if the other uses are standardized and the binary usage is not. A prefix such as "K", "M", or "G" can be used as either a decimal prefix or a binary prefix, and if it is used as the latter, then it is called the latter. Again I ask: when you see "512 MB" used to mean 512x1024x1024, well, the "M" certainly is not a metric or decimal prefix, so what is it, if not a binary prefix?
If you're insisting that "K", "M", or "G" are never called binary prefixes, even when used to denote a power of 1024, then I'm going to have to ask for a WP:RS for that claim. So far we have only your word for it. And that's not enough to justify your WP:POINTy edits. Jeh (talk) 01:17, 20 March 2014 (UTC)
You want to define it as binary prefix but you will be hard-pressed to find such definition in the literature. These prefixes were simply used and rarely formally defined. Without rereading JEDEC, IIRC, not even that standard called them binary prefixes. When one finds the term binary prefix is it related to the IEC prefixes, and this is easy to show. You will have to find the references that define binary prefix as something else involving the metric prefixes. I reverted to my version because the majority of changes were not related to this issue, but to other typographical and grammatical issues. In this form, as well as the form before my last edit, the article gets along just fine without these new-fangled definitions that are nowhere supported in the literature. I remember being astonished about such definitions when this article was created or revamped years ago, but never got interested in reading it much or cleaning it up, because of the ugliness of debate about the issue, where refuseniks appear programmatically almost whenever someone threatens to introduce the real binary prefixes into WP, a process that is long overdue and commonplace around the world, except on WP where the issue is controlled by a small group of sock puppets. Kbrose (talk) 07:46, 20 March 2014 (UTC)
It is only your opinion that "the article gets along just fine". My opinion is different. Your opinion does not automatically win over mine. It does not automatically override prior consensus either. I think there is a powerful pedagogic advantage in having a parallel term to "IEC prefix" and "SI prefix", one that is equally succinct or nearly so; the similarity in pattern (simple adjective-noun) underlines the parallel.
If you had actually followed the debate that led up to the revamp four years ago you would have seen that it was anything but ugly! One of the most vocal opponents of general usage of IEC prefixes on WP participated and was extremely reasonable and reasoned.
In any case that is not an excuse for your: saying nothing then nor for four years afterward; then making significant changes to the article just on your personal whim and against clear prior consensus; then insisting on your changes even when discussion here has begun and several have said "hold up, let's talk about it"; and then continuing to edit the article in other ways, which will make it more difficult to revert your first changes.
Such WP:POINTy editing smacks of article WP:OWNership. (edit - added:) And does not exactly allow you to take the moral high ground with respect to the "ugliness of debate about the issue". (end of addition)
Well, at least you finally came here to answer the cries of protest. But so far you do not seem to be interested in discussion, only in insisting on your way.
Regarding "binary prefix" as applied to KB, etc.: Would it help to think of it not as a single "term", but rather as a term ("prefix") preceded by an adjective ("binary")? Analogy: If I see a pink submarine in the harbor, I don't need to find an official definition somewhere of "pink submarine" to call it that. Yes, "IEC prefix" and "SI prefix" are well known, but I do not believe you will find them defined in the respective standards either; those usages are cases of "everyone knows what it means". It is the same with "customary binary prefix", once we provide a definition.
I ask again: Would you accept "JEDEC prefix" with a definition in a footnote? The footnote would of course have to indicate that such "binary" use of prefixes borrowed from SI predates JEDEC, but I can live with that. Or is it your position that nothing is acceptable except your phrasing? Jeh (talk) 18:19, 20 March 2014 (UTC)
Just as a quibble, I'd point out that "JEDEC prefix" has the defect that the prefixes did not originate with JEDEC. They documented what was already in use, but calling them JEDEC prefixes implies that JEDEC had a role in defining them, which wasn't really the case. One of the difficulties of this entire subject is that the binary usage accreted through time without any formal review - which leaves us battling amorphous tradition. Tarl.Neustaedter (talk) 18:29, 20 March 2014 (UTC)
As I mentioned above, more than once I believe, yes, I know that. iirc that was why we avoided using "JEDEC prefix" before. But I think we can live with that. The use of the term "JEDEC" to denote this usage of these prefixes is already accepted on WP in the template {{Bit and byte prefixes}}. The definition footnote can explain that this usage has been codified by JEDEC, but that JEDEC didn't originate it. For that matter the "SI prefixes" existed long before SI came along. If "JEDEC prefix" gets us past kbrose's objection to "invented terms", I'll call it good enough.
I wonder if this entire kerfuffle could have been avoided if the definition footnote had avoided the word "term". "As used in this article, 'customary binary prefix' refers to..." Jeh (talk) 20:45, 20 March 2014 (UTC)

Term "ISQ binary prefix" fails both common sense and WP:COMMONNAME

These prefixes are nearly universally known as "IEC binary prefixes". They're called that because the IEC proposed them in their current form. Google shows 333,000 hits on "IEC binary prefix" and none for "ISQ binary prefix" (both searched as quoted phrases). We didn't start calling them by a new name every time another standards organization adopted them! Uses of "ISQ binary" or "ISQ prefix" or similar in this article should be changed back to "IEC". It is fine and good to note that these units are now part of the ISQ, but that's as far as that should go. Jeh (talk) 04:10, 18 March 2014 (UTC)

I'm going to agree with Jeh on both of these points ("customary binary prefixes" and IEC/ISQ). Rwessel (talk) 05:36, 18 March 2014 (UTC)
Agreed, I can't see a need for "ISQ". Johnuniq (talk) 05:46, 18 March 2014 (UTC)
I'm going to agree as well. I point to this page every time I have the argument with another "K is 1024!" droid. "IEC Binary Prefixes" means something to many of them, they recognize IEC (and ISO). ISQ doesn't mean anything to any of them. Tarl.Neustaedter (talk) 06:48, 18 March 2014 (UTC)
The prefixes in question were proposed in an IEEE article by Barrow in 1997. They were adopted by the IEC in 1998 and later by IEEE (ca. 2005), and incorporated by the ISQ in 2008. If they had been adopted by the SI, I don't believe any one would argue against calling them "SI prefixes", and for that reason the "common sense" name is "ISQ prefix". I accept that "IEC prefix" is more common, and if that name is preferred on those grounds I would not object, but please get the history right. Dondervogel 2 (talk) 07:22, 18 March 2014 (UTC)
Thanks. Fixed. Jeh (talk) 08:15, 18 March 2014 (UTC)
Correction: According to this 1996 IUPAC report, before the 1997 Barrow article, the prefixes were indeed proposed by the IEC, but does anyone know where to find that proposal? Dondervogel 2 (talk) 07:31, 18 March 2014 (UTC)
I would have argued against calling them "SI prefixes", since that term is already understood to mean prefixes that refer to powers of 1000. We'd have to use "SI binary prefix" or "SI decimal prefix". Jeh (talk) 23:12, 19 March 2014 (UTC)

A Modest Proposal

Clearly there are some disagreements about naming, I propose that you all stop changing the article again and again but rather put up your desired version here on the talk page and discuss it.

Among other advantages, this would allow me to join the discussion; right now I don't think my voice would be heard on account of the fact that I am unwilling to change an article that many times in a short period of time.

While we discuss it, we could revert to the 17 February version[2], which only has minor changes[3] from the 15 January version.[4] --Guy Macon (talk) 00:39, 20 March 2014 (UTC)

I'm fine with that. I suggest we go ahead and have that discussion here, ignoring further edits to the article, such as the one recently made by kbrose. Perhaps such editors will join us here, perhaps not, but if not we will at least be able to point to a reasoned discussion and conclusion in defense of our consensus. Jeh (talk) 01:24, 20 March 2014 (UTC)
I am going to be WP:BOLD and restore the last stable version. Nobody had any problems with that version for nearly a year. --Guy Macon (talk) 02:14, 20 March 2014 (UTC)
Looks good. What else do you have in mind? As I said up above, I personally have no problem with "customary binary prefix" (and that was decided on by clear consensus and has been here for four years), but I am willing to switch to perhaps "JEDEC prefix". Jeh (talk) 06:42, 20 March 2014 (UTC)
I repeat my objection to the words "customary" and "binary" going together because the customary interpretation of these prefixes is clearly the decimal one. What is the interpretation to "binary interpretation of ..."? Dondervogel 2 (talk) 07:03, 20 March 2014 (UTC)
In the semiconductor industry, and in the most widely used general purpose operating system, the binary interpretation is very definitely "customary". It is even enshrined in standards documents published by the leading semiconductor memory industry association, JEDEC. It's even gotten to the point where people think K=1024 applies (or should apply) to everything in computing, even hard drives. How can you say it is not "customary"? Furthermore this usage enjoyed consensus and stability for four years. You can't just insist on changing it because you disagree with it. There is no consensus for removing it.
The objection to "binary interpretation of... " is that the phraseology is not parallel to "SI prefixes" and "IEC prefixes". Jeh (talk) 09:10, 20 March 2014 (UTC)

User:Kbrose just made an edit with the comment "restoring this to my version because most of my changes had nothing to do with the issues discussed."[5] Is everybody OK with that version? Personally, I don't care which version it is left in; I just want it to be in a state that everyone can live with while discussing this. --Guy Macon (talk) 07:39, 20 March 2014 (UTC)

My preference is to start with a relatively recent version and make a list of issues with that recent version. I don't really mind which recent version, but I do have a suggestion, which is the one after my edit on 13 March (which I think was considered uncontroversial by others), and before my edits of 16 March (which sparked off at least part of the present discussion). Dondervogel 2 (talk) 07:55, 20 March 2014 (UTC)
Sure, everyone wants their OWN changes preserved and that version used as the starting point.
I propose that we go back to a version before kbrose's change away from "Customary binary prefixes" and use that as the basis for work here. It does not matter what anyone does to the article in the meantime. Eventually we will post a new version to the actual page and changes that non-cooperative editors made to the page in the meantime will, or will not, be preserved according to what we decide here. If the non-cooperative editors choose to join in the discussion here, that's great, but we can't allow a reasonable discussion to be sidetracked by one or two editors' decisions to edit against long-standing consensus. Jeh (talk) 09:10, 20 March 2014 (UTC)
If there is a consensus here on which earlier version to revert to and we end up with editors who edit against that consensus I will request a temporary page protection. I am fine with whatever everyone else decides. --Guy Macon (talk) 09:37, 20 March 2014 (UTC)
Like I said, I will accept any recent version as a starting point. I have no objection to Jeh's proposal. I see no need to protect the page though, and would prefer to avoid that. Dondervogel 2 (talk) 10:09, 20 March 2014 (UTC)
Oh, of course. PP is only when you have a real problem with someone. I see nothing like that here, just editors who want to improve the page and have a good-faith disagreement about what is best. Sorry if I implied otherwise. --Guy Macon (talk) 10:27, 20 March 2014 (UTC)
My point precisely. All we need to do is agree which version and work from there. I said already I would agree to Jeh's proposal, but it would be a pity to revert all recent changes just because we disagree on a small number of them. For that reason I would also agree to (and possibly even prefer) the very latest version of today from kbrose. Dondervogel 2 (talk) 10:49, 20 March 2014 (UTC)
I do not feel that any version that includes or follows any of kbrose's edits (starting with the one that got rid of "customary binary prefix") is acceptable as a starting point. The few genuine improvements made since then can be easily found and propagated. Re kbrose, he is continuing to edit the article on points unrelated to his initial edit and these edits are being made in the face of calls for discussion here; such edits will make reversion of his earlier edits more difficult, and he has to be aware of that. Although he has finally appeared on this talk page (see earlier section) he seems to be completely uninterested in discussion or compromise. I do not believe that edits made from such a strong position of WP:OWNership should be accepted as a starting point here. Jeh (talk) 18:32, 20 March 2014 (UTC)
I propose that we go back to the stable 17 February version[6]. Seriously, it stayed stable for a year, so how bad could it be?. If anyone thinks that important changes not involving the current content dispute were lost, they are free to re-insert them individually. Here are the changes. --Guy Macon (talk) 22:57, 20 March 2014 (UTC)
I support going back to the 17 February stable version during discussion. −Woodstone (talk) 05:49, 21 March 2014 (UTC)
...and you just did that on the article page. I thought we were going to work on it here, likely in a sandbox page. Jeh (talk) 09:15, 21 March 2014 (UTC)
Why don't we each just make a list of shortcomings of the present version of the page (after Woodstone's revert), and then just agree how to address them one by one? Dondervogel 2 (talk) 12:49, 21 March 2014 (UTC)

Here's my list of shortcomings:

  1. The article makes no mention of the incorporation, in 2008, of IEC prefixes in the International System of Quantities
  2. The term "customary binary prefix", used throughout, is a self-contradiction because there is nothing customary about this binary use of these prefixes. For hundreds of years they have been decimal prefixes, not binary ones. The obvious alternative is "binary interpretation of metric prefixes". No need for the word "customary"
  3. The statement "Main memory and cache memory universally use customary binary prefixes" is misleading at best (I interpret the word "universal" to mean there are no exceptions, which is not correct).
  4. There is no mention of the trend in the computer storage industry (eg Toshiba) to state the capacity of their products in both decimal (GB = 1000^3 B) and binary (GiB = 1024^3 B) units.

Dondervogel 2 (talk) 10:04, 22 March 2014 (UTC)

Discussions long ago led to a few clear distinctions in terminology.
  • A prefix is a symbol with a defined meaning that can be attached in front of a unit
  • A binary prefix is a prefix that has a value based on powers of 2
  • A decimal prefix is a prefix that has a value based on powers of 10
  • An SI prefix (in this context) is k, M, G, etc, with a meaning as defined by SI (thus decimal)
  • An IEC prefix (in this context) is Ki, Mi, Gi, etc, with meaning as defined by IEC (thus binary)
  • A "customary binary prefix" (for want of a better designation) is K, M, G used with binary meaning
  • Consequently an M or G can be either a binary prefx or a decimal prefix, depending on context
I would not want to lose any of this clarity of terms in a new version. Adding inclusion of the IEC (binary) prefixes in the ISQ system is valuable, but also the SI (decimal) prefix are included in it, so the term is not distinctive in many circumstances.
−Woodstone (talk) 13:26, 22 March 2014 (UTC)
I agree with all of Woodstone's bullets except the 6th one. Self-contradiction does not lead to clarity. Dondervogel 2 (talk) 13:33, 22 March 2014 (UTC)
  • Agree with all of Woodstone's points, but for clarity, the constants in points 2 and 3 should be 1024 and 1000.
  • Dondervogel: Your point 1 is easily corrected, but as Woodstone points out, we should not then globally change IEC to ISQ. "IEC binary prefix" is well recognized, "ISQ binary prefix" is not.
  • Regarding your point 2, I want a succinct term for "prefix borrowed from SI but used as a binary prefix" that is obviously parallel to "SI prefix" and "IEC prefix". The binary usage of the SI-borrowed prefixes is most certainly "customary" in the RAM, etc., industry; how can you disagree with this? "Binary interpretation of metric prefix" is a horribly awkward phrase, and self-contradictory besides (it can't be a "metric prefix", however qualified, if it's interpreted as a power of 1024); it is a massive speedbump to the reader. You have just agreed with Woodstone's point 2 that "a binary prefix is a prefix that has a value based on powers of 2", so how you can simultaneously claim that "M" in "MB" cannot possibly be called a binary prefix even when it clearly means 1024x1024 is beyond me; it seems to me that it is your position that is self-contradictory.
"Customary binary prefix" was agreed upon previously by complete consensus and has been stable for four years. You (and kbrose) are going to have to offer something better than "I just don't like it" to start a change away from it. A good start would be for you to suggest something else. It needs to be three words maximum, the last one being "prefix", and if three words, the last two words need to be "binary prefix". I am not likely to compromise on those requirements; parallel terminology is a powerful pedagogic tool. As I said above to kbrose, I would agree to "JEDEC prefix" - that is already enshrined in the template used in the upper right corner. The definition footnote will have to explain that JEDEC didn't originate it, but I can live with that.
  • Re your point 3, I am aware of no exceptions. Please provide a reference for your claim of main or cache memory advertised, spec'd, etc., using decimal prefixes. And I will provide thirty references using customary binary prefixes.
  • Please provide a reference for your claim that Toshiba is using both decimal and binary prefixes in statements of drive capacity. I sure don't find any such here. Fine print (e.g. "Many operating systems will display the capacity of this drive as approximately (whatever) GB") is not using the binary prefix on an equal footing with the decimal and would not justify your claim, not that I can find such statements at that page. And even if one could, one manufacturer would not make a "trend". Jeh (talk) 14:01, 22 March 2014 (UTC)
1. I am pleased to see there is no disagreement here
2. “JEDEC prefix” is a huge improvement on “customary binary prefix”, and I see no consensus for the latter
3. I never mentioned use of decimal prefixes in this context. My point is that use of IEC binary prefixes for this purpose is increasingly common
4. Try this and this for some examples. Taking a closer look, Toshiba appears to have adopted MiB/s as a unit of data transfer rate. They also use GiB for "SLC NAND Flash", whatever that means.
Dondervogel 2 (talk) 14:59, 22 March 2014 (UTC)
I would not oppose using "JEDEC binary prefix" instead of "customary". We can say that they have been codified by JEDEC, just as SI and IEC did for theirs. Powers should remain 2 (binary) and 10 (decimal), to show the link to their names. The fact that in practice not all powers are used, but only specific multiples (of 10 or 3) is not relevant for the definition. −Woodstone (talk) 15:11, 22 March 2014 (UTC)
I support "JEDEC binary prefix" and oppose "customary binary prefix". --Guy Macon (talk) 17:21, 22 March 2014 (UTC)
2. The consensus for "customary binary prefix" was in the discussion that led to a large reorg of this article, four years ago. I've linked it before.
3. Sorry, I typed the wrong word. You claim that use of IEC binary prefixes to refer to size of main or cache memory is becoming "increasingly common". I claim that among RAM makers, it is non-existent. There are a few Linux distros and a few examples of other software that use it, but "increasingly common" is vastly overstating the case as that suggests it is already "common" and is getting more so. In fact it is anything but common to the vast majority of desktop or laptop computer users. Even Apple, who recently decided to change to SI prefixes for displays of hard drive size, file size, etc., is sticking with customary binary prefixes (JEDEC prefixes) for displays of main memory and so on. At best you could say that use of IEC prefixes by operating systems or other software is rare. For the RAM manufacturers, the customary binary prefixes are... not just customary, but universal, as claimed.
4. The article already states that Seagate has quoted transfer rate with both IEC and SI. But you said "capacity." You have not provided anything that shows the use of IEC prefixes for hard drive capacity (or hard drive equivalent). The Toshiba SSHD data sheets do use GiB for the capacity of internal flash memory and buffer memory—i.e. for memory chips—but not for the HD product. Similarly the last link you gave does use GiB for the size of the internal flash RAM chips but GB (decimal sense) for the SSD product. So far, no examples of IEC prefixes for HD, SSHD, or SSD capacity have been shown. Jeh (talk) 18:15, 22 March 2014 (UTC)
2. I meant consensus on this page, here and now, not 4 years ago.
3. I cannot agree with the claim for "universal" use. Certainly manufacturers of PCs stick to the JEDEC prefixes, but scientists seeking unambiguous terminology are using IEC prefixes almost without exception. IEC prefixes are also used by manufacturers of supercomputers.
4. I got this one wrong in my initial post. I had seen Toshiba advertise its storage products using IEC prefixes, but it turns out mainly for data transfer rates. I pointed out this correction in a later edit (though looking back on it now I did not do so very clear, but I acknowledge the error clearly enough here).
Dondervogel 2 (talk) 18:39, 22 March 2014 (UTC)
I think that it is fair to say that most manufacturers choose whatever definition lets them advertise the biggest numbers, and thus are a poor source. Better sources would be product reviews and pages explaining technical details. --Guy Macon (talk) 20:11, 22 March 2014 (UTC)
I don't agree with the statement "most manufacturers choose whatever definition lets them advertise the biggest numbers". If this were the case, the problem would never have arisen because they would all use decimal prefixes. I do agree that manufacturers' advertisements are poor sources though, because they are usually sloppy. Peer-reviewed scientific articles are more reliable. Dondervogel 2 (talk) 20:43, 22 March 2014 (UTC)
2. Consensus plus four years of stability. But... consensus can change, and we do have that template that uses "JEDEC". I am happy with "JEDEC prefix" or "JEDEC binary prefix". (But if it is claimed that MB cannot be a "JEDEC binary prefix" then I am going to seriously doubt the GF of the claimant. It becomes a binary prefix through usage and observation: it's a prefix, and it's used in a binary way. One might object to the usage, but objecting to a purely descriptive term is irrational.)
3. I am not pushing for a statement of universal use by everyone. But I feel it is important to note that among chip makers and the vendors of the most common desktop and laptop operating systems, use of JEDEC prefixes for RAM, etc., is indeed universal. As for "scientists seeking unambiguous terminology," hah—you can of course defend that claim against all apparent exceptions by simply saying "well, the author of that paper must not have been seeking unambiguous terminology." i.e. anyone who doesn't use the IEC prefixes simply doesn't count to you. You're ignoring the longstanding practice of simply using footnotes to define what the prefixes mean in a particular article. That's still unambiguous.
4. ok. We can actually use those links though as examples of use of IEC prefixes, just very clearly described as not applying to the overall HD or whatever product. Jeh (talk) 01:15, 23 March 2014 (UTC)
BTW, I just checked a bunch of peer-reviewed scientific articles, and it look like we need to stop using English and start using Latin when we give the names of animals and plants. Or we could use peer-reviewed scientific articles to establish facts but not to dictate style. I'm just saying. --Guy Macon (talk) 01:28, 23 March 2014 (UTC)
I have been on and off the grid for the past several weeks and won't be steadily on until April (vacation in NZ and Australia) so I haven't been able to carefully review the above. I think I pretty much agree with and support Dondervogel's points. One issue not raised herein, but perhaps to be considered is the current deprecation IEC Binary Prefixes in the MOS; personally I think it is time to specifically enable their usages in relevant articles such as HDD and FDD where inconsistent meaning has and does cause consumer and reader confusion. Going off line again. Tom94022 (talk) 01:35, 23 March 2014 (UTC)
Tom, as you may remember, I support the IEC prefixes. I use them in my own writing and teaching. But the issue of their use on Wikipedia is completely distinct from the article improvement points being discussed here, and I hope that this discussion does not get sidetracked into that one. Let's address the issues various editors have had with this article as evidenced in edits made since 17 February and get the resulting edits done. It looks like we can do that here with a minimum of angst... it looks like we already have near enough to consensus so as not to matter. Let's leave the IEC-in-MOS issue for a later time. Jeh (talk) 06:38, 23 March 2014 (UTC)

Four proposals

I think there is sufficient consensus on some of these to make some specific proposals. For convenience I reproduce the list of (perceived) shortcomings, exactly as I typed them

  1. The article makes no mention of the incorporation, in 2008, of IEC prefixes in the International System of Quantities
  2. The term "customary binary prefix", used throughout, is a self-contradiction because there is nothing customary about this binary use of these prefixes. For hundreds of years they have been decimal prefixes, not binary ones. The obvious alternative is "binary interpretation of metric prefixes". No need for the word "customary"
  3. The statement "Main memory and cache memory universally use customary binary prefixes" is misleading at best (I interpret the word "universal" to mean there are no exceptions, which is not correct).
  4. There is no mention of the trend in the computer storage industry (eg Toshiba) to state the capacity of their products in both decimal (GB = 1000^3 B) and binary (GiB = 1024^3 B) units.

Next step is to add a proposal to address each one ... Dondervogel 2 (talk) 09:29, 23 March 2014 (UTC)

International System of Quantities (ISQ)

I believe there is consensus to describe the incorporation of IEC prefixes into the ISQ. What should we say and where? Dondervogel 2 (talk) 09:35, 23 March 2014 (UTC)

Given the apparent non-use of ISQ as a term, a simple comment to describe that sentence is justified. Rwessel (talk) 16:51, 23 March 2014 (UTC)
The point has nothing to use of "ISQ" as a term. What is needed is a description of the status of the IEC prefixes (alongside SI prefixes) within the ISQ. I agree a single sentence is sufficient for the lede, but a more detailed description is warranted further down, in the context of adoption of IEEE, NIST and other major standards bodies. Dondervogel 2 (talk) 08:55, 24 March 2014 (UTC)

Replacement for "customary binary prefix"

Several editors have objected to use of the term "customary binary prefix". My proposal is to replace it with "JEDEC prefix". Dondervogel 2 (talk) 09:44, 23 March 2014 (UTC)

I still consider "customary binary prefix" a good designation, but if we need to step away from it, I would prefer the explicit "JEDEC binary prefixes". Are these the only prefixes that are stated in the JEDEC documents? Or do they also mention decimal prefixes? If so, the addition of "binary" is necessary, if not then it would still avoid misunderstanding. −Woodstone (talk) 14:14, 23 March 2014 (UTC)
I have no objection to "customary binary prefix". "Customary", like many things, is dependent on context. In this context it is not at all contradictory, self, or otherwise. I don't have any particular love for "customary", but none of the proposed alternatives are an improvement. In particular JEDEC is not - I don't read the document as really intending to establish or define the usage, merely not the actual usage, which long predates the JEDEC document. "Customary binary prefixes" is succinct and clear in this context. Rwessel (talk) 16:49, 23 March 2014 (UTC)
Ddv2, using "JEDEC" was actually my proposal, not yours. But anyway, "JEDEC binary prefix" is more explicit. Jeh (talk) 00:24, 24 March 2014 (UTC)
Woodstone: Last I looked, the JEDEC documents acknowledged the existence of the IEC prefixes in footnotes but did not recommend their use. I never saw any indication that they recommended use of decimal prefixes in statements of memory capacity, though they may have done so for e.g. clock speeds. Downloading their standards is free but requires (free) registration. Jeh (talk) 00:24, 24 March 2014 (UTC)
Rwessel: I feel as you do that there was nothing wrong with "customary". I offered "JEDEC" as a compromise. At this point the relevant question is, can you live with "JEDEC binary prefix"? Remember, the explanatory footnote will note that JEDEC didn't invent them. Jeh (talk) 00:24, 24 March 2014 (UTC)
I'll end up living with whatever the consensus is. But I really don't like JEDEC. As you mentioned these are really only "defined" there in an explanatory footnote. The only real justification for calling them "JEDEC (binary) prefixes" is that's the earliest semi-official standards document found that mentions them at all. I doubt *any* good standards document will actual provide such a definition, because it's clearly wrong. So in a sense we have no choice but to make up a name. That name will almost certain require the words binary and prefix (although I don't think that's at issue), and I think it should be concise as well. I'll reiterate that I don't think customary presents any linguistic problem in this case, in fact it's quite an appropriate term to prepend to "binary prefix" in this context. These are the binary prefixes established by custom (history/long term usage/etc.) as opposed to by law/fiat/good sense/etc. They may well be *bad* binary prefixes (and I'd certainly agree that they are), but they are most certainly the customary ones (even though efforts to introduce a new custom have been made). I find it very difficult to read this as "these prefixes are customarily binary" (which would, indeed be self-contradictory, and just plain wrong). I just don't see that as a reasonable interpretation. Perhaps adding a hyphen would improve clarity ("customary binary-prefixes" - yech, BTW, but I'd support that before JEDEC). Rwessel (talk) 03:37, 24 March 2014 (UTC)
"As you mentioned these are really only "defined" there in an explanatory footnote." Huh? No. It is the IEC prefixes that JEDEC only mentions in an footnote. They recommend the use of what we've been calling "customary binary prefixes" and that rec is not confined to a footnote, it's in the main body copy. My answer re. the footnote was for the question "Are these the only prefixes that are stated in the JEDEC documents? Or do they also mention decimal prefixes?". JEDEC does not, that I recall, mention decimal prefixes. They recommend "customary binary prefixes" (MB meaning 2^20 bytes, etc.) in their main copy (e.g. lists of definitions) and mention the IEC prefixes in footnotes. I will say again that agree completely with you in your reading of the term "customary binary prefixes", but enough people seem to object to it (for reasons that, like you, I find baffling) that I offer "JEDEC binary prefixes" as a compromise. As I said above, though, I do insist on a term of the pattern "xxx binary prefixes" due to the pedagogic power of parallelism. Jeh (talk) 04:30, 24 March 2014 (UTC)
Indeed, I remembered it backwards. Should've reread it before posting, there's been a copy stored on the network for years. The JEDEC document is, however specific to semiconductor memory (it says so). If we're going to be pedantic about this, that would exclude non-semiconductor based memories (perhaps we don't see much core in the real world any more, but it exists), and it would necessarily exclude any logical or virtual address space as seen by an actual running program. So perhaps JEDEC blesses the use of kilo/K=1024 for programs running simple systems without multiple address space or virtual memory, but not on most Windows on Linux systems. Of course those systems could have other sources blessing that usage.
More significantly, it also includes the statement (Note 2 under Mega) "The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states 'This practice frequently leads to confusion and is deprecated.'". "Common usage" being another way to say "customary". Frankly that statement has more than a bit of an odor of disapproval about it (IOW, "for reference, this is how these prefixes are used, but we don't like it."), and I don't really read the three definitions as endorsements, as both kilo and giga both took the trouble to refer to Note 2 under mega (and mega obviously includes that note). I read the inclusion of the IEEE/ASTM quote, and the "included only" clause, as explicit disapproval of the practice (followed by a mild endorsement of the IEC prefixes). I think if JEDEC were an entity with an ego, it would not appreciate having its name attached to these - consider how silly it would be to name a scandal after the journalist reporting it (although that's happened). Rwessel (talk) 05:07, 24 March 2014 (UTC)
*sigh* So what are you saying? We are agreed that we don't have a "perfect" name that everyone agrees on without reservation. We can, each of us, each spend days citing all of the reasons to not like some of them. But at some point we need to move forward. It seems to me that we have enough agreement on "JEDEC binary prefix" that I think we can move forward with that, unless you can find some policy-based reason to oppose it. What I am looking for here is a clear consensus that we can point to the next time someone comes along and willy-nilly changes it away from whatever we agree on here. Jeh (talk) 06:43, 24 March 2014 (UTC)
Moving forward requires some consensus on what to move *to*. If none such exists, we stick with the status quo. While this is, of course, not a vote it seems to me that more people in this discussion have stated or implied (comments along the line of "if we move, I'd accept JEDEC" are properly an endorsement of the status quo) a preference for "customary binary prefix" than there are people wanting to change it. So heck, I don't even see that we have much of a consensus that we need a change, much less on what we want to move to. But here we are. IMO "customary binary prefixes" is clear, accurate and concise. It's major flaw is that it's largely a made up term. "JEDEC binary prefix" is significantly inferior to that (the customary binary prefixes were neither defined or endorsed by JEDEC, and "JEDEC binary prefix" is pretty much as made up as "customary..."), but is better than any of the other suggestions I've seen here. So if we decide we need a change, I'd get on board with JEDEC (unless something else better comes along). Rwessel (talk) 07:58, 24 March 2014 (UTC)
Again being on and off the grid I can't research this, but i find a useful duality between JEDEC and IEC as the two standards groups defining the alternate definitions and therefore find JEDEC Binary Prefixes preferable to "Customary." The fact the JEDEC adopted an historical mess is interesting history, but they have endorsed it and therefore it is reasonable to so label it. Tom94022 (talk) 05:48, 24 March 2014 (UTC)
My point is that JEDEC does not actually endorse them. They report common usage, and say it's bad. Rwessel (talk) 07:58, 24 March 2014 (UTC)
@Jeh: Sorry, I should have said "I support Jeh's proprosal to use the term 'JEDEC binary prefix' or similar". I don't really see the need for the 'binary' in there but do not object to it either.
@Rwessel: You seem to be the only one arguing against 'JEDEC binary prefix'. You say that JEDEC did not invent them, but this seems like a weak argument to me. After all, the SI did not invent "k" for 1000 or "M" for mega, but both are adopted by the SI, and that is why we choose to call them "SI prefixes". It seems to me that all those arguing against 'customary binary' are willing to support Jeh's proposal.
Dondervogel 2 (talk) 09:08, 24 March 2014 (UTC)
CGPM is clearly the intellectual and moral successor of the earlier efforts. Similarly the EU inherited a bunch of stuff from the EC, and we usually lump all the inherited stuff under the "EU" heading. JEDEC just recorded some existing usage. Rwessel (talk) 17:30, 25 March 2014 (UTC)

There is a tendency in this article to distort history to make things neat and tidy and the suggestion to use the term JEDEC binary prefix is an example. JEDECs mention of the binary meanings came well after they were established, is not widely known, and has little or no influence on their continued use. Adopting the term here suggests something that simply isn't true. We should find language that reflect the reality of what happened, a custom that developed, not a standards body recommendation.--agr (talk) 19:10, 24 March 2014 (UTC)

I understand. That's why we agreed on "customary binary prefix" four years ago. It is an accurate description, because the prefixes referred to are most definitely being used for powers of 1024, and such use is most certainly customary in the RAM, etc., industry, and in many operating systems for both RAM and hard drives.
So... Is there some verbiage in the "definition footnote" that would make "customary binary prefix" acceptable to those who don't like it? (Some seem to be adamantly opposed to it.) Is there a basis in WP policy for opposing "customary binary prefix"? Is there an alternative for x in "x binary prefix" that's acceptable? Jeh (talk) 20:27, 24 March 2014 (UTC)

I have to agree with this observation that this article exercises construction, rather than documentation. The foremost construction is that the term binary prefix has applicability to the metric prefixes when used with binary meaning. The term didn't exist until IEC defined the term to mean the new binary multiples, and the article should finally recognized that. Every reliable reference points to binary prefixes as the name for this group. The fact that the metric prefixes are used with binary meanings does not make them binary prefixes. The field got along just fine for decades without a neat term for the erroneous usage. The attempt to classify these usages now, after the fact, especially when these errors are being obsoleted, is distortion of history. History does not show us that there was ever a need to classify them neatly with another misleading name, and the article should not attempt to do so. I corrected this already in my edits, I believe even years ago. When referring to the metric prefixes in binary usage, the wording should be such that it is obvious from the context, not introduce new controversial terms that may be propagating by plagiarism into countless web sites. Furthermore, there is no need to use the term IEC binary prefixes. Binary prefixes is completely sufficient. Only if some kind of emphasis is needed, can the IEC source be included. IEC prefixes certainly is acceptable too, but simply binary prefixes is sufficient. When it comes to the JEDEC definitions, obviously the name can be used, but JEDEC has a very limited realm of influence for recommendations and some manufacturers already are transitioning to the binary prefixes by multiple labeling. Perhaps the term JEDEC sanctioned prefixes is appropriate, although JEDEC certainly sanctioned the use of binary prefixes as well. Their work is clearly intended to provide a smooth transition to the new unit, while the effort and cost of retooling in the industry can be completed, which usually takes many years until equipment costs are amortized. Certainly calling them JEDEC binary prefixes deepens the confusion, there is only one set of binary prefixes. Kbrose (talk) 20:39, 24 March 2014 (UTC)

It is unfathomable to me how you can claim that when, for example, "MB" is used to mean 1,048,576 bytes, the "M" is not a binary prefix in that usage instance. Of course it is. After all it is certainly a prefix, and it certainly is not decimal! And that is at least 90% of your argument against "customary binary prefix", so I can't fathom that argument either. Jeh (talk) 22:23, 24 March 2014 (UTC)
The unit MB in that context is a binary unit, but removing the B or Byte, does not make the prefix a binary prefix. By definition, that place is occupied by the JEC prefixes. When not connected with bytes or bits, the binary context is lost and the metric definition returns. You may say it acts as a binary prefix, but it can never be a binary prefix. Kbrose (talk) 23:25, 24 March 2014 (UTC)
In "MB", if the writer intended the "M" to act as a binary prefix, it's a binary prefix. Granted that it is not a binary prefix according to SI or IEC, but it is a binary prefix nonetheless. Yes, IEC defined their prefixes as binary prefixes, but they do not have the sole authority to define the meaning of words or terms. Again: it's a prefix, and it most certainly is not decimal.
The IEC has way more leverage to define and standardize than you do or WP is supposed to have, and their definitions is sticking with every other standards body. Kbrose (talk) 02:34, 25 March 2014 (UTC)
In this, WP is not defining anything, just calling something by a descriptive sequence of words. It is simply more succinct than "prefixes borrowed from the metric system but used to mean powers of 1024". By your argument, use of that monstrosity would be just as much "defining a term".
However... you wouldn't have a problem with calling the binary usages of KB, MB, GB, etc., "customary binary units"? I can live with that. Don't know about others. Jeh (talk) 00:13, 25 March 2014 (UTC)
Introducing another controversial term adds nothing to the article. It's simply not needed as decades of history have proven. Many people already are using metric multiples exclusively in the correct fashion, and see them on their computers even every day, and might just as well conceive them as customary as well. Customary in reality means metric. Kbrose (talk) 02:34, 25 March 2014 (UTC)
The "term" does not seem a bit controversial to me... and I think it adds a great deal to be able to write "customary binary prefix" instead of "prefix borrowed from the metric system, but used to mean a power of 1024". As for "customary," the article has strong references showing that such prefixes were in use for about 35 years before IEC binary prefixes were created. They were, and remain, completely customary when referring to main memory and etc. (In fact, they are so customary in the computer field that significant numbers of people believe that the hard drive makers are wrong for using SI prefixes! (You can find messages from some of them at talk:Gigabyte.) Doesn't seem to me that metric usage, even though correct per standards, is customary to many computer users at all.) And they were just as much binary prefixes back then as the IEC prefixes are now (even if nobody happened to call them that). As for your claim that people "see them (metric prefixes) on their computers every day," even Apple, who recently decided to use SI prefixes with their proper decimal meaning when displaying hard drive and file sizes, is still using the customary binary prefixes in displays of RAM; and Microsoft continues to use the customary binary prefixes for both RAM and hard drive and file sizes (but displays of data rates are in SI prefixes...). Finally, your "might just as well" phrase is pure conjecture on your part; evidence, as presented in the "consumer confusion" section, is that most users don't really know what they're looking at in this area. Jeh (talk) 07:06, 25 March 2014 (UTC)
Hmmm, this turns out to be more difficult than I thought. My main objection to "customary" and "binary" together was and remains that the customary interpretation of the prefixes "K", "M" and "G", even by the computer industry is the decimal one. The very least that needs to be done is to explain to the reader that use of "customary binary prefix" in the article does not imply that the binary use of these prefixes is customary, except in a subset of the computer industry (Microsoft Windows + semiconductor industry + who else?). Dondervogel 2 (talk) 11:38, 25 March 2014 (UTC)
To repeat myself, you're interpreting that as ((customary binary) prefix) rather than (customary (binary prefix)). English is *somewhat* ambiguous with multi-word compounds, although the basic rule is that you work from the base word out, and use hyphens to override that. IOW, it's "wild-goose chase", instead of "wild goose chase" (which would be a chaotic chasing of a goose, as opposed to the pursuit of a non-domesticated goose). I suggested "customary binary-prefix", although that would be odd since that *is* the normal interpretation, and the hyphen is redundant (just like you wouldn't write "wild goose-chase" if you meant the chaotic chasing of a goose). And alternative to hyphens is making a straight compound word ("customary binaryprefix"), but introducing new constructions like that in English is not very common (unlike, say, in German, where it happens three times before breakfast each day). Also, introducing such in a term ("binaryprefix") would almost always be considered a name, and that *would* be inventing a name, rather than a descriptive term. Rwessel (talk) 17:30, 25 March 2014 (UTC)
I have no problem referring to KB as a customary binary unit in the correct context, but I don't think that helps. You then introduce rather awkward parallelism problems when comparing the three types. IOW, "Customary binary units mean X, but IEC binary prefixes mean Y, and decimal/SI prefixes mean Z." There have also been cases (rare, but documented) of binary usage for other than bits and bytes (I believe an example with Hertz is documented in one of the related articles). Rwessel (talk) 17:30, 25 March 2014 (UTC)
The article makes clear that the binary interpretation of these prefixes is very much "customary" in the "main memory" part of the computer industry, going back to 1959 (Amdahl paper). This interpretation is furthermore overwhelmingly "customary" in marketing channels. When the system makers and retailers advertise laptops with "4 GB RAM" they do not mean 4,000,000,000! Among operating systems: Microsoft Windows, yes, but also Apple Mac OS: today for RAM and similar and until just a version or two ago, for hard drives and files as well. I believe that between these two operating systems at least 97% of desktop and laptop users are covered. The relative handful of uses of IEC prefixes you've found in various scientific and technical journals is insignificant by comparison.
This has created a widespread perception among many "somewhat technical" computer users that, because they see these usages all the time, and "computers count in binary" or some such, this usage ought to be universal in the computer hardware and software fields and that it's the hard drive makers who are wrong!
I get what you're saying that the "customary" use of "M", even for main memory, should have been decimal. But I think you underestimate the number of people who think the binary usage "should have been" universal throughout the computer field, even for clock speeds and data rates. Haven't you heard all of the whining about "500 GB" hard drives that show up with only "466 GB" or whatever the number is? For quite a while the discrepancy was chalked up to "formatting and file system overhead" or similar, but since with a terabyte-sized HD the discrepancy is 10%, that explanation is no longer making much sense (it was always, of course, wrong). Jeh (talk) 17:41, 25 March 2014 (UTC)

Possible compromise

I would like to suggest a possible compromise. Rather than trying to create a generic new phrase to replace "customary binary prefix", we should stick to accurately describing current and past practice. There are only two sets of prefixes that are being discussed in this article, the SI prefixes (K, M, G, T, ...) and the binary prefixes proposed by the IEC (Ki, Mi, Gi, Ti, ...). The SI prefixes in turn have been given two meanings, decimal, as prescribed by SI and other standards bodies, and binary, per customary usage in certain situations by the computer industry. I would therefore suggest that the article stick to these three descriptive terms:

  1. SI prefixes with a decimal meaning
  2. SI prefixes with a binary meaning
  3. IEC binary prefixes

These terms avoid arguments over what "customary" modifies. I've scanned through the article and I think these terms fit without too much awkwardness in most places and would generally make things clearer. The intro would say that binary prefixes are prefixes that have a binary meaning and go on to explain the computer industry's custom to use SI prefixes with a different, binary meaning and the IEC's proposal, but the term "binary prefix" would not be used from then on without the modifier IEC (or ISQ if that issue resurfaces).

Comments?--agr (talk) 14:53, 25 March 2014 (UTC)

This proposal makes matters only worse. There are no "SI prefixes with binary meaning". There are the letters K, M and G used as prefix with binary meaning. An SI prefix is more than a letter of the alphabet. It has a well defined meaning as prefix. If the same letter is used with a different meaning it cannot possibly be an SI prefix. −Woodstone (talk) 15:54, 25 March 2014 (UTC)
Agree, there are no "SI prefixes with a binary meaning". And it starts to get wordy too. Now we could use something like "bastardized SI prefixes with a millevigequaternary interpretation", but that's even clumsier. Rwessel (talk) 17:30, 25 March 2014 (UTC)
We've thrown around phrases like "prefixes borrowed from SI but used with binary meaning". In fact (without looking) I think that is close to what the definition footnote currently says for "customary binary prefix". I think it is accurately descriptive but it's way too awkward to drop in everywhere. Perhaps an initialism? PBFSIBUWBM. Just kidding. Four years ago, consensus was that "customary binary prefix", with a definition footnote to explain further, was sufficient. What has changed? Jeh (talk) 17:41, 25 March 2014 (UTC)
I agree with all above arguing that we should avoid the concept of an SI prefix with a binary meaning. An SI prefix is a well defined thing that is always decimal. But can the same thing be said about a metric prefix? The prefixes k (or K), M and similar had a meaning in the metric system long before the SI, and that meaning evolved with time. Indeed they were first used by computer scientists, and with them a fledgling computer industry, with a decimal meaning, before the SI came to be. Those metric prefixes then started to take on a binary meaning, also before the SI, but the way I see it they were still metric prefixes even with this binary interpretation. Dondervogel 2 (talk) 17:53, 25 March 2014 (UTC)
Prior to 1961, or so, any sort of prefix usage to describe main memory sizes was rare, simply because of the small sizes. And on machines with small memories the usage was not ambiguous in a sales or marketing sense - 32K doesn't really care whether the k is 1000 or 1024. By the late sixties the usage of the prefixes in the binary sense had been well established. We must ignore the usage on decimal machines, where the decimal sense was always used (for example, IBM simultaneously sold decimal 1410s where k=1000, and binary 360s where k=1024). Thankfully ternary machines like the Setun never became popular, or we'd probably be arguing about cases where k=729 or 2187 as well. Without the decimal machines, the use of decimal prefixes for main memory was fairly limited, even when we consider only the period of six or seven years when it was semi-common. It's unlikely, IMO, that decimal prefixes on binary machines were predominant past about 1963, and perhaps not before then. Exceptions exist, of course, and examples of decimal prefixes used on binary machine continue into the seventies (particularly on smaller machines where only the largest models got to the point where "K" was ambiguous). And the industry was vastly smaller then. Rwessel (talk) 19:48, 25 March 2014 (UTC)
As I remember things, "K" was understood to mean 1000 until the mid-1960s. Binary machines had word addressing and a 15-bit maximum address space was the norm. As the present article points out, up through 32K there was no need to reinterpret K, it was just a matter of rounding or truncation. (And the sentence in the article that suggests earlier use of 32K indicates binary usage is dubious.) The introduction of the IBM System/360 is what caused the need for a binary interpretation. Previous machines that addressed memory by character had decimal addressing. Switching to binary addressing of individual characters (which later became common with minicomputers) quadrupled the address space for binary machines and pushed common address sizes above 32K. One either had to use 65K, 131K, 262K, etc. or change the meaning of K. We even have an explicit quote from Ahmdal that he chose to do the later. So Si was around by then, but I think most engineers still called it the metric system. We need a neutral term for the binary usage of K, G, and M. I have no problem with "metric prefixes with a binary meaning," but if that is objectionable, I would propose "the letters K, M and G with a binary meaning." Terabyte in the binary sense is not widespread yet as RAM that size is exotic, but maybe we need to add T as well.--agr (talk) 21:03, 25 March 2014 (UTC)
Terabyte in the binary sense is very widespread: It's how Windows reports sizes of hard drive (and equivalents) and files. Jeh (talk) 17:36, 30 March 2014 (UTC)
I stand corrected. So my suggestion for a neutral term if we cannot agree on something more succinct is "the letters K, M, G and T with a binary meaning." --agr (talk) 21:23, 30 March 2014 (UTC)

If not JEDEC

This discussion seems to have died with almost consensus on JEDEC Binary Prefixes. If not JEDEC, how about Ad Hoc or De Facto? Tom94022 (talk) 17:11, 5 April 2014 (UTC)

Given the worldwide strength of the SI, the only sensible way to call them is "erroneous usage of SI prefixes as binary". Compvis (talk) 19:37, 5 April 2014 (UTC)
That is not particularly helpful. I don't think we can possibly get consensus on anything so critical non-neutral, and I doubt you really think we can either. Jeh (talk) 20:53, 5 April 2014 (UTC)
In the spirit of WP:NPOV, and to "make you aware of your" Anglo-American focus, let me remind you that the world has already spoken loudly and clearly about the SI, both in actual usage and through standards. Rather than reconsider this thorough consensus, Wikipedia should seek to document it, as it aspires to. Compvis (talk) 21:22, 5 April 2014 (UTC)
The world has already spoken loudly and mostly continues to use KB, MB, GB and TB with binary powers of two in actual usage. Increasingly it uses the binary sense with solid-state storage like SSD. Wikipedia documents how the world is, not what some people aspire it to be. Fnagaton 06:28, 6 April 2014 (UTC)
Compvis, this has nothing to do with "Anglo-American focus". The ad hoc binary prefixes are supported by the trade association JEDEC and are used by all of its memory-chip-making members, many of which are based in Japan, Taiwan ROC, mainland China, South Korea, etc. Perhaps I should point out (as I have several times before) that I am in favor of widespread use of the IEC binary prefixes, and I support their use, replacing the widespread use of the ad hoc binary prefixes? Heck, I even use them in my professional work. But widespread usage is not happening yet. (No, not anywhere: this is not limited to "Anglo-American" cultures, or even "Anglo" cultures. Look at how PCs and memory DIMMs are advertised in Munich, or in Prague, or in Taiwan, or in Cape Town, or in Brasilia... all places I have visited recently.) And it is most definitely not Wikipedia's job to scold users of the ad hoc prefixes every time we refer to their usage. Which is what your wording would do, and is obviously intended to do. Jeh (talk) 06:58, 6 April 2014 (UTC)


My preference remains "JEDEC", but I find "ad hoc" a sensible alternative. Any objections? Dondervogel 2 (talk) 08:53, 6 April 2014 (UTC)
I think ad hoc is a bit jargony, and I still prefer customary, but it's not fatally flawed. Rwessel (talk) 16:35, 7 April 2014 (UTC)

Replacement for "Main memory and cache memory universally use customary binary prefixes"

This is a massive overstatement that needs to be toned down or qualified. What it really needs is a careful explanation of who uses JEDEC prefixes in this context and who doesn't. While we discuss how to rephrase I propose replacing "universally" with "usually". Dondervogel 2 (talk) 11:18, 23 March 2014 (UTC)

I find "universally" dangerously strong (it literally requires only a single published instance of contrary usage to be false), but "usually" far too weak given the the reality. Something like "Almost universal" would be reasonable. Rwessel (talk) 16:56, 23 March 2014 (UTC)
Doesn't it all depend upon how one counts? If "almost universal" counts installations then Windows dominates, but if we count by OSes then the picture is not so clear. I suggest we drop this sort of qualification; some OSes report one way, some the other and several give the user the option. Again I need to do some homework here to. Tom94022 (talk) 05:53, 24 March 2014 (UTC)
Are there any examples of OS's reporting *memory* sizes with non-binary (either IEC or customary) prefixes? Certainly there are examples of disk space usage being reported all three ways, but I believe this point is specific to memory and cache sizes. Rwessel (talk) 08:02, 24 March 2014 (UTC)
I foolishly thought the words "main memory and cache memory" were intended to mean "main memory and cache memory", but I see now it was silly of me to think that. If, as I now suspect, it is intended to be a statement about operating systems, would it not be wise to include the word "operating system" somewhere in the sentence? Dondervogel 2 (talk) 08:50, 24 March 2014 (UTC)
I suspect we have to deal with OS, system vendor and component vendor reporting of "main memory and cache memory" sizes. Unfortunately, in any one system there maybe separate suppliers.
Doesn't Dondervogel have a page which describes the current state of OS reporting? Tom94022 (talk) 23:59, 24 March 2014 (UTC)
@Tom94022: You mean this page that you and I composed together a few years ago? It is not completely up to date, but I'm sure you can help me fix that. Dondervogel 2 (talk) 11:43, 25 March 2014 (UTC)
I reworded first to clarify that the remark was about how operating systems report memory, but the paragraph did not make sense like that so I reverted myself. Instead I have replaced "universally" (huge overstatement and obviously incorrect) with "usually" (some would say understated but at least not wrong). Can be improved further but I don't know how because I no longer understand the point being made. Dondervogel 2 (talk) 22:57, 27 March 2014 (UTC)
Any way you slice it, the change to "usually" improved the article. Good job. --Guy Macon (talk) 01:14, 28 March 2014 (UTC)

Increasing use of IEC prefixes

Before making specific proposals, perhaps best to start with an inventory of main uses, here on Talk. Dondervogel 2 (talk) 11:21, 23 March 2014 (UTC)

  1. First we have use in hundreds of scientific publications, increasing exponentially with time since their introduction in December 1998: 1999-2001 (ca. 20 hits); 2002-2004 (60 hits); 2005-2007 (170 hits); 2008-2010 (340 hits); 2011-2013 (610 hits).
  2. Second we have use by industry, eg by Toshiba press releases and product specifications [7] [8], by IBM [9] [10] [11] and by HP [12] [13]
  3. Third, use in supercomputing [14] [15] [16] [17] [18] [19] [20] [21] [22] [23]
  4. ... in education [24] [25] [26] [27] [28] ...
  5. .... and for unambiguous specification of amount of data storage [29] [30] [31] [32]

Any other suggestions? Dondervogel 2 (talk) 12:08, 23 March 2014 (UTC)

While noting the increased use is reasonable, actual use remains rare, and we shouldn't give those examples undue weight. Rwessel (talk) 16:59, 23 March 2014 (UTC)
Those are some impressively crafted search criteria, Ddv2! Agree with Rwessel, though. And there are some cautions about using Google hit counts in WP:GOOGLE. Jeh (talk) 01:51, 24 March 2014 (UTC)
It's not easy to find a filter that keeps baby and not bathwater. I would not rely on this (or any other) for an absolute count, but I think this one provides a reliable indication of growth rate. Dondervogel 2 (talk) 08:40, 24 March 2014 (UTC)
Other Toshiba tech specs say When used herein in relation to memory density, terabyte and/or TB means 1,024x1,024x1,024x1024 = 1,099,511,627,776 bytes. [33] Come to think of it this is a source that means we can add TB in the binary sense to the memory size template.Fnagaton 14:33, 31 March 2014 (UTC)
Interestingly we also have the JEDEC using TB in the binary sense [34] when talking about data sizes written to test SSDs. Fnagaton 15:01, 31 March 2014 (UTC)
Intel also say 1 Terabyte (TB) = 1,099,511,627,776 [35]Fnagaton 15:07, 31 March 2014 (UTC)

Dondervogel 2's WP:POINTy recent edits

Dv2 has added a number of cites to individual papers to try to show that the IEC prefixes are used in research papers. I reverted, stating that a few cites do not show increasing usage as his text first claimed. He reverted, changing the clailm to simply that they were used. This reduces the usages to non-notable IMO. One of his cites - well, two - are used to support a claim that an entire "Encyclopedia" uses them, but the cites show only two specific papers in that publication. I believe these edits are vastly overstating the case, and are contrary to consensus here. If there is no study about the use of IEC prefixes that we can cite showing significant usage, I don't believe that any such cites belong in the article. Jeh (talk) 07:34, 12 July 2014 (UTC)

If the evidence can be cited in the article (and there are plenty more where they came from), why is there a need for a separate study? Dondervogel 2 (talk) 08:11, 12 July 2014 (UTC)

:: One, do not change topic headings created by other poeple. It is part of what I wrote. Except in very rare circumstances, you are not allowed to change what other people write on article talk pages.

Two, characterizing your edits as "proposed improvements" is hardly accurate, given that you reverted my revert of your changes. You aren't "proposing", you're insisting. In violation, I might add, of WP:BRD and similar policies; you are not supposed to re-add your material after a revert, the next step is supposed to be "discuss".
Three, and this is the real point: on Wikipedia we absolutely cannot gather evidence and draw a conclusion from it! That is the very essence of original research. (See WP:OR for a refresher.) Someone else has to draw the conclusions, and then we can cite them. We always have to cite someone else's study. Jeh (talk) 08:25, 12 July 2014 (UTC)
I want to apologize for the vehemence of the preceding. I've just come from... no, that doesn't matter. I'm just wrong here and that's it. I should not have characterized your edits as pointy and one more R (going from BRD to BRRD) is hardly grounds for such a berating as I gave in point 2. Only point three remains. I do hope a good reference documenting increased use and acceptance of IEC binary prefixes can be found. Jeh (talk) 10:58, 12 July 2014 (UTC)
Frankly, I am observing a constant struggle in articles touching this subject matter of attempting--a sort of sport it seems--to find sources and support for each of the opposing fronts. And this results in reverts and harsh statements. Is this really necessary? Isn't it obvious to everyone that the binary prefixes are indeed increasingly used universally. Would we be having this discourse if it weren't so? Ten years ago one had to look hard and long to find them anywhere, the binary interpretation could almost always be relied upon in the traditional circumstances or applications. No longer today. When involved in information and telecommunications technology is easy and trivial to run across numerous usages daily without even looking and one can no longer assume anymore that a particular convention is used. Yes, the 'confusion' can be greater today than it has ever been. To deny the conversion process, and the eventual benefits, seems absurd. The train has left the station for good and this is good. The common complaint that these prefixes sound childish or what, is absurd too, because the newest metric prefixes have always sounded childish when introduced. Giga ? bytes! Peta bytes? Yotta? Hahaha. What is different about Gibi, Tebi ... ?
WP should be following reality, and the reality is clear. Leading scientists and engineers of the world have made decisions in the standards bodies to implement this, and it is happening, leading computer and software makers are implementing these standards. WP should acknowledge this reality and embrace the standards rigorously, rather than bicker about old sentiments, traditions, and personal feelings. Finding and citing sources in which the new prefixes are used is not so important, those are only instances and by themselves prove nothing. Perhaps the volume of such instances does, but citing the number of Google hits for a subject matter appears as crowd sourcing, and should not be encyclopedically permissible either. Instead editors should try to find sources that analyze the usage and draw independent conclusions. These may surely be more difficult to find, as that subject matter is rather dull, as few technical writers would find the task terribly interesting to write about, as the result of the subject matter is inevitable and the standards bodies have spoken. Kbrose (talk) 16:23, 12 July 2014 (UTC)
@Jeh: Your apology is accepted. Thank you for having the decency to offer it. My edits were made in the spirit of BRD, in search of an acceptable compromise. I don't understand why citing research publications as evidence that IEC prefixes are used by scientists is any more (or less) OR than citing IBM or Toshiba web pages as evidence they are used by industry.
@Kbrose: Basically I agree, but frankly I would put it more strongly than that. It seems to me that careful distinction between binary vs decimal prefixes is not just on the increase, but that it is by far the most popular way to disambiguate between (say) 1000^2 bytes and 1024^2 bytes. To deny that, as WP does, is to deny reality.
Dondervogel 2 (talk) 17:12, 12 July 2014 (UTC)
Usage of IEC prefixes is on the increase, but it seems to me only very very slowly. "Most popular?" I don't think so. It is far more common to see statements that e.g. "1 GB = one billion bytes"; look at every hard drive package. WP is not "denying" anything, it is just that what WP can say in its own voice is tightly constrained by e.g. WP:V. I am personally a supporter of the IEC prefixes but WP is not the place to advocate for them. Jeh (talk) 17:48, 12 July 2014 (UTC)
Advocacy is one thing, usage is another. WP should let editors use them as they please, in new articles especially, as long as the articles are self-consistent and it is clear what set of units are used. Articles that discuss subject matter of the past when equipment characterized in 'old ways' shouldn't just be arbitrarily revised. Such permission and acceptability of usage is the best solution, as it permits the transition of WP in the same way the marketplaces and technology is changing. Kbrose (talk) 19:54, 12 July 2014 (UTC)
I am not advocating for use of IEC prefixes at large. I am advocating for their use on Wikipedia though, and I do so because they are the best (and yes, the most widely used) tool to disambiguate. I take your (Jeh's) point about labelling of hard drives, but hard drive manufacturers do not need to trouble themselves with powers to 2, so they do not need binary prefixes. The benefit of the IEC prefixes is that they permit both binary and decimal use in the same article (even in the same sentence) without ambiguity. WP's insistence on using footnotes for this purpose creates ambiguity everywhere, because no editor has the time or energy to disambiguate in this "preferred" way. Dondervogel 2 (talk) 20:52, 12 July 2014 (UTC)
... but all of that is a digression. What this was initially about was my attempt to include a statement of fact, which is that IEC prefixes are used in scientific journals - a statement that I backed up with evidence. That is what we should be discussing here. Dondervogel 2 (talk) 20:57, 12 July 2014 (UTC)
Indeed, they are the best (and only) way to disambiguate. The presumed 'rarity' of the use of the binary prefixes in relation to metric, seems quite natural. In the vast majority of circumstances, the use of binary prefixes, or the binary interpretation of metric prefixes, is completely unnecessary as the metric prefixes are completely adequate, precise, and intuitive. The thrust of the conversion is and should not be increased usage of binary prefixes, but consistent and correct usage of the metric prefixes, and the restriction of the use of the binary prefixes to the few areas where they are more intuitive from a fundamental application aspect. I actually do not have a problem with citing usage cases at this point, as it seems to be the only tool available to make the point, and so I support your inclusion for now. I don't see it as a problem, when WP articles reflect ongoing processes in the field. Isn't that the truest goal of WP? Kbrose (talk) 23:19, 12 July 2014 (UTC)
  1. ^ Gluster About page Gluster About
  2. ^ Whatsabyte page WhatsAByte
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Binary_prefix/Archive_16&oldid=781200091"