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
>
>

Reply via email to