I need some help with bitwise operations.
I have number(64 bit) were first 16 bits are meaningful, and I'd like to set rest of them to "1"
00000000 11000001 00000000 00000000 ... <- currrent value
00000000 11000001 11111111 11111111 ... <- result I am trying to achieve
P.S. Oh, yeah! Sometimes, to solve - you just need to write out your task:)
I got it: value |= (-1 << bitsCount);
bitsCount - count of my meaningful bits
Use the bitwise OR operator:
value |= 0xFFFF
11111111111111112 = 216 - 1= FFFF16
OR it with 11111111 11111111. foo | 0xffff
Related
Referring to page number 79 of " Java The complete Reference" 7th edition by Herbert Schildt.
The author says : " If the integer’s value is larger than the range of a
byte, it will be reduced modulo (the remainder of an integer division by the) byte’s range".
The range of byte in java is -128 to 127. So the maximum value that fits in a byte is 128. If an integer value is assigned to a byte as shown below :
int i = 257;
byte b;
b = (byte) i;
Since 257 crosses the range 127, 257 % 127 = 3 should be stored in 'b'.
But am getting the output as 1 instead of 3.
Where have I gone wrong in understanding the concept?
Just consider the binary representation of the numbers :
257 is represented in binary as 00000000 00000000 00000001 00000001
When you cast this 32 bits int to an 8 bits byte, you keep only the lowest 8 bits :
00000001
which is 1
257 = 00000000 000000000 00000001 00000001 in bits and a byte is made up of 8 bits only...
As a result only the lower 8 bits are stored and 1 is the output.
This is the code I've tried:
int num = ~0;
System.out.print(num);
Output: -1
From what I understand, ~ inverts the bits. So, 0000 0000 would become 1111 1111. How is this -1? I realize that this is a very basic question that involves two's complement, but I'm not able to figure it out.
Because -1 is represented as all ones.
System.out.println(Integer.toBinaryString(-1));
Output is
11111111111111111111111111111111
numbers are reprezented in 32 bit format.
To understand why it shows up as all 1 and then get converted to -1.
Reason:
~0 = ~(00000000 00000000 00000000 00000000) = (11111111 11111111 11111111 11111111) = -1
To understand more, please read this thread: How does the bitwise complement (~) operator work?
1111 1111 is in fact -1 and 1111 1110 is -2. Such is life, not sure how else to put it
I'm trying to solve this problem: I have a byte value (1 byte) and I need to transform this value into a long value (8 bytes). But what I want is just replace the first byte of the long variable with the byte value I had before.
A example:
My Byte Value: 11001101
My Long Value: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
What I want: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 11001101
Simple as that!
I'm trying to do this (example):
byte b = -112;
long l = 0;
l = l | b;
System.out.println(l);
But I get the result -112! In my understanding, the java bit or operator should do an "or" with the first byte of the long value and the byte value. Instead, the or operator is copying the 2-complement representation of the byte value into the long value, and this is not what I want.
The result I was expecting in that case was 144, since -112 is 10010000, which is 144 when considering a unsigned value.
Hope you understand me. Thanks!
What happens here is that b is cast to long, and this is done via sign extension: the most-significant bit (1) is repeated, hence 7 11111111 bytes are used as padding. The remedy here is to explicitly consider only the 8 least-significant bits in the resulting value, using a bitwise and (&):
l = l | ((long)b & 0xff);
Java promotes the signed byte to a signed long before doing math operations, and that sign extends the byte.
To fix it, you can do this:
l = l | (0xFF & (long)b))
or
l |= 0xFF & (long)b
(This works because 0xFF is a positive int value. If it was a byte, it'd also get sign extended to a negative long.) (Casting b to an int here would work as well as casting to a long.)
I was wondering the meaning of "Bitwise Shifting". Currently I am trying to create Image Filters in Java using BufferedImage. I found some good answers on how to access the RGB values individually in other posts but wasnt exactly sure on how it works. I understand the RGB values are stored in a 32-bit int each 8-bit part representing the value.
This is what I was looking at: a link
Basically looking for someone to explain this process, the Google searches Ive done were too technical.
When you have a single integer that contains multiple bytes of information, then masking and shifting are the processes used to access the individual pieces. Assuming the bytes are stored like such (they probably aren't, but...) then this is what you could do to retrieve them:
aRGB: 255, 65, 33, 17
binary: 11111111 01000001 00100001 00010001
To retrieve the red value (65) from a variable x:
x && 0x00FF0000
11111111 01000001 00100001 00010001
* 00000000 11111111 00000000 00000000
-------------------------------------
00000000 01000001 00000000 00000000
Then the shifting operation, to move the bits to where they make sense as a lone value:
00000000 01000001 00000000 00000000 >> 16 = 00000000 00000000 00000000 01000001
The binary mask captures only the second byte of the value, by setting all the other bits to 0; only the bits that match the second byte remain as they are (multiplied by 1, not 0). Then, you shift the bits to the right 16 places, to strip off those extra 0's. Obviously, the leading 0's no longer matter, so the result is just a plain binary 01000001, or decimal 65.
It is technical in nature. You store a value 0 - 255, or in binary:
from
00000000
to
11111111
then you take a larger container like this one:
0000000000000000
and insert it there so if your color is 117
0000000001110101
and shift it to the left one byte so you get
0111010100000000
then you add the second color, say it 65 or 01000001 and get
0111010101000001
then you again shift it one byte to the left and get
011101010100000100000000
at last you add the third color and its for example a 255 or 11111111 you get
011101010100000111111111
so you have stored three values 0 - 255 via bitshift.
There is more than one way to think about a pattern of bits in memory. Usually, we think of the bits stored in an integer as representing a single number. The higher-order bits contribute greater value than the lower-order bits and their values are summed to arrive at a single number, so the following pattern:
00001101 00110000 00000111
Would be interpreted as:
2^0 + 2^1 + 2^3 + 2^13 + 2^14 + 2^15 + 2^17 + 2^18 = 864,263
But we're free to think of this pattern as three individual groups of 8-bit numbers (each representing the numeric value of a color component). However, to convert a bit pattern in the higher-order bits into the number we intend it to represent, we need to interpret those bits as though they appeared in the rightmost 8-bit group. This is why we shift.
For example, to get the value of the leftmost 8-bit group, we need to mask all bits not in that group, and then shift those bits 16 places to the right, so that they occupy the rightmost position:
// first, assume n = 00001101 00110000 00000111
(n & 0xFF0000) >> 16 // red
Zeros are automatically shifted into the vacated bits, leaving:
00000000 00000000 00001101
Which we can now interpret as:
13
Similarly, we can calculate the value of the bits in the center and rightmost groups:
(n & 0x00FF00) >> 8 // green
n & 0x0000FF // blue (no shift necessary)
Setting the value of one of these components requires shifting in the other direction. For example, the following shifts 75 into the center 8-bit position:
n = (n & (0xFF00FF)) | (75 << 8)
We're first resetting the green value (with the 0xFF00FF mask) and then shifting the number 75 8 bits to the left. Finally, we combine these two numbers.
We can see that this works by shifting it back out again:
(n & 0x00FF00) >> 8 // => 75
Resetting or maximizing one of the components is even simpler. As we've seen in the earlier example, zero-ing a component can be done like this:
n = n & 0xFF00FF // clear out green
The following mask, on the other hand, maximizes the value of the green component:
n = n | 0x00FF00
Bitwise operations are operations on the bits of the binary representation of the data rather than the data represented as an integer or floating point number. For example, 8 may be represented as 1000 in binary. Shifting it to the right twice moves all the digits to the right by 3, padding with 0's, resulting in 0010, or 2.
For more, see the Wikipedia article.
Are hexadecimal numbers ever negative? If yes then how?
For binary you would have signed and unsigned.
How would one represent them in Hex? I need this for a hex routine I am about to embark upon.
Yes. For example you'd have the following representations in signed 32-bit binary and hex:
Decimal: 1
Binary: 00000000 00000000 00000000 00000001
Hex: 00 00 00 01
Decimal: -1
Binary: 11111111 11111111 11111111 11111111
Hex: FF FF FF FF
Decimal: -2
Binary: 11111111 11111111 11111111 11111110
Hex: FF FF FF FE
As you can see, the Hex representation of negative numbers is directly related to the binary representation.
The high bit of a number determines if it is negative. So for instance an int is 32 bits long, so if bit 31 is a 1 it is negative. Now how you display that value be it hexadecimal or decimal doesn't matter. so the hex values like
0x80000000
0x91345232
0xA3432032
0xBFF32042
0xC33252DD
0xE772341F
0xFFFFFFFF
are all negative, because the top bit is set to 1
|
v
0x8 -> 1000
0x9 -> 1001
0xA -> 1010
0xB -> 1011
0xC -> 1100
0xD -> 1101
0xE -> 1110
0xF -> 1111
Yes they can be. It's the same as binary as to how you interpret it (signed vs unsigned).
You would take the binary signed and unsigned forms then represent them in hex as you would any binary number.
On one hand, why not - it's just a positional numeric system, like decimal.
On the other hand, they normally use hex notation to deduce the underlying bit pattern - and that is much more straightforward if the number is interpreted as unsigned.
So the answer is - it's possible, mathematically correct and internally consistent, but defeats the most common purpose of hex notation.
In Java, these are the bounds of the Integer data type:
Integer.MIN_VALUE = 0x80000000;
Integer.MAX_VALUE = 0x7fffffff;