• michaelmrose@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    3 months ago

    There is no reason whatsoever to use base 16 for computer storage it is both unconnected to technology and common usage it is worse than either base 2 or 10

    • megane-kun@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      I guess? I just pulled that example out of my ass earlier, thinking well, hexadecimal is used heavily in computing, so maybe something with powers of 16 would do just fine.

      At any rate, my point is that using a prefix system that is different and easily distinguishable from the metric SI prefixes would have been way better.

      • michaelmrose@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        They could have easily used base 2 which is actually connected to how the hardware works and just called it something else

        • megane-kun@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 months ago

          I realized why I didn’t think of base 2 in my previous reply. For one, hexadecimal (base 16) often used in really low-level programming, as a shorthand for working in base 2 because base 2 is unwieldy. Octal (base 8) was also used, but not so much nowadays. Furthermore, even when working in base 2, they’re often grouped into four bits: a nibble. A nibble corresponds to one hexadecimal digit.

          Now, I suppose that we’re just going to use powers of two, not base-2, so maybe it’d help if we do a comparison. Below is a table that compares some powers of two, the binary prefixes, and the system I described earlier:

          Decimal value Value with corresponding binary prefix Hexadecimal Value Value with prefixes based on powers of 16
          20 1 1 1 1
          24 16 16 10 16
          28 256 256 100 256
          210 1 024 1 Ki 400 1 024
          212 4 096 4 Ki 1000 4 096
          216 65 536 64 Ki 1 0000 1 myri
          220 1 048 576 1 Mi 10 0000 16 myri
          224 16 777 216 16 Mi 100 0000 256 myri
          228 268 435 456 256 Mi 1000 0000 4 096 myri
          230 1 073 741 824 1 Gi 4000 0000 16 384 myri
          232 4 294 967 296 4 Gi 1 0000 0000 1 dyri
          236 68 719 476 736 32 Gi 10 0000 0000 16 dyri
          240 1 099 511 627 776 1 Ti 100 0000 0000 256 dyri
          244 17 592 186 044 416 16 Ti 1000 0000 0000 4 096 dyri
          248 281 474 976 710 656 256 Ti 1 0000 0000 0000 1 tryri
          250 1 125 899 906 842 624 1 Pi 4 0000 0000 0000 4 tryri
          252 4 503 599 627 370 496 4 Pi 10 0000 0000 0000 16 tryri
          256 72 057 594 037 927 936 64 Pi 100 0000 0000 0000 256 tryri
          260 1 152 921 504 606 846 976 1 Ei 1000 0000 0000 0000 4 096 tryri
          264 18 446 744 073 709 551 616 16 Ei 1 0000 0000 0000 0000 1 tesri

          Each row of the table (except for the rows for 210 and 250) would be requiring a new prefix if we’re to be working with powers of 2 (four apart, and more if it’d be three apart instead). Meanwhile, using powers of 16 would require less prefixes, but would require larger numerals before changing over to the next prefix (a maximum of 164 - 1 = 216 - 1 = 65 535)

          One thing that works to your argument’s favor is the fact that 1024 = 210. But I think that’s what caused this entire MiB vs. MB confusion in the first place.

          However, having said all that, I would have been happy with just using an entirely different set of prefixes, and kept the values based on 210.