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

I think I have understood this correctly but please put me right if I am barking up the wrong tree

$_[0] & 0xff # A bitmask to gets the last (8 bit) byte from the intege
+r.  
             # It has exactly the same result as $_[0] % 256

>> 5         # bitshift the result of the above so all but
             # the 3 MSB drop off the end.

[download]
the return automagically maps this to the decimal for the three remaining bits. Was use integer necessary for this or does it improve efficiency ?

Here is a one liner to dump what is going on

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

[download]
and some of the output for the interesting regions 
0       00000000000000000000000000000000        0
1       00000000000000000000000000000001        0
2       00000000000000000000000000000010        0
.
.
30      00000000000000000000000000011110        0
31      00000000000000000000000000011111        0
32      00000000000000000000000000100000        1
33      00000000000000000000000000100001        1
.
.
222     00000000000000000000000011011110        6
223     00000000000000000000000011011111        6
224     00000000000000000000000011100000        7
225     00000000000000000000000011100001        7
.
.
255     00000000000000000000000011111111        7
256     00000000000000000000000100000000        0

[download]

Cheers,
R.

Pereant, qui ante nos nostra dixerunt!

Replies are listed 'Best First'.
Re^3: calculating the 3 MSBs from an integer
by borisz (Canon) on Feb 17, 2005 at 14:13 UTC
    You are right on everything. use integer is not needed, I do it always since shifts are done sign wo integer and unsigned with use integer. In this case it does not matter.
    Boris
[reply]
Re^3: calculating the 3 MSBs from an integer
by insaniac (Friar) on Feb 17, 2005 at 14:40 UTC
    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

[reply]
[d/l]
[select]

      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]

In Section Seekers of Perl Wisdom