To explain why MB vs MiB (MegaByte vs.
-
To explain why MB vs MiB (MegaByte vs. MebiByte) enrages programmers so much, imagine that someone came along and told you that the size of an inch was being changed to make it fit metres better -- instead of 3ft3in = 1m, the inch has been shortened to make 3ft = 1m. Except, instead of naming this new inch different they have decided that this new inch is called the inch and the old inch has retroactively been named "iinch" despite the historical weight applied to the original term.
At a very literal and physical level, computers do not work in 1'000s, they use 1'024. This is unavoidable, it's the nature of their binary universe, it's a fixed constant like the speed of light. Using 1KB = 1'000B does nothing in terms of accuracy or clarity; binary counting has nothing to do with SI units anyway!
I reject Kibi/Mebibytes; 1KB = 1024 bytes and I will never explain it, teach it or use it in any other way.
-
-
@Kroc And then there's mebibits.
-
@vwbusguy Is that when compression people talk about storing things in 0.3 bits and the like?
-
@Kroc I've often heard networking people say the distinction is helpful for them. Having it applied to block storage capacity was some definitive fleecing.
-
I'll give two answers. First, what I *think* is happening is if you have some data with say 100 concurrent zeros, you could theoretically store "100" in 7 bits and the value "0" in one bit and given a program that understands where to break, you could de-compress 100 zeros given those 8 bits, losslessly, at a compression rate of "0.08 bits".
Here's a better and more practical example from someone that knows more of what they're talking about with compression: https://iopscience.iop.org/article/10.1088/1538-3873/acf6e0/pdf
-
@vwbusguy I feel that counting the number of bits vs the number those bits can hold is an important distinction lost on the SI people
-
@Kroc Yeah, in this example, I mixed ASCII and binary, but as I understand it, this is more or less how original compression methods worked. The compressed data would look something like 16-0,8-1,4-0, etc.
-
@Kroc Compression of A/V stuff generally does something like this but might group things that are close, so, 256-reddish pixels, 318-bluish pixels, etc., which would be "lossy", as you're losing some specificity in the data, but saving file space.