Centibytes, anyone?
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
I'd put it down to sloppy programming. A floating point value makes sense when they're scaling to KB/MB/GT/TB. They didn't bother handling the size as a simple integer when not scaling.
Software Zen:
delete this; -
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
I think they are missing a decimal: if your file is 429399 bytes and 1 bit that makes 429399.125 bytes. Rounding it to 429399.12 is just sloppy :D
Mircea
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
I was waiting for you to make a Hellraiser reference right up to the end of your post.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
Did the same on a Ubuntu 22.04LTS system and Samsung A22.
...
Size 639.7 kB (639,675 bytes)
...Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
I was waiting for you to make a Hellraiser reference right up to the end of your post.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You weren't alone.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
trønderen wrote:
Why is the size reported down to deci- and centibytes?
The "cost" includes taxes? :-\
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I was waiting for you to make a Hellraiser reference right up to the end of your post.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
One of my favourite horror franchises. I once made a Pinhead headgear for a party once. I haven't seen five and above as they're hard to find.
// TODO: Insert something here
Top ten reasons why I'm lazy 1.
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
trønderen wrote:
except that the correct unit would be "419 K
Can't answer the other but that convention for storage has existed for a long time. The K for memory is 1024 and hard drives is 1000. I haven't checked (or even thought about it for a long time) but pretty sure it goes up the same way, so for example G, etc. Someone might even had tried to create a lawsuit about that long ago? As for the other probably would be easier to see where it shows up if someone with an IPhone tried it rather than a different Android. If it was the same then more likely something in Windows.
-
I was waiting for you to make a Hellraiser reference right up to the end of your post.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
If I pull a USB cable from my Android phone (Samusung Galaxy S7 edge, 2016 vintage) to my Win10 PC, I can access both the memory card and the internal phone memory as if they were local disks. Opening the Properties of a file on the phone, I can read that it is of "Size: 419 KB (429 399.00 bytes)". Well, that makes sense, except that the correct unit would be "419 Ki bytes - we are accustomed to software developers making unit mistakes, especially binary/decimal. But if the exact size had been reported as, say, 429 399.42 bytes, I would have stalled. Why is the size reported down to deci- and centibytes? Do all Android phones have the same reporting format, or is is specific to a Win10 driver, or driver specific to my model Samsung phone?
The display could be tied to international settings? How does it report a MB size file like TrackingData.log? Mac was the only platform that I knew that used 1,000 bytes to equal 1KB. This let their 1.44 3.5inch floppy disks appear even larger than the 1.2MB 5inch floppy that many DOS/Windows competitors used at the time. (circa 1986)
-
The display could be tied to international settings? How does it report a MB size file like TrackingData.log? Mac was the only platform that I knew that used 1,000 bytes to equal 1KB. This let their 1.44 3.5inch floppy disks appear even larger than the 1.2MB 5inch floppy that many DOS/Windows competitors used at the time. (circa 1986)
Yes, it is "international" in the sense that it honors my format preferences. I prefer grouping digits 3 by 3, I prefer a decimal comma rather a decimal point, and if I set the number of decimals to 3, an MB file size is reported like '15,9 MB (16 693 612,000 bytes)'. The issue here is neither the use of M rather than the correct Mi, the kind of digit grouping or kind of separator, but the use of a decimal point (/comma) and fractional part when presenting an integer number. When teaching programming, I always refer to count values, which programmers like to call 'int' or 'long', and measurement values, which programmers like to call 'float' or 'double'. That makes it much easier for the students to learn when to use int and when to use float. Those programming this Property sheet obviously has not grasped the idea of the number of bytes being a count of bytes in the file. They treat it as if it were a measurement on a continuous scale. For the Ki/k and Mi/M question (which is a different issue): All hard disks I ever have been in touch with, regardless of computer family, have had their total size specified in decimal units, like k, M, G and T. Networking people always specified line speeds in decimal units - in bits, not bytes. A 64 kbps line (56 kbps for those in North America) transfers 64000 (56000) bits per second. Floppies arrived before ISO had defined the Ki, Mi, Gi, Ti, ... prefixes, and things were kind of messy - that is why ISO/IEC decided to clean up the mess by defining the standard binary prefixes. There are lots of examples of mixed use of e.g. decimal number of binary units. (The ISO/IEC standard is well above 20 years old now; yet there are lots of people stubbornly resisting to relate to it, insisting that 'We have been using ambiguous units for years, we insist on continuing to do that and do not want to clean up the mess!' :-) For the 1.44 MB floppy disks: They did have higher capacity than the 1.2 MB floppies. Maybe it wasn't quite 1.2 times as much - I am not taking the effort to look up the historical details, but when the 3.5" floppies arrived, they did have a (real) higher capacity than the 5.25" ones. If you go far back in history: In the 1950-60s, machines addressed memory by the word, not by the byte. Memory sizes where given by the number of addressable units: words. Then IBM came with their 360 series, the first major computer series that were byte addressable, and they marketed their memory options by the
-
trønderen wrote:
except that the correct unit would be "419 K
Can't answer the other but that convention for storage has existed for a long time. The K for memory is 1024 and hard drives is 1000. I haven't checked (or even thought about it for a long time) but pretty sure it goes up the same way, so for example G, etc. Someone might even had tried to create a lawsuit about that long ago? As for the other probably would be easier to see where it shows up if someone with an IPhone tried it rather than a different Android. If it was the same then more likely something in Windows.
jschell wrote:
Can't answer the other but that convention for storage has existed for a long time.
For hard disks, size has always been given in decimal units - at least all the ones I have ever worked with. And: Networking people always count bits. When we 35 years ago got 64 kbps ISDN lines, some customers were complaining that they got only a fraction of the expected speed: Less than 8 KB, when they were promised 64! Well, the line transfers exactly (not less than) 8 kilooctets, as promised. There has been a mess with decimal and binary units for more than 50 years. About 25 year ago, ISO/IEC decided to come up with a solution to clean up the mess. 24 years ago, the standard passed through the formal procedures, and were accepted as an international standard. For 24 years, there has been no reason to carry on the old ambiguity. There is a well defined, internationally recognized standard to show whether you are talking about 1024 or 1000, 1 048 576 or 1 000 000. We all know that before 1999, there was no such standard, but that is long ago! You can't today argue with old millennium lack of standards! In the old days, some people tried to argue that 'k' is 1000, 'K' is 1024 - completely disregarding that by international standards, 'K' is degrees Kelvin. Those complaining that they got less than 8 kiloBYTES through a 64 kbps line argued that 'B' indicates 'bytes', 'b' indiates 'bits'. One problem is that they could never dig up a promise of 64 KB; only of 64 kbps. Another is that there is no recognized standard defining 'B' to mean 'byte'; if anything (such as by ISO standards), 'B' means 'Bel', a sound level unit (better known as 1/10 Bel, deciBel or dB). If you want to explicitly indicate 8-bit bytes, use the 'o' unit: A 64 kbps line transfers 8 ko per second. In the old days, a 'byte' could (at least)be from 5 to 9 bit: The space required to store a single character. I guess that there are still machines around providing 6 or 9 bit bytes. In some newer conventions/standards (not at the level of defining general OSI prefixes/units, but e.g. in some programming language standards) 'byte' has been defined as 8 bits. These are application area specific standards - if you want to be very specific about 8 bit units, then use the well defined, standardized unit 'octet'. Arguing against a standard defined in the previous millennium: 'But earlier in the previous millennium, everyone accepted that we mixed decimal and binary f
-
Yes, it is "international" in the sense that it honors my format preferences. I prefer grouping digits 3 by 3, I prefer a decimal comma rather a decimal point, and if I set the number of decimals to 3, an MB file size is reported like '15,9 MB (16 693 612,000 bytes)'. The issue here is neither the use of M rather than the correct Mi, the kind of digit grouping or kind of separator, but the use of a decimal point (/comma) and fractional part when presenting an integer number. When teaching programming, I always refer to count values, which programmers like to call 'int' or 'long', and measurement values, which programmers like to call 'float' or 'double'. That makes it much easier for the students to learn when to use int and when to use float. Those programming this Property sheet obviously has not grasped the idea of the number of bytes being a count of bytes in the file. They treat it as if it were a measurement on a continuous scale. For the Ki/k and Mi/M question (which is a different issue): All hard disks I ever have been in touch with, regardless of computer family, have had their total size specified in decimal units, like k, M, G and T. Networking people always specified line speeds in decimal units - in bits, not bytes. A 64 kbps line (56 kbps for those in North America) transfers 64000 (56000) bits per second. Floppies arrived before ISO had defined the Ki, Mi, Gi, Ti, ... prefixes, and things were kind of messy - that is why ISO/IEC decided to clean up the mess by defining the standard binary prefixes. There are lots of examples of mixed use of e.g. decimal number of binary units. (The ISO/IEC standard is well above 20 years old now; yet there are lots of people stubbornly resisting to relate to it, insisting that 'We have been using ambiguous units for years, we insist on continuing to do that and do not want to clean up the mess!' :-) For the 1.44 MB floppy disks: They did have higher capacity than the 1.2 MB floppies. Maybe it wasn't quite 1.2 times as much - I am not taking the effort to look up the historical details, but when the 3.5" floppies arrived, they did have a (real) higher capacity than the 5.25" ones. If you go far back in history: In the 1950-60s, machines addressed memory by the word, not by the byte. Memory sizes where given by the number of addressable units: words. Then IBM came with their 360 series, the first major computer series that were byte addressable, and they marketed their memory options by the
Thanks for the followup. I have been in my current post longer than the standard! “kibibytes” sounds like a good name for a dogfood! (kibble) I guess comp sci graduates after 1999 will know this. I am curious now to see if advertisements for memory modules will use the correct prefixes.
-
jschell wrote:
Can't answer the other but that convention for storage has existed for a long time.
For hard disks, size has always been given in decimal units - at least all the ones I have ever worked with. And: Networking people always count bits. When we 35 years ago got 64 kbps ISDN lines, some customers were complaining that they got only a fraction of the expected speed: Less than 8 KB, when they were promised 64! Well, the line transfers exactly (not less than) 8 kilooctets, as promised. There has been a mess with decimal and binary units for more than 50 years. About 25 year ago, ISO/IEC decided to come up with a solution to clean up the mess. 24 years ago, the standard passed through the formal procedures, and were accepted as an international standard. For 24 years, there has been no reason to carry on the old ambiguity. There is a well defined, internationally recognized standard to show whether you are talking about 1024 or 1000, 1 048 576 or 1 000 000. We all know that before 1999, there was no such standard, but that is long ago! You can't today argue with old millennium lack of standards! In the old days, some people tried to argue that 'k' is 1000, 'K' is 1024 - completely disregarding that by international standards, 'K' is degrees Kelvin. Those complaining that they got less than 8 kiloBYTES through a 64 kbps line argued that 'B' indicates 'bytes', 'b' indiates 'bits'. One problem is that they could never dig up a promise of 64 KB; only of 64 kbps. Another is that there is no recognized standard defining 'B' to mean 'byte'; if anything (such as by ISO standards), 'B' means 'Bel', a sound level unit (better known as 1/10 Bel, deciBel or dB). If you want to explicitly indicate 8-bit bytes, use the 'o' unit: A 64 kbps line transfers 8 ko per second. In the old days, a 'byte' could (at least)be from 5 to 9 bit: The space required to store a single character. I guess that there are still machines around providing 6 or 9 bit bytes. In some newer conventions/standards (not at the level of defining general OSI prefixes/units, but e.g. in some programming language standards) 'byte' has been defined as 8 bits. These are application area specific standards - if you want to be very specific about 8 bit units, then use the well defined, standardized unit 'octet'. Arguing against a standard defined in the previous millennium: 'But earlier in the previous millennium, everyone accepted that we mixed decimal and binary f