Talk:Binary prefix/Archive 17

Archive 10

←

Archive 15

Archive 16

Archive 17

Archive 18

Compvis's edits to the lede

Original, long-stable version:

In computing, a binary prefix is a specifier or mnemonic that is prepended to the units of digital information, the bit and the byte, to indicate multiplication by a power of 1024.

Compvis's version:

A binary prefix is a prefix added to a unit to multiply it by a power of 2. Such a prefix is typically associated with a unit of information (bit, byte, etc.) and typically correspond to a power of 1024.

Point by point:

• Removal of "In computing": Most articles on WP that describe terms, concepts, or things related to a specific subject area begin with "In subject-area..." Compvis has given no justification for removing this.

• "is a specifier or mnemonic" vs. Compvis's "is a prefix": Using a word in its own definition is circular. Compvis makes the same mistake in his edit comment: "A binary prefix inherently implies: a prefix and a power of two." That is not helpful. The reader should not have to run off to find a definition of "prefix", any more than they should have to go find a definition of "binary". Yes, these interpretations are inherent, if you know the meanings of those words as used in this context. That not everyone knows such things is the reason encyclopedias exist.

• "prepended to" vs. Compvis's "added to": "Added" is ambiguous as to sequence; if anything, in matters of English usage, it more often refers to appending rather than prepending. "Prepended" is precise, indicating that the prefix precedes the unit. (It is odd to see such a staunch defender of the unambiguous IEC binary prefixes preferring such ambiguous wording here.) If the word "prepended" is viewed as too unfamiliar, the wording could be changed to "a specifier or mnemonic that precedes ..." or similar (although "prepended" was challenged recently on the talk page and the conclusion was to leave it). "Added" also implies an arithmetic operation, which conflicts with the word "multiplication" later in the very same sentence.

• Compvis's wording: "added to a unit to multiply it by a power of 2" is incorrect. (I have mentioned above the problem of using "added to" and "to multiply it" in the same sentence with the same referent, but that is not what I'm addressing here.) The problem is that the unit (e.g. the byte) is not what is being multiplied. It can't be; multiplication is an arithmetic operation that is defined for a pair of numbers, not for a number and a unit. What is multiplied by a power of 1024 is rather the number that precedes the prefix. e.g. in "3.5 MiB", the Mi means to multiply the 3.5 by 1024 squared.

• Compvis wants "associated with a unit of information" preceded by the word "typically". Similarly "etc." in "bit, byte, etc." Why the "etc."? What other "units of information" are there? (Yes, "octets" in French usage, but this is English Wikipedia.) With what other units, other than units of information, are binary prefixes used? The standards that define them mention only bits and bytes. It's true that Dondervogel2 has found a very few appearances of "kibihertz", meaning 1024 Hz (e.g. "32 KiHz" = 32768 Hz), and it's also true that at least one of the standards that establish the IEC prefixes mentions the policy of using them with other units. But per WP:LEDE the lede should not mention things that are not described elsewhere in the article; conversely, the lede does not have to mention or allow for everything that is in the rest of the article, only the most important points.

• Similarly, Compvis wants the phrasing "typically correspond to a power of 1024", saying in an edit comment "powers of 1024 are not inherent". But in the standards to which this article refers (and which Compvis is aggressively and pointily POV-pushing with edits like this, this, and of course this), only prefixes corresponding to powers of 1024 are mentioned. So "correspond to a power of 1024" must not be modified by the word "typically" unless examples can be found (in, of course, reliable sources) of binary prefixes that refer to powers of two other than powers of 1024. To do would be WP:OR, as it assumes a possibility that does not, at present, exist; i.e. something someone just thought up one day. Jeh (talk) 09:12, 6 April 2014 (UTC)

To Dondervogel 2: I don't see how your edits address my concerns as stated above. Anyway, per WP:BRD, since there is disagreement the original version should be restored until consensus to change it is reached. Jeh (talk) 11:16, 6 April 2014 (UTC)

Well they were intended to address some of them. Feel free to revert any or all of my edits in the spirit of WP:BRD. I'm just trying to help. Going through your points in turn:

1. I put back the "In computing", albeit in the second sentence;
2. I linked to prefix to avoid circular definition;
3. I agree "prepended" is more precise than "added", but in this case it is unnecessary, because a prefix is always prepended;
4. I specified the prefix is added to the unit symbol and not to the unit itself;
5. I don't agree that binary prefixes are not in use outside computing (and no, that is not particularly a reference to the kibi- in kibihertz, but to more common binary prefixes like semi- in semitone).
6. See #5;

Dondervogel 2 (talk) 12:33, 6 April 2014 (UTC)

Thank you Dondervogel 2 for your great comments, and I do agree. About the prefix comment, a prefix is a very simple concept, and adding "prepended" is bad style (repeating things). We could even say "use the prefix", and it would be very clear because a prefix can only be used in one way: prepended to something else. Compvis (talk) 21:26, 6 April 2014 (UTC)

On a minor point, the scope of this article should be the IEC binary prefixes and the use of metric prefixes to indicate powers of two that the IEC prefixes are intended to replace. Calling English/Latin prefixes like semi- and bi- "binary prefixes" and working them into this article, except perhaps as a see also link, is a bad idea and violates WP:NEO.--agr (talk) 17:46, 6 April 2014 (UTC)

In what sense is "semi-" not a binary prefix? Dondervogel 2 (talk) 18:14, 6 April 2014 (UTC)

It is not listed as such in the reliable sources we reference in this article (IEC, NIST, BIPM, JDEC, etc.). This has been a contentious article, but so far at least everyone has understood what it is about.--agr (talk)

It's not about "understanding what it is about", it's about "reading the title" and/or "giving the right title", so for me "semi-", "bi-", "di-", "quad-", "octo-" do fit in the article. If you want the page to be about "Binary prefixes in computing", then create a page with a title saying that! Actually, even if you talk about computing, you'll have to take into account "quadword", "octet", "semioctet", "octaword", etc. Compvis (talk) 21:26, 6 April 2014 (UTC)

So it is a binary prefix, but we can't call it that because no one else does? Sounds like Alice in Wonderland. Dondervogel 2 (talk) 20:52, 6 April 2014 (UTC)

I am not aware of any reliable sources that refer to semi-, bi-, quad- etc. as binary prefixes, and that is the standard for inclusion in Wikipedia, but if necessary we can rename the article to IEC Binary Prefixes (the older prefixes would be covered as part of the background).--agr (talk)

The prefix does indeed multiply the unit. When one writes km^2, it means (km)^2 and not k(m^2). Compvis (talk) 21:26, 6 April 2014 (UTC)

OED Says No results found for “kibibyte”. OED says kilobyte A unit of memory or data equal to 1,024 bytes. For kibibyte Dictionary says Although this new naming standard has been widely reported in 2003, it seems unlikely to catch on. For kilobyte Dictionary says 1024 bytes. Cambridge We do not have an entry for kibibyte. Then it says for kilobyte a unit of measurement of computer memory consisting of 1,024 bytes. These dictionaries are useful reliable secondary sources. It avoids the [WP:OR] problem. Fnagaton 12:59, 8 April 2014 (UTC)

PS. [1] For binary kilobytes it says This common practice. Fnagaton 13:08, 8 April 2014 (UTC)

[2] The kilobyte is often considered to be 1024 (210) bytes. It then says However, the new standard [IEC] has not entered common usage, and has been actively resisted Fnagaton 13:11, 8 April 2014 (UTC)

Is the name of the chairman irrelevant?

Thor's obituary is relevant to the question. Dondervogel 2 (talk) 12:05, 26 November 2014 (UTC)

Do we mention him in our coverage of every other unit he influenced? No. I don't think it's relevant enough to put up front in the first description of the IEC binary prefixes. If some think it should be mentioned, perhaps it could go in a less important paragraph, maybe in the same area with the criticism section. Jeh (talk) 12:19, 26 November 2014 (UTC)

When the very existence of a unit (or prefix) is attributed to the chairman's vision in the chairman's obituary, this is a clear indication that the chairmanship was instrumental in the birth of that unit or prefix, at least in the eyes of the authors of the obituary. In my opinion the removal of the name "Anders Thor" should not be justified on the grounds that it is irrelevant. If there is some other reason for removing the name, fair enough. What is that reason? Dondervogel 2 (talk) 14:09, 26 November 2014 (UTC)

The chairman's obituary would naturally mention such a thing, and would be is a good source for mentioning it in our article on Anders Thor. But I haven't seen it mentioned in any of our other RS's on this topic. So putting it as up front as it was would seem to me to be undue weight. I didn't remove the name, so I can't answer the question as to why it was removed. But since it's been removed, and since "removed" is the article's prior status, it needs to stay removed until there is consensus to put it back. As I said above I don't think it belongs exactly where it was, but could appear later as part of incidental information. I certainly don't think it's an essential point. Jeh (talk) 14:59, 26 November 2014 (UTC)

I agree with JEH; Thor does not belong exactly where he was, but might appear later as part of incidental information if it is clear he was instrumental. The obituary really doesn't indicate to me that Thor was instrumental in the birth of binary prefixes as it does so for his advocacy on the radian and steradian. Absent a RS on the genesis of binary prefixes at the IEC I think we should leave him out. Tom94022 (talk) 20:09, 26 November 2014 (UTC)

I reckon I've seen a publication describing the history of collaboration between IEC and ISO on binary prefixes, and the roles of the respective chairs, including Thor. If I find it I'll bring this up again. Dondervogel 2 (talk) 12:39, 4 January 2015 (UTC)

Consumer confusion

That section is misleading, its "hard drive capacity" is about formatted capacities, resulting in a multiple of the physical sector size for floppies, some "binary" powers of two (128, 512, 1024, 2048, 4096). Lots of standards available to construct reference lists of any desired size. For ancient hard disks it was still physical, with a BIOS layer for CHS details, later virtual (hard disks organizing their formatted capacity as they see fit pretending CHS, e.g., 512e.) Talking about formatted disk capacities with decimal prefixes for bytes is clumsy for these binary block sizes. I've added "i.e., a multiple of the sector size" to avoid the discussed decimal confusion. –Be..anyone (talk) 08:42, 4 January 2015 (UTC)

I'm sorry, I'd like to address your concerns, but I'm just finding the above mostly incomprehensible. Rwessel (talk) 10:18, 4 January 2015 (UTC)

I don't quite understand it either, but I'll address what I think is the point. First, you can't buy an unformatted hard drive (have not been able to since PATA replaced ST506, ESDI, etc., interfaces) so yes, all capacities these days (including the ones mentioned in the article) are quoted as formatted, and therefore capacities if expressed to the exact byte will be a multiple of the physical formatted sector size. (It's been a long time since I've dealt with HDs that needed "formatting," but it seems to me that most of them were quoted in terms of their typical as-formatted capacities.)

However, by the time we get to even a "500 GB" drive (quoted as 500,000,000,000, actual formatted capacity is, in one sample I have here, 500,107,862,016 bytes) the power-of-1024-ness of the 512-byte sector size is pretty much swamped. That's because the number of LBAs (976,773,168) is very much not related to a power of 1024. @Be..anyone:, do you really think it would be less clumsy to sell it as a "465.76 GiB" drive?

