This question already has answers here:
2's complement hex number to decimal in java
(3 answers)
Closed 9 years ago.
I know that converting a decimal to binary with Integer.toBinaryString(355) = 0000000101100011 and
Integer.toBinaryString(-355) = 1111111010011101 (where I take the lower 16 bits of the 32 bit result).
What I would like to do is the other way and take a 16-bit twos's complement binary string and to convert to decimal.
i.e.
0000000000110010 = 50
1111111111001110 = -50
Rather than 1111111111001110 = 65486
How would I do this?
You need to read the result into short.
short res = (short)Integer.parseInt("1111111111001110", 2);
System.out.println(res);
This prints -50.
Use a short? They occupy 16 bits.
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
Related
This question already has answers here:
Set specific bit in byte
(5 answers)
Closed 11 months ago.
I have a byte for example:
"10000110" which is 97 in decimal.
I don't know the correct ordering, some places it is written "01100001", the point is that I'm speaking about the decimal number 97 which is stored in a single byte in our app.
We don't need bigger numbers than 100 in our app in this place of data and we would like to store an additional boolean data in the last (8th) bit in the corresponding byte, so..
I would like to write a 0 in the 8th bit after I've read that bit for the boolean information.
So this way I will have my boolean data from the 8th bit, and after that I can write the 8th bit to zero, so I can read my byte to get the decimal number. (because we only use values from 0-100 the last bit should always be zero.)
I don't know if it is clear enough, please let me know if you have any questions.
So in short, my question is:
How could I write a 0 to the last bit of a byte in Java?
97 decimal is 61 (hexadecimal) or 1100001 (binary)
If you want to use the high-order bit (10000000 binary or 80 hex) to store other information, you can do this as follows:
byte b = 97;
// Set the high-order bit to 1
byte c = b | 0x80;
// Determine if the high-order bit is set or not
boolean bitIsSet = (c & 0x80) != 0;
// clear the high-order bit (remove the high-order bit to get the value)
byte d = c & 0x7F;
I hope this is clear and answers your question.
This question already has answers here:
Understanding Java data types
(2 answers)
How to represent 11111111 as a byte in java
(2 answers)
JAVA: why binary literal for byte with negative sign is being considered as integer type?
(5 answers)
Closed 1 year ago.
byte b = 0b1111_1111;
byte c = 0b111_1111;
byte d = 0b0111_1111;
The first line causes a compilation error: incompatible types. I also tried 0xFF and decimal, the same. Thanks.
And I think byte means cannot be larger than what 8 bits hold. 0b1111_1111 is 8 bits.
All basic integer types in Java are signed. To be exact, byte, short, int and long are signed big endian two complement integers. That means that they run from - 2n-1 to 2n-1 - 1 where n is the number of bits - 8 for a byte (Byte.SIZE in Java), and therefore the range is from -128 to 127.
The number you are using is always an integer; number literals always are. However, the integer is actually the value 0x000000FF in hexadecimals. That cannot be stored as it is higher than 127. You can however do an explicit conversion; your value does consist of 8 bits after all.
byte b = (byte) 0b1111_1111
works because it simply disregards the 24 bits from the left hand side of the value. Now if you print it you will get -1 as value though as 0b1111_1111 represents 1 in 8 bit two complement form.
If you need it to represent the integer value 255 then you need to perform the following little trick:
int i = b & 0xFF;
which will actually do the following:
First it will convert b to the value 0xFFFFFFFF as integer using sign extension as all calculations default to integer, and it still thinks that b represents -1 after all.
Then it performs a bitwise AND with the value 0x000000FF (which is called a "mask"), resulting of course in the same value 0x000000FF which represents 255.
If you think this is a nuisance then you are right. Java should have used unsigned bytes, but it decided to use only one particular integer type that is signed. Maybe a bit overzealous but still a big improvement over e.g. C where you have way too many integer formats, and each of them may be represented differently on various machines.
This question already has an answer here:
Understanding narrowing primitive conversion
(1 answer)
Closed 1 year ago.
Integer Wrapper class
Integer obj = new Integer("1000");
System.out.println(obj.byteValue( )); //-24
I am not able to understand that how this output is formed. I want to understand how this "1000" in an integer is converted into "-24" in a byte. I want to know about the logic behind this.
The docs say:
Returns the value of this Integer as a byte after a narrowing primitive conversion.
which isn't particularly helpful if you don't know what a "narrowing primitive conversion" is. Well, you can look into the Java Language Specification (section 5.1.3) for the definition of that:
A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T.
The Integer 1000 is represented by 32 bits:
00000000 00000000 00000011 11101000
byte is 8 bits, so we discard all but the 8 lowest order bits, we get:
11101000
which is -24 in 8-bit two's complement binary. -24 = -128 + 64 + 32 + 8
Casting an integer to a byte will give the last 8 bits of of the integer.
1000 in decimal -> 1111101000 in binary
Converting this to a byte value gives you 11101000 which is -24.
This question already has answers here:
Why are integer literals with leading zeroes interpreted strangely?
(8 answers)
Closed 6 years ago.
I just wanted to experiment with some integers and assigned the value "0013" to an integer a. When I print the value to the output console I get "11". What causes this? Why I do not get 13 ?
int b = 0013;
System.out.println(b);
A leading zero mean octal. Just like a leading 0x mean hexadecimal
Java has accidentally automatically taken your number to be an octal number. Unlike hexadecimal notation, where the number is preceded by a 0x, octal is proceeded by a single zero. The compiler has probably taken your number and made it into an octal format.
Try using 13 instead of 0013
This question already has an answer here:
Promotion of byte to int or long
(1 answer)
Closed 7 years ago.
I have the following code:
int i =128;
byte b = (byte) i;
System.out.println( Integer.toBinaryString(i)); //10000000
System.out.println( Integer.toBinaryString(b)); //11111111111111111111111110000000
could someone explain why 1's were added to the left when casting from Integer to Byte and how could a byte carry more than 8 bits !?
You are calling .toBinaryString on the Integer class, so your number is treated as an Integer in any case.
The reason the second call has so many 1 is because it is a negative number. In Java, bytes are signed, so the maximum positive value is 127. By casting 128 into a byte you are actually representing -128. When you cast that small negative number into an 32 bit signed integer as you were doing, all those 1s appear at the beginning.