Octal vs. Hexadecimal

• Date: Fri, 26 Jan 1996 12:53:04 PST
• From:
  Richard Connamacher <phantom@simon.sfsu.edu>
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=us-ascii

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

• Re: Octal vs. Hexadecimal
• From: "Robert J. Brown" <rj@eli.wariat.org>

• Prev: Re: notify() w/o newline
• Next: Re: Octal vs. Hexadecimal
• Index: MOO-cows
• Thread: MOO-cows