Even back in the CHS days, a hard drive could very well have 17 sectors per track, 6 heads, and a completely arbitrary-seeming number of cylinders (basically the number of cylinders that could be crammed in there and still give reliable performance). So there is nothing that influenced these things to be even numbers, let alone powers of 2.

I do not see how the phrase you added "avoided the discussed decimal confusion". I support Rwessel's revision. Jeh (talk) 19:31, 4 January 2015 (UTC)

Just look at the Chkdsk_screenshot.png used on CHKDSK, it shows of course KB in the sense of WP:COMPUNITS, not the SI-gibberish favoured by the industry. The article about floppy sizes and other articles up to 4Kn/512e also confirm that using decimal units for multiples of binary sector sizes never really works. –Be..anyone (talk) 21:12, 4 January 2015 (UTC)

Again, not quite sure what you're trying to say. I agree (I think) that the link to CHKDSK is confusing, since it displays the output of a much more recent version of CHKDSK than the DOS version referenced in this article. Since the size of a HD is (almost) never an exact small multiple of either a power of two or ten, neither system produces exact results, without excessive numbers of decimals. As to the "SI-gibberish", it long predates the binary prefixes, and even then the binary prefixes are only used in a subset of computing (as this article details in Binary prefix#Current practice. Rwessel (talk) 22:21, 4 January 2015 (UTC)

@Be..anyone:, I'm just not seeing what "never really works" about it. What's the problem?

In the CHKDSK picture this is apparently a partition (CHKDSK checks partitions, not entire disks) of 17,007,910,912 bytes capacity. We don't know why the owner of this disk made the partition such a size; it doesn't relate well to any power of 1024 that I can see. If "KB" there meant "1000 bytes" then the first line would say "17007910 KB total disk space". I don't know why you think this "works" any worse than "16609288 KB".

Regarding the entire hard drive, how would it "work better" to label a modern hard drive as 456.76 GB (really GiB) rather than 500 GB?

In any case, the fact is that the hard drive industry (and the network interface industry, and many others) do in fact build hardware with capacities, speeds, etc., conveniently expressed using SI prefixes. It is this article's job to document that, with references... which we have done. Arguing that they "ought to be" doing something different, such as labeling their products differently, is not WP's place. Jeh (talk) 02:16, 8 January 2015 (UTC)

Everything consumers and operating system have seen in the last two decades were multiples of powers of two, minimally 32 (for that I could produce the DOS 5 device driver surviving among other things a CHKDSK, with a notability below frozen water.) In practice only 128, (omit 256), 512 (common), 1024, 2048, and 4096 were relevant. 128 is very obscure, that leaves 512 as smallest case, and all even multiples can be expressed as KB (1024, KiB in geek speak.) Groups of sectors known as data clusters are of course also based on powers of 2 (not 10), that's why you see 4096 = 2*2*2*512 bytes on the CHKDSK image. All other numbers expressed as KB are actually multiples of 4096 = 4 KB, that is a feature of the NTFS file system on this partition. With FAT32 or other FAT file systems the begin of the partition known as Partition Boot Record could consist of multiple sectors not matching any multiple of the cluster size, but that's something consumers and operating systems rarely need to care about, as they are normally only interested in clusters. Powers of 10 never enter the picture from this POV. Of course there are checksums and similar info outside of the 512 bytes on physical disks, and limiting that overhead is the reason for 4Kn and 512e. The K in 4Kn is the binary K, not the decimal k. –Be..anyone (talk) 21:07, 9 January 2015 (UTC)

It's not accurate to say that "everything consumers have seen" has been multiples of powers of two. Disks and other storage media have always been SI-prefixed amounts (500 MB on a label meant 500,000,000 not 500 * 1024 * 1024). The only amounts which have been reliably powers-of-two has been internal memory. Everything else (data rates, data storage amounts, numbers of cpus) has generally used correct terminology on the products themselves. Some operating systems (windows in particular) have used the 2^n prefixes for describing amounts, and lawsuits have emanated from the mismatch between what was printed on boxes vs what Windows would report, but to say "everything customers have seen" is incorrect. Tarl.Neustaedter (talk) 21:26, 9 January 2015 (UTC)

500 decimal MB would be an ancient drive, when CHS still matched a physical disk geometry. What was it for this example? At some point you'd have to reach C*H*S*X=500,000,000 for an X slightly larger than 512 (the gap between one numbered 512 sector to the next sector on the same track.) In cases I've seen the "marketing size" was simply a multiple of 255*63*512 rounded up to the next decimal MB or GB, because 255*63*512 was the best virtual CHS geometry for ancient operating systems. If you ended up with 60 tracks on that disk you had 60*255*63*512=493,516,800 data bytes (ignoring details like maintenance areas reducing the available size, e.g., bad sector table.) –Be..anyone (talk) 22:34, 9 January 2015 (UTC)

(edit conflict) I'm sorry, but you're just being terribly unclear as to what you're proposing. Certainly sector sizes are almost always small powers of two. And any disk capacity will be a multiple of that. Yet the numbers are large enough that any the nature of the binary base is well beyond the few decimals of precision that people use when referring to HD sizes, so calling a HD 500GB or 456GiB is equally precise. That HDs have basically always been sold in decimal units in not really up for debate. Nor is the fact that OSs and the like have often reported disk/partition/volume sizes in binary units is also not in question. Nor is the fact that that inconsistency has caused consumer confusion. And as mentioned elsewhere, decimal units are commonly used in computing as well. So again, what do you want to do here? Please be specific. I’m not trying to be obstinate here, I just don’t understand. Rwessel (talk) 21:32, 9 January 2015 (UTC)

@Be..anyone:: Powers of 10 "enter the picture" because that is the notation used by several major segments of the industry. You can argue until WP runs out of hard drive space that they "shouldn't" use that notation, but as long as they do, this and other WP articles must acknlowledge, document, and explain that fact.

Please note that MacOS has gone to SI prefixes for describing hard drive and file sizes.

""everything consumers have seen has been multiples of powers of two"? Tell me, where is the inherent "power of 2" in a 100 Mbps Ethernet speed? Granted it's divisible by two to the eighth... but that is a side effect of its being equal to 10 to the eighth. Next, think about bus speeds like 33 MHz and multiples thereof...

Incidentally, it is not the case that "All other numbers expressed as KB are actually multiples of 4096 = 4 KB". Small files are usually reported as "1 KB" and that is quite obviously not a multiple of 4096. Also, both NTFS and FATxx keep track of the "last location written" down to the byte, so an actual file size can be e.g. 37 bytes. btw, In NTFS, such a file will likely occupy just 1 K (a file record) on the disk, regardless of cluster size. Jeh (talk) 21:55, 9 January 2015 (UTC)

In your edit to the article you wanted to add "i.e., a multiple of the sector size," to "earlier operating systems generally presented the hard disk drive capacity in decimal digits". Please understand that nobody is disputing the correctness of the resulting statement - that hard drive capacity is a multiple of the sector size. But I am just not seeing how that addition to the text is going to help the reader understand the topic of the article (binary prefixes), or even of the subsection in question (consumer confusion).

You seem to be focused instead on arguing that decimal prefixes should never be used in any computing context, because there's a power of two underneath everything. Ok, that's your opinion. But the article is not arguing for the use of decimal prefixes in any computing context, nor for the adoption of binary prefixes. It is merely documenting current practice and standards in these areas. So... What are you trying to accomplish here? Note that it is not Wikipedia's place to argue for or against anything (see WP:NPOV), so if that's what you want, that's just not going to happen. Jeh (talk) 22:59, 9 January 2015 (UTC)

The problematic statement is or was in the section "customer confusion" about disk sizes, not Ethernet. On the CHKDSK image all multiples of KB are multiples of 4, I don't need to check that, unless the image turns out to be a bizarre joke. Files can have any size, their last used cluster can be full or use only one byte. NTFS in 2001 as shown on the CHKDSK image typically uses clusters of 8 sectors (4096 bytes), IIRC that's required for some otherwise unavailable NTFS features. I don't know what a "file record" is, wikilink please, or do you simply mean the perfectly legal cluster size 2? (binary 10 ;-) –Be..anyone (talk) 23:04, 9 January 2015 (UTC)

He means an MFT entry. I'm not sure it's relevant to the discussion, but if all of the "attributes" of a file (and NTFS treats the contents as just another attribute) fit in the MFT entry, then no additional blocks need be allocated to the file. In any event, while I've never seen an NTFS volume with other than 4KB blocks and 1KB MFT entries, it's certainly architecturally possible. And cluster sizes smaller than 4KB were quite common on smaller HDs and floppies. Rwessel (talk) 23:22, 9 January 2015 (UTC)

My comment about Ethernet, bus speeds, etc, was to demonstrate the falseness of your claim that "everything consumers have seen has been multiples of powers of two".

No, I don't mean a 1K cluster. A file record in NTFS is an entry in the master file table (which is itself a file). It includes the file name, among other things. Every file starts with a 1K "file record segment". Very small files with little data and little metadata can be stored completely within the file record (this is sometimes called a "self file", though I don't think MS uses that term). See here.

Back on-topic: I still don't see what was "problematic". First, the statement "earlier operating systems generally presented the hard disk drive capacity in decimal digits" is completely true. The origin of the "consumer confusion" is that HD makers use GB and TB in their decimal sense while most OSs use the binary meaning. The HD makers do this because a) they have always done so (going back to the 350 RAMAC) and b) the drives are made in sizes conveniently expressed as multiples of powers of 1000, rather than of 1024. Example, "1 TB" is a better thing to put on the box than "931 GiB", which is the same capacity within the stated number of significant figures. I do not see how understanding of this is aided by pointing out that the HD's actual capacity, in bytes, is a multiple of the drive's comparatively minuscule sector size. Jeh (talk) 23:32, 9 January 2015 (UTC)

I've stayed out of this discussion because Jeh and Rwessel have done an excellent job of justifying the reversion. I agree with them. FWIW, I would note that most HDDs prior to embedded servo, that is prior to the 1990s, supported variable block lengths, some of which were not binary, particularly in the IBM mainframe world. I also note Ethernet's payload is variable with the very non-binary range of 46-1500 bytes and ATM's payload size is a non-binary 48 bytes. Finally, aren't there HDDs today with a 520 byte block size? I suggest it is now time to end this discussion. Tom94022 (talk) 19:49, 10 January 2015 (UTC)

Indeed. Seagate's current "Enterprise Performance 15K HDD" line supports 512, 520, 52 and 528 byte sectors for native 512 and 512e drives, and 4096, 4160, 4192 and 4224 byte sectors for 4K drives. In fairness, those extended sizes are not usually visible to the user, rather they disappear in the storage subsystem or in the bowels of the OS someplace. And you do see a capacity reduction on the drive if you select the larger sizes. Rwessel (talk) 20:41, 10 January 2015 (UTC)

ISO vs IEC

I think we need some clarity on standards. ISO and IEC are separate organizations which cooperate, but are not the same. My understanding (potentially flawed) is that ISO/IEC 80000 is a shared specification, but IEC 80000-3 is specific to the IEC. Does some standards guru have a better understanding of this? Tarl.Neustaedter (talk) 23:41, 26 May 2015 (UTC)

Standards information to add to the discussion: [ISO/IEC Guide 99:2007]. Under history, section 0..2, it has:

0.2 History of the VIM

