Re^2: Run length encode a bit vector

-- I think you have probably mis-counted the number of zeros in the second term because there is actually a run of eight zeros there.

Yes. I miscounted.

-- As well as that, you seem to be parsing your data with the low-order bit first in each byte even though you have packed in network order.

Actually irrelevant as it is just sample data. The actual vector to be compressed is built with vec(), so 'b' is the right template.

Comment on Re^2: Run length encode a bit vector

Replies are listed 'Best First'.
Re^3: Run length encode a bit vector by AnomalousMonk (Archbishop) on Jan 05, 2012 at 13:53 UTC
Actually irrelevant as it is just sample data. Can you please provide an example of relevant data and the relevant output you expect from that data? The actual vector to be compressed is built with vec()... Can you say why vec must be used? pack/unpack seem better suited.	[reply]
Re^4: Run length encode a bit vector by Anonymous Monk on Jan 05, 2012 at 14:28 UTC
-- Can you please provide an example of relevant data and the relevant output you expect from that data? You want me to post a 31,156,327 byte bit-vector that represents just under a quarter of a billion boolean states? The vector is just a string of bits. Packing a integer to provide a sample was convenient. The ordering of the bits was irrelevant. The important factor was showing how the rle was to be encoded. -- Can you say why vec must be used? Pack (or any other means) is fine for the rle, but the original vector is built with vec() so the appropriate pack template for accessing the bits in the same order as they were constructed is 'b'. The downside of using unpack 'b' during the rle, is it expands the 31MB vector to a 250 MB string. On the other hand, vec() can process the 31MB without expanding it at all.	[reply]