Re: Octal vs. Hexadecimal

• Date: Fri, 26 Jan 1996 19:04:58 PST
• From:
  "Robert J. Brown" <rj@eli.wariat.org>
• cc: moo-cows.PARC@xerox.com
• In-Reply-to: "<31093F30.3F21@simon.sfsu.edu> (message from Richard Connamacher on Fri, 26 Jan 1996 12:53:04 PST)"

>>>>> "Richard" == Richard Connamacher <phantom@simon.sfsu.edu> writes:

    Richard> This has been said before, but I'm going to resay it:
    Richard> Please, Pavel, make binary strings use hex, not octal.

    Richard> My reasons are simple:

    Richard> 1) lambdaMOO uses eight bit bytes.  Hex is perfect for
    Richard> that.  2) It's a standard.  Maybe this is my limited
    Richard> experience speaking, but everything i've ever seen that
    Richard> dealt with binary data represented it with hex, not
    Richard> octal.  That is, until now.  The maximum value of one
    Richard> byte is 256, or FF.  I have no idea what it is in octal.

Its \377 -- each octal digit is 3 bits:

hex --------->        f     f
regrouping -->     1111  1111
regrouping -->     11 111 111
octal ------->      3   7   7

The advantage of octal is that intellectually challenged individuals
do not have to learn additional rows and collums in the addition
tables;  in fact, they can forget 2 rows and 2 collums from decimal
and it *STILL* works.  The disadvantage (and this actually happened to
me in the early 1970s) is that octal hackers may tend to forget what
they are doing when balancing their checkbooks and carry on 8 instead
of 10.  Whew!  Sure can make a mess!  Hex tends to remind you because
the numbers start to look funny with the letters mixed in :-)

    Richard> 3) It's smaller.  Represented as a binary string using
    Richard> octal, a gif or a bunch of Java opcode would be 1/4
    Richard> larger than the same gif or java opcode represented in
    Richard> hex.  That's including the '~' before each byte, and
    Richard> assuming that it contains no printable characters.  See
    Richard> 1)

    Richard> Hey, if you don't like hex, then why not use decimal?
    Richard> It's better suited to the task than octal.  And atleast
    Richard> then it'd be ready for toint().

    Richard> By the way, I personally think that a cleaner approach
    Richard> would be to make a new data type, BIN, which is
    Richard> specifically for binary data.  It would take some hefty
    Richard> rewriting of the server, so maybe it's beyond Pavel's
    Richard> wish list for before he finishes up his rein as LambdaMOO
    Richard> God.  But think about it: it would be much smaller, only
    Richard> 1/4 the size of the octal binary string and 1/3 the size
    Richard> of the hex binary string; it'd be right in the typeof()
    Richard> that it's binary, etc, etc.  Then, toliteral() could
    Richard> convert it to a hex string, and tobinary() could convert
    Richard> it back.  The dump file would save it as a hex string,
    Richard> and convert it back into binary when it loads.  This, in
    Richard> my opinion, would be the cleanest way to impliment binary
    Richard> data in MOO.

    Richard> Just my $0.02,

    Richard> Phantom

• Octal vs. Hexadecimal
• From: Richard Connamacher <phantom@simon.sfsu.edu>

• Prev: Octal vs. Hexadecimal
• Next: Re: Octal vs. Hexidecimal
• Index: MOO-cows
• Thread: MOO-cows