This week's giveaway is in the Android forum. We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line! See this thread for details.

How would i check (Bitwise) to see if a passed parameter lies within a given range say:

between 0-255 OR 0-100 ?

is there any way i could create a bit mask based on the boundary values (0 and 255) and somehow mask it over this parameter to give me back a boolean value based on which i can flag the passed parameter?

Well, 255 in binary is 11111111. So if a value has any bits to the left of this, then it's outside the range of 0-255. (Note that negative values start with a 1 on the left.)

100 is a little trickier, because its binary representation is 1100100. Following from above, we can rule out anything with bits to the left of this, but the trick is in also ruling out values between 101 and 255. Any ideas...?

I can give more hints, but I think it would be good for you to think through this. If you get stuck, post what you've tried, and we'll get you back on track. [ February 05, 2007: Message edited by: marc weber ]

"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org

Wolfgang Obi
Ranch Hand

Joined: Dec 05, 2005
Posts: 134

posted

0

Originally posted by marc weber: Well, 255 in binary is 11111111. So if a value has any bits to the left of this, then it's outside the range of 0-255. (Note that negative values start with a 1 on the left.)

100 is a little trickier, because its binary representation is 1100100. Following from above, we can rule out anything with bits to the left of this, but the trick is in also ruling out values between 101 and 255. Any ideas...?

that would be avoiding replacing any of the 0's right of the leading one in the decimal representation of 100 (while also minding the boundary of 255 decimal ) ?

and how would i formulate this as java code? with the use of '<<' or '>>' operators maybe?

Originally posted by Wolfgang Obi: ...that would be avoiding replacing any of the 0's right of the leading one in the decimal representation of 100 (while also minding the boundary of 255 decimal ) ? ...

Close, but it's a "bit" more complicated. You could replace these zeros if the 1's were in different places. For example, if you didn't have a 1 in the third position from the right, then you could replace either (or both) of the zeros following that...

Here's one possible approach to thinking through this...

Assuming you're working wiht a 32-bit int, first make sure that the first 25 bits are all zeros. This means that the value is between 0-255, and you now have only seven bits left to consider. Now look at the first of these 7 bits. If this is zero, then you're okay, because regardless of what follows, the value is within 0-63. But if this bit is one, then the remaining six bits can't represent more than 36. So in this case, look the next bit. If this is zero, then you're okay...

Wolfgang Obi
Ranch Hand

Joined: Dec 05, 2005
Posts: 134

posted

0

Originally posted by marc weber:

Close, but it's a "bit" more complicated. You could replace these zeros if the 1's were in different places. For example, if you didn't have a 1 in the third position from the right, then you could replace either (or both) of the zeros following that...

1100010 ==> 98

oh, but i was thinking along the lines of range(101,255).... in which case the 1 in the 3rd position from right would ALWAYS be placed,..no?

meaning that:

we could use the compliment of 100 (which would be 27 Decimal -- or 0011011 binary) to XOR or AND for example (depending on what we're trying to do)....to mask this range away.....

could you maybe give me a little nudge in the dirction of java code / pseudo code ?...'cause i seem to have reached a dead end here....

Originally posted by Wolfgang Obi: ...oh, but i was thinking along the lines of range(101,255).... in which case the 1 in the 3rd position from right would ALWAYS be placed,..no? ...

1101000 ==> 104

Wolfgang Obi
Ranch Hand

Joined: Dec 05, 2005
Posts: 134

posted

0

Originally posted by marc weber: Here's one possible approach to thinking through this...

Assuming you're working wiht a 32-bit int, first make sure that the first 25 bits are all zeros. This means that the value is between 0-255, and you now have only seven bits left to consider. Now look at the first of these 7 bits. If this is zero, then you're okay, because regardless of what follows, the value is within 0-63. But if this bit is one, then the remaining six bits can't represent more than 36. So in this case, look the next bit. If this is zero, then you're okay...

did you mean 63 here?

and isnt 7 Bits set to 1 ---> 128 Decimal? I thought we were considering the last 8 bits set to 1 ---> 255 as highest value ?

im kinda confused Marc.

[ February 05, 2007: Message edited by: Wolfgang Obi ] [ February 05, 2007: Message edited by: Wolfgang Obi ]

The 7th bit from the right represents a decimal value of 64. So if this bit is 1, then if the total value is going to be within 0-100, that means that the six bits to the right can't total more than 36 (because 64 + 36 = 100).

Indeed, these 6 bits have the potential to total 63 if they are all ones. But we're checking for values within the range of 0-100. So assuming we already have a 1 as the seventh bit from the right, some of these remaining six bits will need to be zeros. The question is how we determine what combinations of zeros and ones are acceptable.

I'm suggesting a process of systematically checking the seven rightmost bits. Each of these bits is a fork in the testing road: It will either tell you conclusively (yes or no) whether the value is in range, or it will tell you that you need to move on to the next bit and continue testing...

First, check whether any of the first 25 bits are 1. If so, the value is definitely outside the range of 0-100 (in fact, it's outside the range of 0-255), so we're done checking. But if not, then we need to continue.

Check the 7th bit from the right. If it's zero, then the value is definitely within the range of 0-100 (in fact, it's within the range of 0-63 because we have 0******), so we're done checking. But if it's one, then we need to continue because we have 1******.

Check the 6th bit from the right. If it's zero, then the value is definitely within the range of 0-100 (in fact, it's within the range of 0-95 because we have 10*****), so we're done checking. But if it's one, then we need to continue because we have 11*****.

Check the 5th bit from the right. If it's one, then the value is definitely outside the range of 0-100 (in fact, it's 112 or greater because we have 111****), so we're done checking. But if it's zero, then we need to continue because we have 110****.