81

What method would you use to determine if the the bit that represents 2^x is a 1 or 0 ?

Ande Turner
  • 7,096
  • 19
  • 80
  • 107

14 Answers14

188

I'd use:

if ((value & (1L << x)) != 0)
{
   // The bit was set
}

(You may be able to get away with fewer brackets, but I never remember the precedence of bitwise operations.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    As a matter of curiosity: why did you prefer the left-shift of 1 versus the right-shifting of value? – Erich Mirabal Jul 07 '09 at 13:50
  • 54
    That depends on the language. In java that isn't true. – harmanjd Jul 07 '09 at 13:51
  • 12
    That should be 1L, or (1 << 32) ends up with the same value as (1 << 0) – Matt K Jul 07 '09 at 13:52
  • "That depends on the language. In java that isn't true." You're right, I forgot that java was a strange language... ;-) – ThibThib Jul 07 '09 at 13:55
  • 2
    @Erich: I find it mentally easier to think of varying the mask rather than varying the value. The problem is more easily described as "is bit x set to 1" than "is the value shifted right by x bits 1 in the least bit". Personal taste I guess. @Matt: Fixed, thanks. – Jon Skeet Jul 07 '09 at 13:58
  • 4
    @ThibThib nothing strange about it. Please don't post stupid anti Java flame bait. – amischiefr Jul 07 '09 at 14:04
  • 4
    ThibThib: s/strange/strongly typed/ – Tom Hawtin - tackline Jul 07 '09 at 14:13
  • 12
    I wonder if ((value>>>x) & 1) != 0 is better because it doesn't matter whether value is long or not, or if its worse because it's less obvious. – Tom Hawtin - tackline Jul 07 '09 at 14:16
  • 1
    Another advantage to using (1L<>x) is that if x is constant, then the compiler can inline it and it becomes (effectively) (value & constant), which means a (very) little less work for the JVM. Not a big advantage… but… – Paul Wagland Jan 27 '10 at 13:45
  • @amischiefr - Riddle me this... why did they keep bitwise operators but throw out convenient means of using them (IE, the convention that non 0 values are true and others are false?) Are bitwise operators even particularly fast in Java or are they entirely pointless? – ArtOfWarfare Nov 27 '13 at 16:00
  • 1
    @ArtOfWarfare: I'm *extremely* happy that the "convention" of implicitly converting non-Boolean values to Boolean values was removed. It's easy to explicitly check against 0, but it's nice (IMO) that it won't happen *implicitly*, where most of the time you don't actually want it to. – Jon Skeet Nov 27 '13 at 16:05
  • @JonSkeet - When have you ever once not wanted a boolean value in an if statement? Have you ever once written `if (a & b)` and actually made a mistake where you wanted it to mean anything besides `if (a & b != 0)`? Maybe you wanted `if (a && b)` instead, but if that were the case then it seems a better solution would have been changing the syntax of bitwise operators (or throwing them out entirely. Since java is run in a virtual machine, I see no reason to expose the notion of bits in the language. They'll need to be simulated on platforms that lack bits.) – ArtOfWarfare Nov 28 '13 at 18:06
  • 4
    @ArtOfWarfare: I've sometimes mistyped `==` as `=` - which leads to a valid expression assigning that value, which is *not* what I want. In Java, that's illegal (assuming it's not a `boolean` variable). Bitwise operators are part of Java, and that's a good thing IMO. There are plenty of situations where you *want* bitwise operators. There's no need to conflate that with whether or not the type of a condition expression in `while`, `if` etc should be `boolean` - which I believe it should. – Jon Skeet Nov 28 '13 at 18:35
  • 1
    To clarify the question further, the bit which we are testing for starts from the right and the right most bit is represented by x=0. So if value is 6 which is 110 in binary, bits 1, and 2 are set but not bit 0. The solution is to take a 1, move it to the position we want to be tested and 'AND' with the value. If AND operation result is a 0, the particular bit is zero or not set – user2176745 Jul 15 '20 at 22:03
101

Another alternative:

if (BigInteger.valueOf(value).testBit(x)) {
    // ...
}
finnw
  • 47,861
  • 24
  • 143
  • 221
  • 9
    Not a very good solution if this code is going to be called often. You're replacing a one-line alternative with a one line alternative, and the bit shifts really aren't that hard. – wds Aug 28 '09 at 07:32
  • 3
    Length of line != readability of line, wds. You might be right that the previous solution is more efficient, but the difference is likely marginal, especially if testBit() gets inlined. – Isabelle Wedin Aug 29 '09 at 16:05
  • 8
    It should be noted this solution allocates memory and is much less efficient than bitwise operators. Yes, it often doesn't matter, but sometimes it is important to avoid unnecessary GC and/or inefficient code (Android apps, in a game's main loop, etc). – NateS Oct 28 '10 at 05:16
  • @WCWedin: How do you inline a function in Java? –  Aug 17 '11 at 20:59
  • @Code Monkey, you don't (explicitly.) The JIT makes that decision. – finnw Aug 17 '11 at 21:53
  • 6
    Resource waste. If you can't trust the "future maintainers" for understanding bit operations then you have a bigger problem than that with human resources on the project. Bit operations isn't magic. This is part of the basic set of a programmer skills. – dolmen May 06 '13 at 15:32
  • 2
    @dolmen, if the profiler highlights it as taking a lot of CPU time, I'll replace it with something faster. Until then, it does not matter. – finnw Nov 28 '13 at 20:00
15

I wonder if:

  if (((value >>> x) & 1) != 0) {

  }

.. is better because it doesn't matter whether value is long or not, or if its worse because it's less obvious.

Tom Hawtin - tackline Jul 7 at 14:16

Ande Turner
  • 7,096
  • 19
  • 80
  • 107
  • I think it's better because there is less potential for errors - and if you think it isn't obvious, you can always extract the test into an appropriately named function (boolean isBitSet(long value, int x) or so) – hjhill Aug 26 '09 at 08:30
13

You can also use

bool isSet = ((value>>x) & 1) != 0;

EDIT: the difference between "(value>>x) & 1" and "value & (1<<x)" relies on the behavior when x is greater than the size of the type of "value" (32 in your case).

In that particular case, with "(value>>x) & 1" you will have the sign of value, whereas you get a 0 with "value & (1<<x)" (it is sometimes useful to get the bit sign if x is too large).

If you prefer to have a 0 in that case, you can use the ">>>" operator, instead if ">>"

So, "((value>>>x) & 1) != 0" and "(value & (1<<x)) != 0" are completely equivalent

ThibThib
  • 8,010
  • 3
  • 30
  • 37
8

For the nth LSB (least significant bit), the following should work:

boolean isSet = (value & (1 << n)) != 0;
Eng.Fouad
  • 115,165
  • 71
  • 313
  • 417
Noldorin
  • 144,213
  • 56
  • 264
  • 302
7

You might want to check out BitSet: http://java.sun.com/javase/6/docs/api/java/util/BitSet.html

Yannick Motton
  • 34,761
  • 4
  • 39
  • 55
4

Bit shifting right by x and checking the lowest bit.

schnaader
  • 49,103
  • 10
  • 104
  • 136
4

In Java the following works fine:

if (value << ~x < 0) {
   // xth bit set
} else {
   // xth bit not set
}

value and x can be int or long (and don't need to be the same).

Word of caution for non-Java programmers: the preceding expression works in Java because in that language the bit shift operators apply only to the 5 (or 6, in case of long) lowest bits of the right hand side operand. This implicitly translates the expression to value << (~x & 31) (or value << (~x & 63) if value is long).

Javascript: it also works in javascript (like java, only the lowest 5 bits of shift count are applied). In javascript any number is 32-bit.

Particularly in C, negative shift count invokes undefined behavior, so this test won't necessarily work (though it may, depending on your particular combination of compiler/processor).

How does it work?

The cleverness of this answer lies in that the sign bit of an integer is very easy to read: when that bit is set, then the value is negative; if not set, then the value is either zero or positive.

So the whole idea is to shift the xth bit exactly into the sign bit. That means a displacement of 31 - x to the left (or 63 - x, if value is 64 bits wide).

In java (and other languages as well), the ~ operator computes the bitwise NOT operation, which arithmetically equals to -x - 1 (no matter how wide x is).

Also the java << operator takes only the least significant 5 (or 6) bits of the right-hand side operand (whether 5 or 6 depends on how wide the left-hand side operand is: for int then 5; for long then 6). Arithmetically this is the same as the remainder of division by 32 (or 64).

And that is (-x - 1) % 32 = 31 - x (or (-x - 1) % 64 = 63 - x, for 64 bit wide value).

rslemos
  • 2,454
  • 22
  • 32
2

The value of the 2^x bit is "variable & (1 << x)"

Artur Soler
  • 2,974
  • 2
  • 23
  • 24
  • As Matt Kane said in identical solutions: That should be 1L, or (1 << 32) ends up with the same value as (1 << 0) – drvdijk Jul 07 '09 at 13:59
1

My contribution - ignore previous one

public class TestBits { 

    public static void main(String[] args) { 

        byte bit1 = 0b00000001;     
        byte bit2 = 0b00000010;
        byte bit3 = 0b00000100;
        byte bit4 = 0b00001000;
        byte bit5 = 0b00010000;
        byte bit6 = 0b00100000;
        byte bit7 = 0b01000000;

        byte myValue = 9;                        // any value

        if (((myValue >>> 3) & bit1 ) != 0) {    //  shift 3 to test bit4
            System.out.println(" ON "); 
        }
    } 
}
Littm
  • 4,923
  • 4
  • 30
  • 38
1

If someone is not very comfortable with bitwise operators, then below code can be tried to programatically decide it. There are two ways.

1) Use java language functionality to get the binary format string and then check character at specific position

2) Keep dividing by 2 and decide the bit value at certain position.

public static void main(String[] args) {
    Integer n =1000;
    String binaryFormat =  Integer.toString(n, 2);
    int binaryFormatLength = binaryFormat.length();
    System.out.println("binaryFormat="+binaryFormat);
    for(int i = 1;i<10;i++){
        System.out.println("isBitSet("+n+","+i+")"+isBitSet(n,i));
        System.out.println((binaryFormatLength>=i && binaryFormat.charAt(binaryFormatLength-i)=='1'));
    }

}

public static boolean isBitSet(int number, int position){
    int currPos =1;
    int temp = number;
    while(number!=0 && currPos<= position){
        if(temp%2 == 1 && currPos == position)
            return true;
        else{
            temp = temp/2;
            currPos ++;
        }
    }
    return false;
}

Output

binaryFormat=1111101000
isBitSet(1000,1)false
false
isBitSet(1000,2)false
false
isBitSet(1000,3)false
false
isBitSet(1000,4)true
true
isBitSet(1000,5)false
false
isBitSet(1000,6)true
true
isBitSet(1000,7)true
true
isBitSet(1000,8)true
true
isBitSet(1000,9)true
true
Kaushik Lele
  • 6,439
  • 13
  • 50
  • 76
  • 3
    One division costs about a hundred time more CPU time than a bit operator. And you do it iteratively. This 'solution' is on the level of BigInteger regarding performance. – Agoston Horvath Feb 09 '16 at 09:15
0

declare a temp int and make it equal the original. then shift temp >> x times, so that the bit you want to check is at the last position. then do temp & 0xf to drop the preceding bits. Now left with last bit. Finally do if (y & 1 == 0), if last bit is a 1, that should equal 0, else will equal 1. Its either that or if (y+0x1 == 0)... not too sure. fool around and see

  • 3
    Why did you post a convoluted, hard to read, iffy answer that has nothing on the existing answers with 50+ upvotes? – Keith Pinson Dec 17 '12 at 19:05
0

I coded a little static class which is doing some of the bit operation stuff.

public final class Bitfield {

  private Bitfield() {}

  // ********************************************************************
  // * TEST
  // ********************************************************************

  public static boolean testBit(final int pos, final int bitfield) {
      return (bitfield & (1 << pos)) == (1 << pos);
  }

  public static boolean testNum(final int num, final int bitfield) {
      return (bitfield & num) == num;
  }

  // ********************************************************************
  // * SET
  // ********************************************************************

  public static int setBit(final int pos, final int bitfield) {
     return bitfield | (1 << pos);
  }

  public static int addNum(final int number, final int bitfield) {
      return bitfield | number;
  }

  // ********************************************************************
  // * CLEAR
  // ********************************************************************

  public static int clearBit(final int pos, final int bitfield) {
      return bitfield ^ (1 << pos);
  }

  public static int clearNum(final int num, final int bitfield) {
      return bitfield ^ num;
  }

  }

If there are some questions flying around, just write me an email.

Good Programming!

Alessandro Giusa
  • 1,660
  • 15
  • 11
-2

Eliminate the bitshifting and its intricacies and use a LUT for the right and operand.

typeseven
  • 810
  • 6
  • 8
  • This is considerably slower than a bitwise operation. It would require address lookups over a 1 or 2 clock cycle bitwise operation. – Kyle Falconer Mar 30 '15 at 17:43