Re: Using standardized SI prefixes
On Friday 22 June 2007 07:29, Ivan Jager [EMAIL PROTECTED] wrote: CD-ROMs have 2304 byte raw sectors. 2048 + 256 for ECC, both of which are powers of two. Even if you use the 2304 raw bytes, that is a multiple of 2^8 bytes, and not even divisible by 10^1. Powers of 2 are everywhere. I have 8+2 toes, both of which are powers of two. How did humans even start counting in base 10 when it's obvious that there are 8+2 digits to count with (and that's both powers of 2). :-# -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, Jun 21, 2007 at 05:29:47PM -0400, Ivan Jager wrote: On Thu, 21 Jun 2007, Hamish Moffatt wrote: On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote: You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. Not everywhere related to computers. Only when the unit is bytes. Wow, what a concession! It's natural for memory and structures like it, but not for bitstream quantities like network traffic. Yes, for network traffic both are just as natural. Except that our decimal prefixes (10^N) are part of our language and therefore win by default. Most NAND FLASH chips have 2062 byte blocks, which even throws the memory device argument out the window. I have no idea about this, but I would expect http://www.google.com/search?hl=enq=2062+flash+nandbtnG=Search to have more results where the 2062 is a block size... Sorry, I meant 2112. You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB (72x128M) DIMM, you're actually getting 1207959552 bytes of raw storage. Actually the controllers don't memory-map the extra 8 bits per 64. The existence of the extra bits is totally hidden between the RAM and the controller. For NAND flash however the whole 2112 byte blocks are memory mapped. After every 2112 bytes there's a gap until the next 4K boundary. But even then, the powers of two are more natural than the powers of 10. Yes for memory structures, I agree. You failed to address my point about bitstream quantities like network traffic. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, Jun 21, 2007 at 01:11:52PM +1000, Hamish Moffatt wrote: I think Ben's point is that we don't know. You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. It's natural for memory and structures like it, but not for bitstream quantities like network traffic. But they don't use powers of 10 any more than they do powers of 10. While bps speeds are an oft-quoted case that always use powers of 10, the connection I got here is guaranteed min=max 1Mbps which as far as I can measure it goes right at 1048576 bits per second, rain or sleet. And the ISP is one of the most despicable, cheating, greedy ones you can imagine -- for example our company pays for that 1Mbps more than in a civilised place you would pay for 100Mbps, so if they seen a place to overadvertise something, they would. And as far as I know, usually 1Mbps stands for 1024x1000 bits where network speeds are concerned, to be wrong by both the correct and yours interpretation :p -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Using standardized SI prefixes
Dear Friends and colleagues, I am a newbie on this list and Linux but an oldie when it comes to IT industry. Can i highlight that the main attraction of ubuntu amongst all other Linux derivates is its accessibility to end users. For this feature to continue to flourish it is best if everything from the bottom up is standardise towards the final goal of presenting it to the ordinary end user. In today's world unfortunately presentation does matter a great deal more than its worth, but that is the reality. Kind Regards Farjad http://www.checknetworks.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Morris Sent: Thursday, June 21, 2007 2:27 AM To: [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: Re: Using standardized SI prefixes On Wed, 20 Jun 2007 20:11:23 -0400, Ivan Jager wrote: How many packages can you name that measure bytes in powers of 10? Are there any? debian-installer does so (unless you are creating LVM Logical Volumes, in which case the units that you specify volume sizes in are base-2, but the units that volume sizes are displayed in remain baase-10)... :) -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, 21 Jun 2007, Hamish Moffatt wrote: On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote: On Wed, 20 Jun 2007, Ben Finney wrote: The problem is that *many* cases are incorrect; we can't say that *all* of them are. That uncertainty is not amenable to a mindless text substitution without judgement of each case. The solution can only be for humans to find those cases where the units presented do not match the quantities, and to file bugs against those packages asking for the mistake to be corrected. The other solution can be for humans to find those few (if any) packages that say MB when they mean 1,000,000 and fix only those. Then we'd have a consistent system conforming to the standards most CS people expect. How many packages can you name that measure bytes in powers of 10? Are there any? People tell me I am making an argument from ignorance, and that I think Ben's point is that we don't know. You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. Not everywhere related to computers. Only when the unit is bytes. It's natural for memory and structures like it, but not for bitstream quantities like network traffic. Yes, for network traffic both are just as natural. Hard disks are different again; I don't know that there is any particular reason for them to have 2^n byte sectors (and at the hardware level perhaps they don't). Page sizes are powers of two. Filesystem block sizes are multiples of the sector sizes, and it's very convenient when they can be aranged nicely in pages. CD-ROMs have 2304 byte raw sectors. 2048 + 256 for ECC, both of which are powers of two. Even if you use the 2304 raw bytes, that is a multiple of 2^8 bytes, and not even divisible by 10^1. Most NAND FLASH chips have 2062 byte blocks, which even throws the memory device argument out the window. I have no idea about this, but I would expect http://www.google.com/search?hl=enq=2062+flash+nandbtnG=Search to have more results where the 2062 is a block size... You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB (72x128M) DIMM, you're actually getting 1207959552 bytes of raw storage. But even then, the powers of two are more natural than the powers of 10. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, Jun 21, 2007 at 09:32:09AM +0200, Adam Borowski wrote: On Thu, Jun 21, 2007 at 01:11:52PM +1000, Hamish Moffatt wrote: I think Ben's point is that we don't know. You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. It's natural for memory and structures like it, but not for bitstream quantities like network traffic. But they don't use powers of 10 any more than they do powers of 10. While bps speeds are an oft-quoted case that always use powers of 10, the connection I got here is guaranteed min=max 1Mbps which as far as I can measure it goes right at 1048576 bits per second, rain or sleet. And the ISP is one of the most despicable, cheating, greedy ones you can imagine -- for example our company pays for that 1Mbps more than in a civilised place you would pay for 100Mbps, so if they seen a place to overadvertise something, they would. And as far as I know, usually 1Mbps stands for 1024x1000 bits where network speeds are concerned, to be wrong by both the correct and yours interpretation :p The raw network transports (eg Ethernet and SONET) *are* quoted in powers of 10, and they mean it. Gigabit ethernet is really a billion bits (10^9) per second. OC-3 is really 155,520,000 bits per second. Powers of 10 are perfectly natural in this case (imho). They are what we humans are used to as the default. For computer memory structures where an N bit address bus means you have 2^N bits of storage, powers of 2 make some sense, but not in the general case. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Enough already - Re: Using standardized SI prefixes
Little useful or helpful has been said in this thread for a while now. Please don't continue the discussion, at least on debian-devel. (Sorry to be so blunt.) -- Rule #13 for successful communication: don't do Latin quotations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 19 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]: snipped Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. Really? You need additional knowledge to interpret the program output and you call this less confusing? I doubt that. Yes. I don't like computers that are designed for people who don't know anything. I find such beasts confusing and obnoxious. Resp. Sir, It is precisely for people who don't know anything that comps. do sell, components sell you have cheap prices. Again who decides who knows anything or nothing at all? I'm sure it'll be pretty thin list if we go by that. Also is there something in the debian manifesto which says that people is only for people who do computer science only? snipped But they ARE broken. Have been for years. If you make a simple analogy from that statement to other dings then you need to declare much more people as stupid Don Quixotes, like those who work on LFS (you know, 2GiB is ought to be enough for everyone), or on IPv6, or on Unicode, etc.etc. I seem to be failing to folow your logic again... Anyways, you know we've all switched to IPv6 already, right? We no longer need 6bone because all our ISPs give us IPv6 addresss already. See http://www.6bone.net/ if you don't believe me. Grr. I don't know whether that last sentence was mentioned in seriousness or in jest. We in India, are on ipv4 still the transition is going to take another couple of years till one of the big ISP's does the change. I know this for a fact as there were press releases made by BSNL (Indian ISP) to that effect. http://en.wikipedia.org/wiki/List_of_countries_by_broadband_users But does it mean that we are against IPv6, no all we all want is it should be pretty easy so that ipv4 can work its documented how it is to be done. If similarly, there was an alternative solution for the same in the KB/KiB thing it would make easier for me as a user to decide. How about using these prefixes to unambiguously refer to powers of 10? kd kidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose Doesn't look so for me. It looks more like a bad attempt to miscredit brave people. Yes, all those brave people who risked their lives to, uhh, very bravely do, uhh, something, umm, what people am I trying to miscredit? I think maybe I need to figure this out before I can figure out what brave things they were doing. Oh, or was I trying to miscredit all brave people? I'm sorry, but I don't think I was trying to miscredit anyone. I simply don't want people fixing a part of my system that works exactly how I want it, just because it is confusing to non computer people. There you go again, who are non-computer people. I would surely be interested to known your definition of non-computer people how they should be discriminated against, atleast that is what appears to me. Ivan Ivan Jager [EMAIL PROTECTED] writes: -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Am 2007-06-15 17:36:33, schrieb Ivan Jager: On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote: Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy a disk, what do the vendor says the capacity is? 80 GB. But your software states it is no more than 75GB. What the fuck!? If GiB is confusing to users, so is base 2. People use base 10 and k (kilo) means 1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are used to base 10. How about when you buy 80 GB of RAM, and your software says you have 88 GB? You are fucked too, since your 486 does only support 67108864 Byte of ram. -- Oops! How about using these prefixes to unambiguously refer to powers of 10? kdkidi10^3 Mdmeda10^6 Gdgida10^9 Tdteda10^12 Pdpeda10^15 Edexda10^18 Zdzeda10^21 Ydyoda10^24 Come on, you know you want a yodameter. :) ROTFL! Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Using standardized SI prefixes
Hi Wes, I am sitting on my line but does this mean we sould use n 2B n k2B = kilo Byte with power of 2 n M2B = Mega Byte with power of 2 n G2B = Giga Byte with power of 2 n T2B = Tera Byte with power of 2 ? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Using standardized SI prefixes
#include hallo.h * Ivan Jager [Tue, Jun 19 2007, 06:39:24PM]: It's not that I can't *think* of any problems. It's that I, like several other people here, I don't *have* said problems with the programs I use, and I don't particularly care to have that fixed. Just because you can't tell whether the output of ls -lh is using binary or decimal prefixes doesn't mean it's a problem for everyone else. So if you know that there are problems then there is no point in argumenting against the people who want to have them solved. Umm, again I fail to follow your logic. I want to have problems solved, so why are you arguing with me? Your reasoning seems to imply you think there are no problems in the world. No, it doesn't imply that. And if you cannot follow, don't put words into my mouth. There are simple facts which are NOT mutual exclusive: no problems, problems exist, there are no problems for me. If you try to use the last one to support the first and you don't see a problem there even now then I doubt I can help you with understanding. You're going to have some trouble convincing me of that. :) Me? No comment. If I missed an irony tag somewhere then it is hidden really well. Eduard. -- Die einfachsten Menschen hör ich die feinsten Vermutungen äußern, wenn der Schritt etc. eines Gesandten, Ministers politisch zu erklären ist. -- Jean Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wednesday 20 June 2007 08:28:33 Michelle Konzack wrote: I am sitting on my line but does this mean we sould use n 2B n k2B = kilo Byte with power of 2 n M2B = Mega Byte with power of 2 n G2B = Giga Byte with power of 2 n T2B = Tera Byte with power of 2 No, we should use kB = 1000 B and KiB = 1024 B, since that is what is actually standardized. k2B and friends were an example of how some people avoided misusing standard prefixes (i.e. not using kB for 1024), by making up non-standard ones that did made some sense. There have been lots of schemes like that over the years. If it were k2B that were standardized instead of KiB, I'd be pushing to use that instead, but that's not the case. =) -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Using standardized SI prefixes
On Wed, 20 Jun 2007, Ben Finney wrote: Ivan Jager [EMAIL PROTECTED] writes: Here's a shell for people who don't remember what the output of their commands mean: #!/bin/bash while echo -n '$ '; read cmd line; do man $cmd | cat; eval $cmd $line | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/'; done I'm choosing this to quote because it highlights the mistake being made. The above assumes that this proposal is about *replacing*, unilaterally, every instance of one text with another. This is mistaken, because the proposal is about fixing *only* those cases where the unit does not match the quantity. The programs which output base-ten unit abbreviations correctly would be *broken* by the above simple substitution. The problem is that *many* cases are incorrect; we can't say that *all* of them are. That uncertainty is not amenable to a mindless text substitution without judgement of each case. The solution can only be for humans to find those cases where the units presented do not match the quantities, and to file bugs against those packages asking for the mistake to be corrected. The other solution can be for humans to find those few (if any) packages that say MB when they mean 1,000,000 and fix only those. Then we'd have a consistent system conforming to the standards most CS people expect. How many packages can you name that measure bytes in powers of 10? Are there any? People tell me I am making an argument from ignorance, and that just because I don't know of any such packages doesn't mean they don't exist. Because of these packages that may or may not exist, they say we need to change all the other ones to avoid inconsistiencies with the packages we can't prove don't exist. Yey. Well, anyways, I'm a lot less worried now that I realized that these bug reports get ignored and passed around for years. At the rate things are going, Debian will probably be too newbie oriented for me well before you succeed at filling my output with is. :P Have fun, Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 20 Jun 2007 20:11:23 -0400, Ivan Jager wrote: How many packages can you name that measure bytes in powers of 10? Are there any? debian-installer does so (unless you are creating LVM Logical Volumes, in which case the units that you specify volume sizes in are base-2, but the units that volume sizes are displayed in remain baase-10)... :) -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote: On Wed, 20 Jun 2007, Ben Finney wrote: The problem is that *many* cases are incorrect; we can't say that *all* of them are. That uncertainty is not amenable to a mindless text substitution without judgement of each case. The solution can only be for humans to find those cases where the units presented do not match the quantities, and to file bugs against those packages asking for the mistake to be corrected. The other solution can be for humans to find those few (if any) packages that say MB when they mean 1,000,000 and fix only those. Then we'd have a consistent system conforming to the standards most CS people expect. How many packages can you name that measure bytes in powers of 10? Are there any? People tell me I am making an argument from ignorance, and that I think Ben's point is that we don't know. You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. It's natural for memory and structures like it, but not for bitstream quantities like network traffic. Hard disks are different again; I don't know that there is any particular reason for them to have 2^n byte sectors (and at the hardware level perhaps they don't). CD-ROMs have 2304 byte raw sectors. Most NAND FLASH chips have 2062 byte blocks, which even throws the memory device argument out the window. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Sat, 16 Jun 2007, Wesley J. Landaker wrote: On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote: Le vendredi 15 juin 2007 ?? 17:36 -0400, Ivan Jager a ??crit : Yes. Any time the unit is bytes. There is even a standard for it. I must have missed that one. Could you point us to this standard? I too would love to see that standard. Ok, so it appears to be deprecated, but it does exist. October 30, 1986 ANSI/IEEE Std 1084-1986 IEEE Standard Glossary of Mathematics of Computing Terminology. http://ieeexplore.ieee.org/iel1/2485/1030/00026589.pdf?isnumber=1030prod=arnumber=26589arSt=ared=arAuthor= kilo (K). (1) A prefix indicating one thousand. (2) In statements involving size of computer storage, a prefix indicating 2^10, or 1024. mega (M). (1) A prefix indicating one million. (2) In statements involving size of computer storage, a prefix indicating 2^20, or 1,048,576. Apparently back then giga wasn't ever applied to computer storage. :) Ivan
Re: Using standardized SI prefixes
On Fri, 15 Jun 2007, Ben Finney wrote: Ivan Jager [EMAIL PROTECTED] writes: On Thu, 14 Jun 2007, Ben Finney wrote: [re added the relevant quote] The difference being that digital specifications for things like storage capacity and memory are not measured. They are calculated, and in those contexts they *are* precise. Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. Ok, so this applies to dd and what else? It applies to any software that refers to quantities that use these units. Pick a unit for the quantity, base-10 or base-2, and use its precise meaning and the precise term for it. I think you missed the point. The only times it is not rounded is when the user is specifying a size. (And even then it is sometimes rounded.) I thought this argument was mostly about measured sizes anyways, such as what you would get from ls -lh, df -h, du -h, or their GUI equivalents. These are all rounded. Any time the software says GB when the quantity was actually calculated in 2^30, or says GiB when the quantity was actually calculated in 10^9, the units are mismatched. Whether the quantity was rounded is irrelevant to this fact. It was relevant enough for Alex to say sizes aren't rounded... Yes, accuracy, precision, and ambiguity are all separate things. Rounding is not completely irrelevant though, since most of the time 1 GB is correct, 1 GiB is also correct. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Sat, 16 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]: How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes, but your software says /home only has 79 GB and you know it means 79 * 10^9 bytes? First, it would hardly say 79GB. Maybe 79.96GB which is much closer. Huh, I guess I just have a bigger journal than you, more inodes per byte, and some backup superblocks. (I use the defaults.) Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. It only solves half the problem. GB is still ambiguous even if GiB isn't. Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. I can't say I adhere to, Don't fix what isn't broken, but it does kind of bug me when people are encouranging other people to encourage yet other people to fix things that aren't broken. How about using these prefixes to unambiguously refer to powers of 10? kd kidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose was to look and sound silly while disambiguating from the commonly used ones we all know and love. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ivan Jager wrote: I think you missed the point. The only times it is not rounded is when the user is specifying a size. (And even then it is sometimes rounded.) Rounding doesn't render distinguishing between GB and GiB useless, except perhaps in the extreme case when you're *only* interested in the order of magnitude. I thought this argument was mostly about measured sizes anyways, such as what you would get from ls -lh, df -h, du -h, or their GUI equivalents. These are all rounded. Any time the software says GB when the quantity was actually calculated in 2^30, or says GiB when the quantity was actually calculated in 10^9, the units are mismatched. Whether the quantity was rounded is irrelevant to this fact. It was relevant enough for Alex to say sizes aren't rounded... Yes, accuracy, precision, and ambiguity are all separate things. Rounding is not completely irrelevant though, since most of the time 1 GB is correct, 1 GiB is also correct. Again, this is an extreme example. A more average case might be 3.2 GB, which is *not* a substitute for 3.2 GiB. Do you not agree that rounding can be done to more than one significant digit? -- Magnus Holmgren -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ivan Jager wrote: On Sat, 16 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]: [...] Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) This sounds like another not a perfect solution fallacy. Accurately presenting the full amount of disk space a file uses is an orthogonal problem that having distinct prefixes can't be expected to solve. Having distinct, unambiguous prefixes is still strictly better than having ambiguous prefixes. I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. It only solves half the problem. GB is still ambiguous even if GiB isn't. Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. What you personally have become accustomed to is irrelevant in the big picture and in the long run. That you can't think of any problems doesn't mean that no problems exist (http://en.wikipedia.org/wiki/Argument_from_ignorance). That you mistake an SI MB for a MiB, for example, is not an argument against consistent prefix usage. The quicker everybody stops using power of ten prefixes incorrectly, the quicker this transitional problem goes away. I can't say I adhere to, Don't fix what isn't broken, but it does kind of bug me when people are encouranging other people to encourage yet other people to fix things that aren't broken. But things *are* broken. How about using these prefixes to unambiguously refer to powers of 10? kdkidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose was to look and sound silly while disambiguating from the commonly used ones we all know and love. An appeal to emotions, once again. -- Magnus Holmgren [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 19 Jun 2007, Magnus Holmgren wrote: Ivan Jager wrote: On Sat, 16 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]: [...] Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) This sounds like another not a perfect solution fallacy. Accurately presenting the full amount of disk space a file uses is an orthogonal problem that having distinct prefixes can't be expected to solve. Having distinct, unambiguous prefixes is still strictly better than having ambiguous prefixes. They are not strictly better. Did you not read the part where I said I didn't want an extra column of is that serves no real purpose? What you personally have become accustomed to is irrelevant in the big picture and in the long run. That you can't think of any problems doesn't mean that no problems exist It's not that I can't *think* of any problems. It's that I, like several other people here, I don't *have* said problems with the programs I use, and I don't particularly care to have that fixed. Just because you can't tell whether the output of ls -lh is using binary or decimal prefixes doesn't mean it's a problem for everyone else. (http://en.wikipedia.org/wiki/Argument_from_ignorance). Actually, it is you who can't seem to think of any problems that would arise from changing almost everything. (or rather, you may be choosing to ignore said problems.) In addition, you seem to be trying to move the burden of proof. Why do I need to prove that there isn't a problem? It is those who think it needs changing who should be proving there is a problem and that their proposed change actually fixes it without introducing new problems. That you mistake an SI MB for a MiB, for example, is not an argument against consistent prefix usage. The quicker everybody stops using power of ten prefixes incorrectly, the quicker this transitional problem goes away. I don't mistake an SI MB for a MiB. Our disagreement is because I don't mistake a non-SI MB for an SI one, and, presumably, you do. This is why you see the ambiguity as a serious problem and I don't. I am not against consistent prefix usage. On the contrary, I have pointed out that all the programs I use consistently use MB to mean 2^20 bytes, and that I would rather not have this consistency broken by ever having one say MB when it means 10^6 bytes. Your argment is not in favor of consistency, but rather in favor of explicitly indicating consistency. I would find it much less obtrusive to simply drop a file in / explaining that we are consistent. (But I also think that is unnecesary.) Trying to adhere to what the outside world does will not make Debian consistent, because the outside world is not consistent. http://foldoc.org/?query=megabyte http://www.m-w.com/dictionary/megabyte http://dictionary.reference.com/browse/megabyte http://dictionary.oed.com/cgi/entry/00304795 How about using these prefixes to unambiguously refer to powers of 10? kd kidi 10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose was to look and sound silly while disambiguating from the commonly used ones we all know and love. An appeal to emotions, once again. Maybe, but it doesn't change the fact that every argument you've made in favor of explicit binary prefixes applies equaly well to explicit decimal prefixes instead. It comes with the added benefit that we'd need to file a lot less bug reports. I was actually kind of playing devil's advocate there, as I was arguing in favor of something I don't support. The part where the appeal to emotions comes in is that I don't expect you to support explicit decimal prefixes even though they are almost strictly better than what you do support. Having distinct, unambiguous prefixes is still strictly better than having ambiguous prefixes. So, that is saying it is strictly better to use the explicit binary *and* explicit decimal prefixes. My argument still holds that they are not strictly better because they do have the disadvantage of using an additional character. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
#include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]: Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only This rounding is still overhead, so don't say it doesn't. accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) Oh, you cannot say that easily for everyone either. Just compare an FS with big data files with /usr/share/doc contents. Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. Really? You need additional knowledge to interpret the program output and you call this less confusing? I doubt that. And you care about waste? You waste every 8 bit right now! I can't say I adhere to, Don't fix what isn't broken, but it does kind of bug me when people are encouranging other people to encourage yet other people to fix things that aren't broken. But they ARE broken. Have been for years. If you make a simple analogy from that statement to other dings then you need to declare much more people as stupid Don Quixotes, like those who work on LFS (you know, 2GiB is ought to be enough for everyone), or on IPv6, or on Unicode, etc.etc. How about using these prefixes to unambiguously refer to powers of 10? kd kidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose Doesn't look so for me. It looks more like a bad attempt to miscredit brave people. Eduard. -- Die Menschheit besteht aus einigen wenigen Vorläufern, sehr vielen Mitläufern und einer unübersehbaren Zahl von Nachläufern. -- Jean Cocteau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
#include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:39:22PM]: On Tue, 19 Jun 2007, Magnus Holmgren wrote: Ivan Jager wrote: This sounds like another not a perfect solution fallacy. Accurately presenting the full amount of disk space a file uses is an orthogonal problem that having distinct prefixes can't be expected to solve. Having distinct, unambiguous prefixes is still strictly better than having ambiguous prefixes. They are not strictly better. Did you not read the part where I said I didn't want an extra column of is that serves no real purpose? Don't you read the explanation where people say which purpose it does serve? If you cannot distinguish between a perfect solution and a good partial solution, then you are a real victim of the not a perfect solution fallacy. What you personally have become accustomed to is irrelevant in the big picture and in the long run. That you can't think of any problems doesn't mean that no problems exist It's not that I can't *think* of any problems. It's that I, like several other people here, I don't *have* said problems with the programs I use, and I don't particularly care to have that fixed. Just because you can't tell whether the output of ls -lh is using binary or decimal prefixes doesn't mean it's a problem for everyone else. So if you know that there are problems then there is no point in argumenting against the people who want to have them solved. Eduard. -- Naja, Garbage Collector eben. Holt den Müll sogar vom Himmel. (Heise Trollforum über Java in der Flugzeugsteuerung) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 20 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:39:22PM]: On Tue, 19 Jun 2007, Magnus Holmgren wrote: Ivan Jager wrote: They are not strictly better. Did you not read the part where I said I didn't want an extra column of is that serves no real purpose? Don't you read the explanation where people say which purpose it does serve? If you cannot distinguish between a perfect solution and a good partial solution, then you are a real victim of the not a perfect solution fallacy. Uhh, I think you mixed something up in that last sentence. Anyways, just because it solves one problem for some people doesn't make it strictly better. It's not that I can't *think* of any problems. It's that I, like several other people here, I don't *have* said problems with the programs I use, and I don't particularly care to have that fixed. Just because you can't tell whether the output of ls -lh is using binary or decimal prefixes doesn't mean it's a problem for everyone else. So if you know that there are problems then there is no point in argumenting against the people who want to have them solved. Umm, again I fail to follow your logic. I want to have problems solved, so why are you arguing with me? Your reasoning seems to imply you think there are no problems in the world. You're going to have some trouble convincing me of that. :) Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 19 Jun 2007, Eduard Bloch wrote: #include hallo.h * Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]: Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. No, it doesn't. It rounds up to a multiple of the block size. That only This rounding is still overhead, so don't say it doesn't. But it doesn't. du does not add filesystem overhead when displaying file sizes. It simply rounds up to the block size. The size it adds on is completely independent of the filesystem overhead. accounts for a small fraction of the filesystem overheaad. (Perhaps this will be more obvious if you write a multiple of your blocksize to a file.) Oh, you cannot say that easily for everyone either. Just compare an FS with big data files with /usr/share/doc contents. Yes, what about it? Are you trying to make a point? Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? No, I like to avoid chaos and confusion. I do not currently have problems telling the size of a file, and adding an extra column of is to the output of most programs isn't going to accomplish more than cause confusion for me when I use a program that doesn't waste the extra space to tell me, Oh, by the way, I'm doing the sensical thing. Really? You need additional knowledge to interpret the program output and you call this less confusing? I doubt that. Yes. I don't like computers that are designed for people who don't know anything. I find such beasts confusing and obnoxious. Here's a shell for people who don't remember what the output of their commands mean: #!/bin/bash while echo -n '$ '; read cmd line; do man $cmd | cat; eval $cmd $line | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/'; done Tell me if that isn't obnoxious to use. And you care about waste? You waste every 8 bit right now! Yes, and if people were trying to force me to use UTF-16 so that we could use a different type of whitespace to separate words that what we use to separate sentences, I would also be objecting. I can't say I adhere to, Don't fix what isn't broken, but it does kind of bug me when people are encouranging other people to encourage yet other people to fix things that aren't broken. But they ARE broken. Have been for years. If you make a simple analogy from that statement to other dings then you need to declare much more people as stupid Don Quixotes, like those who work on LFS (you know, 2GiB is ought to be enough for everyone), or on IPv6, or on Unicode, etc.etc. I seem to be failing to folow your logic again... Anyways, you know we've all switched to IPv6 already, right? We no longer need 6bone because all our ISPs give us IPv6 addresss already. See http://www.6bone.net/ if you don't believe me. Grr. How about using these prefixes to unambiguously refer to powers of 10? kd kidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Yes, my intention was to make a silly set of prefixes whose only purpose Doesn't look so for me. It looks more like a bad attempt to miscredit brave people. Yes, all those brave people who risked their lives to, uhh, very bravely do, uhh, something, umm, what people am I trying to miscredit? I think maybe I need to figure this out before I can figure out what brave things they were doing. Oh, or was I trying to miscredit all brave people? I'm sorry, but I don't think I was trying to miscredit anyone. I simply don't want people fixing a part of my system that works exactly how I want it, just because it is confusing to non computer people. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ivan Jager [EMAIL PROTECTED] writes: Here's a shell for people who don't remember what the output of their commands mean: #!/bin/bash while echo -n '$ '; read cmd line; do man $cmd | cat; eval $cmd $line | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/'; done I'm choosing this to quote because it highlights the mistake being made. The above assumes that this proposal is about *replacing*, unilaterally, every instance of one text with another. This is mistaken, because the proposal is about fixing *only* those cases where the unit does not match the quantity. The programs which output base-ten unit abbreviations correctly would be *broken* by the above simple substitution. The problem is that *many* cases are incorrect; we can't say that *all* of them are. That uncertainty is not amenable to a mindless text substitution without judgement of each case. The solution can only be for humans to find those cases where the units presented do not match the quantities, and to file bugs against those packages asking for the mistake to be corrected. -- \ I like to fill my bathtub up with water, then turn the shower | `\on and pretend I'm in a submarine that's been hit. -- Steven | _o__) Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Bastian Venthur [EMAIL PROTECTED] writes: I suggest that we prepare a wikipage on wiki.debian.org with a friendly formulated bugreport template. After this template is mature enough, we can start writing wishlist bugreports on packages making wrong use SI prefixes (e.g. write KB but mean KiB) asking them to consider to switch to binary prefixes instead. Done, URL:http://wiki.debian.org/ConsistentUnitPrefixes. Please modify the bug report as needed; currently I think it may be a bit too wordy, but lack the skill to pare it down without losing necessary explanation or examples. We should not urge to use either binary prefixes or SI prefixes consistently in all packages! Instead we should urge to use the prefixes *correctly*. When 1k means 1000 Bytes, it is OK to use it -- when it means 1024 they, should make the switch to binary prefixes. Agreed, this is the approach I've taken in the bug report. -- \ I have had a perfectly wonderful evening, but this wasn't it. | `\ -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Phillip Susi a écrit : Christof Krüger wrote: Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. Different disciplines often ascribe different meanings to the same words, so there is no reason why the prefix Kilo can not mean 1024 in the context of computer science, so please stop complaining about that. You should just learn that in this context, that is what it means. Always has and always will. Yup, I totally agree. But why do we call it kilo then, when we actually mean 1024? Someone found it handy dozens of years ago and Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. everybody has adapted it. So back then, someone was redefining your pi to 3 because it was close enough and now we should leave it this way? Remember that until computers have been invented (or binary logic), kilo has always meant 1000. And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. However, I don't agree that this should hold true in computer science. One possible meaning of KB is 1000 bytes. The other is 1024 bytes. Now take the sentence: Hello John. I've got a file here and want to send it to you. It's 25KB large. Now please extract from the context which meaning is significant here? The problem is that the both possible meanings depict exactly the same: a quantity of bytes. The context clearly indicates the meaning is 1024. When referring to bytes that context uses 1024. Also capitalizing the K is another indicator. There is no ambiguity in that sentence to anyone familiar with the computer science context. It was already explained that even in computer science, kilo does not always mean 1024. 56 kb/s is 56000 b/s, not 57344 b/s. Anyway, I think the request initially was to indicate what kind of units is in use, not to standardize on whether binary or decimal units should be used. What has to be spotted is the places where formatting makes inserting a i in the unit impossible. They should be very few, since localization already pushes pieces of text around. Then, somebody will stand and claim unification is required. But let's deal with it later. And anyway, we should not use byte anymore. Octet is less ambiguous ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le vendredi 15 juin 2007 à 13:46 -0400, Phillip Susi a écrit : Different disciplines often ascribe different meanings to the same words, so there is no reason why the prefix Kilo can not mean 1024 in the context of computer science, so please stop complaining about that. You cannot always infer a unit from the context. Asking for inaccuracy for such fallacious reasons sounds completely insane, from a scientific PoV. You should just learn that in this context, that is what it means. Always has and always will. Sorry, it hasn't always been like this. And there is even less reason for things to *remain* like this. The only reason that was invoked so far is laziness. Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. Do you need a rule not to do something stupid? And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. If you want comparisons, find suitable ones; you're talking about 1024 being close to 1000. Pi is close to 3, so we can say 3 instead of Pi as well. When told the area of a circle is 3r², you'll be able to infer that in this context, 3 means Pi. The context clearly indicates the meaning is 1024. When referring to bytes that context uses 1024. Not always. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Using standardized SI prefixes
Le vendredi 15 juin 2007 à 17:36 -0400, Ivan Jager a écrit : Yes. Any time the unit is bytes. There is even a standard for it. I must have missed that one. Could you point us to this standard? How about when you buy 80 GB of RAM, and your software says you have 88 GB? How about buying 80 GiB of RAM and having software say you have 80 GiB? How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes, but your software says /home only has 79 GB and you know it means 79 * 10^9 bytes? Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Filesystem overhead is not an inaccuracy. It is expected that you can only create a 79 GiB filesystem on a 80 GiB disk. It is not expected that a 80 GB disk is 88 GB. It only solves half the problem. GB is still ambiguous even if GiB isn't. It is only ambiguous for approximative people. Furthermore, if the use of GiB starts spreading, there will be no regression in the fact that GB is ambiguous. However in the long term that ambiguity will disappear. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Using standardized SI prefixes
On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote: Le vendredi 15 juin 2007 à 17:36 -0400, Ivan Jager a écrit : Yes. Any time the unit is bytes. There is even a standard for it. I must have missed that one. Could you point us to this standard? I too would love to see that standard. Well, there is IEEE 1541, and it does mention bits and bytes. But ... oh wait! It also says to use binary prefixes appropriately, and that SI prefixes *must not* be used to indicate binary multiples. Then there is IEC 60027-2 ... oh, yeah, binary multiples. There are a few others, like ASTM SI-10. They all say the same thing. SI prefixes always have their normal, powers of 10, meaning. All these standards are from almost 10 years ago. Okay, let's look at a really *old* standard, ISO 31: ah, it ALSO says SI prefixes *always* mean powers of ten. If you want to do powers of two, you are supposed to use the prefix with a subscript 2. Note that this standard is being revised and combined with IEC 60027 to be ISO/IEC 8, and will then agree with the others cited above. So basically, IEEE, IEC, ISO, ASTM, have all standardized things, the same way, that SI prefixes always have their SI meaning, even in the context of bits and bytes. This has actually been done, in practice, by standards-aware scientists and engineers for more than 15 years, who have used ad-hoc binary prefixes when necessary. Standardized binary prefixes only make things more clear and less ambiguous, and have now been around for almost 10 years. -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Using standardized SI prefixes
Phillip Susi wrote: Christof Krüger wrote: Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. Different disciplines often ascribe different meanings to the same words, so there is no reason why the prefix Kilo can not mean 1024 in the context of computer science, so please stop complaining about that. You should just learn that in this context, that is what it means. Always has and always will. *Different* disciplines, yes. Here the same words are used for two meanings in the same discipline. The SI units and prefixes aren't just words - they have each been constructed and assigned specific meanings in a _universal_ context. Your analogy with the mouse fails because mouse is a naturally evolved, everyday word, which has *not* been universally defined (the well-defined, scientific term would instead be lat. _Mus_ for the genus or _Mus musculus_ for the species known as the common house mouse). -- Magnus Holmgren [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Fri, 15 Jun 2007, Ben Finney wrote: David Verhasselt [EMAIL PROTECTED] writes: Perhaps transforming it into a localization problem would do the trick. This way, users would be able to set their preference on byte-count in the same place as their preference on currency, decimal, and am/pm vs 24h. Applications could make use of the localization settings to calculate the amount of bytes, which would hopefully eventually centralize and generalize what counting-method the user sees. A GiB is the same in any locale, and has the same display -- GiB -- in any locale. Displaying it another way is misleading. I like the way ls -lh prints it's output, thankyouverymuch. Adding an extra iB accomplishes nothing for me other than causing more filenames to wrap. I'm not saying GiB is always bad, but just because some standards organization defined a prefix to mean something, doesn't mean the same prefix doesn't also have another meaning. When you see GB, why do you insist that the G must have the SI meaning, when the B clearly doesn't? If I say 1 Ton, do you parse that as meaning 1 * 10^12 on's? :) BTW, I prefer SI units over imperial ones, but there are no SI units for information, so we're stuck using bits and bytes. I also generaly prefer things to be unambiguous when there is no disadvantage, but, fortunately, that is not a problem for me in any of the programs I use. They all use the binary powers. If enough of them started using GiB, and even one of the programs I use regurarly switched to using decimal powers, I would suddenly become mistrustful of a lot of other programs, simply for not wasting an i. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Christof Krüger wrote: Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. Different disciplines often ascribe different meanings to the same words, so there is no reason why the prefix Kilo can not mean 1024 in the context of computer science, so please stop complaining about that. You should just learn that in this context, that is what it means. Always has and always will. Yup, I totally agree. But why do we call it kilo then, when we actually mean 1024? Someone found it handy dozens of years ago and Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. everybody has adapted it. So back then, someone was redefining your pi to 3 because it was close enough and now we should leave it this way? Remember that until computers have been invented (or binary logic), kilo has always meant 1000. And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. However, I don't agree that this should hold true in computer science. One possible meaning of KB is 1000 bytes. The other is 1024 bytes. Now take the sentence: Hello John. I've got a file here and want to send it to you. It's 25KB large. Now please extract from the context which meaning is significant here? The problem is that the both possible meanings depict exactly the same: a quantity of bytes. The context clearly indicates the meaning is 1024. When referring to bytes that context uses 1024. Also capitalizing the K is another indicator. There is no ambiguity in that sentence to anyone familiar with the computer science context. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Fri, Jun 15, 2007 at 01:46:10PM -0400, Phillip Susi wrote: Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. Which context would this be? Computer Science? Computer Engineering? Computer Networks? Storage Disks? Magnetic or Optical? File sizes? Memory size? Cache size? I agree that in computer science, many (not necessarily most of) times it would very bad sense to use a power of 10 instead of a power of 2. Like back when they used ten's complement. However, this makes the point stronger, since 10 was a base used with some digital computers. And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy a disk, what do the vendor says the capacity is? 80 GB. But your software states it is no more than 75GB. What the fuck!? If GiB is confusing to users, so is base 2. People use base 10 and k (kilo) means 1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are used to base 10. I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. The context clearly indicates the meaning is 1024. When referring to bytes that context uses 1024. Also capitalizing the K is another indicator. There is no ambiguity in that sentence to anyone familiar with the computer science context. When you use K, this could be true. But remember not all users are familiar with the computer science context. So, you type 600 and see 5.7MB. And users not familiar with the computer science context will think: What the ...?. So, if reading 5.7MiB will do them no favor, that should read 6.0MB. Regards, Thadeu Cascardo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Joe Smith wrote: Also just rembering the exact conversion factors for Imperial units can be a problem especially with some of the more obscure units. Nope - google knows everything! http://www.google.com/search?hl=emailrls=emailq=100+m%2Fs+in+fathoms+per+fortnight 2 parsecs in smoots returns 2 Parsecs = 3.62637237 × 10^16 smoots http://www.kottke.org/03/08/fun-with-the-google-calculator If you lack net access at any given moment, then there's a *nix utility named units, which is conveniently already packaged in debian. http://packages.debian.org/stable/utils/units Thanks to John Hasler for that one. -- Criggie http://criggie.dyndns.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote: On Fri, Jun 15, 2007 at 01:46:10PM -0400, Phillip Susi wrote: Because we needed a name, and Kilo is a good one to use. There is no rule that says you can't use the word for a different meaning in a different context. Which context would this be? Computer Science? Computer Engineering? Computer Networks? Storage Disks? Magnetic or Optical? File sizes? Memory size? Cache size? Yes. Any time the unit is bytes. There is even a standard for it. I agree that in computer science, many (not necessarily most of) times it would very bad sense to use a power of 10 instead of a power of 2. Like back when they used ten's complement. However, this makes the point stronger, since 10 was a base used with some digital computers. It *was* used. Then people realized base 2 was a lot better for digital computers. Some people living on this continent before us used to use base 20. So this makes the point stronger that if I want change for a $10, you should give me back four $5 bills. :) And before computers were invented the word mouse always referred to a small hairy rodent. I don't see you complaining that it can also refer to the computer pointing device on your desk. When someone says they caught a mouse or they clicked with their mouse, you can easily infer which one they mean. Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy a disk, what do the vendor says the capacity is? 80 GB. But your software states it is no more than 75GB. What the fuck!? If GiB is confusing to users, so is base 2. People use base 10 and k (kilo) means 1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are used to base 10. How about when you buy 80 GB of RAM, and your software says you have 88 GB? How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes, but your software says /home only has 79 GB and you know it means 79 * 10^9 bytes? Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. It only solves half the problem. GB is still ambiguous even if GiB isn't. How about using these prefixes to unambiguously refer to powers of 10? kd kidi 10^3 Md meda10^6 Gd gida10^9 Td teda10^12 Pd peda10^15 Ed exda10^18 Zd zeda10^21 Yd yoda10^24 Come on, you know you want a yodameter. :) Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
#include hallo.h * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]: How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes, but your software says /home only has 79 GB and you know it means 79 * 10^9 bytes? First, it would hardly say 79GB. Maybe 79.96GB which is much closer. Should we also add filesystem overhead to all file sizes just to avoid confusing newbies? Second, du already does that. Go figure. I don't want to read some manual or source code just to know which base is used when I read or write 10G. When I write, how can I unambiguously tell the program that I mean 1000 or 1024? Only using G and Gi, this would be possible. It only solves half the problem. GB is still ambiguous even if GiB isn't. Sure, but it makes it possible to make it _right_ in a good portion of situations. The people who really need binary units can make clear what they are doing there. Otherwise they would deliberately create confusion. You like to be among them? You like chaos and cheating? How about using these prefixes to unambiguously refer to powers of 10? kdkidi10^3 Like in kidigram and medameter? What comes next, midroutopicans? Eduard. -- Salz jjFux: Ted hieß ja früher auch Walther Salz winkiller: hm... es sind 8... die 7 kandidaten und NOTA Madkiss Ist der jetzt eigentlich eine gespaltene Persönlichkeit, bei der aber beide Teile bekloppt sind? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ivan Jager [EMAIL PROTECTED] writes: BTW, I prefer SI units over imperial ones, but there are no SI units for information, so we're stuck using bits and bytes. The issue isn't over the chosen unit. The issue is over the chosen *abbreviations*. We use 'B' for byte, 'b' for bit; that's not at issue in this thread. I also generaly prefer things to be unambiguous when there is no disadvantage, but, fortunately, that is not a problem for me in any of the programs I use. This is the I'm alright Jack non-argument I already addressed in this thread. -- \ He who laughs last, thinks slowest. -- Anonymous | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, Jun 13, 2007 at 08:45:13PM +0200, Josselin Mouette wrote: The meaning of 1 TB is approximate only for approximate people. I'd expect more rigor from people working in computer science (if we can call it a science). ... and since most Debian users are not computer scientists, Scott is right. Yesterday my collegue asked me how much storage a server has that we bought from some project money, and he had to write a report. When I told him 931 MiB, he said No, I want a number like 1T or 2T (and he has an IT degree, although not CS in the strict sense). That's how people think, and if you do not acknowledge that, you're living outside of reality. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le jeudi 14 juin 2007 à 12:15 +0200, Gabor Gombas a écrit : On Wed, Jun 13, 2007 at 08:45:13PM +0200, Josselin Mouette wrote: The meaning of 1 TB is approximate only for approximate people. I'd expect more rigor from people working in computer science (if we can call it a science). ... and since most Debian users are not computer scientists, Scott is right. Yesterday my collegue asked me how much storage a server has that we bought from some project money, and he had to write a report. When I told him 931 MiB, he said No, I want a number like 1T or 2T (and he has an IT degree, although not CS in the strict sense). That's how people think, and if you do not acknowledge that, you're living outside of reality. I don't know who told you he always needs precision, but it wasn't me. http://lists.debian.org/debian-devel/2007/06/msg00589.html (The answer to all of your nonsense is already in this post, no need to repeat myself.) -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
Perhaps transforming it into a localization problem would do the trick. This way, users would be able to set their preference on byte-count in the same place as their preference on currency, decimal, and am/pm vs 24h. Applications could make use of the localization settings to calculate the amount of bytes, which would hopefully eventually centralize and generalize what counting-method the user sees. David Verhasselt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Perhaps transforming it into a localization problem would do the trick. This way, users would be able to set their preference on byte-count in the same place as their preference on currency, decimal, and am/pm vs 24h. Applications could make use of the localization settings to calculate the amount of bytes, which would hopefully eventually centralize and generalize what counting-method the user sees. David Verhasselt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, 14 Jun 2007, Ben Finney wrote: Ivan Jager [EMAIL PROTECTED] writes: On Wed, 13 Jun 2007, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. The difference being that digital specifications for things like storage capacity and memory are not measured. They are calculated, and in those contexts they *are* precise. Rounding can be done after the calculated number is obtained, but it's not inherent in the process of obtaining the number the way that measuring 1 km or 1 tablespoon is. Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. Ok, so this applies to dd and what else? I guess fdisk kind of counts, except even there, while being a specified size rather than measured, the size of the partition it creates is still rounded to a whole cylinder. I'm having trouble thinking of anything where a n00b would be specifying sizes with prefixes and expecting it to be exactly a specific size down to the byte. I thought this argument was mostly about measured sizes anyways, such as what you would get from ls -lh, df -h, du -h, or their GUI equivalents. These are all rounded. Do the GUI equivalents show full precision even with prefixes? That seems kind of pointless. AFAIK we are using precise meanings of the prefixes. They are just ambiguous, since they have more than one precise meaning. On computers, when measuring units of bytes, I am confused any time someone isn't using the binary values. (Although I'm not so surprised when the numbers are coming from marketing people.) While 10^9 2**30, I find the later to be a much more useful number on a computer. A few more things I thought of where a user might need to specify a size: xorg.conf VideoRAM option mem argument on kernel commandline mkfs resize2fs ping All of these except for ping want the byte sizes to be divisible by some power of two. Because memory comes in powers of two, and disks come in multiples of 512 bytes, the powers of two tend to be a lot more useful than the powers of ten. I might be too much of a systems person... Let me know if you can come up with examples where you would want to specify byte sizes in powers of 10 rather than 2. I am now somewhat tempted to do a small survey asking random people how much they think a megabyte is. :) Ivan
Re: Using standardized SI prefixes
On Wed, 13 Jun 2007, Wesley J. Landaker wrote: On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote: On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote: Even in the US all legitimate science and engineering is done in SI units. Suurre... That's why in 1999 the NASA Mars orbiter didn't crash because one (NASA) team worked in metric units and the other (private contractor) in imperial units. I am happy to very brutally assert that the team who didn't use SI was not doing legitimate science or engineering. But whether it's from unskilled employees or bad management, it's quite unfortunate. =( Over here we have two sieres of intro physics courses. One is for science students, and the other is for engineers. Guess what the biggest difference is. Yes, I know it's sad, but apparently engineers need to learn their physics in imperial units... :( Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ivan Jager [EMAIL PROTECTED] writes: On Thu, 14 Jun 2007, Ben Finney wrote: Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. Ok, so this applies to dd and what else? It applies to any software that refers to quantities that use these units. Pick a unit for the quantity, base-10 or base-2, and use its precise meaning and the precise term for it. I thought this argument was mostly about measured sizes anyways, such as what you would get from ls -lh, df -h, du -h, or their GUI equivalents. These are all rounded. Any time the software says GB when the quantity was actually calculated in 2^30, or says GiB when the quantity was actually calculated in 10^9, the units are mismatched. Whether the quantity was rounded is irrelevant to this fact. While 10^9 2**30, I find the later to be a much more useful number on a computer. Nothing in this proposal speaks against using 2^30 bytes as a unit of measure. The only thing wrong would be to refer to the unit as GB, because that isn't 2^30 bytes. The only unambiguous standard abbreviation for that unit is GiB. -- \ Many are stubborn in pursuit of the path they have chosen, few | `\ in pursuit of the goal. -- Friedrich Nietzsche | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
David Verhasselt [EMAIL PROTECTED] writes: Perhaps transforming it into a localization problem would do the trick. This way, users would be able to set their preference on byte-count in the same place as their preference on currency, decimal, and am/pm vs 24h. Applications could make use of the localization settings to calculate the amount of bytes, which would hopefully eventually centralize and generalize what counting-method the user sees. A GiB is the same in any locale, and has the same display -- GiB -- in any locale. Displaying it another way is misleading. -- \ We demand rigidly defined areas of doubt and uncertainty! -- | `\ Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas | _o__)Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ben Finney wrote: David Verhasselt [EMAIL PROTECTED] writes: Perhaps transforming it into a localization problem would do the trick. This way, users would be able to set their preference on byte-count in the same place as their preference on currency, decimal, and am/pm vs 24h. Applications could make use of the localization settings to calculate the amount of bytes, which would hopefully eventually centralize and generalize what counting-method the user sees. A GiB is the same in any locale, and has the same display -- GiB -- in any locale. Displaying it another way is misleading. Yes, but the fact is that there are apparently a lot of different opinions on what should be used. Therefore why not agree to disagree, and let the user decide what they want to use. Make a centralized system that converts an arbitrary byte-count to the user's preferred way of viewing it. That's where I got the locale analogy from. I know, it's probably overkill to create a whole new API for just this, but perhaps there is an API where you could add a simple function that does this to. Maybe in GTK? Either way, a centralized system would help stop errorenous usage of GiB, GB or Gb. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, 2007-06-14 at 20:15 +0200, David Verhasselt wrote: Yes, but the fact is that there are apparently a lot of different opinions on what should be used. Therefore why not agree to disagree, and let the user decide what they want to use. Make a centralized system that converts an arbitrary byte-count to the user's preferred way of viewing it. That's where I got the locale analogy from. I know, it's probably overkill to create a whole new API for just this, but perhaps there is an API where you could add a simple function that does this to. Maybe in GTK? Either way, a centralized system would help stop errorenous usage of GiB, GB or Gb. Don't we already do this for °C and °F? -- Alex Jones http://alex.weej.com/
Re: Using standardized SI prefixes
Ben Finney [EMAIL PROTECTED] writes: A GiB is the same in any locale, and has the same display -- GiB -- in any locale. Displaying it another way is misleading. I'm informed that this may not be the case. Consider the statement modified to: A GiB is the same in any locale, and displaying it as GB is never correct no matter the locale. -- \ A free society is one where it is safe to be unpopular. -- | `\ Adlai Ewing Stevenson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 19:57, Joey Hess wrote: I had generally assumed that most programmers were reaonsable and used powers of 2, but this thread is certianly changing my mind about *that*. It's not that unreasonable. Humans generally count in base 10 - computers count in base 2. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgppaW9Zr6ibG.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: shirish writes (Using standardized SI prefixes): Please look at http://en.wikipedia.org/wiki/Binary_prefix . Urgh, these things are ugly and an abomination. We should avoid them. Ian. I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. Christof Krüger
Re: Using standardized SI prefixes
One more opinion: If you consider a number more relevant than its nearest power of 2, then somebody else will consider every digit of that number relevant. In that case, don't use rounding by SI/IEC prefixes at all. For an example see Bug #420716. The first number, where the difference between base 1024 and base 1000 results in a greater inaccuracy than rounding to the next power of 2, is 2^150 vs 10^45. According to the cited wikipedia article, SI and IEC prefixes roughly go only half as far. So the difference between SI and IEC prefixes is immaterial. Regards, Mark Weyer P.S.: I am not subscribed to the list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote: On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: shirish writes (Using standardized SI prefixes): Please look at http://en.wikipedia.org/wiki/Binary_prefix . Urgh, these things are ugly and an abomination. We should avoid them. I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. User Confusion. Most users do not know what a tebibyte is, and they do not care. They know that a terabyte is about a million million bytes, and that is sufficient. Since you're rounding anyway, the loss of accuracy between about a million million bytes and just over a million million bytes is not significant. Certainly not at the expense at having to teach users another new unit. Hard drives are bought in gigabytes, memory is bought in gigabytes, etc. Quoting the same figures with a different unit in the operating system is pedantry for its own sake. Users have already learnt that the term gigabyte is approximate. Introducing new units has only added confusion, rather than removed it. Before the new units, we all knew that 1GB was an approximate figure and likely to be (for bytes) based on a power of 2. Now we have figures quoted in GB and GiB, some of which are power of 10, some of which are power of 2. Some figures quoted in GiB are wrong, and should be in GB; likewise some in GB should be GiB. And we still have many figures in both GB and GiB which are neither of the two! Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse everyone into thinking it's a different thing, of course. Or maybe it should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these help the situation. Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. (And none of this takes into account partitioning and filesystem overhead!) I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. Scott [0] Unless you're older than 25. -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
On 13/06/07, Christof Krüger [EMAIL PROTECTED] wrote: I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. So far in this discussion i honestly thought that the arguments against SI prefixes were too obvious to bother mentioning. Let me start with a dumb example: For a child or uninterested commoner that flying critter is simply a birdie. For those in the know exactly the same entity is a Falco peregrinus. Even if simply calling it birdie or perhaps falcon would be easier, more user friendly more understandable for everyone it simply would not be /correct/. Therefore it must stay Falco peregrinus in all contexts where really conveying information matters. Computers deal with numbers in base two. Humans deal with numbers in base 10. When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. In the same was as with pi redefining or standardizing kilobytes and megabytes would be totally useless AND completely wrong. Computers have always, do, and will continue to deal with their numbers along the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... So, when dealing with computers, must we. One does not redefine Falco peregrinus to birdie because that would make it more understandable for the commoner. Ornithologists need it to stay Falco peregrinus in the future. One does not redefine pi to a value of 3 because that would make it more understandable for the commoner. Mathematicians, architects (and basically everyone else) need it to stay ~3.1415926535 in the future. One does not redefine kilobyte to mean 1000 (base 10) because that would make it more understandable for the commoner. Real computer people need it to stay 1024 (base 10). A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. Finally a personal and subjective thought. At times one has to chose whether to oversimplify facts and information to the point where everyone understands it, (If this happens they DO NOT understand it; they are given the illusion of understanding) or whether to educate the public. I am very convinced the correct solution is always to educate the public. The world is not flat. The earth is not the center of the universe. Pi is not 3. A kilobyte is not 1000; it is 1024 because that is the way computers work. Regards, Bjørn Ingmar Berg -- blog.bergcube.net/
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. No it doesn't. The meaning of 1 TB depends on the context, and has always done so. Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
Hallo, On 6/13/07, Scott James Remnant [EMAIL PROTECTED] wrote: The meaning of 1 TB depends on the context, and has always done so. Wrongly. -- -alex http://www.ventonegro.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. 10% error is no good for me. You can continue to play the at least card, but what about when it's more important if it is at most something? And seeing as this error only goes up exponentially, at which prefix do you draw the line and say no more? And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). -- Alex Jones http://alex.weej.com/
Re: Using standardized SI prefixes
On Wednesday 13 June 2007 15:29, Scott James Remnant wrote: On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote: On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: [...] Please tell me the disadvantages so there can actually be a constructive discussion. User Confusion. Most users do not know what a tebibyte is, and they do not care. They know that a terabyte is about a million million bytes, and that is sufficient. Since you're rounding anyway, the loss of accuracy between about a million million bytes and just over a million million bytes is not significant. Certainly not at the expense at having to teach users another new unit. This is a hurdle to adoption, a one time cost. It is not an argument against IEC prefixes per se. The long-term benefits outweigh the costs, IMO. Hard drives are bought in gigabytes, memory is bought in gigabytes, etc. Quoting the same figures with a different unit in the operating system is pedantry for its own sake. Users have already learnt that the term gigabyte is approximate. No, it's not. It's ambiguous. A given number can be exact or approximate regardless of the unit. 1.0 GB can mean either 1.0·10^9 byte or 1.0·2^30 byte, but whether the real value is exactly one or the other or something near one or the Introducing new units has only added confusion, rather than removed it. New concepts can always cause initial confusion. Relearning is harder than learning something right from the beginning. The same argument has been used against metrication in the US. Again, it's a one-time cost. Before the new units, we all knew that 1GB was an approximate figure and likely to be (for bytes) based on a power of 2. Now we have figures quoted in GB and GiB, some of which are power of 10, some of which are power of 2. Some figures quoted in GiB are wrong, and should be in GB; likewise some in GB should be GiB. And we still have many figures in both GB and GiB which are neither of the two! You're talking a lot about approximation. If I understand you correctly, you're saying that any stated quantity of data must either be an exact number, e.g. 23 368 986 120 bytes, or an approximation with a single significant digit. That is *stupid*. You want to deny people the *possibility* of consistence, unambiguity and accuracy (without resorting to numbers on the form 3.1·10¹²), just because you won't think that you'll need that possibility most of the time. There *is* reason to state rounded numbers with two or three digits, in which case the difference between MB and MiB or GB and GiB definitely matters, and even with a single significant digit, 8 GiB (exactly) is 9 GB when rounded to the nearest whole number. Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse everyone into thinking it's a different thing, of course. Or maybe it should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these help the situation. The 1 440 KiB floppy is dead. Let it rest in pieces. The fact that a marketing department screwed up long ago by thinking that 1 440 kB equals 1.44 MB, which it would have done, had that really *been* 1 440 kB and not 1 440 KiB, is not a case against IEC prefixes. On the contrary, it may well be a prime example of a confusion that wouldn't have happened if the IEC prefixes had been adopted by then. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpQnKqXRd0XO.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote: On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: shirish writes (Using standardized SI prefixes): Please look at http://en.wikipedia.org/wiki/Binary_prefix . Urgh, these things are ugly and an abomination. We should avoid them. I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. User Confusion. Most users do not know what a tebibyte is, and they do not care. They know that a terabyte is about a million million bytes, and that is sufficient. Since you're rounding anyway, the loss of accuracy between about a million million bytes and just over a million million bytes is not significant. Certainly not at the expense at having to teach users another new unit. Hard drives are bought in gigabytes, memory is bought in gigabytes, etc. Quoting the same figures with a different unit in the operating system is pedantry for its own sake. Users have already learnt that the term gigabyte is approximate. Wrong most users think of gigabyte as absolute rather than approximation. If that was not the case then http://en.wikipedia.org/wiki/Binary_prefix#Legal_disputes wouldn't have happened. Most of the users when they burn a CD/DVD use the approximation GB to say a burn a movie DVD. Most of the DVD media is marketted as 4.78 GB while its 4.38 GiB hence when they download a movie (legally downloaded or otherwise) or do mixed mode stuff. Also I don't know many users who go down to byte-size level see how much space is remaining. I do get support calls over this quite a bit. Thinking that users know its an approximate IMHO is an oversimplification. Introducing new units has only added confusion, rather than removed it. The same could be said of relatively newer concepts like free software, open source, copyright, creative licenses, .PNG, .SVG all the newer stuff that the web keeps pouring in. Micro formats anyone. That doesn't mean we stop learning, it just means we adjust ourselves to the new reality. Before the new units, we all knew that 1GB was an approximate figure and likely to be (for bytes) based on a power of 2. Now we have figures quoted in GB and GiB, some of which are power of 10, some of which are power of 2. Some figures quoted in GiB are wrong, and should be in GB; likewise some in GB should be GiB. And we still have many figures in both GB and GiB which are neither of the two! Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse everyone into thinking it's a different thing, of course. Or maybe it should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these help the situation. Right, although it doesn't completely solve the situation it does take things to a nearer perfect answer. I do see that it would take time for us to make that change but its a better change IMO. Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. (And none of this takes into account partitioning and filesystem overhead!) I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. Do you think most common users are ever going to go down to byte size level to see if things fit or not. It would actually be a good test for Novell . I believe they do desktop tests for HIG see how users actually do stuff. Not techies but day-to-day the Johns Janes. Scott [0] Unless you're older than 25. -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] Cheers -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17
Re: Using standardized SI prefixes
I demand that Alex Jones may or may not have written... And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I used one yesterday to do a BIOS upgrade. :-) 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. It means 1024^4 bytes, no more and no less. :-þ -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html We'll get along fine as soon as you realise that I'm God!
Re: Using standardized SI prefixes
On Wednesday 13 June 2007 15:19, Bjørn Ingmar Berg wrote: Let me start with a dumb example: (OK, dumb example duly deleted) Computers deal with numbers in base two. Humans deal with numbers in base 10. When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. I don't agree with that. Compilers generally understand numbers in base 10, for example. More about that later. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. So? This is why there needs to be a separate set of prefixes for powers of 2. As for that falcon, it's just another example of why there needs to be a well-defined vocabulary even if the common people don't care about the details. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. In the same was as with pi redefining or standardizing kilobytes and megabytes would be totally useless AND completely wrong. Computers have always, do, and will continue to deal with their numbers along the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... So, when dealing with computers, must we. Again, computers are perfectly capable of presenting numbers in base ten or any other base, depending on what is most convenient. Otherwise we might have been forced to input numbers in binary and get answers like Total distance: 10011.1 km back (with k meaning 2^10, of course). That SI prefixes have been used to express powers of two is more specifically an artifact of memory addressing. The sizes of memory banks are normally a power of two. In that case it's convenient to say that the memory capacity is 64 MiB when you mean that it's 67 108 864 byte. But for data on a wire, or even files on a disk, there isn't anything constraining sizes to a power of two (block sizes are a number of KiB, but you rarely need to think of that as a user). One does not redefine pi to a value of 3 because that would make it more understandable for the commoner. Mathematicians, architects (and basically everyone else) need it to stay ~3.1415926535 in the future. One does not redefine kilobyte to mean 1000 (base 10) because that would make it more understandable for the commoner. Real computer people need it to stay 1024 (base 10). It's not about redefining kilobyte to mean 1000, because, as has been pointed out repeatedly, a kilobyte is currently either 1000 byte or 1024 byte depending on context. There is no exact definition, just a rather vague convention. This is about once and for all ending that mess. Your analogy with redefining pi as exactly 3 is way off, because pi is a natural constant and as such has been defined since the beginning of time. Redefining pi would be like trying to alter the shape of the universe or the laws of nature. Deciding that SI prefixes shall be SI prefixes even in computer context is not like trying to strip 24 bytes off every block of 1024, or mandating that computers always have to use BCD internally. A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. That doesn't make vagueness and ambiguity *desirable*. It is common to have a well-defined terminology wherever people need to communicate efficiently without misunderstandings. Two examples are the SI units and prefixes. Finally a personal and subjective thought. At times one has to chose whether to oversimplify facts and information to the point where everyone understands it, (If this happens they DO NOT understand it; they are given the illusion of understanding) or whether to educate the public. I am very convinced the correct solution is always to educate the public. Good. Let's then teach the public that borrowing well-defined SI prefixes and giving them a different meaning in some situations was a bad idea, and that an adequate solution exists. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp3oIOldbVpg.pgp Description: PGP signature
Re: Using standardized SI prefixes
Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. The Spanish Royal Academy also defines[2] it as 10^12, which would mean every Spanish speaking country uses that definition too. [1] http://www.m-w.com/mw/table/number.htm [2] http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3LEMA=bill%F3n -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Let me start with a dumb example: For a child or uninterested commoner that flying critter is simply a birdie. For those in the know exactly the same entity is a Falco peregrinus. Even if simply calling it birdie or perhaps falcon would be easier, more user friendly more understandable for everyone it simply would not be /correct/. The word birdie is a generalization of quite every critter that can fly. So it is correct, the critter Falco peregrinus is a birdie, too. Calling this critter falco peregrinus is correct, too. The example just doesn't apply here because KB is not a generalization of KiB and vice versa. Computers deal with numbers in base two. Humans deal with numbers in base 10. When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. Right, and this is the reason why having the same name for different things is not good. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. Well, another example that does not apply here. Nobody wants to change something true to something wrong. The status quo is that KB can mean either 1000 or 1024 bytes depending on the context (or shoe size of the developer or whatever). So there is an ambiguity here. Introducing SI prefixes would eliminate ambiguities if applied consistently. Pi is well defined. There is no ambiguity. Computers have always, do, and will continue to deal with their numbers along the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... So, when dealing with computers, must we. Yup, I totally agree. But why do we call it kilo then, when we actually mean 1024? Someone found it handy dozens of years ago and everybody has adapted it. So back then, someone was redefining your pi to 3 because it was close enough and now we should leave it this way? Remember that until computers have been invented (or binary logic), kilo has always meant 1000. A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. This is called a homograph. An example taken from wikipedia: shift n. (a change) shift n. (a period at work) I agree that in normal life you can guess the meaning from the context because it has completely different meanings. However, I don't agree that this should hold true in computer science. One possible meaning of KB is 1000 bytes. The other is 1024 bytes. Now take the sentence: Hello John. I've got a file here and want to send it to you. It's 25KB large. Now please extract from the context which meaning is significant here? The problem is that the both possible meanings depict exactly the same: a quantity of bytes. Finally a personal and subjective thought. At times one has to chose whether to oversimplify facts and information to the point where everyone understands it, (If this happens they DO NOT understand it; they are given the illusion of understanding) or whether to educate the public. I think that you base your argumentation on wrong assumptions. The purpose of introducing SI prefixes is *not* to make the newbie's life simpler, at least not as primary goal. Surely, there are situations where it really doesn't matter (e.g. if you are interested in the order of magnitude 10% error may be totally acceptable). However, SI prefixes make life easier for technical stuff where it is important to be exact without having to guess the context, ask every time or consider the professional background of your communication partner. Regards, Christof Krüger
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. [...] [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an American billion. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mercredi 13 juin 2007 à 15:06 +0100, Scott James Remnant a écrit : On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. No it doesn't. The meaning of 1 TB depends on the context, and has always done so. The meaning of 1 TB is approximate only for approximate people. I'd expect more rigor from people working in computer science (if we can call it a science). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Using standardized SI prefixes
Christof Krüger [EMAIL PROTECTED] writes: I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. Trying to change every piece of software in existence is a waste of time and energy for a problem that isn't that serious. IMO, that's the *real* objection; most of the arguments are justifications for that position or are about things that we'd get over if this issue were addressed (like the silly words -- there are sillier words in English that just don't sound that way because we're used to them). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: [...] And we still have many figures in both GB and GiB which are neither of the two! okay ... reading on ... [...] I see no problem with this 1TB quote being approximate. It's rounded anyway. So you don't care if it is approximate? Then you should care less if it's even exact! However, I find that tebibyte, gibibyte, mebibyte and kibibyte sound quite familiar to their base-10 friends so that it should be no problem even for a dumb user to understand its meaning if he already knew what a gigabyte or megabyte is. This is especially the case with the short notation (e.g. KiB vs. KB). The more important case is when a user actually *cares* about the exact number. At the moment base 10 and base 2 numbers are often prefixed both with k for kilo, M for mega etc. This means that there will be confusion if something is labeled 100GB. Now consider introducing SI prefixes. There still will be confusion with 100GB, because apparently not everyone likes SI prefixes and continues using the old prefixes with base 2 numbers. However, when something is labeled 100GiB, there is no confusion (remember that we are talking about a user that cares about the exact number, the dumb user will guess that GiB must be something similar to GB). Okay, so we gained some confidence about what is meant. How can we get rid of the rest of uncertainty? Answer: Use the SI prefixes consistently! This will take a while of course, but eventually you can only benefit. Regards, Christof Krüger
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote: Even in the US all legitimate science and engineering is done in SI units. Suurre... That's why in 1999 the NASA Mars orbiter didn't crash because one (NASA) team worked in metric units and the other (private contractor) in imperial units. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mercredi 13 juin 2007 à 15:19 +0200, Bjørn Ingmar Berg a écrit : When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. Anyone starting with such assumptions should never design any kind of user interface. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. Which is why they need appropriate units. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. This is exactly what you are trying to do: state that 1024 = 1000. A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. Yeah, sure. This is why mathematicians always use 3 instead of Pi in calculations. After all they are similar, and you can infer which one is actually being used depending on the context. I am very convinced the correct solution is always to educate the public. The world is not flat. The earth is not the center of the universe. Pi is not 3. A kilobyte is not 1000; it is 1024 because that is the way computers work. I am convinced the correct solution is to educate the group of blindfold hackers who think 1024 = 1000. It is much easier than educating millions of users. Wake up, Neo. There is a world out there. And in this world, kilo means 1000. One thousand. 10³. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Using standardized SI prefixes
As I see it there are two ways of resolving the difference between KiB and KB. * Use Rosetta to update the text and fix the output so that it now reads KiB. This would be relatively simple to do, but not actually helpful longer term. * Fix the source code that calculates KB by doing a bit shift[0] and instead dividing the number of bytes by a power of 10. [0] I'm assuming that most applications will calculate how many Kilobytes/Megabytes are used by dividing by a power of two. -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 13 Jun 2007, Alex Jones wrote: On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. 10% error is no good for me. You can continue to play the at least card, but what about when it's more important if it is at most something? And seeing as this error only goes up exponentially, at which prefix do you draw the line and say no more? And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. But, just because it is approximate, doesn't mean it isn't also ambigouous. :) 1 TB could mean between 5000 and 14999 bytes, between 549755813888 and 1649267441663 bytes, or even between 5000 and 14999.99... bels. :) So, if you want the exact number of bytes, don't round it off, and if you do round it off, don't be surprised if the rounding is ambiguous, because the units are not SI units, and the prefixes may or may not be. Just don't use prefixes when not rounding. I wonder, do people feel as storngly about exactly how many tablespoons 1 TT is? Ivan
Re: Using standardized SI prefixes
On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote: On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote: Even in the US all legitimate science and engineering is done in SI units. Suurre... That's why in 1999 the NASA Mars orbiter didn't crash because one (NASA) team worked in metric units and the other (private contractor) in imperial units. I am happy to very brutally assert that the team who didn't use SI was not doing legitimate science or engineering. But whether it's from unskilled employees or bad management, it's quite unfortunate. =( -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Using standardized SI prefixes
Ivan Jager [EMAIL PROTECTED] writes: On Wed, 13 Jun 2007, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. The difference being that digital specifications for things like storage capacity and memory are not measured. They are calculated, and in those contexts they *are* precise. Rounding can be done after the calculated number is obtained, but it's not inherent in the process of obtaining the number the way that measuring 1 km or 1 tablespoon is. Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. -- \ I moved into an all-electric house. I forgot and left the | `\ porch light on all day. When I got home the front door wouldn't | _o__) open. -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Russ Allbery [EMAIL PROTECTED] writes: Christof Krüger [EMAIL PROTECTED] writes: I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. Trying to change every piece of software in existence is a waste of time and energy for a problem that isn't that serious. This proposal was never about trying to change every piece of software in existence. Just because perfection is unobtainable doesn't stop us from working to improve the state of what we have. IMO, that's the *real* objection; most of the arguments are justifications for that position or are about things that we'd get over if this issue were addressed (like the silly words -- there are sillier words in English that just don't sound that way because we're used to them). Agreed. Most of the arguments against this proposal to follow a useful standard that improves clarity have been essentially yuk or I'm alright Jack. Yes, the names sound silly. So does byte, but we follow that convention. A silly name is not an argument against following the standard. The names are close enough to the wrongly-applied base-10 names that familiarity is fairly easily obtainable, while still being different enough that they are distinct names. Yes, most of us who frequently work with computers have become accustomed to the ambiguity of these terms, in a field where precision of terminology is highly valued. This is no reason not to work toward fixing this for the majority of people who have yet to spend any significant time exposed to these terms. -- \ One of the most important things you learn from the internet | `\ is that there is no 'them' out there. It's just an awful lot of | _o__) 'us'. -- Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Eduard Bloch [EMAIL PROTECTED] writes: What is not really understandable is why this stupid naming has been kept in Windows XP. Because nobody actually cares except control-freak types, and they're certainly not who windows is targetting! -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, Jun 13, 2007 at 07:41:27PM +0100, Adam D. Barratt wrote: On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. [...] [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an American billion. http://en.wikipedia.org/wiki/Long_and_short_scales It all depends on space and time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 09:55:35PM +0200, Magnus Holmgren [EMAIL PROTECTED] wrote: On Monday 11 June 2007 21:41, Joey Hess wrote: Alex Queiroz wrote: On 6/11/07, Joey Hess [EMAIL PROTECTED] wrote: No, I hate that convention. K and k should only ever refer to 1024. Like in kg or km? This thread is about units of data. kbit? kbit/s? kB/s? So, a Gigabit ethernet card has a rate of 1073741824000 bits a second ? cool ;) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:21, Joey Hess wrote: Bastian Venthur wrote: What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? iftop, top, ls, and df are the first few to come to mind. Both ls and df produce very variable-width output where one extra i is no big deal. Besides, they don't use prefixes by default. top uses m for mebi (and nothing for kibi), which is *completely* wrong - but on the other hand m can't be confused with M for mega-. The default layout seems to have enough space left, but, just to be sure, perhaps we can make an exception if it's well documented? iftop uses powers of 2 except if logarithmic scale for the bar graphs is turned on. I think it would be better if it used powers of 10 throughout. There is a comment: /* This 1024 vs 1000 stuff is just plain evil */ None of these put a space between the number and the unit, as is proper, but that I don't think can be reasonably expected. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgpV1ndhcmP5Y.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 23:10, Hendrik Sattler wrote: Abbreviations are ambiguous by design. Who actually says that KB means kilobyte? You're arguing that although IEC prefixes eliminate all ambiguity in the area of amounts and rates of data, there is still some ambiguity left, i.e. IEC prefixes have to be rejected for not being a perfect solution. http://en.wikipedia.org/wiki/Perfect_solution_fallacy I don't like those Special Interest units in all situations ;) SI units aren't special. They are universal. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpsWRlWvrljp.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 02:56, Mark Reitblatt wrote: On 6/11/07, Alex Jones [EMAIL PROTECTED] wrote: Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. That's not consistent. Kilobyte has always meant 2^10 bytes. kilo in kilobyte is not an SI prefix. SI prefixes only apply to SI measurements, of which byte is not a member. There is no confusion; the only place where a kilobyte != 2^10 bytes is in hard drive manufacturer's advertising materials. This is the way it has been for decades, and it is a perfectly acceptable and desirable standard. That's an argument that's been heard before but it's *wrong*. SI prefixes *are* used with non-SI units without losing their normal meaning and there is no reason why bytes should be an exception. Since kilo has always meant 1000, kilobyte must initially have meant 1000 bytes, before people started to use it as if to mean 1024. There is confusion; hard drive manufacturers' advertising material is not the only place where kilobyte != 2^10 bytes. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpy4lPhufMuy.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 08:36:39AM +0200, Magnus Holmgren wrote: That's an argument that's been heard before but it's *wrong*. SI prefixes *are* used with non-SI units without losing their normal meaning and there is no reason why bytes should be an exception. Since kilo has always meant 1000, kilobyte must initially have meant 1000 bytes, before people started to use it as if to mean 1024. There is confusion; hard drive manufacturers' advertising material is not the only place where kilobyte != 2^10 bytes. If I remember my history of computing correctly, kilo was not chosen to mean exactly 1000 when it came to computers. Things were initially done in powers of 2 (oversimplification). Since 2^10 = 1024 ≈ 1000, kilo was chosen as the prefix to use, since it already existed. The idea of going back and redifining the kilo to mean exactly 1000 in the context of computing was a marketing gimmick. Besides, there are other units of measure which carry the same name and have different numerical values based on context (think statute miles and nautical miles), though I don't think any such examples can be found in the SI. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Hi Thijs! You wrote: We are talking about tools like aptitude here, or at least, the OP does. Did you ever have 2 GB free and decided to install a package that would exactly fill that space in? Afaik, we are talking about making the use of the prefixes consistent over all of Debian, so that everywhere the program says MB, you know exactly what that means. Doing everywhere except in apt would kind of defeat the purpose, because then you still can't be sure... Bas. -- +--+ | Bas Zoetekouw | Sweet day, so cool, so calm, so bright, | || The bridall of the earth and skie: | | [EMAIL PROTECTED] | The dew shall weep thy fall tonight;| +|For thou must die. | +-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Hi all, Somebody asked about real world experiences. Ever tried fitting mixed multiple data to a CD or DVD have to see in byte-size if things are good or not. Ever downloaded an .iso only to find later it doesn't fit the CD/DVD by some MiB . How much overburning can be done by a CD/DVD burning application . I do lot of burning of content it really pisses me off. If software guys pick up the trend then only there is hope. Otherwise do the reverse make it so that 1000 bytes is a KB not 1024 something has to be changed. -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 08:44, Roberto C. Sánchez wrote: On Tue, Jun 12, 2007 at 08:36:39AM +0200, Magnus Holmgren wrote: That's an argument that's been heard before but it's *wrong*. SI prefixes *are* used with non-SI units without losing their normal meaning and there is no reason why bytes should be an exception. Since kilo has always meant 1000, kilobyte must initially have meant 1000 bytes, before people started to use it as if to mean 1024. There is confusion; hard drive manufacturers' advertising material is not the only place where kilobyte != 2^10 bytes. If I remember my history of computing correctly, kilo was not chosen to mean exactly 1000 when it came to computers. Things were initially done in powers of 2 (oversimplification). Since 2^10 = 1024 ≈ 1000, kilo was chosen as the prefix to use, since it already existed. The idea of going back and redifining the kilo to mean exactly 1000 in the context of computing was a marketing gimmick. It is possible that nobody used the word kilobyte before it became conventional to use it to mean 1024 bytes, but if they did, it must have meant 1000 bytes, by default. Besides, there are other units of measure which carry the same name and have different numerical values based on context (think statute miles and nautical miles), though I don't think any such examples can be found in the SI. Of course not. The utter mess of miles, gallons, tons, pounds troy/avoirdupois, and so on, is completely irrelevant. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpywNT4mshd8.pgp Description: PGP signature
Re: Using standardized SI prefixes
Magnus Holmgren [EMAIL PROTECTED] writes: No it doesn't. The SI binary prefixes are an abomination. Why - besides pronunciation? Well among other things, the end result of this whole mess will likely be to _increase_ confusion, rather than lessen it: Until now, in a typical computer app, 900K had an unambiguous meaning: 900*1024. Now that a bunch of people are all in a misguided frenzy to correct things (which weren't broken), there will almost certainly be cases where some silly fool will change the _calculation_ but not the label (e.g., in a case where space is at a premium) -- e.g., they'll keep K, but change the calculation to / 1000, because that's correct. However it's _guaranteed_ that many apps will stick with / 1024. Thus a suffix (e.g. K) which was previously unambiguous in practice (and no, disk-drive advertisements don't count) will have become more ambiguous in practice. [At which point of course the kib-fans will start crying out that because things are now very confused, we muuust switch to gib suffixes -- all because they basically screwed things up.] Great. -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:21, Joey Hess wrote: Bastian Venthur wrote: I agree with the sounds stupid part, although I don't belive this is a valid argument. It's a perfectly valid argument for me to use to ignore a bad standard. If the standard makes me talk funny, I will ignore it or make fun of it. Most of the time you won't have to say it. Spoken language tends to be less formal than written language, and 2^10 bytes still is approximately a kilobyte (and so on up to giga, where the approximation starts to fail). So you only have to say kibibyte when you need to be precise. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpEKOaSzboZ9.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 03:54:25PM +0900, Miles Bader wrote: Until now, in a typical computer app, 900K had an unambiguous meaning: 900*1024. No, its 900 Kelvin aka 626.85°C Should I say that kb and Mb are kilo bases and mega bases, as in DNA? Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, Friday's Child, stardate 3497.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le lundi 11 juin 2007 à 19:56 -0500, Mark Reitblatt a écrit : That's not consistent. Kilobyte has always meant 2^10 bytes. No, it has never. Kilo has always meant 10^3. Full stop. End of story. Bye bye. People didn't invent the SI just so that a small group of hackers decide that suddenly it is 2^10 just because it is more convenient. SI units are *universal*. There is a world outside computing, you know. Just ask anyone outside your small world how much bytes they think a kilobyte is. kilo in kilobyte is not an SI prefix. Kilo is always a SI prefix. SI prefixes only apply to SI measurements No. There is no confusion; There seems to be in your mind. the only place where a kilobyte != 2^10 bytes is in hard drive manufacturer's advertising materials. No. A kilobyte is 10^3 bytes everywhere. At least, in all countries who use SI units. This is the way it has been for decades, and it is a perfectly acceptable and desirable standard. It has never been anything but a gross imprecision introduced by people incapable of following rigorous standards. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 09:20:30AM +0200, Josselin Mouette wrote: Le lundi 11 juin 2007 à 19:56 -0500, Mark Reitblatt a écrit : That's not consistent. Kilobyte has always meant 2^10 bytes. No, it has never. Kilo has always meant 10^3. Full stop. End of story. Bye bye. People didn't invent the SI just so that a small group of hackers decide that suddenly it is 2^10 just because it is more convenient. SI units are *universal*. Really? Because there is no history of words being co-opted and being assigned new meanings? Pirate? Hacker? It is a fact that, lacking a better work, people will take a word that is a close approximation in some way and use it. The kilo ≈ 2^10 is not the first, nor will it be the last. It has never been anything but a gross imprecision introduced by people incapable of following rigorous standards. It has never been anything more than people defaulting to a close approximation. Language is imperfect. People make do. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 08:54, Miles Bader wrote: Magnus Holmgren [EMAIL PROTECTED] writes: No it doesn't. The SI binary prefixes are an abomination. Why - besides pronunciation? Well among other things, the end result of this whole mess will likely be to _increase_ confusion, rather than lessen it: In that case it's not an end result. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpO9RTU1zlB8.pgp Description: PGP signature
Re: Using standardized SI prefixes
Miles Bader wrote: Magnus Holmgren [EMAIL PROTECTED] writes: No it doesn't. The SI binary prefixes are an abomination. Why - besides pronunciation? Well among other things, the end result of this whole mess will likely be to _increase_ confusion, rather than lessen it: Until now, in a typical computer app, 900K had an unambiguous meaning: 900*1024. How often must we repeat it: it is not unambiguous. When you buy a hard drive 500G does not mean 500 * 1024³ (please note: one context [size], two different meanings for G). 1Mbit/s usually means 10^6 bits per second in the context of data transfer rates. How is this unambiguous for you? Now that a bunch of people are all in a misguided frenzy to correct things (which weren't broken), there will almost certainly be cases where some silly fool will change the _calculation_ but not the label (e.g., in a case where space is at a premium) -- e.g., they'll keep K, but change the calculation to / 1000, because that's correct. Nope, it's more likely that *if* we take action, we would chose the binary suffix notation to avoid this confusion. -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 03:29 -0400, Roberto C. Sánchez a écrit : It has never been anything but a gross imprecision introduced by people incapable of following rigorous standards. It has never been anything more than people defaulting to a close approximation. Language is imperfect. People make do. You'll tell that to a court if there is such an approximation in a contract. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 09:36:34AM +0200, Josselin Mouette wrote: Le mardi 12 juin 2007 à 03:29 -0400, Roberto C. Sánchez a écrit : It has never been anything but a gross imprecision introduced by people incapable of following rigorous standards. It has never been anything more than people defaulting to a close approximation. Language is imperfect. People make do. You'll tell that to a court if there is such an approximation in a contract. What are you talking about? We all know that the *precise* meaning of kilo is 1000. The point is that the term was also co-opted, since there was not a better term. If you are talking about a contract, I would expect that the *precise* meanings of words are being used, along with definitions of any words where there could be ambiguity. Why do you think that the marketing materials for most hard drives include the note that 1 GB = 1 000 000 000 bytes? If the SI prefixes only ever held their *precise* meanings, then such clarifications would not be necessary. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 03:43 -0400, Roberto C. Sánchez a écrit : What are you talking about? We all know that the *precise* meaning of kilo is 1000. The point is that the term was also co-opted, since there was not a better term. If you are talking about a contract, I would expect that the *precise* meanings of words are being used, along with definitions of any words where there could be ambiguity. When I use a computer program, I don't want to wonder whether it uses precise units or approximate ones. A computer is a damn stupid machine and it will never know whether I need precision. Which is why it should *always* do things the precise way. Why do you think that the marketing materials for most hard drives include the note that 1 GB = 1 000 000 000 bytes? Maybe because they are sold in the US, one of the 3 countries where SI units are not standard? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Mon, 2007-06-11 at 19:56 -0500, Mark Reitblatt wrote: On 6/11/07, Alex Jones [EMAIL PROTECTED] wrote: Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. That's not consistent. Kilobyte has always meant 2^10 bytes. kilo in kilobyte is not an SI prefix. SI prefixes only apply to SI measurements, of which byte is not a member. There is no confusion; the only place where a kilobyte != 2^10 bytes is in hard drive manufacturer's advertising materials. This is the way it has been for decades, and it is a perfectly acceptable and desirable standard. It's all not as simple as you write it. Bit rates have been usually measured in 10^(3x) bit per second, e.g. kbps or kbit/s. So when talking about transfer rates, kilo meant thousand. However, when talking about file/memory sizes, kilo meant 1024. But then again, a lot of people aren't aware of this difference and there are a lot of programs which present e.g. download speeds in 2^(10x) bytes per second (_bits_ per second are more common to be used in lower levels, but there are also programs which use 2^10 _bits_ per second as transfer speed units). Another historic example is a floppy-MB: A 1.44MB floppy disc can store 1,474,560 Bytes, that is 1440 KiB and 1.40625 MiB or approximately 1475KB or 1.48MB with kilo=10^3 and mega=10^6. However, these floppies were known as 1.44MB-floppies. (MB meaning 1000 times 1024 bytes). Very consistent! Your example of hard drive manufacturers is a another good example why we actually SHOULD have unambiguous prefixes. Advertising always tends to abuse ambiguities. When SI prefixes were used consistently, it would have been clear from start that you cannot fit 100 GiB of data on a hard drive advertised as having 100GB free space available. Just because something has been done wrong for a long time doesn't make it right. People who know the inconsistencies get used to them and do not want to change it because it may be inconvenient for them or it simply sounds stupid to them (what an argument!). However, this means that _every_ new generation of students and hobbyists has to go through learning the inconsistencies if we change nothing. Hooray, confusion till the end of times! But if we pushed the use of SI-prefixes, the computer-gurus would have to get used to the new system but following generations would profit from having a consistent unit system. In my opinion this is something that is worth the effort. The problem with such big changes is that a critical mass is needed to benefit from this new system and the faster it is achieved, the shorter the confusion-period will be. I think that the open source community should participate since consistent and unambiguous conventions are a good thing (TM). Christof Krüger
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 09:37 +0200, Christof Krüger wrote: Another historic example is a floppy-MB: A 1.44MB floppy disc can store 1,474,560 Bytes, that is 1440 KiB and 1.40625 MiB or approximately 1475KB or 1.48MB with kilo=10^3 and mega=10^6. However, these floppies were known as 1.44MB-floppies. (MB meaning 1000 times 1024 bytes). Very consistent! The difference is a sufficiently small percentage, that most users will not care. In fact, the only people who ever seem to care enough to know that a 1.44MB floppy disk is actually 1.48 Million Bytes are geeks. I don't think it's the differing scale of units that confuse people, changing KB to KiB everywhere where you don't use kB -- I think it's the reality of having differencing scales in the first place that's confusing. Changing the unit prefixes is just a geek precision gratification that will confuse everybody who is used to talking about kilobytes, and gigabytes... My computer has two gigabytes of RAM! Aha! No it doesn't! It says two gigabytes. No, you mean two gibibytes! A gigabyte is ten-to-the-nice bytes, whereas a gibibyte is two-to-the-thirty bytes! *punch* Ow! You broke my nose! Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
On 12/06/07 15:37, Christof Krüger wrote: Just because something has been done wrong for a long time doesn't make it right. People who know the inconsistencies get used to them and do not want to change it because it may be inconvenient for them or it simply sounds stupid to them (what an argument!). However, this means that _every_ new generation of students and hobbyists has to go through learning the inconsistencies if we change nothing. Hooray, confusion till the end of times! But if we pushed the use of SI-prefixes, the computer-gurus would have to get used to the new system but following generations would profit from having a consistent unit system. In my opinion this is something that is worth the effort. The problem with such big changes is that a critical mass is needed to benefit from this new system and the faster it is achieved, the shorter the confusion-period will be. I think that the open source community should participate since consistent and unambiguous conventions are a good thing (TM). Christof Krüger Until you wrote these two paragraphs I was not particularly interested. Your email prompted me to read some more. Now I'm happy to be counted in the camp of those that chant standardise. (Of course now I'll be laughed at because of using kibibytes, but you get that :) To be fair, I suspect that the use of kibibyte in spoken language would be phased out over time. Perhaps the IEC did pronounce them out aloud so we would all be embarrassed into using the SI units :) And just in case anyone else was as confused as I was, wikipedia cleared it up for me: * http://en.wikipedia.org/wiki/Kibibyte * http://en.wikipedia.org/wiki/Kibi (Ironically, my spell-checker had never heard of a kibibyte :) -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mardi 12 juin 2007 à 09:24 +0100, Scott James Remnant a écrit : Changing the unit prefixes is just a geek precision gratification that will confuse everybody who is used to talking about kilobytes, and gigabytes... The confusion lies in the current situation. Bringing precision doesn't bring any confusion. My computer has two gigabytes of RAM! Aha! No it doesn't! It says two gigabytes. No, you mean two gibibytes! A gigabyte is ten-to-the-nice bytes, whereas a gibibyte is two-to-the-thirty bytes! *punch* Ow! You broke my nose! We're not talking about spoken language here. Nobody cares about gigabytes / gibibytes when discussing how much RAM / disk / horsepower a computer has. We are talking of fixing computer programs with incorrect or confusing display. Of course, I don't usually care that file sizes in my browser window are displayed in kibibytes and mebibytes. Not until I select some of them, see the total size, and ask myself whether they fit on a DVD. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 11:40:46AM +0200, Josselin Mouette wrote: Of course, I don't usually care that file sizes in my browser window are displayed in kibibytes and mebibytes. Not until I select some of them, see the total size, and ask myself whether they fit on a DVD. If you want to figure out whether they fit on a DVD, you want the number of bytes in your total anyway, not the amount of kilobytes (regardless of whether that's 10^3 or 2^10) -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
