I agree it is important, may be a precision on the more general idea is helpful: "Communication of numbers between ordinary people generally happens in base 10." It turns out that the diversity of the notion of numerosity among *homo sapiens* is way far richer than the base-10. See https://wals.info/chapter/131
Indeed, humans have developed base-8 counting systems. Avelino, Heriberto (2006). "The typology of Pame number systems and the limits of Mesoamerica as a linguistic area" <http://linguistics.berkeley.edu/~avelino/Avelino_2006.pdf> (PDF). *Linguistic Typology*. *10* (1): 41–60. doi <https://en.wikipedia.org/wiki/Doi_(identifier)>:10.1515/LINGTY.2006.002 <https://doi.org/10.1515%2FLINGTY.2006.002> On Thu, Jan 9, 2025 at 2:47 PM Nicolas George <geo...@nsup.org> wrote: > Michael Stone (12025-01-08): > > For example...let's take the 18000000000000B drive discussed earlier. > That's > > 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. > And > > it's 18000000MB or 17166137MiB. So if you have a display in MB and you > want > > to know the value in TB you move the decimal 6 places. But if you move > the > > decimal 6 places to get from MiB to TiB you get...the wrong answer. Does > > this actually happen? Yes. All the freaking time. (A classic mashup is > 1024k > > blocks expressed with power of 10 M and G.) Now this next part is > important: > > no normal human working with files and disk space and trying to > communicate > > with other normal humans calculates the values in base 8 or base 16. > > Communication of numbers between ordinary people generally happens in > base > > 10. SI prefixes are base 10. And when you munge up some stupid base 2 > units > > with what people want and expect to be base 10, mistakes and confusion > > happen. And the benefit of all that confusion and increased cognative > load > > is: absolutely nothing. > > The thing is, for people who _expect_ rather than _know_ about this, 10% > accuracy is plenty enough. Especially since, as has been pointed, a lot > of factors will conspire to reduce the space available in practice. > > For the people who need exact figures, on the other hand, binary units > are much more convenient, not just to measure the size of memory > modules: alignment requirements, maximum sizes of files and devices, > size of stripes, they are all based on powers of two. > > > Stefan Monnier (12025-01-09): > > A related problem is when writing code which displays such sizes in > > a human readable way, for example a "speedometer" displaying the number > > of bytes per second with a limited amount of space. A common choice is > > to use 3 chars for the number plus a unit, i.e. things like "254 kB/s" > > or "1.5 MB/s". Now, if you use the "1024" multiplier, you get a funny > > quirk when the current speed is, say 1003 kB/s, because "1003 kB/s" uses > > one char too many, yet we haven't reached "1.0 MB/s" either. > > Well, “1.5” is too few significant digits in the first place. > > So, you start: > > 100 M > 999 M > 1000 M > 1024 M > 1.59 G > 9.99 G > 10.0 G > 99.9 G > 100 G > 999 G > 1000 G > > The switch to the next prefix does not have to be as soon as the > mantissa is greater than one. Notice that the heights of mountains are > in meters, not in kilometers, even for the Himalaya. It is better to go > to 9999 M and only then switch to 9.77 G: more significant digits, not > less readable. > > (Also, the people who designed the symbols for the prefixes really > dropped the ball with k instead of K, but that predates memory units by > a long time.) > > -- > Nicolas George > >
