Talk:Hard disk drive/Archive 18
Appearance
![]() | 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 15 | Archive 16 | Archive 17 | Archive 18 | Archive 19 | Archive 20 | → | Archive 25 |
Strange sentence
"Computers do not internally represent HDD or memory capacity in powers of 1,024; reporting it in this manner is just a convention." — I can't make any sense of this sentence. What does "internally represent HDD or memory capacity" mean? Of course most computers store most numbers in binary. Zerotalk 02:22, 28 September 2014 (UTC)
- While u understand that today's computers store information in a binary form, it is possible that some readers do not, so the preface is a form of explanation as to why Binary Prefixes are a convention. If u can come up with better language please do so. Tom94022 (talk) 18:04, 28 September 2014 (UTC)
- "Storing a number in binary" is not equivalent to "storing a number scaled by a power of 1024". What the sentence is trying to say is that space on a hard drive (or a partition, or a volume, or free space) is not counted internally in GB or TB or GiB or TiB or whatever. The internal count is rather in blocks. That's how the HD reports its capacity: As the number of available Logical Block Addresses. The typical "2 TB" hard drive with 512-byte blocks would be reported, and recorded internally, as having 3,906,250,000 blocks (assuming that the "2 TB" is exact; usually drives hold a few more blocks than the claimed capacity). It's true that this largish integer would be stored "in binary", but the point here is that the binary number does not have to be multiplied by a power of 1024 to get the size in bytes. It is merely the display utility (such as the "Properties" dialog in Windows) that decides to divide the number of blocks by 1024^4 so as to display the size as "1.82 TB" (really TiB). To display size in bytes, the internal number does have to be multiplied by the block size, is 512 bytes on most drives today, 4096 with 4Kn drives - neither of those are powers of two. As Tom said, if you can come up with better wording on this point, please do so. If you don't want to edit the article directly, suggest your wording here and we can beat it around a bit. Thanks! Jeh (talk) 20:28, 28 September 2014 (UTC)
- I know everything you wrote, but it doesn't make the sentence any better. The part "in this manner" seems to refer to reporting in powers of 10, but the grammar would indicate "this" refers to "in powers of 1,024". Also, you are right that many data sizes are measured in blocks or pages, but other things are not (eg. file sizes). The operating system can keep sizes in any form or format it pleases. I think that's the real point. It is also wrong to put "HDD" and "memory capacity" together because RAM chips are measured with the GB=230 convention. Personally I would just delete the sentence, but if you must have something I'd suggest some variation of "Reporting HDD using powers of ten is just a convention in the industry and does not reflect the way that storage capacities are represented in the computer.". Zerotalk 23:35, 28 September 2014 (UTC)
- We can clarify the grammar (it has the correct intent). HDD and memory do belong together since in too many cases HDD capacities are reported by systems in powers of 1024. I'm happy to just clarify the grammar, but if u still think it is strange, then perhaps in yr language, how about, "Reporting on HDD and memory capacity (or usage) in powers of 1,024 is a convention and does not reflect the way that they are represented in the computer." Tom94022 (talk) 16:09, 29 September 2014 (UTC)
Subdividing Form Factor Section
I agreed with Dismic that there is not sufficient material in the Form Factors section to justify sub-sections and therefore reverted the reversion. The edit proposed seemed overly fragmented with single paragraph sections, and the reason suggested, need for anchors, does not require sub-sections. Tom94022 (talk) 21:47, 12 October 2014 (UTC)
- I've not seen any policy assertions so we are in personal taste territory with regard to subsection size but let us make that a moot point. Please recall I asserted having stable anchors is what matters and no one has objected to invisible anchors. I assert "Be Bold" to the invisible anchors alternative. – Conrad T. Pino (talk) 05:46, 13 October 2014 (UTC)
- The added {{Anchor|...}} are on new lines to make the diff verification cleaner but that may be adding a little white space. The difference I measured over 1100 vertical pixels seems minimal to me but I'm happy to embed the {{Anchor|...}} within the target paragraph. – Conrad T. Pino (talk) 06:04, 13 October 2014 (UTC)
- Hello! I'm glad that you're fine without the introduction of sub-sections. I've just repositioned the anchors a bit as they could be introducing double-spacing, what would be against MOS:BULLETLIST. — Dsimic (talk | contribs) 11:30, 13 October 2014 (UTC)
- Thank you! Performing that edit was very kind. Best regards, – Conrad T. Pino (talk) 20:07, 13 October 2014 (UTC)
- You're welcome. :) — Dsimic (talk | contribs) 20:12, 13 October 2014 (UTC)