The number 254 is 11111110 in binary. My problem is I want to grab the last 2 bits (10). I was told to use the % operator to do this but I don't know how. Can anyone help me with this problem?
Supposing you want to get the numeric value of the last 2 binary digits, we can use a mask.
public static void main(String[] args) {
int n = 0b1110;
int mask = 0b11;
System.out.println(n & mask);
}
What the code is doing is taking the number, in this case 0b1110 and doing an and with the mask defined 0b11.
0b is how you tell java that you are expressing the number as binary.
In case you wanted to obtain the binary number as binary, you can use this:
Integer.toBinaryString(n & mask)
You can use % to convert to binary but I believe its easier to use Integer.toBinaryString() and then charAt() to get the last 2 characters like they do in here
How do you get the last character of a string?
The last two bits can be obtained by doing x % 4, or by doing x & 3.
x % 4 is remainder after division by 4, which is a number 0-3, as represented by the last two bits.
x & 3 is a bit-wise AND operation with the binary number 11, i.e. zero'ing all other bits.
The second is generally the fastest at runtime, and the preferred method for doing bit manipulation. (Use a bit-wise operator for bit manipulation, right?)
Related
I am working on a file reader and came into a problem when trying to read a short. In short (punintended), java is converting a two bytes I'm using to make the short into an int to do bitwise operations and is converting it in a way to keep the same value. I need to convert the byte into an int in a way that would preserve its value so the bits stayed the same.
example of what's happening:
byte number = -1; //-1
int otherNumber = 1;
number | otherNumber; // -1
example of what I want:
byte number = -1; //-1
int otherNumber = 1;
number | otherNumber; // 129
This can be done pretty easily with some bit magic.
I'm sure you're aware that a short is 16 bits (2 bytes) and an int is 32 bits (4 bytes). So, between an integer and a short, there is a two-byte difference. Now, for positive numbers, copying the value of a short to an int is effectively copying the binary data, however, as you've pointed out, this is not the case for negative numbers.
Now let's look at how negative numbers are represented in binary. It's a bit confusing, so I'll try to keep it simple. Modern systems use what's called the two's compliment to store negative numbers. Basically all this means is that the very first bit in the set of bytes representing the number determines whether or not it's negative. For mathematical purposes, the rest of the bits are also inverted and offset 1 bit to the right (since you can't have negative 0). For example, 2 as a short would be represented as 0000 0000 0000 0010, while -2 would be represented as 1111 1111 1111 1110. Now, since the bytes are inverted in a negative number, this means that -2 in int form is the same but with 2 more bytes (16 bits) at the beginning that are all set to 1.
So, in order to combat this, all we need to do is change the extra 1s to 0s. This can be done by simply using the bitwise and operator. This operator goes through each bit and checks if the bits at each position in each operand are a 1 or a 0. If they're both 1, the bit is flipped to a 0. If not, nothing happens.
Now, with this knowledge, all we need to do is create another integer where the first two bytes are all 1. This is fairly simple to do using hexidecimal literals. Since they are an integer by default, we simply need to use this to get four bytes of 1s. With a single byte, if you were to set every bit to 1, the max value you can get is 255. 255 in hex is 0xFF, so 2 bytes would be 0xFFFF. Pretty simple, now you just need to apply it.
Here is an example that does exactly that:
short a = -2;
int b = a & 0xFFFF;
You could also use Short.toUnsignedInt(), but where's the fun in that? 😉
I need to convert byte to hex string, and tried below:
String.format("%02x", -1);
Note, -1 here is two's complement integer
However the return I get is "ffffffff" instead of "ff" which is expected?
Because ff isn't -1. It's 255. Specifying 02 in your format might pad a short number with a leading zero to get it up to 2 digits, but it won't truncate a number in a way that would give the wrong value.
If you want to get a one-byte value for a number, you can cut it to one byte with &0xff.
int n = -1;
String.format("%02x", n&0xff);
Because %02 means the minimum width of the result should be 2 and pad with 0 if needed. It does nothing if the result is more than 2 characters wide.
Knowing that, and the fact Java integers are 32 bits long, the result is expected. If you want ff, you can either do String.format("%02x", 255) or String.format("%02x", (byte)-1).
Formatting does not truncate any significant digits. That's why if you specify less positions than needed for representation, your limit will be ignored and all significant digits will be represented. For instance, if you have a number 0x12345 and try to format it using only 2 positions (like in your format), the result string will consist of 5 digits, not 2.
Hexadecimal ff means decimal 255, not decimal -1 as you may have expected. The number -1 is of type int. It takes 4 bytes in memory. Its hexadecimal representation really needs ffffffff, i.e. 8 hex digits. There are no leading zeroes that you could truncate. Leading zeroes are possible for positive numbers only. For instance, -2 will be formatted to fffffffe, -3 to fffffffd, -256 to ffffff00, -257 to fffffeff, etc.
I see this comment, but don't understand it.
Get its last set bit
diff &= -diff;
I tried
int a = 3 & -3; it returns 1.
int a = 2 & -2; it returns 2.
int a = 4 & -4; it returns 4.
int a = 5 & -5; it returns 1.
The comment would be better expressed as 'Get the least significant bit set'. To understand what is going on, you need to examine how negative numbers are represented in binary. The technique is called twos complement and works by starting with the positive representation of the number; you complement each bit (i.e. 1 -> 0 and 0 -> 1). You then add 1 to this number. In the example of 12:
00001100 12
11110011 complement
00000001 binary 1
11110100 add to complement to form twos complement negative
If you now AND the original value with the negative, you get
00000100
where the only bit set corresponds to the least significant bit set in the original pattern.
As the comment said, diff & -diff returns the value of the last bit that was set on diff. For example:
diff = 14
.... = 1110 (binary)
.... ^ last set bit
.... 10 is the last set bit
.... 10 in decimal is 2
Another example
diff = 24
.... = 11000 (binary)
.... ^ last set bit
.... 1000 is the last set bit
.... 1000 in decimal is 8
I would recommend reading the guidelines for how to ask a well formulated question. One recommendation I can personally give is to have one sentence at the end of your question that sums up exactly what it is you want to know.
I am trying to perform a bitwise not on a 128 bit BigInteger in Java. I have a 128 bit number which has the first 64 bits set to 1 and the last 64 bits set to 0 (I am playing with IPv6 masks).
BigInteger b = new BigInteger(2).pow(64).subtract(BigInteger.ONE).shiftLeft(64);
System.out.println(b.toString(2));
This results in the following, if I output it using base 2:
11111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000
I am trying to flip/reverse all the bits using a bitwise not.
System.out.println(b.not().toString(2));
From my understanding of a bitwise not, I was expecting all the 1's to change to 0's and all the 0's to change to 1's, but I get the following instead:
-11111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000
This also seems to match the documentation of the not() function:
This method returns a negative value if and only if this BigInteger is non-negative
Is it a case of looping through all 128 bits and performing a bitwise not on each separate bit instead?
UPDATE
It probably helps if I try and explain what I was trying to achieve to give some context. I am manipulating IPv6 addresses and was trying to determine if a given IPv6 address was within a subnet or not based on an IPv6 mask.
Based on the responses, I think the following should work:
E.g.
Is 2001:db8:0:0:8:800:200c:417b within 2001:db8::/64?
BigInteger n = new BigInteger(1, InetAddress.getByName("2001:db8::").getAddress());
BigInteger b = BigInteger.ONE.shiftLeft(64).subtract(BigInteger.ONE).shiftLeft(64);
// First Address in Subnet
BigInteger first = n.and(b);
// Last Address in Subnet (this is where I was having a problem as it was returning a negative number)
BigInteger MASK_128 = BigInteger.ONE.shiftLeft(128).subtract(BigInteger.ONE);
BigInteger last = first.add(b.xor(MASK_128));
// Convert our test IP into BigInteger
BigInteger ip = new BigInteger(1, InetAddress.getByName("2001:db8:0:0:8:800:200c:417b").getAddress());
// Check if IP is >= first and <= last
if ((first.compareTo(ip) <= 0) && (last.compareTo(ip) >= 0)) {
// in subnet
}
As others have pointed out, it's the sign bit that is giving you the result that you don't want.
There are a couple of ways that you can get the inverted bits. For both of them you will need a 128 bit mask value:
private static final BigInteger MASK_128 =
BigInteger.ONE.shiftLeft(128).subtract(BigInteger.ONE);
Then you can either mask the sign bit:
BigInteger b = BigInteger.valueOf(2).pow(64).subtract(BigInteger.ONE).shiftLeft(64);
System.out.println(MASK_128.andNot(b).toString(2));
Or invert directly using xor:
System.out.println(b.xor(MASK_128).toString(2));
I expect the mask value will be useful elsewhere once you start fleshing things out also.
signed byte 64 = 01000000
Invert it
and we get signed byte -65 = 10111111
Sign "minus" is the "not" operator itself:
-1000000 = 0111111
Type this and you see that the values are equal (+1) in absolute
System.out.println(b.toString());
System.out.println(b.not().toString());
Your answer is perfectly correct ,In java everything is in two's compliment:
Convert Decimal to Two's Complement
Convert the number to binary (ignore the sign for now) e.g. 5 is 0101 and -5 is 0101
If the number is a positive number then you are done. e.g. 5 is 0101 in binary using twos complement notation.
Here goes your solution.
If the number is negative then
3.1 find the complement (invert 0's and 1's) e.g. -5 is 0101 so finding the complement is 1010
3.2 Add 1 to the complement 1010 + 1 = 1011. Therefore, -5 in two's complement is 1011.
So, what if you wanted to do 2 + (-3) in binary? 2 + (-3) is -1. What would you have to do if you were using sign magnitude to add these numbers? 0010 + 1101 = ?
Using two's complement consider how easy it would be.
2 = 0010
-3 = 1101
+
-1 = 1111
Converting Two's Complement to Decimal
Converting 1111 to decimal:
The number starts with 1, so it's negative, so we find the complement of 1111, which is 0000.
Add 1 to 0000, and we obtain 0001.
Convert 0001 to decimal, which is 1.
Apply the sign = -1.
In your case
when you do b.not().toString(2) , you will get the response :
-11111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000001
with 1 at the last bit.
Now do the two's compliment and you will get the right answer.
e.g; Flip all the 1's by 0's and vice-versa. after doing that add one to the solution and you will get the solution that you are seeking.
Final solution
00000000000000000000000000000000000000000000000000000000000000001111111111111111111111111111111111111111111111111111111111111111
Use
VALUE = 0xFFFFFFFFFFFFFFFF0000000000000000 - this is patern for bit 1...10...0
VALUE = 0x0000000000000000FFFFFFFFFFFFFFFF - this is patern for bit 0...01...1
Just type by hand 16 x "F" and "0" and remember to add "0x"before each pattern.
Define this values as final.
If You want to generate such values you must do
value += 0x1;
value << 1;
For n times. In your case n is 64.
I have a scenario where I'm working with large integers (e.g. 160 bit), and am trying to create the biggest possible unsigned integer that can be represented with an n bit number at run time. The exact value of n isn't known until the program has begun executing and read the value from a configuration file. So for example, n might be 160, or 128, or 192, etcetera...
Initially what I was thinking was something like:
BigInteger.valueOf((long)Math.pow(2, n));
but then I realized, the conversion to long that takes place sort of defeats the purpose, given that long is not comprised of enough bits in the first place to store the result. Any suggestions?
On the largest n-bit unsigned number
Let's first take a look at what this number is, mathematically.
In an unsigned binary representation, the largest n-bit number would have all bits set to 1. Let's take a look at some examples:
1(2)= 1 =21 - 1
11(2)= 3 =22 - 1
111(2)= 7 =23 - 1
:
1………1(2)=2n -1
   n
Note that this is analogous in decimal too. The largest 3 digit number is:
103- 1 = 1000 - 1 = 999
Thus, a subproblem of finding the largest n-bit unsigned number is computing 2n.
On computing powers of 2
Modern digital computers can compute powers of two efficiently, due to the following pattern:
20= 1(2)
21= 10(2)
22= 100(2)
23= 1000(2)
:
2n= 10………0(2)
       n
That is, 2n is simply a number having its bit n set to 1, and everything else set to 0 (remember that bits are numbered with zero-based indexing).
Solution
Putting the above together, we get this simple solution using BigInteger for our problem:
final int N = 5;
BigInteger twoToN = BigInteger.ZERO.setBit(N);
BigInteger maxNbits = twoToN.subtract(BigInteger.ONE);
System.out.println(maxNbits); // 31
If we were using long instead, then we can write something like this:
// for 64-bit signed long version, N < 64
System.out.println(
(1L << N) - 1
); // 31
There is no "set bit n" operation defined for long, so traditionally bit shifting is used instead. In fact, a BigInteger analog of this shifting technique is also possible:
System.out.println(
BigInteger.ONE.shiftLeft(N).subtract(BigInteger.ONE)
); // 31
See also
Wikipedia/Binary numeral system
Bit Twiddling Hacks
Additional BigInteger tips
BigInteger does have a pow method to compute non-negative power of any arbitrary number. If you're working in a modular ring, there are also modPow and modInverse.
You can individually setBit, flipBit or just testBit. You can get the overall bitCount, perform bitwise and with another BigInteger, and shiftLeft/shiftRight, etc.
As bonus, you can also compute the gcd or check if the number isProbablePrime.
ALWAYS remember that BigInteger, like String, is immutable. You can't invoke a method on an instance, and expect that instance to be modified. Instead, always assign the result returned by the method to your variables.
Just to clarify you want the largest n bit number (ie, the one will all n-bits set). If so, the following will do that for you:
BigInteger largestNBitInteger = BigInteger.ZERO.setBit(n).subtract(BigInteger.ONE);
Which is mathematically equivalent to 2^n - 1. Your question has how you do 2^n which is actually the smallest n+1 bit number. You can of course do that with:
BigInteger smallestNPlusOneBitInteger = BigInteger.ZERO.setBit(n);
I think there is pow method directly in BigInteger. You can use it for your purpose
The quickest way I can think of doing this is by using the constructor for BigInteger that takes a byte[].
BigInteger(byte[] val) constructs the BigInteger Object from an array of bytes. You are, however, dealing with bits, and so creating a byte[] that might consist of {127, 255, 255, 255, 255} for a 39 bit integer representing 2^40 - 1 might be a little tedious.
You could also use the constructor BigInteger(String val, int radix) - which might be readily more apparently what's going on in your code if you don't mind a performance hit for parsing a String. Then you could generate a string like val = "111111111111111111111111111111111111111" and then call BigInteger myInt = new BigInteger(val, 2); - resulting in the same 39 bit integer.
The first option will require some thinking about how to represent your number. That particular constructor expects a two's-compliment, big-endian representation of the number. The second will likely be marginally slower, but much clearer.
EDIT: Corrected numbers. I thought you meant represent 2^n, and didn't correctly read the largest value n bits could store.