How does Java convert int into byte?

How does Java convert int into byte?


int i =132;
byte b =(byte)i;
System.out.println(b);



The output is -124



Why is that? I know this is a very basic question, but I'm still not able to map it, or understand how this happens?




10 Answers
10



In Java, an int is 32 bits. A byte is 8 bits .


int


byte


bits



Most primitive types in Java are signed, and byte, short, int, and long are encoded in two's complement. (The char type is unsigned, and the concept of a sign is not applicable to boolean.)


byte


short


int


long


char


boolean



In this number scheme the most significant bit specifies the sign of the number. If more bits are needed, the most significant bit ("MSB") is simply copied to the new MSB.



So if you have byte 255: 11111111
and you want to represent it as an int (32 bits) you simply copy the 1 to the left 24 times.


255


11111111


int



Now, one way to read a negative two's complement number is to start with the least significant bit, move left until you find the first 1, then invert every bit afterwards. The resulting number is the positive version of that number



For example: 11111111 goes to 00000001 = -1. This is what Java will display as the value.


11111111


00000001


-1



What you probably want to do is know the unsigned value of the byte.



You can accomplish this with a bitmask that deletes everything but the least significant 8 bits. (0xff)



So:


byte signedByte = -1;
int unsignedByte = signedByte & (0xff);

System.out.println("Signed: " + signedByte + " Unsigned: " + unsignedByte);



Would print out: "Signed: -1 Unsigned: 255"


"Signed: -1 Unsigned: 255"



What's actually happening here?



We are using bitwise AND to mask all of the extraneous sign bits (the 1's to the left of the least significant 8 bits.)
When an int is converted into a byte, Java chops-off the left-most 24 bits


1111111111111111111111111010101
&
0000000000000000000000001111111
=
0000000000000000000000001010101



Since the 32nd bit is now the sign bit instead of the 8th bit (and we set the sign bit to 0 which is positive), the original 8 bits from the byte are read by Java as a positive value.





well done, the best explanation on this subject, Wayne! I'm just looking for the math formalization why in a two's complement representation the sign bit can be copied on the right in order to add bits. It's easy to understand it thinking to the rule of how to obtain the negative of a number. that is: consider all the bits from right to left and write them unchanged till the first 1 comprised. Then invert the subsequent bits. If i consider the missing bit to be 0s, it's easy to understand that they all go to 1. But i was looking for a more 'math' explanation.
– AgostinoX
Aug 22 '14 at 19:44






Whats hapenning here signedByte & (0xff) is that 0xff is an interger literal, thus signedByte gets promoted to an integer before the bitwise operation is performed.
– Kevin Wheeler
Nov 8 '14 at 23:40


signedByte & (0xff)


0xff



To understand how it works, we need to know that computers work in bits.



132 in base 10 (decimal) is 10000100 in base 2 (binary). Since Java stores int in 32 bits, what we have is


10000100


int



When an int is converted into a byte, Java chops-off the left-most 24 bits. What we get is 10000100.


int


byte


10000100



In two's complement, the left-most bit is used as the sign. If the left-most bit is 0, nothing further will be done.


0



If the left-most bit is 1 (as we have here), it means that the number is negative and more work needs to be done. To get the magnitude, we minus one then apply one's complement (apply one's complement means we invert the bits):


1



10000100 - 1 = 10000011


10000100


10000011



Invert 10000011 = 01111100


10000011


01111100



01111100 when interpreted as a decimal number, is 124.


01111100



So we have a negative number with a magnitude of 124, giving us -124.





Very nicely explained
– ZAJ
Aug 9 '16 at 7:16





So now 132 in decimal is -124 in byte. How does the reverse works ?
– Nilesh Deokar
May 14 at 12:51



byte in Java is signed, so it has a range -2^7 to 2^7-1 - ie, -128 to 127.
Since 132 is above 127, you end up wrapping around to 132-256=-124. That is, essentially 256 (2^8) is added or subtracted until it falls into range.



For more information, you may want to read up on two's complement.



132 is outside the range of a byte which is -128 to 127 (Byte.MIN_VALUE to Byte.MAX_VALUE)
Instead the top bit of the 8-bit value is treated as the signed which indicates it is negative in this case. So the number is 132 - 256 = -124.



often in books you will find the explanation of casting from int to byte as being performed by modulus division. this is not strictly correct as shown below
what actually happens is the 24 most significant bits from the binary value of the int number are discarded leaving confusion if the remaining leftmost bit is set which designates the number as negative