In 1997 the Joint Committee for Guides in Metrology (JCGM), chaired by the Director of the BIPM, was formed by the seven International Organizations that had prepared the original versions of the Guide to the expression of uncertainty in measurement (GUM) and the International vocabulary of basic and general terms in metrology (VIM). The Joint Committee took on this part of the work of the ISO Technical Advisory Group 4 (TAG 4), which had developed the GUM and the VIM. The Joint Committee was originally made up of representatives from the International Bureau of Weights and Measures (BIPM), the International Electrotechnical Commission (IEC), the International Federation of Clinical Chemistry and Laboratory Medicine (IFCC), the International Organization for Standardization (ISO), the International Union of Pure and Applied Chemistry (IUPAC), the International Union of Pure and Applied Physics (IUPAP), and the International Organization of Legal Metrology (OIML). In 2005, the International Laboratory Accreditation Cooperation (ILAC) officially joined the seven founding international organizations.

The VIM (International vocabulary of Metrology), a joint specification, does have the IEC binary prefixes. Where that fits into the ISQ, I'm not entirely sure.

Tarl.Neustaedter (talk) 23:52, 26 May 2015 (UTC)

The ISQ is a subset of the IEC 80000 specification: it is defined (in that standard) to be only the quantities and their relationships. The ISQ excludes, by definition, units and their prefixes, even though these are covered by IEC 80000. This has nothing to do with the bodies involved. So a link that conflates IEC 80000-13 and the ISQ would be an easter egg. —Quondum 01:52, 27 May 2015 (UTC)

"Standards and projects under the direct responsibility of ISO/TC 12 Secretariat and its SCs" includes as one of its sixteen standards, IEC 80000-13:2008. The fact that it is published by IEC does not mean it is not an ISO standard - it is both. Tom94022 (talk) 05:31, 27 May 2015 (UTC)

JEDEC has not adopted the IEC binary prefixes

The dictionary mentions the IEC prefixes mega but the memory standards follow the terms and definitions in JEDEC Standard No. 21-C (pdf page 9) [3]

• 2.5.4 – K When describing the storage capacity of a memory device the quantity K=1024 is used.
• 2.5.5 – M When describing the storage capacity of a memory device, the quantity M=2 exp 20 or 1024 K is used.

SWTPC6800 (talk) 22:31, 13 July 2015 (UTC)

Read the comment in JEDEC_memory_standards#Unit_prefixes_for_semiconductor_storage_capacity:

The specification notes that these prefixes are included in the document only to reflect common usage. It refers to the IEEE/ASTM SI 10-1997 standard as stating, that "this practice frequently leads to confusion and is deprecated". However the JEDEC specification does not explicitly deprecate the common usage.

JEDEC is well aware that the practice is flawed and deprecated, but since they are a conglomeration of manufacturers who don't like changing anything, they continue to document existing common usage. In the context of purely semiconductor memory, the sizes are always 2^n, so they have not stumbled into the ambiguity problems seen elsewhere in the industry. Tarl.Neustaedter (talk) 00:09, 14 July 2015 (UTC)

Decimal vs binary meanings of 'terabyte'

There is a discussion of the decimal and binary meanings of 'terabyte' at Talk:Terabyte#Disputed_references. The discussion has possible implications for this page. If you wish to comment, please do so on the terabyte talk page. Dondervogel 2 (talk) 10:54, 29 July 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 8 external links on Binary prefix. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• NAdded archive https://web.archive.org/20141011045228/http://seagate.com/docs/pdf/whitepaper/mb604_4k_transition_faq.pdf to http://www.seagate.com/docs/pdf/whitepaper/mb604_4k_transition_faq.pdf
• NAdded archive https://web.archive.org/20150825101849/http://www.dell.com to http://www.dell.com/
• NAdded archive https://web.archive.org/20120216125450/http://www.gateway.com/systems/category/529598023.php to http://www.gateway.com/systems/category/529598023.php
• YAdded archive https://web.archive.org/20090112230144/http://freedos-32.sourceforge.net:80/showdoc.php?page=standards to http://freedos-32.sourceforge.net/showdoc.php?page=standards
• NAdded archive https://web.archive.org/20110607085741/http://www.gnome.org/projects/gnome-network/ to http://www.gnome.org/projects/gnome-network/
• NAdded archive https://web.archive.org/20111003184846/http://archive.netbsd.se/?ml=pkgsrc-changes&m=4873558 to http://archive.netbsd.se/?ml=pkgsrc-changes&m=4873558
• NAdded archive https://web.archive.org/20120718045228/http://www.hitachigst.com/tech/techlib.nsf/techdocs/B259B4A73296DA628625751600058A80/$file/ProductBrochureMarch2009.pdf to http://www.hitachigst.com/tech/techlib.nsf/techdocs/B259B4A73296DA628625751600058A80/$file/ProductBrochureMarch2009.pdf
• YAdded archive https://web.archive.org/20110102065839/http://www.osta.org/technology/pdf/dvdqa.pdf to http://www.osta.org/technology/pdf/dvdqa.pdf#page=20

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 15:32, 25 August 2015 (UTC)

Hi.

I just checked half of the bot contributions. I placed Y where the bot has done a good job and N when the correction is not okay. Some additional comments:

• The first source needs to be replaced with https://web.archive.org/web/20100715030704/http://www.seagate.com/docs/pdf/whitepaper/mb604_4k_transition_faq.pdf
• The second link and third link are not sources at all; they are used haphazardly. Vandalism? Or probably a poor attempt in WP:SYNTH?
• The fifth link needs to be replaced with https://web.archive.org/web/20130121122842/http://projects.gnome.org/gnome-network/index.shtml. The source itself is alive, at https://projects.gnome.org/gnome-network/index.shtml.
• The sixth link needs to be replaced with https://web.archive.org/web/20090826161925/http://archive.netbsd.se/?ml=pkgsrc-changes&m=4873558
• The seventh link is not archived properly on Wayback Machine.

Best regards, Codename Lisa (talk) 16:14, 4 March 2016 (UTC)

"Decimal" k/K prefix

I've undone 685078597 but I've mistakenly not provided a rationale. The rationale is that the table in question is not referring to decimal prefixes, but to customary (i.e. non-SI) prefixes for binary units - as opposed to the standardized "*bi" prefixes that IEC came up with. There is no question that, historically, what is now strictly speaking a kibibyte has often been abbreviated as "KB". LjL (talk) 17:41, 10 October 2015 (UTC)

You are correct and for that reason I have removed the lowercase k rather than the uppercase, with corresponding edit summary. Thanks! Jeh (talk) 18:15, 10 October 2015 (UTC)

Just to quibble, I wouldn't say never lower-case "k". I have seen people specifying "kB" and "kb" (indeed, the latter, bits, the k was almost always lower-case). But most of the individuals I can remember using the lower-case form did so because of training in the SI system and have since migrated to "kiB". And these days I almost never see kilobits specified for anything except communications speed, where SI usage is intended anyway. The days of chips with only a few thousand storage cells are behind us :-). Tarl.Neustaedter (talk) 20:33, 10 October 2015 (UTC)

I'm sure that every possible mistake has been made :) but the correct customaryy usage was with uppercase K. As the article states, in the old days of K-scale memories, the uppercase K was used to distinguish "a bigger K than k". Jeh (talk) 20:49, 10 October 2015 (UTC)

To be fair, if it was "customary", there was no "correct" or "incorrect" about it. If both usages were relatively widely employed, then both were, by definition, "customary". LjL (talk) 21:06, 10 October 2015 (UTC)

But both weren't "relatively widely employed", not to mean 1024. "K" was and remains far more common. Hence "k" should not be listed under the "customary" heading in the table in question. Jeh (talk) 21:27, 10 October 2015 (UTC)

Do we have sources stating what was and wasn't commonly employed, anyway? LjL (talk) 21:30, 10 October 2015 (UTC)

There are several examples, going back to the 1970s, of the usage of K in the article, including specification in some standards. If you have counter-examples showing use of k for 1024, please cite them. Jeh (talk) 01:24, 11 October 2015 (UTC)

Here you go:

• Ray Horak (2008). Webster's New World Telecom Dictionary. John Wiley & Sons. p. 271. ISBN 9780471774570. In computing and storage systems, a kB (kiloByte) is actually 1,024 (2^10) bytes, since the measurement is based on a base 2, or binary, number system. The term kB comes from the fact that 1,024 is nominally, or approximately, 1,000.
• Janet S. Dodd (1997). The ACS style guide: a manual for authors and editors. American Chemical Society. p. 124. ISBN 9780841234611. kB (kilobyte; actually 1024 bytes) KB (kilobyte; kB is preferred)
• Karl Erik Rosengren (2000). Communication: An Introduction. Sage Publications. p. 43. ISBN 9780803978362. A kilobyte (kB) consists of 2^10 = 1024 B
• F. J. M. Laver. Information Technology: Agent of Change. Cambridge University Press. p. 35. ISBN 0521350352. when describing the performance of IT systems the larger units 'kilobytes' (kB) [...] Strictly speaking, k means the 'binary thousand' 1024
• M. Valcárcel, M.D. Luque de Castro (1988). Automatic Methods of Analysis. Elsevier. p. 29. ISBN 0444430059. measured in kilobytes (1 kb = 1024 bytes)
• Brian K. Williams. e-Study Guide for: Using Information Technology. Although the prefix kilo- means 1000, the term kilobyte and symbol kB or KB have historically been used to refer to either 1024 (2^10) bytes or 1000 (10^3) bytes

Well, dang! There you go indeed. The "k" goes back afaiac. Also a couple of these refs can go in the "history" section (and tyvm for formatting them so well). Jeh (talk) 16:47, 11 October 2015 (UTC)

FOLDOC

Is the Free On-Line Dictionary of Computing a reliable source or a personal web site? Or maybe a wiki? It is used as a reverence for yottabyte.

Byte multiples using powers of 1000 up to yottabyte are given by the on-line computing dictionary FOLDOC (Free On-Line Dictionary of Computing).

-- SWTPC6800 (talk) 21:16, 27 October 2015 (UTC)

References

Similar to Rowlett's Dictionary of Units I guess, which is generally considered reliable. In any event, I do not recall anyone questioning the fidelity of FOLDOC when it defined the kilobyte as 1024 B. Dondervogel 2 (talk) 21:56, 27 October 2015 (UTC)

I think the correct description of FOLDOC is reliable but not authoritative. It's largely a personal project which is no longer is associated with Imperial College, where it started. It presents a view of conventional thought, without delving into boundary conditions. In particular, they don't look at the distinction between megabytes of main memory vs megabytes of disk storage versus megabytes per second of transmission speed, distinctions which drive the focus of this Wikipedia article. Tarl.Neustaedter (talk) 22:22, 27 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 9 external links on Binary prefix. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• NAdded archive http://web.archive.org/web/20070922182110/http://ieeexplore.ieee.org:80/xpl/freeabs_all.jsp?tp=&arnumber=1067329&isnumber=22917 to http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=1067329&isnumber=22917
• NAdded archive http://web.archive.org/web/20070922193418/http://ieeexplore.ieee.org:80/xpl/freeabs_all.jsp?tp=&arnumber=26589&isnumber=1030 to http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=26589&isnumber=1030
• NAdded archive http://web.archive.org/web/20070921234529/http://ieeexplore.ieee.org:80/xpl/freeabs_all.jsp?isnumber=4706&arnumber=182896&count=1 to http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4706&arnumber=182896&count=1
• NAdded archive http://web.archive.org/web/20070921235028/http://ieeexplore.ieee.org:80/xpl/freeabs_all.jsp?arnumber=4116787 to http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4116787
• YAttempted to fix sourcing for https://www.pddocs.com/FlashMemory/Documents/Vroegh%20Third%20Amended%20Complaint.pdf
• YAttempted to fix sourcing for https://www.pddocs.com/FlashMemory/faq.aspx
• YAdded archive http://web.archive.org/web/20060102132121/http://www.iec.ch:80/news_centre/release/nr2005/nr2005.htm to http://www.iec.ch/news_centre/release/nr2005/nr2005.htm
• NAdded archive http://web.archive.org/web/20081208180004/http://ieeexplore.ieee.org:80/servlet/opac?punumber=8450 to http://ieeexplore.ieee.org/servlet/opac?punumber=8450
• YAdded archive http://web.archive.org/web/20070922215418/http://standards.ieee.org:80/board/rev/305agenda.html to http://standards.ieee.org/board/rev/305agenda.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 07:44, 27 February 2016 (UTC)

Hi.

I just checked the bot contributions. I placed Y where the bot has done a good job and N when the correction is not okay.

Best regards, Codename Lisa (talk) 15:41, 4 March 2016 (UTC)

Are there standard prefixes for negative powers of 2?

Are there standard prefixes for negative powers of 2? If there are no standards, do any standards documents mention why they are not defining them? Both IEEE 1541-2002 and ISO/IEC IEC 80000-13:2008 appear to only be viewable by purchase, so it could be helpful if this wiki article helped people know whether negative-power prefixes were not standardized and why. --Bb913b8a (talk) 15:23, 8 August 2016 (UTC)

No such standards. In the computer world, we largely deal with natural numbers (integers), so we don't have much use for measurements of millionths of a byte. The cases where we do deal with fractional values tend to be real-world measurements (such as fractions of a wavelength), and those universally use proper ISO terminology. Tarl N. (discuss) 16:59, 8 August 2016 (UTC)

'tis a damn good question though. I agree with Bb913b8a that the article can be improved by stating that prefixes for negative powers are not presently defined by IEC 80000-13. I don't think we can state why that is unless we can find a source to support the explanation. Dondervogel 2 (talk) 12:13, 10 August 2016 (UTC)

I think it is a naive question at best. There should be no surprise that the topic is unaddressed by standards bodies. There simply is no need for fractional binary unit prefixes, even more so as the need for positive powers is limited to a rather narrow segment of hardware-related topics, such as digital memory capacity. In all cases in which fractional values of the bit and byte are used, such as in transmission rates, it has been customary to use metric values already. To provide standards-based legitimacy to other systems simply makes no sense. Kbrose (talk) 15:25, 10 August 2016 (UTC)

The article already lists the IEC binary prefixes that exist. It doesn't need to explicitly say that others are not defined - this is indicated by their not appearing in the table of those that are. Jeh (talk) 16:26, 10 August 2016 (UTC)

Beg to differ, with Kbrose because clock speeds are sometimes measured in kibihertz = 1 [(2^-10) s]^-1, and with Jeh because his statement is logically flawed without the presence of a statement that the list of IEC prefixes is a complete one (and I do not see such a statement). Dondervogel 2 (talk) 17:25, 10 August 2016 (UTC)

Oh, please. The presentation of the table of prefixes, referenced to IEC documents, is sufficient. To follow through with your idea, every article that includes a list of members of a class should include a statement that there are no other members of the class. That's absurd.

But if you like talking about things that are "logically flawed", try this: A claim that e.g. "the IEC has not defined any binary prefixes for fractional multiples" cannot be proven! Certainly there are none in IEC 80000-13, but how do you know there is no other IEC document that defined them? Oh, here's a list of IEC documents, it's not in any of those. Well, how do you know that that list is definitive? ... etc. Forget it. Jeh (talk) 17:47, 10 August 2016 (UTC)

Kibihertz? Cite please? I've never seen it, and I have trouble imagining that anyone could have a use for it without trying to be cute. Note that 10BaseT Ethernet clocks at 10Mb == 10,000,000 bps (frequency is 12.5 MHz with 4B5B encoding), telephony B channel clocks 64Kb == 64,000 bps. Tarl N. (discuss) 18:13, 10 August 2016 (UTC)

The KiHz is certainly not used much. My point is purely that the concept exists and that there are those who advocate its use. Dondervogel 2 (talk) 18:57, 10 August 2016 (UTC)

I think both of those qualify as "being cute". In neither case is there an actual need for a binary prefix. Those appear to be cases of a solution looking for a problem. Certainly there is no need for the inverse (duration of a cycle) in binary prefixes. In short, outside of main memory storage, there is no meaningful use of the binary prefixes, so no use for inverses. More importantly, we're an encyclopedia, we document what others write about (See WP:SECONDARY), and only in cases where they are notable. So no point in discussing inverse binary prefixes here at this time. Tarl N. (discuss) 20:37, 10 August 2016 (UTC)

Yep. Good luck finding a RS that says "there are no binary prefixes for negative powers of 1024." Since you won't find one, Don., we can't make that claim. Jeh (talk) 20:51, 10 August 2016 (UTC)

The kibiherz is not a negative binary power. As defined above kibihertz = 1 [(2^-10) s]^-1 = 2^10 s^-1, just the normal "kibi". −Woodstone (talk) 01:38, 11 August 2016 (UTC)

I agree with what is being said in the above posts but you are all missing the point so perhaps I need to explain it better. I don't have time to do that now, but I ask you all to read what I said again more carefully, read both links (and click on the link within the second like, referring back to a previous forum discussion that explains why the participants in that discussion see the need to use negative powers) and think about the question "what's wrong with explaining to the reader that IEC 80000-13:2008 does not define binary prefixes with negative powers of two?" Dondervogel 2 (talk) 06:31, 11 August 2016 (UTC)

Believe it or not, I can continue to disagree with you even though I get your point completely. I honestly don't think a few forum posters count as a source WP should pay attention to. See WP:DUE. (A few forum posters add up to DUE-ness considerably less than that of a blog post.) We might as well write paragraphs beginning with "Some people say that..." . Jeh (talk) 11:06, 11 August 2016 (UTC)

We can certainly say e.g. that "ISO/IEC 80000-13, which defines binary prefixes along with other quantities and units used in information science, does not define binary prefixes with negative powers of two." While universal negatives are often impossible to source, the absence of information in the most relevant standard can be stated. We shouldn't attempt to explain why without a reliable source. But the fact that negative powers are not defined, as contracted with the decimal SI prefixes, seems reasonable to note.--agr (talk) 11:35, 11 August 2016 (UTC)

Yes, this makes sense to me. Thank you. Dondervogel 2 (talk) 20:49, 11 August 2016 (UTC)

I added agr's suggestion but it was reverted. Dondervogel 2 (talk) 12:12, 13 August 2016 (UTC)

I appreciate the lively discussion about my question. For what it's worth, I arrived at this question when writing code that accepted input of fractional inches and stored them internally as multiples of 1/1024 of an inch so that various algorithms on the measurements could operate strictly on integers rather than floats. I was hoping that an existing standard could back me up in calling these units "mibi-inches" in the source code's comments and variable names, but I do not have access to any of the standards so I came to the binary prefix page looking for an answer. This is only a case of "being cute" as Tarl N. described, but I thought I should now mention it here because it's possible that there may be more people out there asking this question than you would first think, and like me, most of them probably do not have access to the standards documents to check if those prefixes are defined or at least explicitly ignored. There are not many SI prefixes–only 20, I think–so to me it is surprising that standards bodies would not go ahead and define all 20 respective binary prefixes after they have put in the effort to define the first 10, if only for the sake of symmetry and comprehensiveness. To me it seems a natural question to ask, "What about the other 10," but I suppose I could be especially unusual. If none of the standards documents mention the negative-power prefixes at all then there may be no need to mention them in this wiki, but if they do then you could do a great service to curious minds by citing it on the binary prefix page. Again, thank you for the consideration and I hope that someone with access to all of the relevant standards documents can definitively confirm absence of any mention of the topic within those documents. Bb913b8a (talk) 01:47, 27 August 2016 (UTC)

I agree it's a natural question to ask and I see no merit in any of the counter-arguments made on this page, confirming what we all knew already (for example that the kibihertz is rarely used and that Ki- is a prefix representing a positive power of 2), but none of them addressing your point. I can confirm that neither IEC 80000-13:2008 nor ISO 80000-1:2009 mention prefixes for negative powers of two and consider this point worthy of mention. Dondervogel 2 (talk) 22:29, 27 August 2016 (UTC)

Units and unit prefixes are defined by the standards bodies not for esthetic reasons, for symmetry or beauty, but based on practical needs and scientific requirements. They are certainly aware of their powers in the market place, that some people find 'cute' uses for their definitions, which would only confuse the issues even more. Kbrose (talk) 12:57, 28 August 2016 (UTC)

I repeat: you have not addressed the point raised by the original commenter, which is that it is not clear from the article whether binary prefixes for negative powers are defined by IEC 80000-13. You have also provided no good argument for removing the statement that they are not, which did not mention uses, cute or otherwise. Dondervogel 2 (talk) 18:26, 28 August 2016 (UTC)

If you're determined to add a negative statement, I would suggest a statement to the effect that IEC 80000-13 defines Kibi through Yobi, only, not defining any other parallel prefix, either deca/hecto or negative powers. I'd avoid speculating on why (you and I know why, but we can't document it). Tarl N. (discuss) 20:52, 28 August 2016 (UTC)

It's also not clear from the article whether binary prefixes are used by financial traders or dairy farmers. Articles only include useful and due and sourced information, not every possible statement. The table in the lead of the article says all that is necessary. Johnuniq (talk) 23:35, 28 August 2016 (UTC)

The article clearly states in its opening sentence and paragraph the purpose and use of binary prefixes. It never leaves any doubt about application, nor does it create any ambiguity or notion that it somehow isn't complete by ignoring another set of prefixes for which there is no practical use. No other article about units does that either, none speculate whether or why there aren't units for some property never measured. The next extension of granting this mentioning would be for someone to ask and request a statement, whether and why there aren't prefixes for the 10 and 100 equivalents like in the metric system. Kbrose (talk) 01:40, 29 August 2016 (UTC)

Replying to Tarl_N, Johnuniq and Kbrose

• @Tarl_N I'm not determined on anything, just pointing out that the issues raised by Bb913b8a had not been addressed by those. No one is arguing for explanation, just a statement of fact. Your proposal about how to phrase such a statement is a reasonable one.
• @Johnuniq Your comment about airy farmers is a smoke screen. The proposal is not about who does not uses the prefixes but about pointing out that ISO 80000-1 and IEC 80000-13 defining prefixes positive powers but not negative ones.
• @ Kbrose Your points are covered by my replies to Tarl N and Johnuniq.

Dondervogel 2 (talk) 21:08, 29 August 2016 (UTC)

• @Woodstone No one said that kibi was a negative power. My point was that the reciprocal of a kibihertz is 1/(1024) s^-1, so 1 KiHz could usefully be written in terms of the binary equivalent of 1 ms, if there were such a thing. Dondervogel 2 (talk) 08:30, 30 August 2016 (UTC)
• @Tarl_N re "outside of main memory storage, there is no meaningful use of the binary prefixes, so no use for inverses", I ask you to think of any counting system that works naturally in powers of two. The most common one outside of computing is counting octaves, and ten octaves above 1 Hz is 1 KiHz. Use of binary prefixes would therefore simplify communication of frequency ratios to musicians. Even for non-acousticians, the 'one-third octave band' is widely used with one of two similar but different meanings, one as one third of an octave (1/3 oct) and the other as one tenth of a decade (1/10 dec), usually without distinguishing between them (and here I am NOT talking about fringe use - this is normal practice amongst acoustical engineers, and leads to similar confusions in interpretation as between the kB and KiB). Distinguishing between these two related concepts would be facilitated by introducing binary prefixes. Dondervogel 2 (talk) 08:39, 30 August 2016 (UTC)

Where in that article is it using Kibihertz? From reading it, I only see use of powers of 10 (e.g., 31.62Hz to 15.85kHz) . That someone *could* use the prefixes, particularly in an effort to be cute, it easily imagined. But we (Wikipedia) are not in the business of proselytizing, we're in the business of documenting what is (in particular, what's published). The use of these binary prefixes is widely disliked, albeit seen as necessary given history. The general feeling I've seen in the computer industry is that the mapping of 10^3 to 2^10 was a shortcut which has backfired - and the sooner we stop doing that, the better. There isn't much enthusiasm for developing the parallel prefix system documented here.

