I recently learned a method in BigInteger Java class called
BigInteger.testBit(n)
Its main function is (this & (1<<n)) != 0), but I do not quite understand the source code
return (getInt(n >>> 5) & (1 << (n & 31))) != 0;
Can someone explain it?
I'm not familiar with how it's implemented, but judging by that code, I would assume that a BigInteger is implemented by storing it's value in a list of integers, and getInt(n) returns the n'th of these, where 0 = least significant.
The first will store the least significant 32 bits, getInt(1) will store bits 32-63 etc. By shifting n right by 5, you get the index of the integer in the internal list that has the bit you care about, it's the equivalent to n div 32.
With that integer, you then pick out the bit you care about from it with the (1 << (n & 31)). n & 31 is the equivalent of n modulo 32, and the 1 << is the equivalent of 2^. This gets you a bit mask that selects precisely the bit you care about.
Related
I was recently looking into some problems with but manipulation in Java and I came up with two questions.
1) Firstly, I came up to the problem of flipping all the bits in a number.
I found this solution:
public class Solution {
public int flipAllBits(int num) {
int mask = (1 << (int)Math.floor(Math.log(num)/Math.log(2))+1) - 1;
return num ^ mask;
}
}
But what happens when k = 32 bits? Can the 1 be shifted 33 times?
What I understand from the code (although it doesn't really make sense), the mask is 0111111.(31 1's)....1 and not 32 1's, as someone would expect. And therefore when num is a really large number this would fail.
2) Another question I had was determining when something is a bit sequence in 2s complement or just a normal bit sequence. For example I read that 1010 when flipped is 0110 which is -10 but also 6. Which one is it and how do we know?
Thanks.
1) The Math object calls are not necessary. Flipping all the bits in any ordinal type in Java (or C) is not an arithmatic operation. It is a bitwise operation. Using the '^' operator, simply using 1- as an operand will work regardless of the sizeof int in C/C++ or a Java template with with the ordinal type as a parameter T. The tilde '~' operator is the other option.
T i = 0xf0f0f0f0;
System.out.println(T.toHexString(i));
i ^= -1;
System.out.println(T.toHexString(i));
i = ~ i;
System.out.println(T.toHexString(i));
2) Since the entire range of integers maps to the entire range of integers in a 2's compliment transform, it is not possible to detect whether a number is or is not 2's complement unless one knows the range of numbers from which the 2's complement might be calculated and the two sets (before and after) are mutually exclusive.
That mask computation is fairly inscrutable, I'm going to guess that it (attempts to, since you mention it's wrong) make a mask up to and including the highest set bit. Whether that's useful for "flipping all bits" is an other possible point of discussion, since to me at least, "all bits" means all 32 of them, not some number that depends on the value. But if that's what you want then that's what you want. Especially combined with that second question, that looks like a mistake to me, so you'd be implementing the wrong thing from the start - see near the bottom.
Anyway, the mask can be generated with some reasonably nice bitmath, which does not create any doubt about possible edge cases (eg Math.log(0) is probably bad, and k=32 corresponds with negative numbers which are also probably bad to put into a log):
int m = num | (num >> 16);
m |= m >> 8;
m |= m >> 4;
m |= m >> 2;
m |= m >> 1;
return num ^ m;
Note that this function has odd properties, it almost always returns an unsigned-lower number than went in, except at 0. It flips bits so the name is not completely wrong, but flipAllBits(flipAllBits(x)) != x (usually), while the name suggests it should be an involution.
As for the second question, there is nothing to determine. Two's complement is scheme by which you can interpret a bitvector - any bitvector. So it's really a choice you make; to interpret a given bitvector that way or some other way. In Java the "default" interpretation is two's complement (eg toString will print an int by interpreting it according to its two's complement meaning), but you don't have to go along with it, you can (with care) treat int as unsigned, or as an array of booleans, or several bitfields packed together, etc.
If you wanted to invert all the bits but made the common mistake to assume that the number of bits in an int is variable (and that you therefore needed to compute a mask that covers "all bits"), I have some great news for you, because inverting all bits is a lot easier:
return ~num;
If you were reading "invert all bits" in the context of two's complement, it would have the above meaning, so all bits, including those left of the highest set bit.
I am new to bytes and bits and I'm also not very good in maths either. I kind of understand the bitwise operators, but I don't know how to solve math equations/formulas with 2 variables. I'm not sure this is the proper place to ask this but anyway.
I have an formula like this:
(Adr_MSB & 0x3F) << (8 + Adr_LSB)
Now what I want is that I would get an integer (for example 33) and the code would transform it into Adr_MSB and Adr_LSB (which are bytes).
It should work up to 128 (ok I guess it will be 127).
I know that this question might sound dumb or something, but I just don't know enough maths to solve this.
Thanks for all help.
EDIT: By experimenting I figured out, that Adr_MSB is a multiplier (e.g. if it's 10 the result is 10 times biger than if it's 1).
From what I understand
the (Adr_MSB & 0x3F) part of the takes the last six bits of the Adr_MSB and returns corresponding integer.
Eg: 125 (1111101) will return 61 (111101)
Note: This step is removing all bits other than last 6 bits, these bits are lost. Hence Lossless inverse function is not possible.
The (8 + Adr_LSB) just adds 8 to Adr_LSB.
<< is a bit wise Left Shift Operator.
Eg. 61 << 3 = 488 . Since 61 is 111101, adding three zeros to the right (Left Shifting three times) will give 111101000 which is 488.
Effective inverse of the expression (Adr_MSB & 0x3F) << (8 + Adr_LSB) to be applied to given number x
Take first six bits from x and convert it to int. This will be Adr_MSB.
Count the rest of the bits. Subtract 8 from this count and it will be Adr_LSB.
Does the following represent what you are looking for?
((Adr_MSB & 0x3F) << 8) | Adr_LSB
Would this work?
int x = 33;
byte Adr_MSB = (byte)x;
byte Adr_LSB = (byte)24;
System.out.println((Adr_MSB & 0x3F) << (8 + Adr_LSB));
Adr_LSB can also be -8.
Since you do bitwise AND on Adr_MSB and 111111, you have only six consecutive bits available to represent the number, so not all integers can be represented just by shifting those 6 bits. This solution works for x up to , so... you can argue that is not a good solution, but it is a start.
I have two related questions:
the bitwise operator >>> means that we are shifting the binary number by those many places while filling 0 in the Most Significant Bit. But, then why does the following operation yields the same number: 5>>>32 yields 5 and -5>>>32 yields -5. Because if the above description is correct then both these operations would have yielded 0 as the final result.
In continuation to above, As per Effective Java book, we should use (int) (f ^ (f >>> 32)) (in case the field is long) while calculating the hash code (if the field is long). Why do we do that and what's the explanation
5 can be represented as 0101 if you shift it by 1 bit i.e 5>>>1 this will result as 0010=2
If the promoted type of the left-hand operand is int, only the five
lowest-order bits of the right-hand operand are used as the shift
distance. It is as if the right-hand operand were subjected to a
bitwise logical AND operator & (ยง15.22.1) with the mask value 0x1f.
The shift distance actually used is therefore always in the range 0 to
31, inclusive.
When you shift an integer with the << or >> operator and the shift
distance is greater than or equal to 32, you take the shift distance
mod 32 (in other words, you mask off all but the low order 5 bits of
the shift distance). This can be very counterintuitive. For example (i> >> 32) == i, for every integer i. You might expect it to shift the entire number off to the right, returning 0 for positive inputs and -1
for negative inputs, but it doesn't; it simply returns i, because (i
<< (32 & 0x1f)) == (i << 0) == i.
Answer to your first question is here why is 1>>32 == 1?
The second question answer, in short, is that in such way the whole long value is used(not a part of it) and note that it is probably the fastest way to do this.
I know this question has been answered long back, but I tried an example to get more clarification and I guess it'll others too.
long x = 3231147483648l;
System.out.println(Long.toBinaryString(x));
System.out.println(Long.toBinaryString(x >>> 32));
System.out.println(Long.toBinaryString(x ^ (x >>> 32)));
System.out.println(Long.toBinaryString((int) x ^ (x >>> 32)));
This prints -
101111000001001111011001011110001000000000
1011110000
101111000001001111011001011110000011110000
1001111011001011110000011110000
As #avrilfanomar mentions, this XORs first 32 bits of long with the other 32 bits and unsigned right shift operator helps us in doing this. Since we want to use this long field while calculating the hashcode, directly casting the long to int would mean that long fields differing only in the upper 32 bits will contribute the same value to the hashcode. This potentially means that two objects differing only in this field will have same hashcode and it'll be stored in the same bucket (with say a list to resolve collision) and this impacts the performance of hash-based collections. Hence, this operation.
I have an int and I want to invert the bits of it using the ~ bit operator. This should be a very simply thing to do, however I tried and it doesn't work. I suppose this is because java uses two's complement to represent it's int. So what is the most efficient way to do this? 50 when inverted should be 13 and that's the value I'd like to have
It seems you want only the part of the bitwise complement until the most signifficant set bit of the input. Then you just have to mask the complement,
int invert(int n) {
return ~n & mask(n);
}
int mask(int n) {
n |= n >> 1;
n |= n >> 2;
n |= n >> 4;
n |= n >> 8;
return n | (n >> 16);
}
Java int is 32-bit long with 1 bit used for sign. Therefore 50 is represented in binary as 00000000000000000000000000110010. If you bit-invert this, you'll get 11111111111111111111111111001101, which is java integer value -51 in decimal notation.
Since an int should be at least 32 bits wide, ~50 is definitely not 13. I think you are assuming the int to be only 8 bits wide, which may have been the case some 237 years ago, but definitely not nowadays and not in Java, anyway. If you need a data type that is guaranteed to be 8 bits wide, use byte.
But even then ~50 is not 13, only if take the least significant 6 bits into account. But all this doesn't have anything to do with two's complement.
I have a program which works with genetic algorithms and generates an 8-bit binary string (chromosome consisting of eight genes).
I would like to know how I would go about changing / flipping the first gene/bit.
For example:
Original chromosome:
01010101
Changed chromosome:
11010101 //First bit has been changed
If the first bit has a value of 1, I would like to 'flip' it to make it a 0; and, obviously, if the first bit in the array/chromosome is a 0, I would like to 'flip' that to a 1.
Thank you.
You could use the following:
chromosome ^= 0x80;
The xor-assignment (^=) flips the chromosome bits that are set in the right-hand side expression, and 0x80 is 10000000 in binary.
More generally, to flip the k-th bit (with the least significant bit being bit 0):
chromosome ^= (1 << k);