public class castingsample

public static void main(String args)

int i;
byte y;
i = 1024;
for(i = 1024; i > 0; i-- )

y = (byte)i;
System.out.print(i + " mod 128 = " + i%128 + " also ");
System.out.println(i + " cast to byte " + " = " + y);










I have never seen that in any book in 46 years.
– user207421
Jun 27 '17 at 1:59



here is a very mechanical method without the distracting theories:



This more practical method is in accordance to the much theoretical answers above. So, those still reading those Java books saying to use modulo, this is definitely wrong since the 4 steps I outlined above is definitely not a modulo operation.





What Java books saying to use 'modulo'? I've never seen any CS book stating that in 46 years, let alone any Java book. What 'modulo'? There is no modulo operation in Java. Only a remainder operator.
– user207421
Jun 27 '17 at 2:01



Two's complement Equation:



enter image description here



In Java, byte (N=8) and int (N=32) are represented by the 2s-complement shown above.


byte


int



From the equation, a7 is negative for byte but positive for int.


byte


int


coef: a7 a6 a5 a4 a3 a2 a1 a0
Binary: 1 0 0 0 0 1 0 0
----------------------------------------------
int: 128 + 0 + 0 + 0 + 0 + 4 + 0 + 0 = 132
byte: -128 + 0 + 0 + 0 + 0 + 4 + 0 + 0 = -124



A quick algorithm that simulates the way that it work is the following:


public int toByte(int number)
int tmp = number & 0xff
return (tmp & 0x80) == 0 ? tmp : tmp - 256;



How this work ? Look to daixtr answer. A implementation of exact algorithm discribed in his answer is the following:


public static int toByte(int number)
int tmp = number & 0xff;
if ((tmp & 0x80) == 0x80)
int bit = 1;
int mask = 0;
for(;;) right;
tmp = -(tmp & 0xff);
break;


return tmp;





You can't return from toByte() if it's declared a void function...
– John Perry
Sep 2 '17 at 19:48


toByte()


void





Fixed, thanks @JohnPerry
– Francisco Neto
Feb 11 at 22:17



Conceptually, repeated subtractions of 256 are made to your number, until it is in the range -128 to +127. So in your case, you start with 132, then end up with -124 in one step.



Computationally, this corresponds to extracting the 8 least significant bits from your original number. (And note that the most significant bit of these 8 becomes the sign bit.)



Note that in other languages this behaviour is not defined (e.g. C and C++).





To be clear, the result you get is the same as if repeated subtractions were done. In practice, the JVM does not actually do it this way. (It would be horribly inefficient!)
– Stephen C
Jul 13 '17 at 12:13





Indeed. I hope my second paragraph covers how the JVM actually does this. But I have fiddled with my language a little.
– Bathsheba
Jul 13 '17 at 12:14






Yes. The change of "essentially" to "conceptually" makes a huge difference!
– Stephen C
Jul 13 '17 at 12:17


N is input number
case 1: 0<=N<=127 answer=N;
case 2: 128<=N<=256 answer=N-256
case 3: N>256
temp1=N/256;
temp2=N-temp*256;
if temp2<=127 then answer=temp2;
else if temp2>=128 then answer=temp2-256;
case 4: negative number input
do same procedure.just change the sign of the solution





The correct answer is arrived at by bit-masking, not by division and remainder.
– user207421
Jun 27 '17 at 2:02






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

ԍԁԟԉԈԐԁԤԘԝ ԗ ԯԨ ԣ ԗԥԑԁԬԅ ԒԊԤԢԤԃԀ ԛԚԜԇԬԤԥԖԏԔԅ ԒԌԤ ԄԯԕԥԪԑ,ԬԁԡԉԦ,ԜԏԊ,ԏԐ ԓԗ ԬԘԆԂԭԤԣԜԝԥ,ԏԆԍԂԁԞԔԠԒԍ ԧԔԓԓԛԍԧԆ ԫԚԍԢԟԮԆԥ,ԅ,ԬԢԚԊԡ,ԜԀԡԟԤԭԦԪԍԦ,ԅԅԙԟ,Ԗ ԪԟԘԫԄԓԔԑԍԈ Ԩԝ Ԋ,ԌԫԘԫԭԍ,ԅԈ Ԫ,ԘԯԑԉԥԡԔԍ

How to change the default border color of fbox? [duplicate]

Henj