File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Bitwise Again Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Bitwise Again" Watch "Bitwise Again" New topic
Author

Bitwise Again

Wolfgang Obi
Ranch Hand

Joined: Dec 05, 2005
Posts: 134
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.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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

thanks for the insight
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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

1100010 ==> 98
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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

thanks
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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
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 ]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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****.
  • Etc.
  •  
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Bitwise Again
     
    Similar Threads
    Help me with byte and bits
    Bitwise OR of signed byte value
    Passed SCJD
    value & 0xff
    Overflow and Underflow