# Bitwise Again

Wolfgang Obi

Ranch Hand

Posts: 134

posted 9 years ago

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?

or maybe with the help of compliments?

'really appreciate some help. Thanks.

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?

or maybe with the help of compliments?

'really appreciate some help. Thanks.

posted 9 years ago

Well, 255 in binary is 11111111. So if a value has

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 ]

*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

Posts: 134

posted 9 years ago

that would be avoiding replacing any of the 0's

and how would i formulate this as java code?

with the use of

thanks for the insight

Originally posted by marc weber:

Well, 255 in binary is 11111111. So if a value hasanybits 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,. Any ideas...?but the trick is in also ruling out values between 101 and 255

that would be avoiding replacing any of the 0's

*of the leading one in the decimal representation of 100 (while also minding the boundary of 255 decimal ) ?*

**right**and how would i formulate this as java code?

with the use of

**'<<'**or

**'>>'**operators maybe?

thanks for the insight

posted 9 years ago

Close, but it's a "bit" more complicated. You could replace these zeros

1100010 ==> 98

Originally posted by Wolfgang Obi:

...that would be avoiding replacing any of the 0'srightof 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...

1100010 ==> 98

*~Joe Strummer*

sscce.org

posted 9 years ago

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...

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...

*~Joe Strummer*

sscce.org

Wolfgang Obi

Ranch Hand

Posts: 134

posted 9 years ago

oh, but i was thinking along the lines of

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....

thanks

Originally posted by marc weber:

Close, but it's a "bit" more complicated. You could replace these zerosifthe 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....

thanks

posted 9 years ago

1101000 ==> 104

Originally posted by Wolfgang Obi:

...oh, but i was thinking along the lines ofrange(101,255)....

in which case the 1 in the 3rd position from right would ALWAYS be placed,..no? ...

1101000 ==> 104

*~Joe Strummer*

sscce.org

Wolfgang Obi

Ranch Hand

Posts: 134

posted 9 years ago

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 ]

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 ]

posted 9 years ago

The 7th bit from the right represents a decimal value of 64. So if this bit is 1, then

Indeed, these 6 bits have the

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

First, check whether 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****. Etc.

*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...*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.

*~Joe Strummer*

sscce.org