130
int i =132;

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

Mindboggling. Why is the output -124?

Pacerier
  • 86,231
  • 106
  • 366
  • 634
harshit
  • 7,925
  • 23
  • 70
  • 97

12 Answers12

175

In Java, an int is 32 bits. A byte is 8 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.)

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.

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.

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"

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.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
Wayne
  • 4,094
  • 4
  • 21
  • 11
  • 1
    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 08 '14 at 23:40
  • That's not 0xFF, it's 0x7E in your example! – JohnyTex Oct 11 '18 at 14:42
90

132 in digits (base 10) is 1000_0100 in bits (base 2) and Java stores int in 32 bits:

0000_0000_0000_0000_0000_0000_1000_0100

Algorithm for int-to-byte is left-truncate; Algorithm for System.out.println is two's-complement (Two's-complement is if leftmost bit is 1, interpret as negative one's-complement (invert bits) minus-one.); Thus System.out.println(int-to-byte( )) is:

  • interpret-as( if-leftmost-bit-is-1[ negative(invert-bits(minus-one(] left-truncate(0000_0000_0000_0000_0000_0000_1000_0100) [)))] )
  • =interpret-as( if-leftmost-bit-is-1[ negative(invert-bits(minus-one(] 1000_0100 [)))] )
  • =interpret-as(negative(invert-bits(minus-one(1000_0100))))
  • =interpret-as(negative(invert-bits(1000_0011)))
  • =interpret-as(negative(0111_1100))
  • =interpret-as(negative(124))
  • =interpret-as(-124)
  • =-124   Tada!!!
Pacerier
  • 86,231
  • 106
  • 366
  • 634
  • 7
    Very nicely explained – ZAJ Aug 09 '16 at 07:16
  • 1
    So now 132 in decimal is -124 in byte. How does the reverse works ? – Nilesh Deokar May 14 '18 at 12:51
  • @NileshDeokar, The reverse is by POLA since they fit (; cf [JLS 5.1.2](https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2)); output coincides with sign-leftpad (`0` for positive and `1` for negative). – Pacerier May 28 '19 at 23:56
  • What is POLA? The convertion from `int` to a `byte` is a lossy convertion (ie information is lost). Therefore, there is no way to convert it back into its original `int` value. – daparic Jan 06 '20 at 14:30
23

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.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
16

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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
6

here is a very mechanical method without the distracting theories:

  1. Convert the number into binary representation (use a calculator ok?)
  2. Only copy the rightmost 8 bits (LSB) and discard the rest.
  3. From the result of step#2, if the leftmost bit is 0, then use a calculator to convert the number to decimal. This is your answer.
  4. Else (if the leftmost bit is 1) your answer is negative. Leave all rightmost zeros and the first non-zero bit unchanged. And reversed the rest, that is, replace 1's by 0's and 0's by 1's. Then use a calculator to convert to decimal and append a negative sign to indicate the value is negative.

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.

daparic
  • 3,794
  • 2
  • 36
  • 38
  • *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 02:01
  • grep harder. `http://iiti.ac.in/people/~tanimad/JavaTheCompleteReference.pdf` page 59 – daparic Jan 06 '20 at 14:05
  • grep harder at page 63 here [https://github.com/ontiyonke/book-1/blob/master/%5BJAVA%5D%5BThe%20Complete%20Reference%20Java%20Ninth%20Edition%5D.pdf] – daparic Dec 18 '20 at 06:35
4

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.

From the equation, a7 is negative for byte but positive for 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
user207421
  • 305,947
  • 44
  • 307
  • 483
bcorso
  • 45,608
  • 10
  • 63
  • 75
2

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);

    }

}

}
ironwood
  • 8,936
  • 15
  • 65
  • 114
pen
  • 37
  • 2
2

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(;;) {
            mask |= bit;
            if ((tmp & bit) == 0) {
                bit <<=1;
                continue;
            }
            int left = tmp & (~mask);
            int right = tmp & mask;
            left = ~left;
            left &= (~mask);
            tmp = left | right;
            tmp = -(tmp & 0xff);
            break;
        }
    }
    return tmp;
}
1

If you want to understand this mathematically, like how this works

so basically numbers b/w -128 to 127 will be written same as their decimal value, above that its (your number - 256).

eg. 132, the answer will be 132 - 256 = - 124 i.e.

256 + your answer in the number 256 + (-124) is 132

Another Example

double a = 295.04;
int b = 300;
byte c = (byte) a;
byte d = (byte) b; System.out.println(c + " " + d);

the Output will be 39 44

(295 - 256) (300 - 256)

NOTE: it won't consider numbers after the decimal.

0

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++).

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • 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
  • 1
    Yes. The change of "essentially" to "conceptually" makes a huge difference! – Stephen C Jul 13 '17 at 12:17
0
  1. In java int takes 4 bytes=4x8=32 bits
  2. byte = 8 bits range=-128 to 127

converting 'int' into 'byte' is like fitting big object into small box

if sign in -ve takes 2's complement

example 1: let number be 130

step 1:130 interms of bits =1000 0010

step 2:condider 1st 7 bits and 8th bit is sign(1=-ve and =+ve)

step 3:convert 1st 7 bits to 2's compliment

            000 0010   
          -------------
            111 1101
       add         1
          -------------
            111 1110 =126

step 4:8th bit is "1" hence the sign is -ve

step 5:byte of 130=-126

Example2: let number be 500

step 1:500 interms of bits 0001 1111 0100

step 2:consider 1st 7 bits =111 0100

step 3: the remained bits are '11' gives -ve sign

step 4: take 2's compliment

        111 0100
      -------------
        000 1011 
    add        1
      -------------
        000 1100 =12

step 5:byte of 500=-12

example 3: number=300

 300=1 0010 1100

 1st 7 bits =010 1100

 remaining bit is '0' sign =+ve need not take 2's compliment for +ve sign

 hence 010 1100 =44

 byte(300) =44
Yashu
  • 1
  • 1
-1
 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