in reply to Re^2: calculating the 3 MSBs from an integer
in thread calculating the 3 MSBs from an integer

thanks for the explanation, but my output is like this: 
0       00000000000000000000000000000000        0
1       00000001000000000000000000000000        0
2       00000010000000000000000000000000        0
3       00000011000000000000000000000000        0
..

[download]

the binary forms are "a bit" akward, no? I just copy pasted your command line..

and why is the piece: $_ & 0xFF needed? without it, the code seems to work as well... or am i missing something mayor overhere?

anyhow.. now i know i shouldn't have skipped the chapters about bitwise operators :-D

--
to ask a question is a moment of shame
to remain ignorant is a lifelong shame

Replies are listed 'Best First'.
Re^4: calculating the 3 MSBs from an integer
by Random_Walk (Prior) on Feb 17, 2005 at 15:27 UTC

    I am running on AIX and I guess you may be on Windows ? I think your byte order must be the other way round than mine. When you get up to 253..256 does the last value go 7,7,7,0

    apart from the binary bytes being reversed the rest works as expected for me on 'doze (NT4)

    253     11111101000000000000000000000000        7
254     11111110000000000000000000000000        7
255     11111111000000000000000000000000        7
256     00000000000000010000000000000000        0

    [download]

    If you replace the I* in the pack with N (force byte order we want and the * was never really required) I think you may see something nicer. This version works on box *nix and *dose for me

    perl -le'print join "\t", $_, (unpack "B*", pack "N", $_), ($_ & 0xFF)
+ >>5 for (0..256)'

    [download]

    Cheers,
    R.

    Pereant, qui ante nos nostra dixerunt!
[reply]
[d/l]
[select]
      that was it! And I'm using Linux btw, it's been ages since I used MS ;-)
      but i still don't understand why the & 0xFF is required... without it, it seems to work as well
      --
      to ask a question is a moment of shame
      to remain ignorant is a lifelong shame
[reply]
[d/l]

        Hi Again,

        Sorry for implying allegiance to Redmond ;). Back home now and just given it a taz on x86/Linux and I get the same reversed byte order. I guess it is the Intel architecture not the OS. Sadly my Alpha/Linux is in another country and offline so no testing possible there. I will try it on a SPARC at work tomorrow just for fun.

        The & 0xff is a bit mask that will only drop through bits from the first (8 bit) byte. If I take it off when I get to 256 my total goes up to 8 (Intel/Linux). As long as your input is only 1 byte then it will not be a problem. 

        perl -le'print join "\t", $_, (unpack "B*", pack "N", $_), $_ >>5 for 
+(0..256)'
<snip>
254     00000000000000000000000011111110        7
255     00000000000000000000000011111111        7
256     00000000000000000000000100000000        8

        [download]

        Cheers,
        R.

        Pereant, qui ante nos nostra dixerunt!
[reply]
[d/l]

In Section Seekers of Perl Wisdom