Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

Bit Manipulation in Java

Thread view: 
leslie_tighe@yahoo.com - 26 Nov 2005 06:35 GMT
Hello,

I am new to working with the bit operators in java and need to
implement an algorightm and was hoping to get some guidance to address
the questions or url to material that may help.

1) I am starting out a byte array of lenght 20.
2) Next I need to determin the offsetbits, which are supposed to to be
the low order 4 bits of byte[19].  How do I determine this?
3)How do I convert this value in to an Int ?

Thanks in advance for your help.

Leslie
Andrey Kuznetsov - 26 Nov 2005 07:15 GMT
> 1) I am starting out a byte array of lenght 20.

byte [] b = new byte[20];

> 2) Next I need to determin the offsetbits, which are supposed to to be
> the low order 4 bits of byte[19].

int mask = 15;

public int getOffsetBits() {
   return b[19] & mask;
}

> 3)How do I convert this value in to an Int ?
don't know such type.
May be you want int or Integer?

Signature

Andrey Kuznetsov
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

Alan Krueger - 26 Nov 2005 15:51 GMT
>>2) Next I need to determin the offsetbits, which are supposed to to be
>>the low order 4 bits of byte[19].
[quoted text clipped - 4 lines]
>     return b[19] & mask;
> }

To tie in another thread, this may be one of those instances where
symbolic constants might be more maintainable than magic values.
John C. Bollinger - 26 Nov 2005 20:34 GMT
>>> 2) Next I need to determin the offsetbits, which are supposed to to be
>>> the low order 4 bits of byte[19].
[quoted text clipped - 7 lines]
> To tie in another thread, this may be one of those instances where
> symbolic constants might be more maintainable than magic values.

Agreed.  Furthermore, I tend to use hexadecimal notation for literals
intended for this sort of purpose.  It emphasizes (to me at least) that
it is not the value of the number that is important /per se/, but rather
its binary representation.

Signature

John Bollinger
jobollin@indiana.edu

Roedy Green - 26 Nov 2005 16:37 GMT
On 25 Nov 2005 22:35:01 -0800, "leslie_tighe@yahoo.com"
<leslie_tighe@yahoo.com> wrote, quoted or indirectly quoted someone
who said :

>1) I am starting out a byte array of lenght 20.
>2) Next I need to determin the offsetbits, which are supposed to to be
>the low order 4 bits of byte[19].  How do I determine this?
>3)How do I convert this value in to an Int ?

see http://mindprod.com/jgloss/masking.html

http://mindprod.com/jgloss/binary.html

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

zero - 26 Nov 2005 18:31 GMT
> see http://mindprod.com/jgloss/masking.html
>
> http://mindprod.com/jgloss/binary.html

Not really related to the OP, but I've always wondered if bit manipulations
in Java are really performant?  In (relatively low to the ground) languages
like C and C++ manipulating individual bits can be done for reasons of
memory usage and/or speed.  But does that apply for Java too, or does the
JVM handle bit manipulations in a way that levels out these advantages?  
And if you're going to use bits, is it better to use a BitSet, or just use
raw data types and manipulate those bits?  Anyone have some insight in
this?

Signature

Beware the False Authority Syndrome

Roedy Green - 26 Nov 2005 19:16 GMT
>Not really related to the OP, but I've always wondered if bit manipulations
>in Java are really performant?  In (relatively low to the ground) languages
[quoted text clipped - 4 lines]
>raw data types and manipulate those bits?  Anyone have some insight in
>this?

The JVM has bit operators that map very directly onto the bit
manipulation operators of most modern CPUs, so I would expect longs
and ints to do equally well to C with Hotspot or AOT compilers.

BitSet is for sets larger than 64 bits.  It does the housekeeping to
simulate long bit strings with an array of longs.

see http://mindprod.com/jgloss/binary.html#BITSET
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

zero - 26 Nov 2005 19:35 GMT
> The JVM has bit operators that map very directly onto the bit
> manipulation operators of most modern CPUs, so I would expect longs
[quoted text clipped - 4 lines]
>
> see http://mindprod.com/jgloss/binary.html#BITSET

That's a very clear and helpful answer, thanks Roedy :-)

Signature

Beware the False Authority Syndrome

Luc The Perverse - 26 Nov 2005 20:38 GMT
To think that Sun would deliberately pass up a possible speed advantage by
choosing some form of integer arithmatic over binary ops, is ludicrous.

Now yes, if there is some hardware platform out there which does not contain
native implementations for these calls (I don't know of any) then the JVM
would have to work around that.

Signature

ALEX TAYLOR

>
>> see http://mindprod.com/jgloss/masking.html
[quoted text clipped - 11 lines]
> raw data types and manipulate those bits?  Anyone have some insight in
> this?


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.