Hello,
I have a half dozen or so bytes I've read in from a file sitting in a
list. Something like: (255 0 240 31 ....)
But, this data is supposed to be a five bit field followed by some
eleven bit fields. Or sometimes a five bit field followed by a bunch
of seven bit fields, etc. and then some zeros as the very end to make
it fit back to 8 bit byte boundaries.
For example:
11100|1100101|1100010|00000 -- the raw data
5 7 7 zeros - the divisions
28 101 98 - the values of the 5 and 7 bit
numbers
But, right now, when I read these 24 bits in from my file this the
list I get: (230 92 64)
How do I get, from the file or from the list, the 5 bit value and the
7 bit values?
I've figured out the numeric byte specifier, and using (ldb (byte 5 3)
(first byteList)) I can correctly pull out 28. But the next 7 bits
(or sometimes 11, sometimes 4, etc.) may cross the normal 8 bit byte
boundary.
It seems like a bit array might be my ticket, since I might be able to
derive displaced arrays from it, but I can't figure out how to get my
data into a bit array.
Is there a way to read five bits from the file, then eleven?
Thanks,
Chris Perkins
Media Lab, Inc.
I figured it out.
Combine the numbers in the list together (using logior and lsh) to get
one big number with all the bits in it, then use ldb with different
byte specifiers to pull out the pieces.
I kept looking at the problem with old ideas of bytes, longs, etc.
and forgot that Lisp has arbitrarily big numbers.
Thanks,
Chris
In article <····························@posting.google.com>,
Chris Perkins <········@medialab.com> wrote:
>Hello,
>
>I have a half dozen or so bytes I've read in from a file sitting in a
>list. Something like: (255 0 240 31 ....)
>
>But, this data is supposed to be a five bit field followed by some
>eleven bit fields. Or sometimes a five bit field followed by a bunch
>of seven bit fields, etc. and then some zeros as the very end to make
>it fit back to 8 bit byte boundaries.
>
>For example:
>11100|1100101|1100010|00000 -- the raw data
>5 7 7 zeros - the divisions
>28 101 98 - the values of the 5 and 7 bit
>numbers
>
>But, right now, when I read these 24 bits in from my file this the
>list I get: (230 92 64)
>
>
>How do I get, from the file or from the list, the 5 bit value and the
>7 bit values?
>
>I've figured out the numeric byte specifier, and using (ldb (byte 5 3)
>(first byteList)) I can correctly pull out 28. But the next 7 bits
>(or sometimes 11, sometimes 4, etc.) may cross the normal 8 bit byte
>boundary.
>
>It seems like a bit array might be my ticket, since I might be able to
>derive displaced arrays from it, but I can't figure out how to get my
>data into a bit array.
I think the simplest way would be to combine all the 8-bit bytes into a
single number and then use LDB to extract the bytes in the sizes you want.
(let ((combined (dpb (first bytelist) (byte 8 16)
(dpb (second bytelist) (byte 8 8)
(third bytelist)))))
(values (ldb (byte 5 19) combined)
(ldb (byte 7 12) combined)
(ldb (byte 7 5) combined)))
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> Is there a way to read five bits from the file, then eleven?
>
>
> Thanks,
>
> Chris Perkins
> Media Lab, Inc.
The solution of putting them all in a bignum will suffice, especially
given that you say there are only a few bytes that you are concerned
with at a time.
A somewhat more elaborate solution that I've used to decode Huffman
codings is to create a "bitstream" interface which will use an
integer/bignum as a buffer. The bitstream will accept requests for any
number of bits, and a sufficient number of additional bytes are read
from the underlying file into the buffer to provide the requested
bits.
For best performance, there is probably a better way to read the file
in than byte-by-byte.
A possible advantage of my more conservative buffer over the single
bignum approach might occur if the problem scales to be a very long
series of short chunks: it is conceivably more efficient to execute
the bit operations on a fixnum size buffer than on a single very large
bignum. But perhaps not.