|
in reply to Re: Bit order in bytes
in thread Bit order in bytes
If you are using or have access to a big-endian machine, you'd see different results above
Actually, it's the same results - these templates apparently know whether they're on a big-endian or little-endian machine, and adjust themselves accordingly to standardise the output.
Not what I was expecting ... I have, however, just tested this.
Cheers,
Rob |
Re^3: Bit order in bytes
by BrowserUk (Patriarch) on Dec 10, 2013 at 12:32 UTC
|
print unpack 'b*', "\x12\x34";;
0100 1000 0010 1100
2 1 4 3
print unpack 'B*', "\x12\x34";;
0001 0010 0011 0100
1 2 3 4
print unpack 'b*', pack 'v', 0x1234;;
0010 1100 0100 1000
4 3 2 1
print unpack 'b*', pack 'n', 0x1234;;
0100 1000 0010 1100
2 1 4 3
I can't make sense of that at all.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
Your pack 'v' and pack 'n' arrange the bytes in reverse order - and unpack 'b*' just unpacks them both from the same end ... hence the bytes come out in the reverse order - but each byte is read in ascending bit order, in accordance with the 'b' template spec.
Where you're unpacking the \x12\x34, that's also correct. Both 'b*' and 'B*' read the bytes in the same order, but read those bytes from opposing ends.
I don't think there's any nybble-swapping. You've just got one byte that's read either as 01001000 or (reversed) 00010010 (depending upon the template) - and another byte that's being read as either 00101100 or (reversed) 00110100 (depending upon the template).
... I think ...
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
I did say "apparent nybble swapping" :)
Its one of those things that has caused me to look twice on many occasions, but never caused me enough concern nor affected anything I was doing, to require investigation.
Now looking at it, it becomes clear that it just comes down to the fact that when we right "\x12",
we write the high nybble 0x1 before the low nybble 0x2.
Thus, when it is displayed with 'b', lsb -> msb, the digits appear to swap places.
Another red-herring laid bare :)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
print unpack 'b*', "\x12\x34";;
01001000 00101100
18 52
print unpack 'B*', "\x12\x34";;
00010010 00110100
18 52
| [reply]
[d/l] |
|
|
Nybbles == 4-bits, so looking at the byte values in decimal doesn't show it.
Look at the patterns of the nybbles (in hex):
## 'b' lists bits lsb->msb
print unpack 'b*', "\x12\x34";;
1248 1248 1248 1248
0100 1000 0010 1100
2 1 4 3
## 'B' lists bits msb <- lsb
print unpack 'B*', "\x12\x34";;
8421 8421 8421 8421
0001 0010 0011 0100
1 2 3 4
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
Re^3: Bit order in bytes
by Anonymous Monk on Dec 11, 2013 at 00:36 UTC
|
It's when you're working with floating point that you'd have to deal with the headache you're anticipating.
Int formats are considerably more agreeable to deal with across different endian machines. | [reply] |
|
|
