text:
Talk:Byte

Wiki Education Foundation-supported course assignment
This article was the subject of a Wiki Education Foundation-supported course assignment, between 14 January 2020 and 15 May 2020. Further details are available on the course page. Student editor(s): Nakanob.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 16:28, 16 January 2022 (UTC)

Decibel is not an SI unit
In the section titled "Unit Symbol" there is an entire paragraph explaining that the symbol 'B' is the SI unit of the bel. This is not true.

Although often used with SI prefixes - e.g. decibel(dB) - the bel itself is not, nor can it ever be an SI unit itself, it is a dimensionless ratio. Because it is dimensionless, it is often necessary to indicate how it was calculated by adding an appropriate suffix (e.g. dBi, dBm) in order to make meaningful comparisons.

http://physics.nist.gov/cuu/Units/outside.html

JNBBoytjie (talk) 10:38, 13 April 2016 (UTC)

 * Thank you. Done. Kbrose (talk) 14:17, 13 April 2016 (UTC)

C 'char' type
AFAICS 'unsigned char' is right. Based on the C Standard, (signed) char need only hold values between -127 and 127 inclusive, in other words only 255 distinct values. If you want a guarantee of 256 distinct values you need unsigned char. Ewx (talk) 08:04, 25 August 2016 (UTC)

 * It is not necessary to specify unsigned char. The C standard already mandates that a value stored in a char is guaranteed to be non-negative. A signed char is an integer type and has to be declared, not an unsigned char. Kbrose (talk) 11:50, 25 August 2016 (UTC)
 * I have two problems with this concept....:
 * What happened to -128? (0x80)
 * What version of the C standard? The original compiler I was using in the 80s (Turbo-C 1.0, 1.5 and 2.0) had by default 'char' being signed. But you could configure the compiler to make it unsigned by default. That was obviously before the current C standard... Dhrm77 (talk) 13:51, 25 August 2016 (UTC)
 * Formally speaking there is only one C standard, ISO/IEC 9899:2011; the rest have been withdrawn, as you can see on the ISO website. That doesn't stop people referring to older revisions (or drafts, given the excessive cost of the current version), or implementing them, though.  In this case however, the question is irrelevant: all versions of the C standard permit char to be either a signed or an unsigned type.  As for 'what happened to -128', the point is to permit a variety of representations of signed types; there's more to the world than x86 and two's complement. Ewx (talk) 08:05, 26 August 2016 (UTC)

 * Which C standard? Is the specification for char the same in C89, C90, C99 and C11? If not, the article should reflect that. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:45, 25 August 2016 (UTC)

 * No, char is not guaranteed to be unsigned. C99 and n1570 are completely explicit about this (6.2.5#15). Ewx (talk) 07:57, 26 August 2016 (UTC)

For the record, this is the text of 6.2.5#3:
 * An object declared as type char is large enough to store any member of the basic execution character set. If a member of the basic execution character set is stored in a char object, its value is guaranteed to be nonnegative. If any other character is stored in a char object, the resulting value is implementation-defined but shall be within the range of values that can be represented in that type.

Kbrose (talk) 11:57, 26 August 2016 (UTC)

 * You're reading the wrong bit. That just tells you that certain characters have non-negative representation in a char.  It does not tell you that the type itself is unsigned.  Once again, see 6.2.5#15 for text that is actually relevant here. Ewx (talk) 18:50, 26 August 2016 (UTC)
 * I have to agree with Ewx, I think it just says that if you need to store non-negative values, you can, if you want to store something else, it depends on the implementation, which is a way of saying that they are not defining if a char is signed or unsigned. It even opens the door to implementing a range of -64 to +191 if you wanted to, instead of the classic -128 to +127 or 0 to 255. Dhrm77 (talk) 22:02, 26 August 2016 (UTC)
 * -64 to 191 would be forbidden (SCHAR_MIN must be at most -127) but -127 to 127 is permitted (and realistic for 1s complement machines); so is -2147483648 to 2147483647 or 0 to 4294967295 (and realistic for word-addressed machines).Ewx (talk) 07:25, 27 August 2016 (UTC)

Merge Octet (computing) into Byte
Octet (computing) should be merged into Byte as Octlet (computing) is another name for Byte and Wikipedia does not have two articles for two names of the same thing (instead both are mentioned in the WP:LEAD and the article's title is at the WP:COMMONNAME). -KAP03(Talk • Contributions • Email) 22:47, 26 March 2017 (UTC)
 * Oppose. I see your point, but I'm afraid that merging may blur the differences between the terms even more (than how they are confused in the current articles). Byte, Octet, Octlet (and the not mentioned Octad) are related but not multiple names for the same thing in general. They need to be distinguished carefully and we should rather improve/sharpen the articles emphasizing their differences.
 * While byte is today understood as referring to a group of 8 bits most often, without context it does not define a specific count of bits. Historically, a byte was defined as any group of bits from 1 to 6 (with 5 and 6 bit being the most commonly used forms even at that time). Later it was defined as the group of bits necessary to hold a character, that is 5 to 8 bits. With the advent of micro-computers in the late 1970s / early 1980s, this shifted towards meaning 8 bits by default. Therefore, byte is a platform-specific term.
 * Octet, however, was specifically defined to avoid the ambiguity of the term byte, and always means 8 continous bits, regardless of context and platform. That's why octet (rather than byte) is the term used in formal definitions of f.e. network protocols, in the telecommunication industry, etc.
 * Octad is a term similar to octet, however, it has fallen into disuse in recent decades and is not in common use any more. Like octet, it specifically means 8 bits as well, however, it looks at them from the angle of how many bits are necessary to define 129 to 256 states in coding (at least this is what I draw from the usage of similar terms like tetrads and pseudo-tetrads). Looking from that angle it appears as being don't care if those 8 bits holding the state are grouped together physically.
 * Octlet (per IEEE 1754) means 8 octets or 64 bits, so it is clearly different from octets.
 * --Matthiaspaul (talk) 12:31, 27 March 2017 (UTC)

 * oppose - No, they are not two names for the same thing, but names for different things. As a side note, the VFL instructions of Stretch could specify any byte size from 1 to 8 and 12 was a common byte size for CDC users. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:22, 28 March 2017 (UTC)

 * Oppose - There has been significant discussion of the distinction on the respective article talk pages. Bytes have not always been 8 bits. An octet is defined as 8 bits. Bytes are used in processors. Octets are used in communications. It is probably possible to cover both in a single article but that would not be a trivial merge and I'm no convinced that what we'd end up with would be an improvement over current coverage. If someone wants to create a sandbox version of a merged Byte article, I'd be happy to assess in more detail. ~Kvng (talk) 18:34, 9 April 2017 (UTC)
 * Support - I think the articles should be merged. It's true that byte has meant other things in the past, but the modern definition (according to the International System of Quantities) is 8 bits. Dondervogel 2 (talk) 18:50, 9 April 2017 (UTC)
 * Oppose - The terms don't always represent the same thing and are used for different purposes.Jko831 (talk) 19:37, 21 September 2017 (UTC)

Architectural support for byte sizes other than 8
Off the tope of my head, these machines come to mind as supporting byte sizes other than 8

1 to 48 bits 1-36 bits 6 or 9 bits 3, 4, 6, 8 or 24 bits 6, 9, 12 or 18
 * CDC 3600 and 3800
 * DEC 36-bit machines
 * GE, Honeywell and Bull 36-bit machines
 * RCA 601
 * UNIVAV and Unisys 36-bit machines

Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:41, 29 March 2017 (UTC)
 * Shmuel, do you actually mean bytes in this context? I recall the larger sizes to be called words. If you can, please provide some refs, it would be great if we could track this down to historic sources in order to improve the article.
 * --Matthiaspaul (talk) 00:37, 30 March 2017 (UTC)

 * Yes, I actually mean byte and both CDC and DEC used the word byte as part of the instruction names, e.g., Deposit Byte. Two easy citations from bitsaver are

 * Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:40, 3 April 2017 (UTC)
 * Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:40, 3 April 2017 (UTC)
 * Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:40, 3 April 2017 (UTC)

 * Another more recent example would be the Nintendo 64 with 9-bit bytes. 2003:71:CF10:FD00:A843:F00A:C1FE:7F1F (talk) 20:40, 23 September 2018 (UTC)

Status of error checking bits
The IBM 7030, for which the term byte was coined, did not include error checking bits as part of a byte. Nor did the DEC PDP-6, the CDC 3600, or any of the other computers with the ability to access bytes of various size. The System/360 Principles of Operation contains the text "Within certain units of the system, a bit-correction capability is provided by either appending additional check bits to a group of bytes or by converting the check bits of a group of bytes into an arrangement which provides for error checking and correction (ECC). The group of bytes associated with a single ECC code is called an ECC block. The number of bytes in an ECC block, and the manner in which the conversion or appending is accomplished depend on the type of unit involved and may vary among models." Accordingly, I call for the reinstatement of the text "The byte size designates only the data coding and excludes any parity or other error checking bits." Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:30, 21 June 2017 (UTC)

 * I removed that statement because the lead is supposed to summarize the important points in the article body. The statement I removed, (a) is not covered in the body (b) may not be one of the more important points about the topic. I am not at all opposed to including this information in the article body and once that is stable, we can consider it for inclusion in the lead. ~Kvng (talk) 14:51, 24 June 2017 (UTC)

"Octad"
Is the origin unclear?

The article currently states:

"The exact origin of the term is unclear, but it can be found in British, Dutch, and German sources of the 1960s and 1970s, and throughout the documentation of Philips mainframe computers."

Surely this is just the eighth member of the sequence which starts "monad", "dyad", "triad", ie a group of eight things (looking toward Greek). "Octet" and "octad" appear similar because the Latin and Greek cardinal number 8 both have the same form (octō, ὀκτώ). Compare e.g. "quintet" vs "pentad" for a group of 5.

Of course the correct term would be an ogdoad (from the genitive of the ordinal) but not everyone who wants to use precise, technical language also knows Greek.

If the question is about who first used the term in its computing sense, that may be unanswerable because it probably slipped in from an earlier technical or mathematical sense. –moogsi(blah) 23:46, 23 October 2018 (UTC)

… representing a binary number
oRLY? Anybody having a programming experience—even amateur—knows that bytes more frequently do not represent numbers (serving as opcodes, parts of bitmaps or compressed data…) than do represent numbers explicitly. Even for such complicated number format as IEEE 754 it wouldn’t be helpful to think of every isolated byte as of a sensible numerical value. Objections against complete removal? If any, then change to “are capable of representing a binary number” maybe? Incnis Mrsi (talk) 10:06, 27 July 2019 (UTC)

 * I'm fine with that. You can change it to “are capable of representing a binary numbers”. Vmelkon (talk) 02:10, 12 February 2021 (UTC)

 * I completely agree for the purposes of this article, the following is just being pedantic; Opcodes are a small part of the actual instruction, most of which is just a bunch of numbers that can be directly read on most architectures and for most instructions.  For architectures that either limit immediates to 8 bits or actually are 8 bits, the bytes in program code are very likely to have direct meaning as numbers.  Sure, you might have to read them as nibbles and mentally stick an "r" in front of them if the thought of assigning numbers to other numbers that represent offsets in sram adds too much confusion on top of the fact that you're trying to read raw instructions,  or if you're on ARM calculate the sign bit from a bitwise operation on 3 bits spread around the T4 encoding of the branch instruction because the people designing the instruction set were high on horse tranquilizers that day, but they're numbers with direct meaning as such.  The opcode itself is just a number too, although you kinda have to squint in some cases, but if you tell an x86 to 233 it's going to 233, damnit.  :D    --A Shortfall Of Gravitas (talk) 03:47, 5 August 2021 (UTC)

Unit Multiples
Is this really correct? "100 gigabytes is specified when the disk contains 100 billion bytes (93 gibibytes) of storage space." The whole section has no attribution, so I can't check it. But I had always gathered that the difference was available storage space on formatted vs un-formatted disk. - Tsuchan (talk) 12:42, 27 May 2020 (UTC)
 * This should not need attribution anymore, is not an opinion, but straight forward application of prefixes. But I clarified the statement in a more verbose form. - Kbrose (talk) 15:08, 27 May 2020 (UTC)
 * More on the topic: [ https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1105427872 ] (# My own explanation on the background; currently on this page). - MasterQuestionable (talk) 06:58, 22 September 2022 (UTC)
 * More on the topic: [ https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1105427872 ] (# My own explanation on the background; currently on this page). - MasterQuestionable (talk) 06:58, 22 September 2022 (UTC)
 * More on the topic: [ https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1105427872 ] (# My own explanation on the background; currently on this page). - MasterQuestionable (talk) 06:58, 22 September 2022 (UTC)

Proposed merger
Is it absolutely necessary for kilobyte, kibibyte, megabyte, mibibyte, gigabyte, gibibyte, etc. to all have their own individual wikipedia pages that all say the exact same thing? Can't we put the information on one page, and have all those terms redirect to that one page? — Preceding unsigned comment added by 73.70.13.107 (talk) 10:33, 14 October 2020 (UTC)
 * Wikipedia has no problem with duplication and redundancy not least because it is not paper. As long as each article is properly sourced and notable, there's no reason to replace them all with one "mega sized" article. QuiteUnusual (talk) 11:52, 14 October 2020 (UTC)
 * The merge suggestion has merit precisely because the articles don't sum up to a massive article. They're 95% (99%?) the same article—just at different levels of development because some get more attention than others.
 * Clearly the hypothetical merge destination would not be Gigabyte, so I'm moving the discussion here to the talk page of Byte. I see that the IP editor making the original proposal and selected Binary prefix for the redirect, but I think that may be confusing the thing with the name. Millilitre redirects to Litre § SI prefixes applied to the litre, not Metric prefix, and that strikes me as appropriate.
 * Either way, this is a change worth discussing first, and care will need to be taken to preserve the best citations, but yes, I think consolidation is a good way to deal with the existing mess of nearly identical articles. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  14:03, 14 October 2020 (UTC)
 * I just made an effort to gather some of the best content from the relevant articles and centralized it here. A lot of what was available is dated and esoteric (“In 2013, one expert estimated that the "amount of data generated worldwide" would reach 4 zettabytes by the end of the year”) and of questionable value.
 * The biggest concern now might be how redirects and disambiguation are handled. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  18:20, 10 December 2020 (UTC)
 * I made a earnest attempt scrape as many good bits from the 16 redirected articles as possible. Some genuinely interesting facts and citations existed in only one or two of the articles, so I’m hopeful that the consolidation will make those nuggets more findable to readers. There was a lot of cruft to sift through—and I had to make judgment calls—so if anyone wants to go through the trimmings for anything I overlooked, that would be welcome. Cheers —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  02:34, 11 December 2020 (UTC)
 * There has been no consensus for these actions, so I have reversed them. The articles have been more or less stable for years, with only occasional curiosity about a single article. There is not mess, and separate articles introduce no problems for WP policies or maintenance. It is good to have places for unit-specific content and that shows in some of the articles. kbrose (talk) 14:59, 11 December 2020 (UTC)
 * I’m not arguing that the existence of the 16 articles I redirected violates policy, but policy violations are not the only reason for advantageous merging. I’m citing two reasons:
 * Fragmentation dilutes editor attention. Byte is still rated C-class despite having existed since 2001. The other 16 articles are Start-class dumping grounds for poorly curated trivia. None of these 16 articles is improving at a rate we should be proud of. Take Kilobyte: it’s been something like 22 months since the last substantive improvement (, and I thank you!); most edits are just fighting entropy. When I tagged a dubious statement there in June, I ended up waiting through three months of silence before removing the statement. This discussion has existed for two months and received no feedback. The stability you cited is not a compelling argument for keeping bad content.
 * Purposeful redundancy is okay; gratuitous redundancy is not. I’ve noted above that Litre and its many prefixed variants are successfully consolidated in one article. The same is true for Newton, Decibel, and most units. Is there some good reason that this model isn’t appropriate for Byte? I will note that Gram exists along side Kilogram and Metric tonne but not an exhaustive set of articles, so there is precedent for a middle ground. I don’t see any justification for Kilobyte’s existence within the current version of the article, but it’s not impossible for me to imagine. I doubt Zebibyte will ever need a standalone article.
 * I don't think there was a truly compelling reason to revert my edits en masse, and I think we should re-implement the redirects, but I’m open to considering the 16 affected articles on a case-by-case basis. Making Byte a better article, though, should be the highest priority. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  16:43, 11 December 2020 (UTC)
 * I don't have any strong objections to a merge but clearly some more discussion needed. A single article is fairly standard in other cases, although in this case the prefixed units, especially kB and MB, are the ones in more common use which could muddy the issue of an article title.  Perhaps formally tagging the articles for merger would generate a little more interest in this discussion.  Some musings on a talk page for a few weeks, with no explicit support and some scepticism, is hardly good support for a fairly dramatic action.  A formal merger proposal without clear opposition, on the other hand, could be interpreted as consensus.  Lithopsian (talk) 15:12, 11 December 2020 (UTC)
 * Just a pre-vote, but I would definitely support merging anything about say, petabyte. Units not in widespread usage, ones that most people wouldn't recognise, are hardly notable in themselves.  Lithopsian (talk) 15:15, 11 December 2020 (UTC)
 * The trend is usually to divide content to more specific topics. Even the small articles in this series have value, because they quickly point the user to a specific definition without having to sort through a lot of information. This has become more important since automated services and devices exist, increasingly, such as the Google assistants and apps, that pull up specific definitions from WP for key words and topics and read them to the user. This is also a good reason to not bunch parenthesized comments right after the key word or article title with lots of pronunciations and in this case unit symbols. Short, clear, specific sentences have more impact. kbrose (talk) 15:36, 11 December 2020 (UTC)
 * There are lots of cases where foo is a redirect to bar . — Preceding unsigned comment added by Chatul (talk • contribs)
 * I’m also a big believer in making the first two sentence count for all they can because they’re what Google’s Knowledge Graph harvests and regurgitates. I wouldn’t go so far, though, as to agree that Wikipedia needs to adopt dictionary-like fragmentation just to accommodate Google. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  16:50, 11 December 2020 (UTC)
 * The Litre, Newton, Decibel, are convincing examples, and, per consistency, I am leaning for a merger. The pages were so similar that creating the 16 pages looked merely as a programming exercise about automated article writing. And fragmentation is trully a editor waste of time: I recently made manually 14 similar edits to see them all reverted at once.  QuiteUnusual reply has given no reason why to keep separate articles: stating that there was no reason to merger is not a reason. Neither has  kbrose, stating that it was the status quo and that dividing was trendy. So, I am for a merger. I would also add that, giving the user a complete page is like teaching to fish, while the single article for each suffixed unit is like giving one a fish. Teaching is encyclopedic. --Robertiki (talk) 03:37, 12 December 2020 (UTC)
 * In addition to Metre, we have separate articles for Kilometre, Millimetre, Micrometre, Nanometre, Picometre and Femtometre. While I can see a case for keeping Kilometre and (maybe) Millimetre, all others seem frivolous to me because so much of the information is duplicated (making them difficult to maintain), and we could better serve our readers by redirecting those to Metre. The same reasoning applies to multiples of byte. I suggest the following: Let's make a single Byte article that addresses the concerns raised against merging, and then review whether we still need Kilobyte, Megabyte, etc? Dondervogel 2 (talk) 09:46, 12 December 2020 (UTC)
 * Do you have specific suggestions for changes to Byte you would want to see implemented before a merger? I think all concerns raised thus far are either about procedure or the relative benefits of keeping the diaspora of articles so as to better mesh with Google (and maybe Wikidata?). As I’ve said, I’m interested in making Byte better, so I’m interested in ideas for improvements. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  14:41, 12 December 2020 (UTC)
 * My two cents: we should keep a particular multiple split when it has enough examples, history, etc that justifies a separate article. Example: "Apollo Guidance Computer computer had Kilobytes of RAM memory". If the multiple has only a couple of those examples, then that's a case for merge; if it has 4~5 (or more), plus a history with more than a paragraph, etc, then that's a case for split. In my opinion. Imagine having KiB, MiB, TiB each one with its own example, history, etc all in the same article; it'd be a mess. And I'd guess that there's a lot of encyclopedic history to be told in many (if not all) of the multiples (at least up to Terabyte), considering the rapid evolution and the impact of digital systems in human history.
 * For maintainability issues, we can try the template in case it's not being used already (I didn't check). Feelthhis (talk) 16:17, 12 December 2020 (UTC)
 * There is another way of reaching the intended purpose this discussion. I would support developing one article into a full treatment of all units and their histories and relationships, but at the same time keeping minimal versions of each separately, consisting only of a concise definition (to be used in Google fact finds) and a link to the general description of the whole set. They would not be redirects, but bare definitions with a reference for background. −Woodstone (talk) 16:24, 12 December 2020 (UTC)
 * A lone definition with…what? A warning to editors not to add more? Is there any precedent for this hybrid organization? —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  17:01, 12 December 2020 (UTC)
 * A lone definition with…what? A warning to editors not to add more? Is there any precedent for this hybrid organization? —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  17:01, 12 December 2020 (UTC)

A week has passed since the merger and subsequent reversion, and several days have passed since the last contribution to this conversation. My takeaways are these: Unless it is felt that formal proposal is genuinely needed, I intend to re-implement the 13 supported redirects in the next day or so, to keep improving Byte, and to give further consideration to what form Kilobyte, Megabyte, and Gigabyte might take to best serve Wikipedia’s readers. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  13:50, 17 December 2020 (UTC)
 * 1) For all eight binary units and the five decimal units larger than Gigabyte, there seems to be clear support for redirecting.
 * 2) * The primary argument for retention of all 17 articles is to establish a definition for each word. This justification is at odds with point 1 at WP:NOT, and there seems to be a general consensus among conversation participants that this is not the right approach.
 * 3) * ’s primary concern was that the expanded section of Byte be up to the task of clearly explaining the multiple systems. and I tag-teamed to improve that section significantly, and I think it’s currently in much stronger shape than the corresponding section in any of the 17 articles has ever been.
 * 4) For Kilobyte, Megabyte, and Gigabyte, there seems to be a recognition that the articles are problematic but not a consensus on a solution.
 * 5) * The strongest argument for not merging everything to Byte, raised by, is that in everyday life, kB and KB are more common than B.
 * 6) ** This could justify retaining two articles at Byte and at Kilobyte OR retaining a single consolidated article at Kilobyte instead of at Byte. I take the former option more seriously because Byte remains the best article title. Its definition is settled, and the word itself is a constituent part of all the unit names (not just ‘Kilobyte’ and ‘Megabyte’ but ‘Kibibyte’ and ‘Mibibyte’ too). The average reader is going to be able to best understand the relationship between units when the article’s starting point is the base unit.
 * 7) * noted that  might be able to help keep quality up in satellite articles.
 * While not objecting to jameslucas's proposal, I wonder whether we need two more articles Decimal multiples of byte and Binary multiples of byte, that would each describe a subset of multiples as indicated by their titles. I also wonder whether a similar exercise is needed for Kilobit, Megabit, Kibibit etc. Dondervogel 2 (talk) 14:10, 17 December 2020 (UTC)
 * I don't think creating articles with titles that are unlikely search terms helps Wikipedia users as much as it might satisfy us. It also makes it less obvious where kilobyte, megabyte, etc. should redirect.  Lithopsian (talk) 15:26, 17 December 2020 (UTC)
 * Again, not an objection so far as this proposal goes. I think we may be underestimating the purpose and value of redirects here.  Whether the content for, say kilobyte, is in byte or a separate article called kB or whatever may cause sleepless nights for us editors but is of little consequence to the average reader.  They can search, link, or otherwise open something about "kilobyte" and will get information about kilobyte, albeit in an article titled "byte".  Bolding of common synonyms in the lead, or giving them sections or anchors, avoids confusion and everyone is happy.  Separate articles are only really needed when there is sufficient distinct text to make that article useful and where it would otherwise overload or unbalance the parent article, or where multiple semi-distinct topics just make a single article unwieldy.  I'm not convinced any of these cases apply here.  The article is not overly huge and the child articles contain little distinct information, largely repeated across each one, and easily mergeable.  Perhaps they could be expanded, but the distinct information in each one at this point would barely be worth a section in a parent article.  Perhaps the question to ask is "if they were all in a single article today, would we want to  do a WP:SPLIT?"  Nothing to stop them being split again in the future if it becomes useful.  Lithopsian (talk) 15:26, 17 December 2020 (UTC)
 * , in your first attempt of merging I notice that, from all the content from Exabyte, you brought only the phrase "global monthly Internet traffic in 2004" to your merge. Is this how things will be handled? If that's going to be the tone of this process, then I suggest starting a deletion discussion prior the removal, for respect to the editors who put their time and effort writing all the valuable content that is to be removed. Please take this into consideration before starting the process. Feelthhis (talk) 00:05, 18 December 2020 (UTC)
 * It’s undoubtedly helpful to have a few real-world examples to illustrate for the reader the relative sizes of these units, which is why I created and harvested the best examples I could find.  has already improved it, and I’ll keep trying to expand it. (And I’d be open to adding more tiers—10 kB, 100 kB, 10 MB, etc.—if you think it’d help readers.)
 * With that said, I think it’s essential to observe that the vast majority of examples and comparisons present in the 16 articles are not about the units they supposedly illustrate. The average reader is not going to be familiar with “DARPA's ARGUS-IS surveillance system”, so the fact that it could—in 2014—“stream 1 exabyte of high-definition video per day” cannot possibly help most readers understand the size of an exabyte (and those it would help probably don’t need that help). Many of the examples, including the section, are arguably worse because they are dealing with amounts of data an order of magnitude or more different from the example they are supposedly illustrating.
 * It’s a bit surprising to me that so much of this trivia was allowed to accumulate, and now that it’s thousands of bytes deep, I appreciate that its removal seems dramatic, but I don’t think most editors who spent some time reviewing it fact-by-fact with an eye towards its purpose within the article would deem the content appropriate or its removal controversial. I made a serious effort to gather the best examples, invited others to double-check my work, and in the course of engaging in this discussion have spent additional time with the material on the chopping block. I don’t think it’s defensible. I’m willing to dot the is on this process if it’s judged necessary, but I hope not to. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  01:29, 18 December 2020 (UTC)
 * I notice that for Gigabyte you used the example "about half an hour of video". But... just "video"? In a topic about bits and bytes? With all due respect, all examples from Gigabyte are objectively better and were all going to be deleted (in fact, if it wasn't for Kbrose rescuing them, they were all deleted). Do you mind if I invite users and  to this discussion? I hope not. The way I see it now, too many good content will be lost and from now on my position is against the mass merging/deletion.
 * The non encyclopedic material (for instance outdated trivia) is best handled in a case-by-case manner instead of a mass deletion across multiple articles, in my opinion. It's like cancer, you want to remove the bad (cancerous) stuff and keep all the good (healthy) stuff. This mass merging/deletion will remove the bad stuff all the good stuff. Feelthhis (talk) 03:53, 18 December 2020 (UTC)
 * The video example for gigabyte was added by me (replacing a self-reference to Wikipedia). The source says "2 GB per hour of video (varies greatly)" in the context of a 4.7 GB DVD. I agree it's weak and can be removed as far as I'm concerned. Dondervogel 2 (talk) 08:13, 18 December 2020 (UTC)
 * No one should be excluded from this conversation. I’ve pinged both and  at least once each in the course of this, and I hope I’ve been clear that further curation of examples is being explicitly requested. The cancer analogy, though, I find inapt. If we agree that these “bodies” are now valued primarily as organ donors, it’s probably better for organ-hunting purposes to move them to the freezer intact than to carve them up and in doing so create obfuscating layers of history states. Unlike organic organs, these word organs are still viable after being declared “dead” for a while. (Granted, I’d probably weigh the pros and cons differently if I thought there were many good organs left to be found.) —jameslucas  ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  12:39, 18 December 2020 (UTC)

I have redirected the articles for binary units, which contain none of the content being discussed yesterday. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  14:15, 19 December 2020 (UTC)
 * I have redirected the articles for decimal units greater than Gigabyte after giving them one more comb through for not-yet-harvested informative elements and finding none. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  02:00, 21 December 2020 (UTC)

Addressing ambiguous definitions of megabyte and gigabyte

 * I think some of the information from individual articles needs to be copied across before those individual articles can be replaced with re-directs. I imagine there are multiple examples (I've not carried out an audit or check of any kind) but one that springs to mind is the fact that there exist (or at least have existed) 3 different definitions of "megabyte". Another concern is a false impression in the text of symmetry between decimal and binary definitions of kilo, mega, ... yotta. (Only the table hints at the fact that only the first 3 have binary definitions, whereas all of them are decimal). Dondervogel 2 (talk) 15:33, 12 December 2020 (UTC)
 * The 3½-inch floppy’s “1.44 MB” seems like a marketing simplification rather than a third definition; I think the way is currently presented in Megabyte, as a definition of equal relevance, is misleading and not to be emulated. It could be retained as a footnote, but that little bit of history more properly belongs at Floppy disk (and, yes, it’s there). —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  17:01, 12 December 2020 (UTC)
 * If the information about the history of "megabyte" is hidden in Floppy disk the reader would need to be told (in Byte) where to find it. But I actually believe the information should not be hidden there. Much better to have a section about the meaning of the word "megabyte" either in Megabyte itself or (if re-directed here) in Byte. The evolving meaning of related terms (kilobyte, gigabyte, terabyte ...) is also not apparent from a re-direct to Byte. Dondervogel 2 (talk) 09:35, 13 December 2020 (UTC)
 * Maybe I’m missing part of the story? My understanding is that the ‘1.44 MB’ label was a one-off marketing anomaly rather than something that precipitated an evolution of meaning—a funny footnote remembered by few of us and having no relevance to the current definitions of ‘byte’, ‘kilobyte’, or ‘megabyte’. Correct me if I’m wrong! —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  14:45, 13 December 2020 (UTC)
 * I don't think it can be dismissed as a one-off anomaly. See p17 of Hale & Stanney (2014). . I see it more as an ongoing symptom of a deeper malaise, namely the ambiguity of KB, MG, GB ... This ambiguity continues (and will continue) for as long as there are two different interpretations of each prefix, and the ambiguity increases with increasing order of the anomaly because while MB can be interpreted 3 different ways, for GB (either 1000 MB or 1024 MB) there are 4 different interpretations, and so on. Dondervogel 2 (talk) 16:54, 13 December 2020 (UTC)
 * If the muddling is commonplace, that would being worth mentioning more prominently than I suggested. In the Google Books preview of the Handbook page 17 is a list of references, so I’m not sure I’m seeing what you’re suggesting I see. If it’s another example besides the 3½-inch floppy, that’d be great. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  22:11, 13 December 2020 (UTC)
 * I'm not arguing that particular use is widespread, only that the ambiguity is. The statement in question (paraphrasing a little) reads "[MB] may mean 1000x1000 bytes or it may mean 1024x1024 bytes, or even 1000x1024 bytes", and seems to be on p24 of the version your link points to (search for "1024" and you'll find it). Dondervogel 2 (talk) 22:43, 13 December 2020 (UTC)
 * Here's another example. Rata (2009) defines kilobyte as either 1000 bytes or 1024 bytes, megabyte as either one million bytes or 1024 kilobytes (with 3 possible interpretations) and gigabyte as either one billion bytes or 1024 megabytes (4 interpretations). It's the same problem, getting worse at each step increment in the exponent. Dondervogel 2 (talk) 23:09, 13 December 2020 (UTC)

New material added on 28 Jan 2020
I just reverted (for the second time) the addition of a large amount of unreferenced material. Addition of new material is welcome if it is backed up by reliable sources. If you wish to reinstate this material, please read WP:BRD and then gain consensus for the change by discussing it here. Dondervogel 2 (talk) 10:16, 29 January 2021 (UTC)

Call for practical examples
I’m hoping that someone with more technical knowledge than I possess could help source and/or calculate better practical examples for the table. I’ve tried to find published, understandable-to-the-layperson examples, but they are surprisingly hard to come by. Trying to make an example for ‘terabyte’ a few weeks ago, I looked up file sizes of H.264-encoded 1080p video, and a number of independent sources said 30 hours should be very close to 1 TB. Then I went searching for chunk of video 30 hours long (aiming for something that I had heard of despite having never seen), and I found Avatar: The Last Airbender. I see that has today  for the same video data. I’m very glad that my amateur calculations are being scrutinized, and there are enough factors (encoding options, aspect ratio, compression of animation vs compression of live action, etc.) that I can believe that my best attempts may have been off by 200+%.

FWIW, I really like the introduction of the footnote, which allows the inclusion of a check-our-math explanation without burying the everybody-gets-it conclusion. This also helps us steer clear of WP:OR since the only original work is the basic math, which is fine as long as the inputs are verifiable. The newly revised table entry is too jargon-heavy, so it’d be good if the next example is something where we don’t feel compelled to mention the aspect ratio for instance. Cheers —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄  20:36, 24 February 2021 (UTC)
 * Video is particularly bad as an example for this as most of it is variable-rate based on content and encoders differ heavily in quality; there are also multiple ways of encoding the same data.  As a quick recent example from my own re-encodings of terrible movies from UHD Bluray for streaming over my NAS and adding in Rifftrax commentary, with 10bpc H.265 one can encode with a "constant rate factor" mode that attempts to maintain a steady quality level based on an arbitrary number.  The size of the output video varies massively based on content.  The first of the spastic Michael Bay transformers movies is 143 minutes and weighed in at ~15GB re-encoded from ~70GB on the original disk.  The last Avengers movie, around 50GB from disk, and 181 minutes long, which consists of a surprising number of fairly still scenes and talking heads (so very little motion), came in at 2.6GB at one step higher quality and I ended up re-encoding again at 4 steps higher quality because I couldn't quite believe the compression would have gone that well and it was closer to 5GB...  once I watched marvel characters sitting around talking for most of 3 hours the compression made sense.   It's also completely possible to re-encode movies with naive constant bit rate compression so that they're both larger than the originals and lose quality in some scenes (which required a burst of higher bit-rate than the encoder was set to for that particular scene).   You won't really find a good "average" for video like this because there isn't any.  1TB for 30 hours sounds like it's roughly based on the encoding settings used for 1080p Bluray (including audio), which was often encoded at gigantic sizes purely to eat up space and make it difficult for people to deal with on home computers (or it was back when bluray was new, anyway), and may contain huge lossless audio files in multiple languages that people are accidentally factoring into their numbers for the actual video size.
 * You'll not find many published examples because of this... and I'm talking about two movies at around the same resolution (aspect ratio differs), the same type-ish of source (Disney does cripple their UHD Bluray releases by not including DolbyVision which their movies are mastered in, but this has been accounted for in the sizes above by subtracting both the enhancement layer size and DV metadata sizes from the transformers movie original and re-encode.) Maybe a good place to look would be Sony's camera manuals?   I don't shoot video but as I recall all the Sony a7 series manuals list approximated video time / SD card size / selected video resolution and bitrate and that's about as good as you'll get (and they still include the warning that the times vary heavily based on content being filmed).  --A Shortfall Of Gravitas (talk) 04:43, 5 August 2021 (UTC)

"PiB" listed at Redirects for discussion
A discussion is taking place to address the redirect PiB. The discussion will occur at Redirects for discussion/Log/2021 May 20 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. User:1234qwer1234qwer4 (talk) 10:55, 20 May 2021 (UTC)

wrongly deleted
IMHO the way I wrote it, the byte as information, is definitely much clearer when in the context of binary "digits" or flags (and corresponding hexadecimal digits). As it is written now you have many many words surrounding the concept and not touching it. So my edit is definitely in place. Please user:Dondervogel 2 next time discuss before deleting work that your fellow wikipedian put time and effort into.

Here is the deleted section:

Hexadecimal and binary representation: Byte values can be easily represented with hexadecimal digits. Since 4 set bits correspond to the hexadecimal digit F, every four-bit byte value is easily written as a single hexadecimal digit value, and the hexadecimal value of each digit can easily be translated back into its four bit binary value. Thus an 8 bit byte can be read as two 4 bit bytes, each represented by a single hexadecimal digit. So for example with an 8-bit byte, hexadecimal FF is the maximum value with all bits set (corresponding to decimal 255) and hexadecimal 10 is easily translated as binary 0001_0000 (corresponding to decimal 16).

I also added some short captions so that one can trudge through all the wording:

Byte size: The size of the byte has historically been ...

The 8 bit standard: The modern de facto standard of eight bits...

The unit symbol B: The unit symbol for the byte was designated as...

Thanks in Advance, Moshe aka פשוט pashute ♫ (talk) 11:51, 24 June 2021 (UTC)

 * Work is rarely ever deleted; all of it is still archived in the page history. Per the BOLD, revert, discuss cycle, it is actually good to first revert and then discuss. Anyway, I do think that a paragraph about hexadecimal representation would be good to have, since bytes are often represented that way. However, I think it should not be put in the lead, since the lead section is supposed to be merely a summary of the article, and this is a bit too specific to be a summary. Lastly, captions are normally not applied to individual paragraphs. That makes it look more like some sort of glossary, which would not really be appropriate here. (also pinging involed editor ) ―Jochem van Hees (talk) 12:22, 24 June 2021 (UTC)
 * If there is consensus for it, I would not object to the paragraph being reinserted further down the article, but please not in the lead. I do think it would require a little more context to explain the difference between the byte as a unit of storage, and a byte of information. Dondervogel 2 (talk) 12:52, 24 June 2021 (UTC)
 * First, the text following Hexadecimal and binary representation: doesn't discuss binary representation, so the head is misleading. Second, neither the head nor the text mention octal representation, which is both important historically and still, alas, in use for octets. Third, as Dondervogel mentioned, it doesn't belong in the lede. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:27, 24 June 2021 (UTC)
 * First, the text following Hexadecimal and binary representation: doesn't discuss binary representation, so the head is misleading. Second, neither the head nor the text mention octal representation, which is both important historically and still, alas, in use for octets. Third, as Dondervogel mentioned, it doesn't belong in the lede. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:27, 24 June 2021 (UTC)

 * My main point was that the wording in the lead just doesn't even explain what a byte is. Rather it starts "arguing with itself" on side details like what the standard representation is or what the symbold is. So what I will do is simply move all that too out of the lead and create a short and clear explanatory lead.  My explanation through representation, which has EVERYTHING to do with the subject and NOTHING to do with computers, as OPPOSED to the way it is now in the lead, IMHO was better. But, since there are already three who seem to agree  that I'm wrong, I will not argue but rather put up an alternative simple explanation that DOES give the definition perhaps with an example. פשוט pashute ♫ (talk) 21:26, 14 July 2021 (UTC)
 * It is not "arguing with itself", it is explaining that there is no standard definition for a byte. Given that one of the functions of the lead is to define the subject, this seems very appropriate to me. ―Jochem van Hees (talk) 11:33, 16 July 2021 (UTC)
 * I give up. But it seems that the article has been changed for the better now. (Not sure anymore what was there before and what has changed if at all).פשוט pashute ♫ (talk) 16:54, 13 December 2021 (UTC)

Initial description: not quite on point?
The first sentence of the lead is:
 * "The byte is a unit of digital information that most commonly consists of eight bits."

This treats the byte as a unit of storage or information, and nothing else. However, use of the term normally relates to how the data is constructed, and in particular that it is a sequence of eight bits that are grouped together. (See Byte | Merriam-Webster.) For example, when we refer to a byte of computer memory, we usually specifically mean one of the 8-bit groupings of memory storage that are addressed together using a single byte address, not individual bits that might be scattered in arbitrary locations. I think it makes sense to put the emphasis on this meaning in this article, and to have the definition as a unit (measure of amount) of storage capacity as a derived meaning. —Quondum 16:52, 29 June 2021 (UTC)

[20220818] On recent editing that had references "broken"
@Tea2min, please see the relevant edit history [ https://en.wikipedia.org/wiki/Byte?action=history&offset=20220818072031&limit=4 ]. The reasons have been well explained I believe. .     I believe what should be fixed are the templates, not the usage.

- MasterQuestionable (talk) 17:00, 18 August 2022 (UTC)

I would revert your edit (commit 1105047710) within hours, if there wasn't any objection with plausible reasoning: For preparing my further edits (which is based on the old version).

- MasterQuestionable (talk) 20:54, 18 August 2022 (UTC)

Due to an implementation problem in MediaWiki, my further editing of the article is pending. More details: https://www.mediawiki.org/wiki/Topic:X1hnma8u8r7amg4c

- MasterQuestionable (talk) 01:46, 19 August 2022 (UTC)

Line feeds are not allowed in refs: see. So several of the 'quote=' contain line feeds which generate the error. I fixed these but someone has unfixed them again. - Oculi (talk) 11:38, 19 August 2022 (UTC)
 * Is there a tool to replace them with ? If not, is the number small enough to do that manually? - Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:56, 19 August 2022 (UTC)
 * A recent edit changed the citations to use poem quote, which preserves new lines (LF for Unix). Why not use quote and insert where breaks are to be kept? - Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:33, 19 August 2022 (UTC)
 * poem and poem quote preserve indentation, seemed to be important to original contributor. Also, running all the lines together with reduces readability. Feel free to change, I have no real preference. I needed to change the greying with italics because  appears not to be compatible with poem quote. - User-duck (talk) 13:54, 19 August 2022 (UTC)
 * Why even bother these templates after all? Things would probably be better without using them. - MasterQuestionable (talk) 05:18, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 05:13, 20 August 2022 (UTC)
 * poem and poem quote preserve indentation, seemed to be important to original contributor. Also, running all the lines together with reduces readability. Feel free to change, I have no real preference. I needed to change the greying with italics because  appears not to be compatible with poem quote. - User-duck (talk) 13:54, 19 August 2022 (UTC)
 * Why even bother these templates after all? Things would probably be better without using them. - MasterQuestionable (talk) 05:18, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 05:13, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 05:13, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 05:13, 20 August 2022 (UTC)

I thought about a workaround: having the "quote" content detached from the "Cite" templates; or dropping all the "Cite" templates wholesale. (I don't find these templates anyhow helpful really) - MasterQuestionable (talk) 06:26, 20 August 2022 (UTC)

Lengthy quotes in references
There's a problem with the lengthy quotes in the references. I don't know enough about our citation templates to fix this. - Tea2min (talk) 07:25, 18 August 2022 (UTC)
 * What are you asking? The section title suggests that you're addressing a stylistic issue, but you don't need knowledge of the citation templates to fix that.
 * If you're asking how to quote text in a citation, use the quote parameter and indicate any elided text with "nbsp... ". --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:26, 18 August 2022 (UTC)
 * Who meant the content is too long and don't know how to fix. - MasterQuestionable (talk) 17:11, 18 August 2022 (UTC)
 * For example, the Buchholz 1977 and Behmer 2000 reference contain a mixture of black and gray text color, and weird character sequences like "<&>" and "<.>". Tea2min (talk) 17:16, 18 August 2022 (UTC)
 * - MasterQuestionable (talk) 17:38, 18 August 2022 (UTC)
 * I just checked Buchholz 1977. The source text quoted did not contain gray text or "weird character sequences". Were they added during transcription into the article? User-duck (talk) 01:33, 21 August 2022 (UTC)
 * https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1104865968 - MasterQuestionable (talk) 17:01, 24 August 2022 (UTC)
 * I just checked Buchholz 1977. The source text quoted did not contain gray text or "weird character sequences". Were they added during transcription into the article? User-duck (talk) 01:33, 21 August 2022 (UTC)
 * https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1104865968 - MasterQuestionable (talk) 17:01, 24 August 2022 (UTC)
 * https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1104865968 - MasterQuestionable (talk) 17:01, 24 August 2022 (UTC)

You can't cite a Wikipedia talk page in a Wikipedia article
https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1105317022

This alone may not suffice as the reason to decide whether certain content is qualified for inclusion or not. I believe the inclusion criteria should be entirely based on factual validity, besides nothing else.

- MasterQuestionable (talk) 05:39, 20 August 2022 (UTC)
 * I tend to agree. Unfortunately "Wikipedia" does not. They discourage first party sources. They specifically mention Wikipedia articles (and wikipedia clones). I found this reference/source troubling and was actually glad to see the content removed because I do not know how to deal with the referencing. Also, I found the tidbit interesting but did not know if it really added to the article. - User-duck (talk) 17:00, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 23:43, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 23:43, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 23:43, 20 August 2022 (UTC)

Be Bold does not mean Be Reckless
These revisions [ https://en.wikipedia.org/wiki/Byte?action=history&offset=20220819165028&limit=5 ] apparently resulted in degraded readability comparing to my last revision [ https://en.wikipedia.org/?oldid=1105186269 ]. I'd suggest making more careful verifications (in cases of uncertainty, discuss first) before committing the change.

- MasterQuestionable (talk) 06:12, 20 August 2022 (UTC)
 * I disagree about the "degraded readability". The long quotes were not formatted consistently, they were incompatible with the quote citation parameter, the greyed text is barely readable, and the extraneous "<&>", "< >", etc. markups do not help. I was very careful to make sure the content and intent of the quotes were maintained. I would appreciate any "Reckless" mistakes being corrected (or at least noted). The only reason I noticed this article is the CS1 errors. If the CS1 error messages had not been ignored (this is reckless) and the original quotes had been done outside the citation templates, I would not have noticed them.
 * PS: I was hoping someone would notice the "Bare URL" and clarify the "... About bits and bytes: prefixes for binary multiples - IEC ..." reference. It does not meet my understanding of the Wikipedia standards for references. I could attempt to clarify it or simple tag it.
 * PPS: I have longtime, extensive knowledge about computers. - User-duck (talk) 16:41, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 23:51, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 23:51, 20 August 2022 (UTC)
 * - MasterQuestionable (talk) 23:51, 20 August 2022 (UTC)

Using poem quote presrves indentation, which is desirable, but it also preserves soft line breaks, which leads to jagged output and is not desirable. Is there a quote template that preserves indentation, allows wrapping and allows explicit tags? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:49, 21 August 2022 (UTC)
 * https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1105424720 - MasterQuestionable (talk) 17:01, 24 August 2022 (UTC)
 * https://en.wikipedia.org/?diffonly=1&diff=prev&oldid=1105424720 - MasterQuestionable (talk) 17:01, 24 August 2022 (UTC)

My own explanation on the background
May be of use: [ |*| On the "1,000 or 1,024" affairs (Byte counting) # Background |*| https://github.com/exiftool/exiftool/issues/152#issue-1344954990 ]

- MasterQuestionable (talk) 06:56, 20 August 2022 (UTC)

Date format
A standard date format should be established for this article. The predominate format is yyyy-mm-dd but this is not a preferred format. I saw one date using dmy. I would normally pick dmy or mdy, I have a slight preference for. But since the Talk page for this article is rather active, maybe a consensus could be obtained. User-duck (talk) 03:02, 21 August 2022 (UTC)
 * In the references (where brevity is helpful), I would stick with yyyy-mm-dd. It's clear, concise, and avoids the tussle between US and non-US formats. Dondervogel 2 (talk) 09:32, 21 August 2022 (UTC)
 * ISO 8601 derived time formats tend to be most accessible among all other options. - MasterQuestionable (talk) 16:47, 24 August 2022 (UTC)
 * ISO 8601 derived time formats tend to be most accessible among all other options. - MasterQuestionable (talk) 16:47, 24 August 2022 (UTC)

GB album example
Hi, it looks like somebody had added a citation needed tag for a 122-minute album being too small to count as 1 GB.

Well, I did the math and it looks like 122 minutes is too long to count as 1 GB, if you think of it in terms of uncompressed CD-quality audio. CD quality is 16-bit stereo at 44100 samples a second, 1411200 bits/second, 84672000 bits/minute, or 10584000 bytes/minute.

So if you count how many minutes can fit in 1 GB at CD quality:

>>> (1000*1000*1000)/(16*2*44100*60/8)   94.48223733938019    >>> (1024*1024*1024)/(16*2*44100*60/8)    101.449529856387

The answer is 94 minutes 28.934240362811398 seconds for 1 GB, 101 minutes 26.97179138322 seconds for 1 GiB. --Kjoonlee 09:23, 22 November 2022 (UTC)

TB video example
It lists that all 61 episodes in 4:3 1080p is a way to think of 1 TB. The citation says that it equals 0.2925 TB. That means you could fit the episodes three times. I don’t know how to figure out the math, but helpful examples could be: X hours/minutes of 1080p@60 fps. x hours/minutes of 4K(2160p)@60 fps. Your Glutes (talk) 06:32, 1 September 2023 (UTC)

Should I write wikipage for higher ubits of measurements and kibibytes?
I've noticed that English wiki has only 3 pages about units if measurements (byte, megabyte and gigabyte). What about others? Кокушев Сергей (talk) 05:22, 16 December 2023 (UTC)

 * The short answer is no. There used to be many such articles, but they were considered repetitive. By consensus they were consolidated and harmonised at one location, the Byte article. Dondervogel 2 (talk) 07:34, 16 December 2023 (UTC)

Better example for PB?
2000 years of MP3 does not seem a great example (wouldn't it be better as 2 years for a TB). Could there be a better example for a PB? Robertm25 (talk) 14:23, 27 March 2024 (UTC)
 * CERN? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:32, 27 March 2024 (UTC)

title: Talk:Byte


text:
Binary prefix

A binary prefix is a unit prefix that indicates a multiple of a unit of measurement by an integer power of two. The most commonly used binary prefixes are kibi (symbol Ki, meaning 210 = 1024), mebi (Mi, 220 = $1,048,576$), and gibi (Gi, 230 = $1,073,741,824$). They are most often used in information technology as multipliers of bit and byte, when expressing the capacity of storage devices or the size of computer files.

The binary prefixes "kibi", "mebi", etc. were defined in 1999 by the International Electrotechnical Commission (IEC), in the IEC 60027-2 standard (Amendment 2). They were meant to replace the metric (SI) decimal power prefixes, such as "kilo" ("k", 103 = 1000), "mega" ("M", 106 = $1,000,000$) and "giga" ("G", 109 = $1,000,000,000$), that were commonly used in the computer industry to indicate the nearest powers of two. For example, a memory module whose capacity was specified by the manufacturer as "2 megabytes" or "2 MB" would hold 2 × 220 = $2,097,152$ bytes, instead of 2 × 106 = $2,000,000$.

On the other hand, a hard disk whose capacity is specified by the manufacturer as "10 gigabytes" or "10 GB", holds 10 × 109 = $10,000,000,000$ bytes, or a little more than that, but less than 10 × 230 = $10,737,418,240$ and a file whose size is listed as "2.3 GB" may have a size closer to 2.3 × 230 ≈ $2,470,000,000$ or to 2.3 × 109 = $2,300,000,000$, depending on the program or operating system providing that measurement. This kind of ambiguity is often confusing to computer system users and has resulted in lawsuits. The IEC 60027-2 binary prefixes have been incorporated in the ISO/IEC 80000 standard and are supported by other standards bodies, including the BIPM, which defines the SI system, the US NIST,  and the European Union.

Prior to the 1999 IEC standard, some industry organizations, such as the Joint Electron Device Engineering Council (JEDEC), attempted to redefine the terms kilobyte, megabyte, and gigabyte, and the corresponding symbols KB, MB, and GB in the binary sense, for use in storage capacity measurements. However, other computer industry sectors (such as magnetic storage) continued using those same terms and symbols with the decimal meaning. Since then, the major standards organizations have expressly disapproved the use of SI prefixes to denote binary multiples, and recommended or mandated the use of the IEC prefixes for that purpose, but the use of SI prefixes in this sense has persisted in some fields.

While the binary prefixes are almost always used with the units of information, bits and bytes, they may be used with any other unit of measure, when convenient. For example, in signal processing one may need binary multiples of the frequency unit hertz (Hz), for example the kibihertz (KiHz), equal to $1,024 Hz$.

Definitions
In 2022, the International Bureau of Weights and Measures (BIPM) adopted the decimal prefixes ronna for 10009 and quetta for 100010. In analogy to the existing binary prefixes, a consultation paper of the International Committee for Weights and Measures' Consultative Committee for Units (CCU) suggested the prefixes robi (Ri, 10249) and quebi (Qi, 102410) for their binary counterparts, but, no corresponding binary prefixes have been adopted.

Comparison of binary and decimal prefixes
The relative difference between the values in the binary and decimal interpretations increases, when using the SI prefixes as the base, from 2.4% for kilo to nearly 27% for the quetta prefix. Although the prefixes ronna and quetta have been defined, as of 2022 no names have been officially assigned to the corresponding binary prefixes.

Early prefixes
The original metric system adopted by France in 1795 included two binary prefixes named double- (2×) and demi- ($1,024$×). However, these were not retained when the SI prefixes were internationally adopted by the 11th CGPM conference in 1960.

Main memory
Early computers used one of two addressing methods to access the system memory; binary (base 2) or decimal (base 10). For example, the IBM 701 (1952) used a binary methods and could address 2048 words of 36 bits each, while the IBM 702 (1953) used a decimal system, and could address ten thousand 7-bit words.

By the mid-1960s, binary addressing had become the standard architecture in most computer designs, and main memory sizes were most commonly powers of two. This is the most natural configuration for memory, as all combinations of states of their address lines map to a valid address, allowing easy aggregation into a larger block of memory with contiguous addresses.

While early documentation specified those memory sizes as exact numbers such as 4096, 8192, or $1.024$ units (usually words, bytes, or bits), computer professionals also started using the long-established metric system prefixes "kilo", "mega", "giga", etc., defined to be powers of 10, to mean instead the nearest powers of two; namely, 210 = 1024, 220 = 10242, 230 = 10243, etc. The corresponding metric prefix symbols ("k", "M", "G", etc.) where used with the same binary meanings. The symbol for 210 = 1024 could be written either in lower case ("k")  or in uppercase ("K"). The latter was often used intentionally to indicate the binary rather than decimal meaning. This convention, which could not be extended to higher powers, was widely used in the documentation of the IBM 360 (1964) and of the IBM System/370 (1972), of the CDC 7600, of the DEC PDP-11/70 (1975) and of the DEC VAX-11/780 (1977).

In other documents, however, the metric prefixes and their symbols were used to denote powers of 10, but usually with the understanding that the values given were approximate, often truncated down. Thus, for example, a 1967 document by Control Data Corporation (CDC) abbreviated "216 = 64 × 1024 = $1,048,576$ words" as "65K words" (rather than "64K" or "66K"), while the documentation of the HP 21MX real-time computer (1974) denoted 3 × 216 = 192 × 1024 = $1.049$ as "196K" and 220 = $1,073,741,824$ as "1M".

These three possible meanings of "k" and "K" ("1024", "1000", or "approximately 1000") were used loosely around the same time, sometimes by the same company. The HP 3000 business computer (1973) could have "64K", "96K", or "128K" bytes of memory. The use of SI prefixes, and the use of "K" instead of "k" remained popular in computer-related publications well into the 21st century, although the ambiguity persisted. The correct meaning was often clear from the context; for instance, in a binary-addressed computer, the true memory size had to be either a power of 2, or a small integer multiple thereof. Thus a "512 megabyte" RAM module was generally understood to have 512 × 10242 = $1.074$ bytes, rather than $1,099,511,627,776$.

Hard disks
In specifying disk drive capacities, manufacturers have always used conventional decimal SI prefixes representing powers of 10. Storage in a rotating disk drive is organized in platters and tracks whose sizes and counts are determined by mechanical engineering constraints so that the capacity of a disk drive has hardly ever been a simple multiple of a power of 2. For example, the first commercially sold disk drive, the IBM 350 (1956), had 50 physical disk platters containing a total of $1.1$ sectors of 100 characters each, for a total quoted capacity of 5 million characters.

Moreover, since the 1960s, many disk drives used IBM's disk format, where each track was divided into blocks of user-specified size; and the block sizes were recorded on the disk, subtracting from the usable capacity. For example, the|IBM 3336]] disk pack was quoted to have a 200-megabyte capacity, achieved only with a single $1,125,899,906,842,624$-byte block in each of its 808 × 19 tracks.

Decimal megabytes were used for disk capacity by the CDC in 1974. The Seagate ST-412, one of several types installed in the IBM PC/XT, had a capacity of $1.126$ when formatted as 306 × 4 tracks and 32 256-byte sectors per track, which was quoted as "10 MB". Similarly, a "300 GB" hard drive can be expected to offer only slightly more than $1,152,921,504,606,847,000$ = $1.153$, bytes, not 300 × 230 (which would be about $1,180,591,620,717,411,300,000$ bytes or "322 GB"). The first terabyte (SI prefix, $1.181$ bytes) hard disk drive was introduced in 2007. Decimal prefixes were generally used by information processing publications when comparing hard disk capacities.

Some programs and operating systems, such as Microsoft Windows, still use "MB" and "GB" to denote binary prefixes even when displaying disk drive capacities, as did Classic Mac OS. Thus, for example, the capacity of a "10 MB" (decimal "M") disk drive could be reported as "9.56 MB", and that of a "300 GB" drive as "279.4 GB". Some operating systems, such as Mac OS X, Ubuntu, and Debian, have been updated to use "MB" and "GB" to denote decimal prefixes when displaying disk drive capacities. Some manufacturers, such as Seagate Technology, have released recommendations stating that properly-written software and documentation should specify clearly whether prefixes such as "K", "M", or "G" mean binary or decimal multipliers.

Floppy disks
Floppy disks used a variety of formats, and their capacities was usually specified with SI-like prefixes "K" and "M" with either decimal or binary meaning. The capacity of the disks was often specified without accounting for the internal formatting overhead, leading to more irregularities.

The early 8-inch diskette formats could contain less than a megabyte with the capacities of those devices specified in kilobytes, kilobits or megabits.

The 5.25-inch diskette sold with the IBM PC AT could hold 1200 × 1024 = $1,208,925,819,614,629,200,000,000$ bytes, and thus was marketed as "1200 KB" with the binary sense of "KB". However, the capacity was also quoted "1.2 MB", which was a hybrid decimal and binary notation, since the "M" meant 1000 × 1024. The precise value was $1.209$ (decimal) or $1⁄2$ (binary).

The 5.25-inch Apple Disk II had 256 bytes per sector, 13 sectors per track, 35 tracks per side, or a total capacity of $16,384$ bytes. It was later upgraded to 16 sectors per track, giving a total of 140 × 210 = $65,536$ bytes, which was described as "140KB" using the binary sense of "K".

The most recent version of the physical hardware, the "3.5-inch diskette" cartridge, had 720 512-byte blocks (single-sided). Since two blocks comprised 1024 bytes, the capacity was quoted "360 KB", with the binary sense of "K". On the other hand, the quoted capacity of "1.44 MB" of the High Density ("HD") version was again a hybrid decimal and binary notation, since it meant 1440 pairs of 512-byte sectors, or 1440 × 210 = $196,608$. Some operating systems displayed the capacity of those disks using the binary sense of "MB", as "1.4 MB" (which would be 1.4 × 220 ≈ $1,048,576$). User complaints forced both Apple and Microsoft to issue support bulletins explaining the discrepancy.

Optical disks
When specifying the capacities of optical compact discs, "megabyte" and "MB" usually meant 10242 bytes. Thus a "700-MB" (or "80-minute") CD has a nominal capacity of about $536,870,912$, which is approximately $512,000,000$ (decimal).

On the other hand, capacities of other optical disc storage media like DVD, Blu-ray Disc, HD DVD and magneto-optical (MO) have been generally specified in decimal gigabytes ("GB"), that is, 10003 bytes. In particular, a typical "$50,000$" DVD has a nominal capacity of about $13,030$, which is about $10,027,008 bytes$.

Tape drives and media
Tape drive and media manufacturers have generally used SI decimal prefixes to specify the maximum capacity, although the actual capacity would depend on the block size used when recording.

Data and clock rates
Computer clock frequencies are always quoted using SI prefixes in their decimal sense. For example, the internal clock frequency of the original IBM PC was $300$, that is $300,000,000,000$.

Similarly, digital information transfer rates are quoted using decimal prefixe. The Parallel ATA "100 MB/s" disk interface can transfer $322$ bytes per second, and a "56 Kb/s" modem transmits $1,000,000,000,000$ bits per second. Seagate specified the sustained transfer rate of some hard disk drive models with both decimal and IEC binary prefixes. The standard sampling rate of music compact disks, quoted as $1,228,800$, is indeed $1.229 MB$ samples per second. A "1 Gb/s" Ethernet interface can receive or transmit up to 109 bits per second, or $1.172 MiB$ bytes per second within each packet. A "56k" modem can encode or decode up to $116,480$ bits per second.

Decimal SI prefixes are also generally used for processor-memory data transfer speeds. A PCI-X bus with $143,360$ clock and 64 bits wide can transfer $1,474,560 bytes$ 64-bit words per second, or $1,468,000 bytes$ = $700 MiB$, which is usually quoted as $730 MB$. A PC3200 memory on a double data rate bus, transferring 8 bytes per cycle with a clock speed of $4.7 GB$ has a bandwidth of $4.7 bytes$ × 8 × 2 = $4.38 GiB$, which would be quoted as $4.77 MHz$.

Ambiguous standards
The ambiguous usage of the prefixes "kilo ("K" or "k"), "mega" ("M"), and "giga" ("G"), as meaning both powers of 1000 or (in computer contexts) of 1024, has been recorded in popular dictionaries,  and even in some obsolete standards, such as ANSI/IEEE 1084-1986 and ANSI/IEEE 1212-1991, IEEE 610.10-1994, and IEEE 100-2000. Some of these standards specifically limited the binary meaning to multiples of "byte" ("B") or "bit" ("b").

Early binary prefix proposals
Before the IEC standard, several alternative proposals existed for unique binary prefixes, starting in the late 1960s. In 1996, Markus Kuhn proposed the extra prefix "di" and the symbol suffix or subscript "2" to mean "binary"; so that, for example, "one dikilobyte" would mean "1024 bytes", denoted "K2B" or "K2B".

In 1968, Donald Morrison proposed to use the Greek letter kappa (κ) to denote 1024, κ2 to denote 10242, and so on. (At the time, memory size was small, and only K was in widespread use.) In the same year, Wallace Givens responded with a suggestion to use bK as an abbreviation for 1024 and bK2 or bK2 for 10242, though he noted that neither the Greek letter nor lowercase letter b would be easy to reproduce on computer printers of the day. Bruce Alan Martin of Brookhaven National Laboratory proposed that, instead of prefixes, binary powers of two were indicated by the letter B followed by the exponent, similar to E in decimal scientific notation. Thus one would write 3B20 for 3 × 220. This convention is still used on some calculators to present binary floating point-numbers today.

In 1969, Donald Knuth, who uses decimal notation like 1 MB = 1000 kB, proposed that the powers of 1024 be designated as "large kilobytes" and "large megabytes", with abbreviations KKB and MMB.

Consumer confusion
The ambiguous meanings of "kilo", "mega", "giga", etc., has caused significant consumer confusion, especially in the personal computer era. A common source of confusion was the discrepancy between the capacities of hard drives specified by manufacturers, using those prefixes in the decimal sense, and the numbers reported by operating systems and other software, that used them in the binary sense, such as the Apple Macintosh in 1984. For example, a hard drive marketed as "1 TB" could be reported as having only "931 GB". The confusion was compounded by fact that RAM manufacturers used the binary sense too.

Legal disputes
The different interpretations of disk size prefixes led to class action lawsuits against digital storage manufacturers. These cases involved both flash memory and hard disk drives.

Early cases
Early cases (2004–2007) were settled prior to any court ruling with the manufacturers admitting no wrongdoing but agreeing to clarify the storage capacity of their products on the consumer packaging. Accordingly, many flash memory and hard disk manufacturers have disclosures on their packaging and web sites clarifying the formatted capacity of the devices or defining MB as 1 million bytes and 1 GB as 1 billion bytes.

Willem Vroegh v. Eastman Kodak Company
On 20 February 2004, Willem Vroegh filed a lawsuit against Lexar Media, Dane–Elec Memory, Fuji Photo Film USA, Eastman Kodak Company, Kingston Technology Company, Inc., Memorex Products, Inc.; PNY Technologies Inc., SanDisk Corporation, Verbatim Corporation, and Viking Interworks alleging that their descriptions of the capacity of their flash memory cards were false and misleading.

Vroegh claimed that a 256 MB Flash Memory Device had only 244 MB of accessible memory. "Plaintiffs allege that Defendants marketed the memory capacity of their products by assuming that one megabyte equals one million bytes and one gigabyte equals one billion bytes." The plaintiffs wanted the defendants to use the customary values of 10242 for megabyte and 10243 for gigabyte. The plaintiffs acknowledged that the IEC and IEEE standards define a MB as one million bytes but stated that the industry has largely ignored the IEC standards.

The parties agreed that manufacturers could continue to use the decimal definition so long as the definition was added to the packaging and web sites. The consumers could apply for "a discount of ten percent off a future online purchase from Defendants' Online Stores Flash Memory Device".

Orin Safier v. Western Digital Corporation
On 7 July 2005, an action entitled Orin Safier v. Western Digital Corporation, et al. was filed in the Superior Court for the City and County of San Francisco, Case No. CGC-05-442812. The case was subsequently moved to the Northern District of California, Case No. 05-03353 BZ.

Although Western Digital maintained that their usage of units is consistent with "the indisputably correct industry standard for measuring and describing storage capacity", and that they "cannot be expected to reform the software industry", they agreed to settle in March 2006 with 14 June 2006 as the Final Approval hearing date.

Western Digital offered to compensate customers with a free download of backup and recovery software valued at US$30. They also paid $$4,770,000 Hz$ in fees and expenses to San Francisco lawyers Adam Gutride and Seth Safier, who filed the suit. The settlement called for Western Digital to add a disclaimer to their later packaging and advertising.

Western Digital had this footnote in their settlement. "Apparently, Plaintiff believes that he could sue an egg company for fraud for labeling a carton of 12 eggs a 'dozen', because some bakers would view a 'dozen' as including 13 items."

Cho v. Seagate Technology (US) Holdings, Inc.
A lawsuit (Cho v. Seagate Technology (US) Holdings, Inc., San Francisco Superior Court, Case No. CGC-06-453195) was filed against Seagate Technology, alleging that Seagate overrepresented the amount of usable storage by 7% on hard drives sold between 22 March 2001 and 26 September 2007. The case was settled without Seagate admitting wrongdoing, but agreeing to supply those purchasers with free backup software or a 5% refund on the cost of the drives.

Dinan et al. v. SanDisk LLC
On 22 January 2020, the district court of the Northern District of California ruled in favor of the defendant, SanDisk, upholding its use of "GB" to mean $100,000,000$.

IEC 1999 Standard
In 1995, the International Union of Pure and Applied Chemistry's (IUPAC) Interdivisional Committee on Nomenclature and Symbols (IDCNS) proposed the prefixes "kibi" (short for "kilobinary"), "mebi" ("megabinary"), "gibi" ("gigabinary") and "tebi" ("terabinary"), with respective symbols "kb", "Mb", "Gb" and "Tb", for binary multipliers. The proposal suggested that the SI prefixes should be used only for powers of 10; so that a disk drive capacity of "500 gigabytes", "0.5 terabytes", "500 GB", or "0.5 TB" should all mean $56,000$, exactly or approximately, rather than 500 × 230 (= $44.1 kHz$) or 0.5 × 240 (= $44,100$).

The proposal was not accepted by IUPAC at the time, but was taken up in 1996 by the Institute of Electrical and Electronics Engineers (IEEE) in collaboration with the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC). The prefixes "kibi", "mebi", "gibi" and "tebi" were retained, but with the symbols "Ki" (with capital "K"), "Mi", "Gi" and "Ti" respectively.

In January 1999, the IEC published this proposal, with additional prefixes "pebi" ("Pi") and "exbi" ("Ei"), as an international standard (IEC 60027-2 Amendment 2)  The standard reaffirmed the BIPM's position that the SI prefixes should always denote powers of 10. The third edition of the standard, published in 2005, added prefixes "zebi" and "yobi", thus matching all then-defined SI prefixes with binary counterparts.

The harmonized ISO/IEC IEC 80000-13:2008 standard cancels and replaces subclauses 3.8 and 3.9 of IEC 60027-2:2005 (those defining prefixes for binary multiples). The only significant change is the addition of explicit definitions for some quantities. In 2009, the prefixes kibi-, mebi-, etc. were defined by ISO 80000-1 in their own right, independently of the kibibyte, mebibyte, and so on.

The BIPM standard JCGM 200:2012 "International vocabulary of metrology – Basic and general concepts and associated terms (VIM), 3rd edition" lists the IEC binary prefixes and states "SI prefixes refer strictly to powers of 10, and should not be used for powers of 2. For example, 1 kilobit should not be used to represent $125,000,000$ bits (210 bits), which is 1 kibibit."

The IEC 60027-2 standard recommended operating systems and other software were updated to use binary or decimal prefixes consistently, but incorrect usage of SI prefixes for binary multiples is still common. At the time, the IEEE decided that their standards would use the prefixes "kilo", etc. with their metric definitions, but allowed the binary definitions to be used in an interim period as long as such usage was explicitly pointed out on a case-by-case basis.

Other standards bodies and organizations
The IEC standard binary prefixes are supported by other standardization bodies and technical organizations.

The United States National Institute of Standards and Technology (NIST) supports the ISO/IEC standards for "Prefixes for binary multiples" and has a web page documenting them, describing and justifying their use. NIST suggests that in English, the first syllable of the name of the binary-multiple prefix should be pronounced in the same way as the first syllable of the name of the corresponding SI prefix, and that the second syllable should be pronounced as bee. NIST has stated the SI prefixes "refer strictly to powers of 10" and that the binary definitions "should not be used" for them.

As of 2014, the microelectronics industry standards body JEDEC describes the IEC prefixes in its online dictionary, but acknowledges that the SI prefixes and the symbols "K", "M" and "G" are still commonly used with the binary sense for memory sizes.

On 19 March 2005, the IEEE standard IEEE 1541-2002 ("Prefixes for Binary Multiples") was elevated to a full-use standard by the IEEE Standards Association after a two-year trial period. , the IEEE Publications division does not require the use of IEC prefixes in its major magazines such as Spectrum or Computer.

The International Bureau of Weights and Measures (BIPM), which maintains the International System of Units (SI), expressly prohibits the use of SI prefixes to denote binary multiples, and recommends the use of the IEC prefixes as an alternative since units of information are not included in the SI.

The Society of Automotive Engineers (SAE) prohibits the use of SI prefixes with anything but a power-of-1000 meaning, but does not cite the IEC binary prefixes.

The European Committee for Electrotechnical Standardization (CENELEC) adopted the IEC-recommended binary prefixes via the harmonization document HD 60027-2:2003-03. The European Union (EU) has required the use of the IEC binary prefixes since 2007.

Current practice

Some computer industry participants, such as Hewlett-Packard (HP), and IBM have adopted or recommended IEC binary prefixes as part of their general documentation policies.

As of 2023, the use of SI prefixes with the binary meanings is still prevalent for specifying the capacity of the main memory of computers, of RAM, ROM, EPROM, and EEPROM chips and modules, and of the cache of computer processors. For example, a "512-megabyte" or "512 MB" memory module holds 512 MiB; that is, 512 × 220 bytes, not 512 × 106 bytes.

JEDEC continues to include the customary binary definitions of "kilo", "mega", and "giga" in the document Terms, Definitions, and Letter Symbols, and,, still used those definitions in their memory standards.

On the other hand, the SI prefixes with powers of ten meanings are generally used for the capacity of external storage units, such as disk drives,    solid state drives, and USB flash drives, except for some flash memory chips intended to be used as EEPROMs. However, some disk manufacturers have used the IEC prefixes to avoid confusion. The decimal meaning of SI prefixes is usually also intended in measurements of data transfer rates, and clock speeds.

Some operating systems and other software use either the IEC binary multiplier symbols ("Ki", "Mi", etc.)     or the SI multiplier symbols ("k", "M", "G", etc.) with decimal meaning. Some programs, such as the Linux/GNU ls command, let the user choose between binary or decimal multipliers. However, some continue to use the SI symbols with the binary meanings, even when reporting disk or file sizes. Some programs may also use "K" instead of "k", with either meaning.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Binary prefix