![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | → | Archive 10 |
Warning: These values are wrong, SI uses 10-based counting, not 2-based. SEC (below) is 2-based. This also seems formatted quite messily (spaces everywhere).
Comments to the article like that belong here. Or fix the article if you think its wrong. -- kudz75 06:26, 30 May 2005 (UTC)
Added again by User:66.231.16.111 as a HTML comment - Omegatron 19:28, May 30, 2005 (UTC)
non standard usage? i noted a warning about this being incorrect, and i commented on the spaces used for formatting, but i mreant around the table headings (" Symbol " or " Value ") ... not the numerical seperator used for reading clarity. the original author says SI kilo for bytes is 2^10 = 1024, that's the SEC KiB (noted below). SI kB or KB is 10^3 = 1000 ... hard disk manufactorers say "1 GB = 1 000 000 000 bytes" because they use SI numbering ... or 10 based counting, which is what SI is for, not base 2 counting, which SEC does. I added this as a comment this time so that i don't pollute the document, but I didn't know who to take this to
(please note that they meant Megabytes (MB) int his article when they said Mb) Cavebear42 23:36, 31 May 2005 (UTC)
To clarify this: CD capacity is measured in minutes, based on the original "Red Book" standard for audio CD's. Audio CD's play at 75 blocks per second (most people say "sectors" but this is arguably incorrect because CD's use a spiral track). For audio, the usable amount of data per block is 2352 bytes (usually referred to as "raw bytes"); for CD-ROM ("Yellow Book") the usable amount of data is reduced to 2048 "cooked" bytes per block because of added error detection and error correction bytes.
So, in slightly different formulas (with the same results):
The longest CD that can possibly be recorded (but violates some Red-Book specifications) is 99 minutes, 59 seconds and 74 blocks, because of the BCD-based encoding of timing information:
Jac goudsmit 23:05, 26 September 2007 (UTC)
Bitrate: "192 kbps" Length: 262.3 s Expected size if "k" = 1000: 192 * 1000 * 262.3 / 8 = 6295200 bytes Expected size if "k" = 1024: 192 * 1024 * 262.3 / 8 = 6446284 bytes Actual size: 6296347 bytes
I think the new table "Approximate ratios between binary prefixes and their decimal equivalent" should be folded into the preexisting tables. ("> 109 (7.4% error)" and so on) - Omegatron 14:22, Jun 6, 2005 (UTC)
I've rewritten some text on the 1000*1024 hybrid "megabyte" used e.g. in floppies. This text was quite properly restored by User:Smyth after deletion by an anon. I just checked http://www.cdw.com and as of 2005 every vendor still refers to the standard floppy as nominally 1.44 MB.
Now, as for Windows XP, the situation is curioser and curioser. I was going to put something in the article but changed my mind pending any rational explanation of what Windows XP is doing.
As of the last time I tried, which was five minutes ago: when formatting a 3.5" floppy, Windows XP's formatting utility designates the diskette and the formatting operation as
That is, Windows XP still uses 1.44MB as the nominal capacity of a floppy.
But, after formatting, Properties reports the "capacity"
(which is exactly 2847 sectors BTW... and only 1.4235 "hybrid" 1024000 megabytes, not 1.44, so obviously this is the usable capacity after the overhead of the FAT directory is deducted).
Now, 1457664 / 1024 / 1024 = 1.39014 MiB. That is, the second value is NOT consistent with MB meaning MiB, and cannot be explained as roundoff error since the fraction BOTH rounds AND truncates to 1.39 MiB, not 1.38 MiB.
Sounds like some kind of unaccountable sloppiness on Microsoft's part. I can come up with the following wild-ass guess. Suppose there was some point in the code's history in which the code computed 1457664 / 1024 / 1000 = 1.4235 hybrid "megabytes."
Now suppose that for some reason that was arbitrarily truncated to 1.42 MB for display.
Now suppose someone came along and decided that it should be displayed in 1024 * 1024-byte "MB."
Now suppose that instead of fixing the calculation they slapped on a correction.
Now suppose that for some reason they based the correction on 1.42 rather than 1.4235.
1.42 * 1000 / 1024 = 1.3867
Finally, suppose for some utterly unaccountable reason they decided to truncate rather than round... well, I guess you could get 1.38.
Given that all of the intermediate values in the appropriate calculations can be expressed EXACTLY in binary fractions OR decimals OR floating point with a very reasonable number of decimal places, this would seem to suggest sloppiness.
Yes, I remember the days when computers were still occasionally used for computing and programmers were expected to know the rudiments of mathematics and numerical analysis. Just hand me that slide rule, Sonny, and some carbon paper to put in my IBM Selectric. Dpbsmith (talk) 13:18, 21 Jun 2005 (UTC)
There is a discussion going on at Talk:kilobyte about the POVness of kilo- = 1000, etc. - Omegatron 04:13, Jun 26, 2005 (UTC)
Discussion at Wikipedia:Village pump (policy)/Archive I#Unit Disagreement.2C MiB vs. MB. - Omegatron July 8, 2005 12:58 (UTC)
A vote has been started on whether Wikipedia should use these prefixes all the time, only in highly technical contexts, or never. - Omegatron 14:49, July 12, 2005 (UTC)
User:Pmsyyz wrote (in bold): As of 2005 this naming convention [Kibi...] has not gained widespread use, but its use is growing. It is strongly supported by many standardization bodies, including IEEE and CIPM.
I think there is a non-neutral POV in this sentence, "Hard disk drive manufacturers state capacity in decimal units, so what is advertised as a "30 GB" hard drive will hold 30 × 10^9 bytes, roughly equal to 28×2^30 bytes (i.e. 28 GiB)."
It implies that HD manufacturers specifically use the decimal designation to inflate the capacity designation. While it may be true at this point in history, it almost certainly was not the original intent of the engineers who created the first hard drives. I propose something like, "Hard disk drive manufacturers state capacity in decimal units. Since most computer operating systems report drive usage and capacity in binary units, the difference causes an apparent loss between the advertised capacity and the formatted, usable capacity."
Second, since the article speculates on the tradition of using decimal units for HDD capacity, I don't think the immediate subsequent statement is accurate, "This usage has a long engineering tradition, and was probably not influenced by marketing. It arose because nothing about the physical structure of the disk drives makes power-of-two capacities natural: the number of platters, tracks and sectors per track are all continuously variable."
I propose, "The decimal unit capacity in hard disk drives follows the method used for serially accessed storage media which predated direct access storage media like hard disk drives. Paper punch cards could only be used in a serial fashion, like the magnetic tapes that followed. When a stream of data is stored, it's more logical to indicate how many thousands, millions, or billions of bytes have been stored versus how many 1024, 1,048,576, or 1,073,741,824 bytes have been. When the first hard disk drives were being developed, the decimal measurement was only natural since the hard disk drive served essentially the same function as punch cards and tapes. Thus today, any device that is addressed or seen as "storage" uses the decimal system to identify capacity."
JJLatWiki 18 July 2005 16:09 (UTC)
I added the Legal Disputes section. The information I provided is publically available in many places on the web. Within each case is exactly the kinds of debates going on here.
In my opinion, the difference though is that these people are attempting to take advantage of the debate and claim that corporations are literally charging "per megabyte" and that the corporate megabyte is smaller than the "commonly understood" megabyte and so the consumer is being deceived and cheated. In my opinion, the plaintiffs are filing frivolous lawsuits without merit.
Even though the capacity available to the user is (almost universally) less than the capacity designation, consumers do not pay a dollar amount per mega/gigabyte, therefore they are not paying something for nothing. Likewise, there are no hard drive or Flash drive manufacturers who designate capacity in the binary method and are therefore harmed by the other manufacturers' deception.
EVEN IF the capacity designation were accurate according to the binary method, and a 30GB drive had a formatted capacity of 32,212,254,720 bytes, it is a practical impossibility to store 32,212,254,720 bytes of user data on such a drive. Who is to be sued for THESE losses?
JJLatWiki 18:50, 18 July 2005 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | → | Archive 10 |
Warning: These values are wrong, SI uses 10-based counting, not 2-based. SEC (below) is 2-based. This also seems formatted quite messily (spaces everywhere).
Comments to the article like that belong here. Or fix the article if you think its wrong. -- kudz75 06:26, 30 May 2005 (UTC)
Added again by User:66.231.16.111 as a HTML comment - Omegatron 19:28, May 30, 2005 (UTC)
non standard usage? i noted a warning about this being incorrect, and i commented on the spaces used for formatting, but i mreant around the table headings (" Symbol " or " Value ") ... not the numerical seperator used for reading clarity. the original author says SI kilo for bytes is 2^10 = 1024, that's the SEC KiB (noted below). SI kB or KB is 10^3 = 1000 ... hard disk manufactorers say "1 GB = 1 000 000 000 bytes" because they use SI numbering ... or 10 based counting, which is what SI is for, not base 2 counting, which SEC does. I added this as a comment this time so that i don't pollute the document, but I didn't know who to take this to
(please note that they meant Megabytes (MB) int his article when they said Mb) Cavebear42 23:36, 31 May 2005 (UTC)
To clarify this: CD capacity is measured in minutes, based on the original "Red Book" standard for audio CD's. Audio CD's play at 75 blocks per second (most people say "sectors" but this is arguably incorrect because CD's use a spiral track). For audio, the usable amount of data per block is 2352 bytes (usually referred to as "raw bytes"); for CD-ROM ("Yellow Book") the usable amount of data is reduced to 2048 "cooked" bytes per block because of added error detection and error correction bytes.
So, in slightly different formulas (with the same results):
The longest CD that can possibly be recorded (but violates some Red-Book specifications) is 99 minutes, 59 seconds and 74 blocks, because of the BCD-based encoding of timing information:
Jac goudsmit 23:05, 26 September 2007 (UTC)
Bitrate: "192 kbps" Length: 262.3 s Expected size if "k" = 1000: 192 * 1000 * 262.3 / 8 = 6295200 bytes Expected size if "k" = 1024: 192 * 1024 * 262.3 / 8 = 6446284 bytes Actual size: 6296347 bytes
I think the new table "Approximate ratios between binary prefixes and their decimal equivalent" should be folded into the preexisting tables. ("> 109 (7.4% error)" and so on) - Omegatron 14:22, Jun 6, 2005 (UTC)
I've rewritten some text on the 1000*1024 hybrid "megabyte" used e.g. in floppies. This text was quite properly restored by User:Smyth after deletion by an anon. I just checked http://www.cdw.com and as of 2005 every vendor still refers to the standard floppy as nominally 1.44 MB.
Now, as for Windows XP, the situation is curioser and curioser. I was going to put something in the article but changed my mind pending any rational explanation of what Windows XP is doing.
As of the last time I tried, which was five minutes ago: when formatting a 3.5" floppy, Windows XP's formatting utility designates the diskette and the formatting operation as
That is, Windows XP still uses 1.44MB as the nominal capacity of a floppy.
But, after formatting, Properties reports the "capacity"
(which is exactly 2847 sectors BTW... and only 1.4235 "hybrid" 1024000 megabytes, not 1.44, so obviously this is the usable capacity after the overhead of the FAT directory is deducted).
Now, 1457664 / 1024 / 1024 = 1.39014 MiB. That is, the second value is NOT consistent with MB meaning MiB, and cannot be explained as roundoff error since the fraction BOTH rounds AND truncates to 1.39 MiB, not 1.38 MiB.
Sounds like some kind of unaccountable sloppiness on Microsoft's part. I can come up with the following wild-ass guess. Suppose there was some point in the code's history in which the code computed 1457664 / 1024 / 1000 = 1.4235 hybrid "megabytes."
Now suppose that for some reason that was arbitrarily truncated to 1.42 MB for display.
Now suppose someone came along and decided that it should be displayed in 1024 * 1024-byte "MB."
Now suppose that instead of fixing the calculation they slapped on a correction.
Now suppose that for some reason they based the correction on 1.42 rather than 1.4235.
1.42 * 1000 / 1024 = 1.3867
Finally, suppose for some utterly unaccountable reason they decided to truncate rather than round... well, I guess you could get 1.38.
Given that all of the intermediate values in the appropriate calculations can be expressed EXACTLY in binary fractions OR decimals OR floating point with a very reasonable number of decimal places, this would seem to suggest sloppiness.
Yes, I remember the days when computers were still occasionally used for computing and programmers were expected to know the rudiments of mathematics and numerical analysis. Just hand me that slide rule, Sonny, and some carbon paper to put in my IBM Selectric. Dpbsmith (talk) 13:18, 21 Jun 2005 (UTC)
There is a discussion going on at Talk:kilobyte about the POVness of kilo- = 1000, etc. - Omegatron 04:13, Jun 26, 2005 (UTC)
Discussion at Wikipedia:Village pump (policy)/Archive I#Unit Disagreement.2C MiB vs. MB. - Omegatron July 8, 2005 12:58 (UTC)
A vote has been started on whether Wikipedia should use these prefixes all the time, only in highly technical contexts, or never. - Omegatron 14:49, July 12, 2005 (UTC)
User:Pmsyyz wrote (in bold): As of 2005 this naming convention [Kibi...] has not gained widespread use, but its use is growing. It is strongly supported by many standardization bodies, including IEEE and CIPM.
I think there is a non-neutral POV in this sentence, "Hard disk drive manufacturers state capacity in decimal units, so what is advertised as a "30 GB" hard drive will hold 30 × 10^9 bytes, roughly equal to 28×2^30 bytes (i.e. 28 GiB)."
It implies that HD manufacturers specifically use the decimal designation to inflate the capacity designation. While it may be true at this point in history, it almost certainly was not the original intent of the engineers who created the first hard drives. I propose something like, "Hard disk drive manufacturers state capacity in decimal units. Since most computer operating systems report drive usage and capacity in binary units, the difference causes an apparent loss between the advertised capacity and the formatted, usable capacity."
Second, since the article speculates on the tradition of using decimal units for HDD capacity, I don't think the immediate subsequent statement is accurate, "This usage has a long engineering tradition, and was probably not influenced by marketing. It arose because nothing about the physical structure of the disk drives makes power-of-two capacities natural: the number of platters, tracks and sectors per track are all continuously variable."
I propose, "The decimal unit capacity in hard disk drives follows the method used for serially accessed storage media which predated direct access storage media like hard disk drives. Paper punch cards could only be used in a serial fashion, like the magnetic tapes that followed. When a stream of data is stored, it's more logical to indicate how many thousands, millions, or billions of bytes have been stored versus how many 1024, 1,048,576, or 1,073,741,824 bytes have been. When the first hard disk drives were being developed, the decimal measurement was only natural since the hard disk drive served essentially the same function as punch cards and tapes. Thus today, any device that is addressed or seen as "storage" uses the decimal system to identify capacity."
JJLatWiki 18 July 2005 16:09 (UTC)
I added the Legal Disputes section. The information I provided is publically available in many places on the web. Within each case is exactly the kinds of debates going on here.
In my opinion, the difference though is that these people are attempting to take advantage of the debate and claim that corporations are literally charging "per megabyte" and that the corporate megabyte is smaller than the "commonly understood" megabyte and so the consumer is being deceived and cheated. In my opinion, the plaintiffs are filing frivolous lawsuits without merit.
Even though the capacity available to the user is (almost universally) less than the capacity designation, consumers do not pay a dollar amount per mega/gigabyte, therefore they are not paying something for nothing. Likewise, there are no hard drive or Flash drive manufacturers who designate capacity in the binary method and are therefore harmed by the other manufacturers' deception.
EVEN IF the capacity designation were accurate according to the binary method, and a 30GB drive had a formatted capacity of 32,212,254,720 bytes, it is a practical impossibility to store 32,212,254,720 bytes of user data on such a drive. Who is to be sued for THESE losses?
JJLatWiki 18:50, 18 July 2005 (UTC)