On a separate issue, if you want to ping me, you need to include the "." at the end of my username. Tarl N. (discuss) 12:01, 30 August 2016 (UTC)

@Tarl_N In your post you suggested that there was no conceivable use of binary prefixes outside computing. I am countering that by arguing that any system in which the factor 2 places an important role (I gave examples of music and acoustical processing) is such a conceivable use. I am not pretending that it (eg kibi-) is used in those contexts - except very rarely - just that it could (usefully) be. And please don't reply asking for a source because you know I don't have one and also know I don't need one because I am not arguing for making the claim in the article. In the blog, a base 10 logarithmic scale (10^0.1) is described as a proxy for base-2 concept (2^(1/3)), and both ratios are given the same name, 'one-third octave', making it a very close parallel with 1000 B and 1024 B both being referred to as "kilobyte". Dondervogel 2 (talk) 17:23, 30 August 2016 (UTC)

Ah. Sorry, if I said "conceivable" that was an overstatement. What I probably should have said is "reasonable" or "desirable". The general feel I get in the industry when discussing the issue is that the shortcut of equating 10^3 == 2^10 was a miserable mistake which should not be repeated. The binary prefixes are actively detested - I ran into roadblocks attempting to change a message from "nnn GB" to "nnn GiB", because it didn't exactly replicate what Marketing said (note, it was a calculated value, having chopped out overhead, so not an even number). And Marketing, which couldn't care less about accuracy, wasn't going to change their vocabulary. Memory is gigabytes and everyone knows that's 1024^3. Period. We had a several very senior engineers lined up saying that the previous output was simply flat false and incorrect, and one marketeer who said "tough". So we shipped the product still saying "nnn GB" (because GiB looked too linux-ey). This kind of experience seems widely replicated across the industry, leaving a sour taste in everyone's mouth - and no desire to encourage anyone else to repeat this mistake. Tarl N. (discuss) 00:07, 31 August 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Binary prefix. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080507065825/https://www.hagley.lib.de.us:80/1980.htm to http://www.hagley.lib.de.us/1980.htm
• Corrected formatting/usage for http://www.annodex.net/cgi-bin/man/man2html?units
• Corrected formatting/usage for http://www.annodex.net/cgi-bin/man/man2html?8

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:23, 11 September 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Binary prefix. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20130810032314/http://www.sandisk.com:80/media/416788/80-11-01707_rev1_datasheet_ultracf_r1.pdf to http://www.sandisk.com/media/416788/80-11-01707_rev1_datasheet_ultracf_r1.pdf
• Added archive https://web.archive.org/web/20100331115539/http://www.seagate.com:80/docs/pdf/whitepaper/storage_solutions_guide.pdf to http://www.seagate.com/docs/pdf/whitepaper/storage_solutions_guide.pdf
• Added {{dead link}} tag to http://sdd.toshiba.com/techdocs/MKxx33GSG_MK1235GSL_r1.pdf
• Added archive https://web.archive.org/web/20130227015453/http://www.sandisk.com:80/Assets/Categories/Products/card_capacitydisclaimer.pdf to http://www.sandisk.com/Assets/Categories/Products/card_capacitydisclaimer.pdf
• Added {{dead link}} tag to ftp://ftp.software.ibm.com/common/ssi/pm/sp/n/tsd00063usen/TSD00063USEN.PDFIBM
• Added {{dead link}} tag to http://h20566.www2.hp.com/portal/site/hpsc/template.BINARYPORTLET/public/kb/docDisplay/resource.process/?spf_p.tpst=kbDocDisplay_ws_BI&spf_p.rid_kbDocDisplay=docDisplayResURL&javax.portlet.begCacheTok=com.vignette.cachetoken&spf_p.rst_kbDocDisplay=wsrp-resourceState%3DdocId%253Demr_na-c02022732-1%257CdocLocale%253D&javax.portlet.endCacheTok=com.vignette.cachetoken

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:35, 2 November 2016 (UTC)

Untitled

See also WP:COMPUNITS section in the Wikipedia Manual of Style. The talk pages for several of the unit pages (Talk:Kibibyte, Talk:Mebibit, etc) refer to this page for a historical discussion which is now archived. The vote on the "centralization" and the related discussion from 2005 can be found in Talk:Binary_prefix/Archive_2. There is also some relevant discussion in Talk:Binary_prefix/Archive_1 (2002-2005) and several related discussion threads from 2008 in Wikipedia talk:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June_2008). -- era (Talk | History) 19:46, 5 December 2008 (UTC)

"are not be used as placeholders" ...

... is not correct English. Dondervogel 2 (talk) 21:27, 9 June 2017 (UTC)

Oh. Didn't see it before. Fixed? Jeh (talk) 21:38, 9 June 2017 (UTC)

The present sentence reads "Compliance with the SI requires that the prefixes take their 1000-based meaning, and are not to be used as placeholders for other numbers, like 1024", which is better than before but still does not seem correct to me. On first reading the "are" in the second half of the sentence appears refer to refer to the "compliance" in the first, which would not make sense. On second reading you realise it's actually meant to refer to "the prefixes", but the reader does not benefit from this tortuosity. I'm no linguist but the sentence does not read well. Dondervogel 2 (talk) 23:17, 9 June 2017 (UTC)

How about "... and that they are not to be used... "? Jeh (talk) 23:25, 9 June 2017 (UTC)

Yep - that works. Dondervogel 2 (talk) 11:58, 10 June 2017 (UTC)

Not neutral information

This article does not take a neutral point of view, and actually functions as a representative of one side of the argument by ignoring and neglecting to mention any and all usage of binary structures that would counter the argument to use decimal notations.

The fact is that ALL data structures in memory and on disk habitually make use of powers of 2 because the memory locations (variables) that hold their locations have maximum values revolving around powers of two, e.g. 16, 256, and so on.

Therefore, most data structures will be organized around those sizes. This is the reason that computer memory and files on disk are referred to in binary sizes.

If there had been a section of filesystems, this would very quickly become evident.

No mention is made whatsoever of these reasons FOR using binary numbers. The original article (before my edit) said that only computer RAM and nothing else basically uses powers of 2, this is false.

It said "most other" contexts use decimal numbers. This is false.

There are only two main contexts wherein decimals numbers are used: disk capacity and data transfer rates.

Data transfer rates have historically been denoted in bits/second, and there has never been a confusion around this.

To this day, such data rates are mentioned in "Kbit/s" or "Mbit/s" and always denote powers of 1000.

This article simple gives a very skewed representation of the real state of affairs. It seems arduous effort was put into hiding away all usages of binary numbers and their reasons why (which can be found in their usages).

To understand anything about binary numbers you MUST mention data structures or file(system)-structures on disk.

You must mention WHY there are 512 and 1024 and 4096 byte sectors.

This is wholly neglected and avoided. Aye, it is silently kept back.

To lie by omission is still to lie.

92.109.167.182 (talk) 19:13, 12 June 2017 (UTC)

Thank you for raising this on talk. From the above, you seem to have two main concerns:

1. The article is (your word) "skewed"? Please provide specific examples of text that needs improvement.
2. There is a need for a section on "filesystems". Why not add such a section? That way the new section can be judged on its merits, separately from your other edits.

Have I missed anything else important? Dondervogel 2 (talk) 19:38, 12 June 2017 (UTC)

This article is not promoting the use of binary or decimal prefixes for anything. It is merely descriptive of practice. If the IP wants its objections to be considered reasonably it should recast its objections in language that is not such a blatant failure to AGF. Jeh (talk) 20:11, 12 June 2017 (UTC)

I'll add a comment that whatever the IP thinks the reason for 512, 1024 and 4096 byte disk sectors, he's probably wrong. I've worked with systems using 576 and 2080 octet blocks, too. He's mistaken that all data on disk is stored in powers of two. Generally it's stored in either a multiple or fraction of the host computer's main memory page size (which itself might not be 2^n, e.g., DEC-10 systems used 4608-bit blocks - 128 words ☓ 36-bit words), or some block size plus some overhead (e.g., early ZFS systems). I suspect the IP has a narrow view of the computer world. Tarl N. (discuss)

Let's look at a few of the IP's claims...

92.109.167.182 wrote: The fact is that ALL data structures in memory and on disk habitually make use of powers of 2 [...]

No, they don't.

Data structures are whatever size they are declared to be - possibly padded up slightly by the compiler and/or memory allocator, but there is no particular preference for larger powers of 2.

Here are a few examples from the Windows 10 kernel, 64-bit edition (you can easily verify these with the debugger):

IRP (I/O request packet) - 208 bytes, appended to which is an array of from 1 to an indeterminate number (usually 10 or fewer, but could be, say, three or seven) of "I/O stack locations" of 78 bytes each.

Executive process object (EPROCESS) - 1256 bytes. It contains a kernel process object (KPROCESS) - 352 bytes. It is associated with the Process environment block (PEB) - 896 bytes.

There's a similar trio of structures for threads. 1192, 872, and 6168 bytes, respectively.

File object (FILE_OBJECT) - 216 bytes.

Security descriptor (_SECURITY_DESCRIPTOR) - 40 bytes.

Page Frame Number array entry - 48 bytes.

etc., etc., etc.

And of course the size of an array, such as a character string, or the array of IO_STACK_LOCATIONs that follows an IRP, is whatever it is. Nobody who needs to store, say, a 83-byte string pads the allocation up to 128 bytes. Nor does the compiler.

Now, about the supposed cause. the IP claims because that this is (continuing from the quote above):

[...] because the memory locations (variables) that hold their locations have maximum values revolving around powers of two, e.g. 16, 256, and so on.

Well, since the data structure sizes are obviously not being influenced by anything to be small powers of two in the first place, this assertion of a cause for powers-of-two sizes is obviously wrong.

