# Octal vs. Hexadecimal

Richard Connamacher (phantom@simon.sfsu.edu)
Fri, 26 Jan 1996 12:53:04 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    This has been said before, but I'm going to resay it:

    Please, Pavel, make binary strings use hex, not octal.

    My reasons are simple:

    1) lambdaMOO uses eight bit bytes.  Hex is perfect for that.
    2) It's a standard.  Maybe this is my limited experience speaking,
    but everything i've ever seen that dealt with binary data
    represented it with hex, not octal.  That is, until now.  The
    maximum value of one byte is 256, or FF.  I have no idea what it is
    in octal.
    3) It's smaller.  Represented as a binary string using octal, a gif
    or a bunch of Java opcode would be 1/4 larger than the same gif or
    java opcode represented in hex.  That's including the '~' before
    each byte, and assuming that it contains no printable characters.
    See 1)

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

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

    Just my $0.02,

    Phantom