Talk:Binary prefix/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Discussion of page name

This page needs a rename as part of the "Kill your friendly neighbourhood stub" campaign. Any suggestions? At the risk of sounding a little audacious, I suggest a renaming from "Byte/Prefixes" to "Byte prefixes" ;-) -- Tarquin 20:09, 22 September 2002 (UTC)

Change "Byte" to "Binary", because these prefixes are also applied to other units such as bits and words (as the introductory text clearly says!) -- Dwheeler 21:26 21 May 2003 (UTC)

Discouraging deprecated usage

I find it a bit confusing to have the first table listing the deprecated usage of the prefixes. Maybe it's better to have the first table listing the current standard, then have the colloquial usage listed much later in the article... --Bob03:33 Oct 14, 2002 (UTC)

Better yet, kill the first table altogether. The bottom half is superfluous anyway. I have never seen "yotta" being used meaning 2^80, except by a handful of nerds at Wikipedia... ;-) Herbee 02:52, 2004 Feb 21 (UTC)

The mythical nona- and dogga-

User:81.63.111.215 added the phrase "as well as nobi- and dogbi-", presumably based on the assumption that there are legitimate decimal-based prefixes nona- for 10²⁷ and dogga- for 10³⁰. They are not SI prefixes, or at least NIST knoweth not of them. I'm perfectly prepared to be convinced of their existence, but I want to see some evidence that some recognized standards organization is promulgating them. I have so far found nothing but loose assertions in Google searches. Dpbsmith 00:27, 21 Mar 2004 (UTC)

The official list of prefixes is maintained by the Bureau International des Poids et Mesures. Consider that evidence against this nonsense. Herbee 02:37, 2004 Mar 21 (UTC)

Thanks for keeping up on all of this, dpb. +sj+

VfD, re: Zebi/Yobibyte

Further information: Wikipedia:Votes for deletion/Zebibyte

Hexadecimal billion

Further information: Talk:Binary prefix/Hexadecimal Billion

Hard disk sizes

My Maxtor 40 GB is actually 38.2 GB (dd tells me it has 80022600 sectors, or 38.1577 MB). That's 39,073.5352 MB, 40,011,300 K, 40,971,571,200 bytes. OTOH, my Maxtor 160 GB has 320173056 sectors, or 152.67 GB. That's 156,334.5 MB, 160,086,528 K, 163,928,576,512 bytes. Clearly, if GB meant 1000*1024*1024 bytes, then they'd be giving me less than claimed (and I could sue them!). If GB meant 1000³ bytes, they'd be giving me almost a gig more for my 40 GB, and almost 4 gigs more for my 160 GB. They probably use 1 GB = 1000*1000*1024 bytes.

But my Quantum Fireball advertises "4.0 GB" and actually has that much (assuming Windows is accurate), 4.0062 GB, 4102.32 MB, 4200776 K, 4301594624 bytes. It also says "4.3AT" and has "43" in the model number, which I assume refers to 4.3 decimal GB.

Then, my Seagate 40 GB has 78163247 sectors, or 37.2711 GB, 38165.6479 MB, 39081623.5 K, 40019582464 bytes. It should have 78165360 sectors (according to the specs), no idea why it has less. It'd be false advertising unless GB meant 1000*1000*1000 bytes. Western Digital seems to use 1 GB = 1000*1000*1000 bytes, as well (which means it was worth paying more for my Maxtor). Hitachi seems to use 1000*1000*1024 bytes.

