Byte order (or you are both wrong)
Richard Harter
g-rh at cca.UUCP
Thu Apr 24 15:34:15 AEST 1986
>In article <17162 at rochester.ARPA> crowl at rochester.UUCP (Lawrence Crowl) writes:
>
>CHALLENGE: Come up with a scheme for representing numbers, and a sorting
>scheme in which numbers sort naturally. Your scheme must deal with variable
>length character strings and variable size numbers. That is, you cannot
>requires strings to be padded with nulls, or numbers to be padded with zeros.
Presented without endorsement:
Addressing nomenclature -- big endian (i.e. msb is bit 0, etc.)
Item is divided into five parts:
Part I - sign bit (0 is negative, 1 is postive)
Part II - Size of field size in unary, i.e. string of 1's terminated by 0
Part III - Field size, in binary (Field size is size of field to left of
implicit decimal point.
Part IV - Portion of string to left of implied decimal point, encoded in
bytes.
Part V - Portion of string to right of implied decimal point, encoded in
ternary, using two bits per ternary digit, as follows:
00 Sentinel, terminating right field
01 ternary 0
02 ternary 1
03 ternary 2
All numbers are represented as ascii characters.
The point of the ternary representation (or something equivalent) is
that it provides for a sentinel for variable length strings that sorts
lexicographically.
If an integer is to be considered as a number and compared in that fashion
it goes in the left field -- if it is to be considered as a character string
it goes in the right field.
I believe that this representation meets the challenge.
I sincerely hope that I never have to work with it.
Richard Harter, SMDS Inc.
More information about the Comp.lang.c
mailing list