I must say though that I find this proposed reason to be absurd (even beyond the fact that it doesn't seem to be "working"). When I define a data structure, the fact that the maximum address for that structure is e.g. 0xFFFFFFFF (minus the size of the structure) does not at all influence me to make the structure 32 instead of 27 bytes, or 512 instead of 490, or any such thing.

Besides, almost all in-memory data structures are so small that we wouldn't usually express their sizes using any prefix at all! So they're pretty irrelevant to any talk of prefixes, binary or otherwise.

I will grant that there are exceptions. An x86 or x64 page table page occupies exactly 4096 bytes, and furthermore is page-aligned. However, I then have to point out that the number of page table pages that exist is in no way constrained or even influenced to a power of two. It is a highly dynamic number, depending primarily on the number of processes (also not a power of two, let alone 1024) and on how much virtual address space each has defined. So the total space occupied by page tables, while it will always be a multiple of 4 Ki, will only be a multiple of 1 Mi or 1 Gi by happenstance. And even then for not very long.

As for disks... as Tarl N. (talk · contribs · deleted contribs · logs · filter log · block user · block log) said, disk sector size has been all over the map, historically. The article already mentions the IBM 350 (sector size of 100 bytes) and the variable block length format (CKD) used by most drives attached to mainframes; the block size was picked by each installation. In the mid-70s I spent quite a bit of time on an HP system with disks that had a block size of 200 bytes. Yes, today, 4096 or 8192 byte memory pages are common, and that is why hard drives almost universally use 512 or 4096 byte sectors. But this was not always the case.

I must also mention that we're speaking here of the "end user" data in the sector. The actual length of the data field in each sector is considerably longer, to store the CRC data, the sector preamble, etc. Then there is the channel code... It is tempting to think that it must be easier for the drives' read/write circuitry to count to a nice binarily-even 0x200 bytes (or rather from 0 through 0x1FF) when reading or writing a block... since the end can then be noted by the counter overflowing... but since the drive actually has to read or write a somewhat larger number of bytes, and the resulting total size is not a power of two, this is a red herring. The number of bytes the drive actually reads or writes per block is just not a "convenient" binary number.

It is true that some elements of on-disk structure (file system metadata) are commonly small powers of two in their unit size. For example, one "file record" in NTFS is 1024 bytes. But that's because they conveniently fit into blocks - which are the size they are because of common machines' page size. It has nothing to do with what makes an efficient file system. But, like the page table example above, the number of file records in a file system is not influenced or "preferred" to be a power of two. In any case we never really see the "amount of space in file records" unless we're looking very very deep into the volume. This article is concerned with common uses of decimal and binary prefixes.

Similarly, also in NTFS, the security descriptor for a file may contain an arbitrary number of Access Control Entries.

Just like a hard drive can have an arbitrary number of cylinders. Which blows any "binary preference" for total hard drive capacity out the window.

As for the file itself, all modern file systems track the actual length of the file (e.g. byte offset to last byte written) down to the byte. Thus even though the file has to occupy an integral number of fixed-length sectors, its data length is not necessarily that.

To sum up so far: Both in-memory data structures and file system structures are red herrings as far as examples of binary-sized things are concerned.

The IP is invited to come up with common examples of binary-sized things that are not currently reported by the article. But not data structures or file system metadata. Those claims just don't fit the facts.

The IP is also invited to cite specific wording that is "non-neutral" and suggest alternatives.

But please do avoid the argumentative and accusing verbiage with which the thread was started.

I would like to point out that the article's current form is the result of a lot of discussion that culminated in the article being replaced by a major rewrite. The replacement happened with this diff. The discussion of that effort, which began with copying the page into a sandbox and then editing on that while discussing, is archived starting with archive 15 and continuing through the first section of archive 16. Many opponents of the IEC binary prefixes participated. They felt it was key that the article not assign undue weight to those prefixes, to argue for their use, or to otherwise violate neutrality. As part of that, there was quite an effort to make the lists of "things with sizes quoted using powers of 1024" and "things with sizes quoted using powers of 1000" exhaustive. I really doubt we missed much on either side. Nobody brought up "data structures", either in memory or on disk. Jeh (talk) 09:44, 13 June 2017 (UTC)

Later thoughts: I believe that nobody mentioned data structures because the examples given in the article are products that one might buy (RAM, hard drives, etc.). The entire binary prefix confusion in the public (tech folks are, in general, not confused) arises from the fact that Windows and some other OSs display sizes of hard drives and similar devices using customary binary prefixes while hard drive makers use decimal. It is true that Windows displays file sizes using customary binary prefixes but there is no alternative display using decimal prefixes to compare these to, nor did anybody pay money for a "file" and then be disappointed that it's not as big as they thought it was!

And in general only developers have visibility of the sizes of file system metadata structures or of in-memory objects.

And... dare I say it? Wikipedia is written for a general audience. Jeh (talk) 02:14, 15 June 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 10 external links on Binary prefix. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.sandisk.com/media/416788/80-11-01707_rev1_datasheet_ultracf_r1.pdf
• Corrected formatting/usage for http://www.sandisk.com/Assets/Categories/Products/sd_capacitydisclaimer.pdf
• Added archive https://web.archive.org/web/20070922234210/http://www.wdc.com/settlement/docs/longform.htm to http://www.wdc.com/settlement/docs/longform.htm
• Added archive https://web.archive.org/web/20100507132711/http://www.wdc.com/settlement/docs/longform.htm to http://www.wdc.com/settlement/docs/longform.htm
• Added archive https://web.archive.org/web/20160305014709/http://www-cs-staff.stanford.edu/~knuth/fasc1.ps.gz to http://www-cs-staff.stanford.edu/~knuth/fasc1.ps.gz
• Added archive https://web.archive.org/web/20130613121942/http://www.chester.iucr.org/iucr-top/cexec/rep96/idcns.htm to http://www.chester.iucr.org/iucr-top/cexec/rep96/idcns.htm
• Added {{dead link}} tag to http://ej.iop.org/links/rDo33k%2CNb/lrUHtuYE3BGiff6cav5vpA/me0112.pdf
• Corrected formatting/usage for http://www.seagate.com/docs/pdf/whitepaper/storage_solutions_guide.pdf
• Corrected formatting/usage for http://sdd.toshiba.com/techdocs/MKxx33GSG_MK1235GSL_r1.pdf
• Added archive https://web.archive.org/web/20130613220438/http://www.wdc.com/en/library/2579-001028.pdf to http://www.wdc.com/en/library/2579-001028.pdf
• Corrected formatting/usage for http://www.sandisk.com/Assets/Categories/Products/card_capacitydisclaimer.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:43, 20 July 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Binary prefix. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070902080558/http://www.wdc.com/en/products/products.asp?driveid=301 to http://www.wdc.com/en/products/Products.asp?DriveID=301
• Added archive https://web.archive.org/web/20071016171124/http://wdc.com/settlement/docs/complaint.htm to http://www.wdc.com/settlement/docs/complaint.htm
• Added archive https://web.archive.org/web/20161007222128/https://jdebp.eu/FGA/1mb44-is-not-a-standard-floppy-disc-size.html to https://jdebp.eu./FGA/1mb44-is-not-a-standard-floppy-disc-size.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 06:24, 26 July 2017 (UTC)

ST-412 is BINARY in size

Currently, the article says:

"One of the earliest hard disk drives in personal computing history, the Seagate ST-412, was specified as "Formatted: 10.0 Megabytes".[23] More precisely, the drive contains 4 heads or active surfaces (tracks per cylinder), 306 cylinders, and when formatted with a sector size of 256 bytes and 32 sectors/track results in a capacity of 10 027 008 bytes. This drive was one of several types installed into the IBM PC/XT[24] and extensively advertised and reported as a "10 MB" (formatted) hard disk drive"

This is wrong. The sector size in an IBM PC/XT was fixed at 512 bytes, and the drive is specified to have 17 sectors/track. This results in 10653696 bytes, or actually slightly more than even a binary 10MB (which would be 10485760 bytes). From Seagate's datasheet itself: ftp://ftp.seagate.com/techsuppt/mfm/st412.txt — Preceding unsigned comment added by 24.85.213.54 (talk) 04:12, 17 September 2017 (UTC)

And yet... http://www.vintage-computer.com/ibmpcxt.shtml Jeh (talk) 10:49, 24 September 2017 (UTC)

The only relevance of that page is the screenshot showing 10592256 bytes usable, which is still more than 10485760 (and represents the raw block capacity less MBR, cylinder alignment, boot sector, and filesystem overhead.) 24.85.213.54 (talk) 02:35, 25 September 2017 (UTC)

The system available capacity of a dumb drive like the ST506/412 varies with the controller - the April 1982 Seagate specification uses 256 bytes per sector and 32 sectors per track as the example format to specifify these drives and market them as a 10.0 MB drives (unformatted they are 12.76 MB drives). IBM with the WD controller used 512 bytes per sector but that is not Seagate's specification. So the article is correct. Tom94022 (talk) 00:43, 26 September 2017 (UTC)

Using IEC prefixes

To avoid any confusion, it is better that all Wikipedia editors use IEC binary prefixes (Ki, Mi etc.) for memory devices like RAMs and ROMs. -Polytope4D talk 08:18, 24 September 2017 (UTC)

At present, use of IEC prefixes is deprecated by WP:COMPUNITS. If you feel strongly, the place to make this recommendation is the mosnum talk page. Dondervogel 2 (talk) 09:04, 24 September 2017 (UTC)

I concur with Dondervogel2. Please note that I personally completely support the IEC prefixes; I think they're a good solution to a real problem. But... there have been two major disputes on WP over whether or not the IEC binary prefixes should be routinely used in Wikipedia articles. The consensus was (and as far as I can tell, remains) that since the IEC prefixes are not familiar to most readers, and are not used by most of our references, we should not use them except in very limited, specified circumstances. And despite that I like the IEC prefixes, I must agree that these are valid points; we're not here to lead the way in adoption of new standards. The resulting guidelines are inscribed at WP:COMPUNITS. If you want to open this question up to another discussion, that is of course your right. But I don't see that the circumstances have changed much (IEC prefixes are still unfamiliar to most readers and are still not used by most of our references). And in lieu of that any such proposal is not going to receive a warm welcome from those who remember the previous discussions, which got quite heated. Thank you for your consideration, however it goes. Jeh (talk) 10:36, 24 September 2017 (UTC)

Yes. Perhaps I should have written "If (and only if) you feel strongly ...", for you would need a string stomach. The situation boils down to a choice between familiar ambiguous units and unfamiliar unambiguous ones. Some prefer familiar units while others prefer unambiguous ones, and both camps are deeply entrenched. Dondervogel 2 (talk) 13:44, 24 September 2017 (UTC)

@Polytope4d and Jeh: Perhaps it is time to reopen the discussion. As I recall the last so-called consensus was declared in spite of a number of editors in oposition. Things have changed and possibly the minds of some of the editors once opposed? Tom94022 (talk) 17:14, 24 September 2017 (UTC)

I agree things have changed since 2008. At that time constructive debate was almost impossible due to the antics of one loud-mouthed editor and his band of sock-puppets. The climate is different now that editor and his socks are gone. Perhaps it's worth a try. Dondervogel 2 (talk) 20:47, 24 September 2017 (UTC)

I am unenthusiastic. WP P&G haven't changed, and those are the real determining factors here, not number of proponents. About the only change I notice in the real world is that MacOS switched to SI prefixes used in the SI sense for disc and file sizes and capacities. That is a step in the right direction, but it isn't using the IEC prefixes for e.g. RAM sizes - it doesn't make the IEC prefixes any more known to the public. Personally I think my time on WP is better spent in other ways. Jeh (talk) 22:45, 24 September 2017 (UTC)

I am not proposing the wholesale use of IEC prefixes, as in GiB for RAM, but that the outright prohibition be removed so as to allow the use of unambiguous prefixes where confusion reigns as in FDD capacities. Specfically I would revise the paragraph of WP:COMPUNITS beginning

"The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except: ..."

and its 16 to allow use where appropriate for clarity rather than preclude use in all but a few rare exceptions. Who knows how difficult this may be given the passage of time and certain editors. Tom94022 (talk) 01:24, 25 September 2017 (UTC)

You are wasting your time. This is one of those situations where the consensus is clear and you just have to accept it. See WP:1AM. --Guy Macon (talk) 02:15, 25 September 2017 (UTC)

You are mistaken. An essential ingredient to reach consensus is civility. In the mosnum discussion on this subject, civility was notable only by its absence Dondervogel 2 (talk) 13:30, 25 September 2017 (UTC)

In this talk page the count is 3 in favor of a review, 1 neutral and 1 against; there have been other editors proposing usage of IEC prefixes - so it is not so clear who is WP:1AM. As best I can recall the "many" of the so-called consensus was perhaps 8. Tom94022 (talk) 16:05, 25 September 2017 (UTC)

If you think you have a consensus, go to Wikipedia talk:Manual of Style/Dates and numbers and make a proposal. This isn't the right place tp propose changine the existing WP:COMPUNITS guideline. --Guy Macon (talk) 17:00, 25 September 2017 (UTC)

I took a look at the Apple, Dell and HP websites and they all advertise RAM size as GB. The IEC binary prefixes do not seem to have caught on with the general public, which is our audience. Can you give an example of an article where using the binary prefixes would result in a meaningful improvement that could not be better achieved by an explanatory sentence or footnote?--agr (talk) 16:54, 25 September 2017 (UTC)

And since they are Windows oriented they footnote HDD sizes. The Floppy disk article is one such, particularly the the performance and capacity section. I am pretty knowledgeable on the subject but have a hard time with this table whereas unmbiguous units would make it far more understandable even if some users had to lookup Kib. The same thing probably applies in optical and SSD articles. If the useage is consistant as in RAM then there is no ambiguity but even that maybe changing as in Apple. If Windows goes conventional then who knows, but right now IMO the deprecation causes more problems than it solves. Tom94022 (talk) 18:40, 25 September 2017 (UTC)

In my opinion, the deprecation solves more problems than it causes. But I would also note that my opinion doesn't matter, and neither does the opinion of anyone else posting on this page. This is the wrong place. Wikipedia talk:Manual of Style/Dates and numbers is the right place. --Guy Macon (talk) 20:02, 25 September 2017 (UTC)

Yes, we all agree this is the wrong place. Any objections to moving this discussion wholesale to mosnum? Dondervogel 2 (talk) 21:22, 25 September 2017 (UTC)

That depends on what "moving" means. Please do not copy/paste anything because that leads to unnecessary confusion with a pointless wall-of-text at the other page. Anyone is welcome to go to the appropriate guideline and start a discussion on changing it. Then they could post here with a link. The discussion would be a waste of time because KB, MB and so on are still common usage. Johnuniq (talk) 22:54, 25 September 2017 (UTC)

I suggest we formulate a proposed change to paragraph of WP:COMPUNITS beginning "The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except: ..." and its 16 here and then take it there for further discussion. Just calling for a discussion is liable to be less productive. Tom94022 (talk) 00:47, 26 September 2017 (UTC)

Formulate it on your talk page. It does not belong here. --Guy Macon (talk) 01:48, 26 September 2017 (UTC)

Well, it isn't about improving this article. So even though such discussion would be related to the subject here, Guy is correct. If you (Tom, Dond2, etc.) want to have any hope of changes in your direction you're going to have to make it apparent that you're not even coming close to violating P&G. Jeh (talk) 02:30, 26 September 2017 (UTC)

Forgive my ignorance but I have no idea what P&G stands for. From the begionning I have stated this is the wrong venue. The only thing stopping me transferring this discussion to where it belongs is Johnuniq's objection. Dondervogel 2 (talk) 10:13, 26 September 2017 (UTC)

This is the talk page of an article and should be used to discuss improvements to the article. Use the MOS talk page to discuss a proposal to change the MOS. If starting that discussion, it would be a very good idea to not copy/paste anything because that would be pointless and would only generate confusion. Just start a discussion and include a link to here, for example [[Talk:Binary prefix#Using IEC prefixes]]. P&G = WP:PAG = policies and guidelines. I assume the intended guideline was WP:TPG which says what has been mentioned a few times now, namely that this page is not the place to discuss changing the MOS. Johnuniq (talk) 10:25, 26 September 2017 (UTC)

Another reason to not do copy/paste (i.e. "move" the discussion) is that it will not show the correct page history at the target page.

There has been no significant discussion here, so there's nothing of substance that really needs to be "moved". Just start the discussion somewhere else. If you want to formulate a proposed change before actually talking about it at the MOS talk page, do that at one of your talk pages. Or maybe there's a Wikiproject that would be willing to host it. Jeh (talk) 10:48, 26 September 2017 (UTC)

Before we start another discussion elsewhere, I would like to point that WP:COMPUNITS already has an exception allowing the IEC prefixes "in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical." That could include Floppy disk, for example, assuming there is a verifiable mix of units in use there. Any new discussion should include a rationale for a broader exemption, with example articles.--agr (talk) 11:00, 26 September 2017 (UTC)

The case against deprecation is on Thundrbird 2's user page. Dondervogel 2 (talk) 11:05, 26 September 2017 (UTC)

Again, I would like to see examples of articles that would be materially improved by employing IEC prefixes yet are not covered by the exemption I just quoted.--agr (talk) 11:33, 26 September 2017 (UTC)

Arnold - Groan. There should be no "before we start another discussion elsewhere". Let's have the next comment be "please continue this discussion at .... ". Jeh (talk) 13:40, 26 September 2017 (UTC)

Arnold, I agree with your interpretation of the rules with regard to the FDD article, but it was shouted down in 2008. As far as moving this discussion I see no reason to do so until its clear where to go - perhaps the FDD article? Tom94022 (talk) 16:33, 26 September 2017 (UTC)

That seems to me to be defensible. Go for it. Just leave a pointer here. Jeh (talk) 21:31, 26 September 2017 (UTC)

I have now openned a new discussion at Talk:Floppy_disk#Use_unambiguous_prefixes.3F. FWIW I expect another shout down along the lines that the MOS exception does not apply to that article. Tom94022 (talk) 17:01, 27 September 2017 (UTC)

What's the connection with 'octave'?

The point is that an identical confusion exists on frequency scales as with computer memory:

• Both work in factors of two;
• In both cases use is made of the approximation 2^10 =~ 1000;
• In both cases confusion results from that use.

Is one-third octave is a better article to point to than octave? Dondervogel 2 (talk) 07:47, 23 November 2017 (UTC)

I do not see where octave notation uses the approximation 2^10 ~= 1000. And even if it did, none of that has anything to do with binary prefixes. Nobody uses binary prefixes instead of octave designators (A0, A1, A2, etc.). Jeh (talk) 09:56, 23 November 2017 (UTC)

I'm struggling with understanding "I do not see where octave notation uses the approximation 2^10 ~= 1000". By far the most widespread definition of "one-third octave" is one tenth of a decade, which is precisely this confusion. Where do you *not* see that? Dondervogel 2 (talk) 13:07, 23 November 2017 (UTC)

I too find this remark puzzling. What is a "third-octave"? Yes there is an interval "third" (on natural instruments 5/4) that happens to fit about three times in an octave, so indeed that comes to 1000/1024. But much more importantly the "fifth" (naturally 3/2, not near a fifth of an octave) fits about 12 times in seven octaves leading to 3¹²/2¹⁹, or 531441/524288. Both discrepancies play a role in tuning. I don' t really see the connection to binary prefixes. −Woodstone (talk) 16:46, 23 November 2017 (UTC)

I too wondered about adding a link to Octave in the See Also section but after reading the above now see the relevance which suggests some of the above could be in the body of the article and not just as a See Also link. Problem is the article is very data and digital specific starting with the lede so there is no obvious place to add something. Perhaps in Section 2 or Section 2.2 with a single sentance about octave and third octave having a similar relationship leading to similar confusion. Tom94022 (talk) 18:05, 23 November 2017 (UTC)

As is common in many parts of life, different specialties use different terminology. What is a common term for one group of specialists is a rarely-used term (sometimes with a subtle difference in meaning) for another group.

In this case "one third octave" is a very commonly used term in the areas of sound reinforcement, public address systems, and recording studios. See Equalization (audio)#Graphic equalizer. The preferred frequencies are defined by ISO 266:1997.[4] Here are some typical one third octace equalizers:[5][6][7] and here are some instructions for using one:[8]

Matlab can generate a graphic equalizer: https://www.mathworks.com/help/audio/examples/graphic-equalization.html?requestedDomain=www.mathworks.com

The ISO frequencies are:

 01 - 20 Hz
 02 - 25 Hz
 03 - 31.5 Hz
 04 - 40 Hz
 05 - 50 Hz
 06 - 63 Hz
 07 - 80 Hz
 08 - 100 Hz
 09 - 125 Hz
 10 - 160 Hz
 11 - 200 Hz
 12 - 250 Hz
 13 - 315 Hz
 14 - 400 Hz
 15 - 500 Hz
 16 - 630 Hz
 17 - 800 Hz
 18 - 1000 Hz
 19 - 1250 Hz
 20 - 1600 Hz
 21 - 2000 Hz
 22 - 2500 Hz
 23 - 3150 Hz
 24 - 4000 Hz
 25 - 5000 Hz
 26 - 6300 Hz
 27 - 8000 Hz
 28 - 10000 Hz
 29 - 12500 Hz
 30 - 16000 Hz
 31 - 20000 Hz

The ISO standard does some rounding, for example using 80 Hz instead of the mathematically correct 79.5 Hz.

The ISO scale is base 10, not base 2. Each step is one decibel of frequency (10 steps = ten times larger).

One decibel of frequency is very close to one third of an octave.[9][10] Thus the scale approximately doubles every 3 steps.[11]

The ISO rounding makes some of the approximate doublings into exact doublings. Three steps up from 400 Hz is 800 Hz, three steps up from 500 Hz is 1000 Hz. However, three steps up from 630 Hz is 1250 Hz (not 1260 Hz), and three steps up from 1600 Hz is 3150 Hz (not 3200 Hz).

So, what does any of this have to do with binary prefixes? Absolutely nothing, as far as I can tell. The one third octave frequencies are based on powers of ten, not powers of two. The ISO rounding just makes them look like powers of 2 in some cases. --Guy Macon (talk) 18:12, 23 November 2017 (UTC)

It's clear I did not explain myself well the first time so let me try again.

• If you start at 1 kHz and count up 10 octaves you expect to get 1024 kHz (= 1000 KiHz)
• Similarly, if you count down 10 octaves from 1 kHz you expect to get 1/1024 kHz
• and if you define an octave as a factor of 2 this is exactly what happens.
• If you then define a one-third octave as a third of an octave (2^1/3 in frequency), you can then count 30 one-third octaves up or down and you get the same result.
• So far so good, but the term "one-third octave" is not actually defined this way by standards bodies like ANSI and IEC. These standards instead define a "one third octave" as 10^0.3 (and not 2^1/3 as you might expect), such that 30 of them give precisely a factor of 1000. The confusion between 30 times 1/3 octave (1024) and 30 one-third octaves (1000) is precisely the confusion that exists with the two definitions of kilobyte.

That's the connection. Dondervogel 2 (talk) 18:44, 23 November 2017 (UTC)

References

You explained yourself just fine. The problem is that what you wish the definition of "one-third octave" is (a third of an octave) does not match what the actual definition of "one-third octave" is (a decibel). Despite the name, the term "one-third octave" is not defined as a third of an octave. It is defined as a decibel of frequency. It is called "one-third octave" because a decibel of frequency is very close to a third of an octave -- far closer than the precision at which the center frequency of analog filters can be set. (by the time digital EQs came around, the one third octave graphic equalizer had already been named.) No audio engineer cares about the difference between the two definitions. They are close enough to be interchangeable in real life. There are many other things that have the wrong names. A surplus of electrons is called "negative". You cannot "dial" a phone anymore. All though the US there are places called "Telegraph hill" that were named long before Morse invented his electric telegraph. The Hundred Years War lasted 116 years. New Mexico was named during the 1500s, but Mexico (formerly Nueva Espana - New Spain) came into being hundreds of years later in 1821. Catgut comes from sheep and horses. The Battle of Bunker Hill was fought on Breed's Hill. We put up with many things that are named incorrectly and "one-third octave" is one of them. --Guy Macon (talk) 19:23, 23 November 2017 (UTC)

Maybe there is room for an "umbrella" article about scales of quantities that are based on logarithmic "steps". Jeh (talk) 21:11, 23 November 2017 (UTC)

You are both missing the point. It's not about whether the scale is a logarithmic or linear, nor whether the names are to my or to anyone else's liking. It's simply that for both the kilobyte and the one-third octave the number 2^10 is approximated as 10^3 - no more, but also no less. I don't know how else to say it. That simple fact seems to me sufficient to merit a 'See also' but I am clearly in the minority, and therefore will pursue it no longer. Dondervogel 2 (talk) 23:01, 23 November 2017 (UTC)

Actually it is Macon who is clearly in the minority and confusing things with lots of irrelevant material. You and I think it should be in the article and JEH thinks maybe the topic deserves a second article. So if u want to propose some text in the article why not go ahead. I don't think just a link in See Also is enough, but maybe just some explanation on the see also. Something like:

See Also

Octave The confusion between 30 times 1/3 octave (1024) and 30 one-third octaves (1000) is precisely the confusion that exists with the two definitions of kilobyte.

would be OK by me and perhaps even JEH. Tom94022 (talk) 05:20, 24 November 2017 (UTC)

Still, this article is about "binary prefix", not about approximating powers of 10 by powers of 2. In the circumstance depicted I do not see any prefixes appear. And talking about misnomers (above), the worst of all is perhaps the "octave", which is named after a rather peculiar uneven division of a doubled frequency. −Woodstone (talk) 15:40, 24 November 2017 (UTC)

...and the claim "The confusion between 30 times 1/3 octave (1024) and 30 one-third octaves (1000) is precisely the confusion that exists with the two definitions of kilobyte" is patently false, because, unlike the case with "kilo", nobody anywhere defines "one-third octave" as anything other than a decibel of frequency. This is an easily-verifiable fact.

I am sorry thatTom94022 thinks that an explanation of how one-third octave is used in the only industry that uses it is "confusing things with lots of irrelevant material", but I cannot fix whatever it is that is making him ineducable on the topic. --Guy Macon (talk) 00:02, 25 November 2017 (UTC)

Power of two

As an introduction for the article it is much more useful to first state that the prefixes are powers of two, which is intuitive for people to make the correlation to BINARY, even if they struggle to grasp powers of 1024. The next paragraph of the lead even goes into this detail. The sentence states that binary prefixes represent *a* power of two, not *every* power of two. This is no different than in the decimal system of prefixes. Kbrose (talk) 22:37, 11 March 2019 (UTC)

I'd agree. I think the wikilink to Powers of two is a better choice than to Exponentation. Tarl N. (discuss) 22:55, 11 March 2019 (UTC)

I prefer technical precision to "easier to understand". Please note the first columns of each of the two parts of the table that's shown in the lede. The focus is clearly on powers of 1024. Jeh (talk) 00:12, 12 March 2019 (UTC)

I agree with Jeh. In an encyclopedia giving the reader the correct answer is more important than giving the reader an east to understand answer. Anybody who can't grasp the concept of powers of 1024 won't be able to grasp the concept of a binary prefix anyway. --Guy Macon (talk) 00:57, 12 March 2019 (UTC)

This has nothing to do with precision but with teaching. Precision is not sacrificed at all, especially as it drills further down in the next section and with table. It is pedagogical to drill down, not up. Kbrose (talk) 01:03, 12 March 2019 (UTC)

We should not teach what is not true. Or what is misleading. The current opening sentence is misleading. Your point about starting with "powers of 2" and then narrowing it would perhaps be more defensible if we were writing a tutorial for those with perhaps a sixth-grade level of prior knowledge in arithmetic. But that's not our target audience and we don't have to start at such a beginner level, only to contradict ourselves in the same graf. The link to the term "binary prefix" is still established. Jeh (talk) 03:13, 12 March 2019 (UTC)

I agree with Jeh that 1024 is easier to understand and more accurate. I note that the Metric prefix article uses both "power of 1000" and "power of 1024" rather than either "power of 10" or "power of 2" so I would add consistency as a third reason for "power of 1024." Tom94022 (talk) 05:25, 12 March 2019 (UTC)

I think people are elevating pedantry to sainthood here. The prefixes under discussion cover a finite list of powers of 2, which all happen to be powers of 1024. Because they correspond to powers of 10 which all happen to be powers of 1000. We can't just skip discussing where the number 2 comes in because of the word "binary" in the title of the relevant standards.

Whether using 2 or 1024 as a base, it's necessary to explain the limits on the exponent: lower (1024¹ = 2¹⁰ ≈ 1000¹ = 10³), upper (1024⁸ = 2⁸⁰ ≈ 1000⁸ = 10²⁴), and modulo. And the corresponding fact that only certain metric unit prefixes have corresponding binary equivalents. (There's no hibyte or μibyte.)

A power of 1024 is a power of 2 in the same way that an even integer is an integer. Talking about arithmetic background, there are two categories of people:

1. Those used to powers of two, for whom this is natural and not confusing at all. I fall into this category and didn't notice the switch until I paid particular attention, in the same way that I rarely notice whether some information I'm looking at is written in upper-case or lower-case letters.
2. Those not used to powers of two, who could stand a little reminder of what powers of 1024 have to do with the word "binary".

I think the current lead's first two paragraphs do this quite well. 209.209.238.189 (talk) 02:34, 23 March 2019 (UTC)

!votes

By my count:

On the question of linking to exponentiation vs. linking to powers of two in the lead, it seems to be 3 to 3 3 to 2 for exponention (Tom94022, Jeh and Guy Macon vs. 209.209.238.189 Kbrose and Tarl N.)

On the question of power of 1024 vs. Power of 2 in the lead it seems to be 3 to 2 for 1024. (Tom94022, Jeh and Guy Macon vs. Kbrose and 209.209.238.189)

On the question of "As this is a power of 1024, and 1024 is a power of two this usage is referred to as a binary measurement." in the body, I don't see any disagreement. Please correct me if I am wrong.

Per WP:STATUSQUO, I restored the stable 15:37, 11 March 2019‎ (UTC) version from before edit war, but that's only for avoiding edit warring while we discuss this.

Did I get anyone's position wrong?

Does anybody want to switch positions?

Does anyone who has not commented want to weigh in here?

Is anyone willing to go along with some other position?

If we can't come to an agreement, this will most likely need an RfC. --Guy Macon (talk) 03:48, 23 March 2019 (UTC)

Move me to neutral. It's certainly not worth fighting over. Tarl N. (discuss) 05:07, 23 March 2019 (UTC)

My preference is to primarily speak of powers of two (resp 10), in accordance with the names. That not all powers are given a specific symbol is of secondary importance. The way it is currently stated in the article is quite adequate.−Woodstone (talk) 08:43, 23 March 2019 (UTC)

I'm in the neutral camp, with Tarl_N. Our efforts are better spent arguing against Luddism. Dondervogel 2 (talk) 09:09, 23 March 2019 (UTC)

Incorrect statement about ethernet

"a 1 Gbit/s (gigabit per second) Ethernet connection transfers data at 1000000000 bit/s."

This is a lousy example because it's not actually a data rate - it's a "nominal" physical layer usable speed including some overhead and excluding other.

1. The actual data rate due to packetization and overhead is far less and variable so the statement is untrue a the users level

2. The actual baud rate of a 1000baseT link is 125 mbaud with multiple signalling levels over 4 four lanes (and the other variants are all 'Gbit ethernet' but again differently encoded). So the statement is also meaningless at the physical level

10Gbit is even more confusing and can be 12.5Gbit 8)

Is there not something simpler and more concrete that could be used as an example 80.2.249.197 (talk) 17:05, 30 December 2019 (UTC)

I suggest just using the phrase "nominal speed" in the sentence should be sufficient; the point being it is not a nominal speed of 1073741824? Tom94022 (talk) 17:37, 30 December 2019 (UTC)

T for TeBi

In a section about Other standards bodies and organizations the article claims, that JEDEC supported K, M, G, and T with a non-free reference. If that is true please add T to Template:Bit and byte prefixes. Otherwise remove the T in this section for consistency, also see Template talk:Bit and byte prefixes 2009…2015. –84.46.53.250 (talk) 16:05, 2 January 2020 (UTC)

Fixed. Thank you for pointing out the inconsistency. Dondervogel 2 (talk) 13:45, 29 February 2020 (UTC)

Introduction to the Article does not give a simple definition

The first paragraph defines bit and byte, which is good. The second paragraph, "The computer industry has historically..." does not give a definition of Ki, Mi, Gi, etc. Instead it gives the history that isn't the definition of these quantities, per IEC IEC 80000-13. The intro needs to be re-organized to start with a clear and concise definition of what is being discussed. The history lesson does not achieve that end. Pwfen (talk) 01:22, 14 February 2022 (UTC)

Good point; tried to fix it. Tom94022 (talk) 07:28, 14 February 2022 (UTC)

table that was formerly in lede, preserved here

IEC Binary Prefixes
Prefix Symbol Multiplier kibi Ki 210 1024 mebi Mi 220 10242 gibi Gi 230 10243 tebi Ti 240 10244 pebi Pi 250 10245 exbi Ei 260 10246 zebi Zi 270 10247 yobi Yi 280 10248

Based on this table we have a clue about binary prefix on meters:

• 1024 meters is 1 KiM (not lower "kim")
• 1024² meters is 1 MiM
• ...

Krauss (talk) 10:08, 25 July 2022 (UTC)

Add a section about IEC prefix in other units

Not popular, but no problem (!). As in the example above, 1024 meters is 1 KiM; 1024² meters is 1 MiM, etc. A binary prefix is for it. Krauss (talk) 10:16, 25 July 2022 (UTC)