So we have one company using 1024³ (except I have no recent HDs from Quantum, and they don't seem to make them anymore), two companies using 1000²*1024, and two more using 1000³.

Elektron 22:25, 2004 Aug 30 (UTC)

Also, Toshiba uses 1 GB = 1000³ bytes, so does Fujitsu. Samsung says they use 1000³, and not-so-official sector counts appear to confirm this. Since Quantum doesn't make hard disks anymore, for current hard disks, we have two companies using 1000²*1024, and five using 1000³ Elektron 23:36, 2004 Aug 30 (UTC)

Consolidate all the little articles

I propose that all the little articles:

SI, bits	SI, bytes	IEC, bits	IEC, bytes
Kilobit	Kilobyte	Kibibit	Kibibyte
Megabit	Megabyte	Mebibit	Mebibyte
Gigabit	Gigabyte	Gibibit	Gibibyte
Terabit	Terabyte	Tebibit	Tebibyte
Petabit	Petabyte	Pebibit	Pebibyte
Exabit	Exabyte	Exbibit	Exbibyte
Zettabit	Zettabyte	—	—
Yottabit	Yottabyte	—	—

should be consolidated into this article (without destroying any useful information). If they are not, then someone should at least go through them all and lowercase all of them. Unit names are always lowercase. For instance:

"The Gibibyte is closely related to the Gigabyte, which is..." should be

"The gibibyte is closely related to the gigabyte, which is...", etc. - Omegatron 03:44, Sep 24, 2004 (UTC)

I concur, but really, the SI "gigabyte" isn't really a 'binary prefix'. One day I think I'll have to do this though. Elektron 20:01, 2004 Nov 1 (UTC)

Why not? That's what this article is about; using giga and gibi as binary prefixes. The individual "small" articles are getting bigger, though. - Omegatron 20:17, Nov 1, 2004 (UTC)

I still think all the little articles should be combined into this article. Kibibyte, for instance, has info that is not in Mebibyte. It's really silly to have a separate article for each one, that basically only contains a single number and it's relation to two other numbers. All of that info should be in this article, and then the info that isn't doubled everywhere will be in one place. - Omegatron 18:57, Dec 21, 2004 (UTC)

Nobody objected, so go ahead and do it if you want. [[User:Smyth|– Smyth\^talk]] 19:36, 21 Dec 2004 (UTC)

Nobody said it was a good idea, either. Plus it will take some significant work with the bigger articles like megabyte. Don't wanna change it if everyone is suddenly going to say "no that was bad" and revert it. - Omegatron 14:22, Dec 29, 2004 (UTC)

I thought this sort of thing was already done with other articles like kilowatt, attogram, and so on, except now that I look, they all have little articles for each. Hmm... Has there been discussion about this for other units? - Omegatron 22:21, Dec 30, 2004 (UTC)

I agree that gigabyte shouldn't redirect here... it's not a binary prefix, and that would just confuse things. However, it wouldn't be a bad idea to go through all the articles and strip out all the information that belongs in more general articles (like this one) and replace it with a quick summary and link to the more comprehensive discussion, per Wikipedia:Summary style. The amount of duplication is distressing. 68.81.231.127

Good point. gigabit/byte should not redirect, i guess, even though they are binary prefixes in this instance (according to this article, giga, mega, etc. can be used as both binary prefixes and SI prefixes, though I think they should only be considered SI prefixes. but according to this very article, they ARE binary prefixes...) I already added the see also binary prefix to each article, but no one notices and just adds stuff to each individual article. - Omegatron 20:07, Jan 13, 2005 (UTC)

It's even worse.. those are SI prefixes, but they are not SI units because B is not an SI symbol for byte (or even Bel, at least not yet I think :). And then there are special case like the 1,024×1,000 megabyte variant....

Anyway, a lot of articles seem to link to the kilo-, mega-, and giga- variants (150–250 for the -bytes series), while tera- is only linked about 50 times, and peta- and higher have <20 each. So at least the big three or four are natural links, and might justify their own articles. There are also enough special cases in the big three (which industry uses it, etc) that they'd still need separate sections in a big article, so it's probably easier to keep them separate. (I don't think it matters either way, but if the larger units are turned into redirects, they should probably be pointed to byte [or bit].)

Byte unit (SI prefix)
Other:	kilo- | mega- | giga- | tera- | peta- | exa- | zeta-
Related bit unit: Megabit
Related binary prefix unit: Mebibyte

A bigger problem is reducing duplication of effort. There is very different text saying very similar things on different pages. A Wikipedia:Navigational templates could help with all the related units, while using a standard paragraph and pointer to the main articles here and at the SI prefix page using would clear out a lot of the rest (using Wikipedia:Summary style again... there is an example at Gigabyte#Distinction between 1000 and 1024 megabytes, though it needs a lot of work). The navigation template to the right needs some work, but really like simple over cluttered... ahem... Afrotropic is an abomination :).

I'm just playing with ideas... I'm not even sure this is the right approach. 68.81.231.127 00:09, 14 Jan 2005 (UTC)

Alright. If we're not going to consolidate all the little articles, we should add a template to all of them with all of the others on it. Anons search for "petabyte", find our article, and then start adding info about gigabytes, etc. We need to indicate that there already are articles about each particular value and also about this article. - Omegatron 01:16, Mar 24, 2005 (UTC)

Template for Binary prefixes

I have created a template available at:

{{Binary prefixes}}

which I would like to insert into this article. I would hope that this could enable aome rationalisation of the existing tables, and could perhaps eventually be inserted into all the individual binary prefix articles, e.g. kibi, mebi, etc (assuming that they are not merged beforehand).

Does anyone have any objection or wish to edit the template beforehand (see edit link in top line of template)? Ian Cairns 21:47, 15 Nov 2004 (UTC)

Looks good. pretty big though. maybe list only as powers of 10 and powers of 2? - Omegatron 22:55, Nov 15, 2004 (UTC)

Very good, but not 800x600 friendly. Alternating table row backgrounds would be nice though. --Delicates 03:09, 24 Nov 2004 (UTC)

I've reduced the overall width by removing the number values. Is this any better, particularly for 800x600? (The alternating backgrounds will have to wait for another day...) Ian Cairns 18:46, 24 Nov 2004 (UTC)

Now I really don't like the middle section, and don't think it deserves a place under the sun due to it being inappropriately erroneous, and making the whole table ambiguous and confusing. Might want to put word "standard" as well into the SI heading. The IEC section lacks the 2ⁿ column which is more appropriate there. --Delicates 22:13, 24 Nov 2004 (UTC)

Thanks for that. I'm concerned that you think it's erroneous. Please can you indicate where the errors might be? The SI prefixes are known as such in Wikipedia, so I didn't see the need to include the word 'standard'. If they become known as SI standard prefixes, then I'm happy to change the template. Regarding the 2^n column, I was told that the table was too wide as it was previously. I was trying to avoid duplicating the same column. I have been wondering whether it might be possible to remove one of the 'kilo' columns to reduce the width further without generating confusion, but I don't think this can be done easily. Please can you indicate where you find the template confusing? Alternatively, be bold with your editing and let others review your changes. Thanks, Ian Cairns 23:35, 24 Nov 2004 (UTC)

The problem I have with it is that it has two identical columns that contradict eachother which is both erroneous and confusing in context of the same table. I think the middle section should be taken out alltogether, because it is redundant in the presence of “≈” symbol, which makes the association of the SI prefixes with the binary meaning pretty clear. The only problem that with this is the inconsistent use of ‘k’ and ‘K’ for “kilobyte”. The people who find this page through a search engine won't be aware of SI prefixes being known in Wikipedia as standard. It is good to be consistent so that people don't have doubts when they see something applied to one thing but not to another. --Delicates 02:13, 25 Nov 2004 (UTC)

Given that Delicates thought the template was 'very good' at 03:09, I've added the template to the existing article, to see it in context - without thinking yet whether any of the existing tables can now be rationalised / avoided. Ian Cairns 00:22, 25 Nov 2004 (UTC)

pebi, mebi, etc. just redirect to this article, you know. - Omegatron 22:25, Dec 30, 2004 (UTC)

Binary or decimal context implied by electronic memory

In the page, I see the quote: Electronic memory such as RAM and ROM always uses the binary versions, because the physical structure of the device makes it naturally come in sizes that are powers of two.

This isn't true, but I don't yet know how to fix it concisely, help.

For example, flash is an electronic memory, and ECC-protected RAM is an electronic memory, but their capacities aren't naturally powers of two.

A concise true alternative I saw said recently was: The RAM and ROM folk gave us this confusion by behaving as if memory were reliable. That is, by converting to precise binary prefixes from loose decimal approximations, they left no room for ECC, etc.

In more detail ...

All that's naturally a power of two in memory is the count of raw cells in a single layer.

Yes, P * Q cells appear in a rectangular array. P * Q is a power of 2 because P and Q are powers of 2. P and Q are powers of 2 because pins cost much money. If you make N pins into an address bus, then you can address 2^N rows or columns. Yes. So far so good.

But electronic memory today - 2005 - often contains a lot more than a single layer of raw 1 or 0 cells. As in modems, so now in memory cells, the discrete stored voltage may be multilevel, e.g., representing 0 or 1 or 2 or 3 or 4, not always binary. The chip may contain more than one layer. Part of the chip may be dedicated to ECC, or left free for wear-leveling.

Consequently, the capacity of flash memory in particular is now "continuously variable", and their physicists follow the HDD physicists by using the standard metric units to count bits.

—Preceding unsigned comment added by 65.241.179.2 (talk • contribs) 15:32, 23 January 2005

Memory controllers on motherboards always address whole bytes (which includes any parity or ecc bits) or whole words (whole multiples of whole bytes) in chunks measured in binary multiples. This is because binary math is the natural form for practically all processors. The presence of ECC in RAM makes no difference. The ECC bits are part of the byte, even though the ECC bits are not sent to the CPU, the memory controller reads the extra bits when it reads the byte. RAM modules are always measured according to how many binary multiple bytes are available no matter how wide the data path is.

"Flash memory" today refers to non-volitile storage devices that are accessed exactly like hard drives. They use virtual cylinder, head, and sector specifications for the computer system to address the device and even though they contain memory that is accessed in a "random" (non-serial) method, in discreet rows and columns, it is not considered "RAM".

Yes, Flash often uses multilevel cell technology, but the data is converted to a binary representation. So even though one cell can hold more than a simple on/off representation, the absolute capacity is still a function of bits and bytes. And the memory used by the CPU through the memory controller does not yet use multilevel cell technology. DDR and RAMBUS are still ones and zeros.

Flash manufacturers have followed the hard disk drive path to designate capacity, decimal. No matter how many ECC cells or spare cells for wear-leveling are allocated, the capacity is based on decimal multiples and does not include the spares and ECC.

So I guess I would say, instead of, "Electronic memory such as RAM and ROM always uses the binary versions, because the physical structure of the device makes it naturally come in sizes that are powers of two. I propose, "RAM memory modules always designate capacity in binary multiples because that type of math is "native" to binary processors. or " because CPU's use RAM in binary multiples and building RAM modules according to that system is most logical."

JJLatWiki 18 July 2005 09:11 (Pacific Daylight)

"Flash memory" today refers to non-volitile storage devices that are accessed exactly like hard drives.

Large flash units used for bulk storage are certainly treated like hard drives but bare flash chips and flash used in microcontrolors for program storage is far more like a more conviniant to use variant of EPROM (reads out like rom, requires special actions for programming) Plugwash 23:53, 16 June 2006 (UTC)

Do not include -zebi and -yobi

There are no such prefixes. They should not be included in a table that purports to be documenting the IEC standard. Everyone understand, and the article states explicitly, that they are the logical extension of the IEC system, but until and unless the IEC chooses to extend the system they should not be included. Dpbsmith (talk) 19:35, 30 Jan 2005 (UTC)

• PLEASE DO NOT reinsert these values into the table without discussion. They are not "unofficial extensions." They are not real terms at all. They are purely speculative; someone's guess as to what names would be used if these units had names. I believe, based on Google hits, that they are mostly a sort of nerdish urban legend propagated by people copying tables from teach other. Unless you can convince me otherwise by showing a good citation from a serious, authoritative source that shows the names "zebibyte" and "yobibyte" are in real use in the computer field, I will continue to feel that these should not be in the table of binary prefixes at all. I don't mind the sentence pointing out that -zebi and -yobi are the obvious continuations. I'm not at all sure it's necessary to give the numeric values of 2⁷⁰ and 2⁸⁰, but you wanted them there and I didn't see a problem with it. Change them to the 1000ⁿ×1.#### format if you think that provides more insight. But they should not go in the main table. Dpbsmith (talk) 13:34, 4 Feb 2005 (UTC)

I'm just not sure what harm there is in adding them to the table, properly identified as speculative. Why the allergy? As for giving the values, yes they are required because they're not easily calculated (i.e. they must be done by hand, unless you have some peculiar calculator available). Ah well, this is not worth an edit war, obviously.

Urhixidur 00:51, 2005 Feb 5 (UTC)

What's so hard about 1024 × = = = = = = = = on the calculator that comes with Windows and many other calculators? Gene Nygaard 01:02, 5 Feb 2005 (UTC)

The Calculator handles it, because it takes special care with large numbers. Excel, on the other hand, uses normal integers and thus fails to carry enough precision.

Urhixidur 15:47, 2005 Mar 27 (UTC)

B is for bel

In editing the article, Urhixidur commented " B is Bel, b recommended for byte".

Big deal. B is also for boron.

But you'd need to change that last b to an m to describe someone who imagines a likelihood of even as much confusion between bytes and bels (lowercase, of course) as there would be between boron and bels.

1. Why should bels get preference in any case? They aren't an SI unit, are only listed as acceptable for use with SI.
2. Bels and bytes are used in completely different fields of activity.
3. The bel is never used standing alone, and never used with any prefix other than "deci-".
4. Bytes are never used WITH the prefix "deci-".

Those points are, of course, applicable even setting aside the reason I changed Urhixidur's edits in the first place; "b" is used as the symbol for "bits" in this article, and it would be silly to use the same symbol for "bytes" as well. Gene Nygaard 23:44, 30 Jan 2005 (UTC)

One more point about SI: In SI, the radian (symbol rad) is a derived unit. The rad (symbol rad) is among the units in Table 10 of the BIPM brochure and in Table 9, temporarily accepted for use with the SI, in the NIST brochure. Gene Nygaard 00:01, 31 Jan 2005 (UTC)

« Why should bels get preference in any case? »

Because of the well established rule that upper-case symbols tand for units named after people, in this case Alexander Graham Bell.

« Those points are, of course, applicable even setting aside the reason I changed Urhixidur's edits in the first place; "b" is used as the symbol for "bits" in this article, and it would be silly to use the same symbol for "bytes" as well. »

There is not a single occurrence of "b" standing for bit anywhere in the article.

Urhixidur 01:30, 2005 Feb 5 (UTC)