Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm wondering about this part of a code (it's an IP mask code)
int mask = 0xffffffff << (32 - prefix);
System.out.println("Prefix=" + prefix);
System.out.println("Address=" + ip);
int value = mask;
byte[] bytes = new byte[]{
(byte)(value >>> 24), (byte)(value >> 16 & 0xff),
(byte)(value >> 8 & 0xff),
(byte)(value & 0xff) };
try {
InetAddress netAddr = InetAddress.getByAddress(bytes);
System.out.println("Mask=" + netAddr.getHostAddress());
<< is the Left Shift operator. >> is the Right Shift operator. You can read about bit shifting in Java here.
0xffffffff is an hexadecimal number.
These are hexadecimal numbers and bitwise operations.
Hexadecimal numbers use a number system with radix 16. Thus 0xffff means:
(((15*16+15)*16+15)*16+15)*16+15=65'535
This is mainly useful because a nibble (one hexadecimal digit), maps exactly on four bits. Since F is 1111 in binary, 0xffff means 1111 1111 1111 1111 (or the last 16 bits are one).
<< and >> are bitwise arithmetic shifts. If you specify 0xffff<<8, it means you shift the number eight bits to the left thus:
1111 1111 1111 1111 ff ff ff ff
<< 8 << 8
------------------------ --------------
1111 1111 1111 1111 0000 ff ff ff ff 00
>> is a shift in the opposite direction, but the highest bit also determines the value of the new bits at the left. In case the left bits should be zero, you need to use the logical right shift (>>>).
Other bitwise operations include |, &, ~ and ^ (not to be confused with &&, ||, etc.).
Related
I was going through a java file and saw this block of code and can't really understand what's happening here. What does the & symbol means here and when I run this, I get the values 2 and 8 respectively.
package com.company;
public class Question_2 {
public static void main(String[] args) {
int mask = 0x000F;
int value = 0x2222;
int f = 90;
int h = 9;
System.out.println(value & mask);
System.out.println(f & h);
}
}
This is The output I get:
2
8
& is a bit wise operation
& is 1 if both bit at the same position is 1 otherwise 0
Also, to perform this operation, your operands will be converted to base 2
90 = 0101 1010 in base 2
09 = 0000 1001 in base 2
_________
0000 1000 which is 8 convert to decimal
000f in hexadecimal = 0000 0000 0000 1111
2222 in hexadecimal = 0010 0010 0010 0010
using & on this is 0000 0000 0000 0010 which is 2 convert to decimal
That is how basic & operator works.
& refers to Bitwise AND operation.
the mask variable used to enable specific bit and disable the others.
in this code,
System.out.println(value & mask);
the mask keeps the first (from right to left) 4 bits and unsets the others, so always the value of the bitwise AND between the mask variable and any value will be less than 15 because 0x000F -> 0000 0000 0000 1111
mathematically: since the mask is 0x000F if the value of & between the mask and any value is zero then the number is dividable by 16 otherwise it's not dividable by 16
& is the bitwise AND operation.
System.out.println(value & mask);
outputs the hex representation of bitwise ANS.
System.out.println(f & h);
outputs the decimal representation of the bitwise AND.
& is smart enough to return the result of the same representation as it's arguments.
& is used as a relational operator to check a conditional statement just like && operator.
but there is a small change in how & takes care of conditional statement. && would first check the first data, if its true then it checks the next one and son on.. but in case of single & character, it just evaluate all conditions even if previous one is a failed one. Thus, any change in the data values due to the conditions will only be reflected in this case.
& can also be used as bitwise operator
println(f & h ) ->
01011010
& 00001001
00001000 -> 8 in decimal
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I am having a hard time converting this ActionScript code to C#. I don't understand how I can mimic what ByteArray() is doing in C#. If anyone could help me recreate this functionality I would really appreciate it.
ActionScript (seed is a uint.):
//Start by reversing the byte order of the seed
var ba:ByteArray = new ByteArray();
ba.endian = Endian.BIG_ENDIAN;
ba.writeInt(seed);
ba.position = 0;
ba.endian = Endian.LITTLE_ENDIAN;
seed = ba.readInt();
You can use BitConverter.GetBytes(UInt32) to get your byte[], then call Array.Reverse on the array, then use BitConverter.ToUInt32(byte[]) to get your int back out.
Edit
Here's a more efficient and cryptic way to do it:
public static UInt32 ReverseBytes(UInt32 value)
{
return (value & 0x000000FFU) << 24 | (value & 0x0000FF00U) << 8 |
(value & 0x00FF0000U) >> 8 | (value & 0xFF000000U) >> 24;
}
This is what you need to know to understand what's happening here:
A UInt32 is 4 bytes.
In hex, two characters represent one byte. 179 in decimal == B3 in hex == 10110011 in binary.
A bitwise and (&) preserves the bits that are set in both inputs: 1011 0011 & 1111 0000 = 1011 0000; in hex: B3 & F0 = B0.
A bitwise or (|) preserves the bits that are set in either input: 1111 0000 | 0000 1111 = 1111 1111; in hex, F0 | 0F = FF.
The bitwise shift operators (<< and >>) move the bits left or right in a value. So 0011 1100 << 2 = 1111 0000, and 1100 0011 << 4 = 0011 0000.
So value & 0x000000FFU returns a UInt32 with all but the 4th byte set to 0. Then << 24 moves that 4th byte to the left 24 places, making it the 1st byte. Then (value & 0x0000FF00U) << 8 zeros out everything but the 3rd byte and shifts it left so it is the second byte. And so on. The four (x & y) << z create four UInt32s where each of the bytes have been moved to the place they will be in the reversed value. Finally, the | combines those UIntt32s bytes back together into a single value.
I have something like this:
byte[0] = 0001 0100 0011 0100 (dec value: 5172)
byte[1] = 0000 0000 0111 1100 (dec value: 124)
byte[2] = 0000 0000 0000 0000 (dec value: 0)
byte[3] = 0000 0000 0000 0000 (dec value: 0)
I would like to combine them and make one long value in Java. How to do that?
Can it be converted on this way?
result = 0 + (0 x 2^16) + (0 x 2^16) + (124 x 2^32) + (5127 x 2^48)
ie.
result = byte[3] + (byte[2] x 2^16) + (byte[1] x 2^32) + (byte[0] x 2^48)
Edit: Let me try to explain better. When I open tool ModScan32 and connect to my device I see some registers. In this tool there are different kind of options how to show data. One of them are to represent them as binary or decimal. When I choose binary or decimal I get values as they are in my example above. When I read this data with my software I get exactly the same (converted values) in the decimal. Now my question is if it is necessary to hold data in 4 16 bit registers and i know their decimal values what is the proper way to combine those values from registers and get real value?
Your idea is basically OK. There are a few things to be aware of.
I believe the result you are after in your case is 0001010000110100000000000111110000000000000000000000000000000000.
Here’s an attempt that does not work:
int[] registers = { 5172, 124, 0, 0 };
long result = registers[0] << 48 | registers[1] << 32 | registers[2] << 16 | registers[3];
System.out.println(Long.toBinaryString(result));
<< 48 means shift 48 bits to the left, that should be good enough, right? | is a bitwise logical or, it fills the 1 bits from either operand into the same bit posistion of the result. You could use + instead if you preferred.
This prints:
10100001101000000000001111100
We only have the first 32 bits of the result, that’s not good enough. When trying to read it, note that Long.toBinaryString() does not include leading zeroes. Just imagine 3 zeroes in front of the number.
But what went worng? Where did the last 32 bits go? Even when they were all zeroes. The problem is that we are doing the calculation in ints, they are 32 bits, not 64. EDIT: My previous explanation was not entirely correct on this point. The truth is: When doing << on an int, only the last 5 bits of the right operand are considered, so since 48 is 110000 in binary, only 10000 is used, so the shift is the same as << 16. Similarly << 32 is the same as << 0, no shift at all. So registers[0] and [1] have ended up in the wrong bit posistion. The solution is easy when you know it: we need to convert to long before doing the calculation. Now the last 6 bits of the right operand are used, so 48 and 32 are understood as 48 and 32:
long result = ((long) registers[0]) << 48 | ((long) registers[1]) << 32 | registers[2] << 16 | registers[3];
This time we get
1010000110100000000000111110000000000000000000000000000000000
Again, imagine 3 zero bits in front and all is as expected.
There is one more thing. Say you got a negative value from a register, for example:
int[] registers = { 5172, -124, 0, 0 };
The calculation that just worked now gives us
1111111111111111111111111000010000000000000000000000000000000000
This time there are 64 bits printed, so it’s easy to see there are too many 1s in the beginning. They come from the int representation of -124. The solution is to mask them out:
int[] registers = { 5172, -124, 0, 0 };
long result = ((long) registers[0] & 0xFFFF) << 48
| ((long) registers[1] & 0xFFFF) << 32
| (registers[2] & 0xFFFF) << 16
| (registers[3] & 0xFFFF);
System.out.println(Long.toBinaryString(result));
0xFFFF is 16 1 bits, and & is the bitwise logical ‘and’, giving a 1 bit in the result only in positions where both operands have a 1 bit. Now -124 gets masked to 1111111110000100 so the result is the expected:
1010000110100111111111000010000000000000000000000000000000000
That should do it.
So I was reading the example source code from this Android page on ViewGroups,
and I came across these lines:
// Report our final dimensions.
setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),
resolveSizeAndState(maxHeight, heightMeasureSpec,
childState << MEASURED_HEIGHT_STATE_SHIFT));
So I hope to learn:
What does the << operator exactly do in Java?
What is happening in last line of the aforementioned snippet?
Thanks.
It isn't an operand, it is an operator. A bit-wise shift operator, to be exact.
Given x and y as operands, x << y shifts the bits of the x value y bits to the left. It is basically the same as multiplying by 2 to the power y.
<< is one of bit shifting operator.
It is quite offen we use higher 16 bits of one single 32 bits int for one thing and lower 16 bits of another thing.
childState << MEASURED_HEIGHT_STATE_SHIFT means childState is passing a height (in its lower 16 bits) which is expecting to be in higher 16 bits of the int passing to resolveSizeAndState().
What does the << operator exactly do in Java?
It's moving bits to the left. As mentioned in previous answers:
1111 1110 << 2
1111 1000 // Have added 0 from right
What is happening in last line of the aforementioned snippet?
Code is changing state. It's sometimes used to represent states. e.g.
state1 = 1 << 0;
state2 = 1 << 1;
state3 = 1 << 2;
so you have 3 unique states.
"<<" is a bit operator.
I quote the explaination from tutorial for Java
The signed left shift operator "<<" shifts a bit pattern to the left, and the signed right shift operator ">>" shifts a bit pattern to the right.
And also I quote an example from here
int a = 60; /* 60 = 0011 1100 */
int c = 0;
c = a << 2; /* 240 = 1111 0000 */
so you can see a << n is almost a*(2^n)
This is Bitwise and Bit Shift Operators. More info can be found at http://docs.oracle.com/javase/tutorial/java/nutsandbolts/opsummary.html
For Ex:
1111 1110 << 2
1111 1000 // Have added 0 from right
0001 1111 >> 3
0000 0011 // Will preserve MSB and shift it right
If you don't want the first bit to be preserved, you use (in Java, Scala, C++, C afaik, and maybe more) a triple-sign-operator:
1100 1100 >>> 1
0110 0110
This question already has answers here:
Why does Java mask shift operands with 0x1F?
(2 answers)
Closed 9 years ago.
How does the shift operator << work when the value of the shift bits is greater than the total number of bits for the datatype?
For example,
int i = 2;
int j = i<<34;
System.out.println(j);
The size of an integer is 32 bits, however we are shifting 34 bits. How does this work?
I'm not sure the source on this, but according to WikiPedia (emphasis mine):
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 & with the mask value 0x1f (0b11111).[4]
The shift distance actually used is therefore always in the range 0 to
31, inclusive.
Edit: It looks like the WikiPedia entry basically lifted the information straight out of the Java Specification.
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.
Getting back to your original problem, (i << 33) == (i << (33 & 0x1f))
== (i << 1). You can do the whole thing in binary if you like. 270 in binary is : 0000 0000 0000 0000 0000 0001 0000 1110 Shifting right by 1,
you get: 0000 0000 0000 0000 0000 0000 1000 0111 which is 135.
But a better way to do this problem in your head is to dispense with the binary entirely.
The value of i >> s is floor(i / 2<sup>s</sup>) (where s has already been masked off so it's less than 32). So, 270 << 1 = floor(270/2) = 135.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19
If you try 1 << 34, you end up with 4. The runtime basically has an implicit mod NUMBER_OF_BITS on the right-hand operand of the shift. In the previous example, it's 1 << (34 % 32), which becomes 1 << 2, which is 4.