Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bitpack has unexpected behavior #371

Open
hatf0 opened this issue Nov 15, 2021 · 0 comments
Open

bitpack has unexpected behavior #371

hatf0 opened this issue Nov 15, 2021 · 0 comments

Comments

@hatf0
Copy link
Member

hatf0 commented Nov 15, 2021

While trying to implement #369, I was trying to use bitpack in a behavior that would be equivalent to this:

ubyte[] data = cast(ubyte[])['A', 'B', 'C'];
auto grouped = data.bytegroup!(3, uint).map!bswap;
foreach(group; grouped) {
   auto a = (group >> 26) & 0x3f;
   auto b = (group >> 20) & 0x3f;
   auto c = (group >> 14) & 0x3f;
   auto d = (group >> 8) & 0x3f;
   writefln("%.6b %.6b %.6b %.6b", a, b, c, d);
}

This extracts the top 4 6-bit values from a 32-bit value, which is what I expect bitpack to do. But, the equivalent Mir Algorithm code does not result in the same behavior:

ubyte[] data = cast(ubyte[])['A', 'B', 'C'];
auto grouped = data.bytegroup!(3, uint).map!bswap;
foreach(group; grouped.bitpack!6.retro) {
   writefln("%.6b", group);
}

It appears that, instead of reading from the top-most bit for a 32-bit value (which is what I would normally expect), bitpack!6 seems to start at the LSB, and reads values from the bottom-up, resulting in these bytes being read:

value = 01000001010000100100001100000000
000001
010000
100100
001100
000000

instead of

value = 01000001010000100100001100000000
010000
010100
001001
000011
000000

Is there any way to toggle this behavior on / off?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant