Signed versus Unsigned Integers

30

Solution 1

Unsigned can hold a larger positive value and no negative value.

Yes.

Unsigned uses the leading bit as a part of the value, while the signed version uses the left-most-bit to identify if the number is positive or negative.

There are different ways of representing signed integers. The easiest to visualise is to use the leftmost bit as a flag (sign and magnitude), but more common is two's complement. Both are in use in most modern microprocessors — floating point uses sign and magnitude, while integer arithmetic uses two's complement.

Signed integers can hold both positive and negative numbers.

Yes.

Solution 2

I'll go into differences at the hardware level, on x86. This is mostly irrelevant unless you're writing a compiler or using assembly language. But it's nice to know.

Firstly, x86 has native support for the two's complement representation of signed numbers. You can use other representations but this would require more instructions and generally be a waste of processor time.

What do I mean by "native support"? Basically I mean that there are a set of instructions you use for unsigned numbers and another set that you use for signed numbers. Unsigned numbers can sit in the same registers as signed numbers, and indeed you can mix signed and unsigned instructions without worrying the processor. It's up to the compiler (or assembly programmer) to keep track of whether a number is signed or not, and use the appropriate instructions.

Firstly, two's complement numbers have the property that addition and subtraction is just the same as for unsigned numbers. It makes no difference whether the numbers are positive or negative. (So you just go ahead and ADD and SUB your numbers without a worry.)

The differences start to show when it comes to comparisons. x86 has a simple way of differentiating them: above/below indicates an unsigned comparison and greater/less than indicates a signed comparison. (E.g. JAE means "Jump if above or equal" and is unsigned.)

There are also two sets of multiplication and division instructions to deal with signed and unsigned integers.

Lastly: if you want to check for, say, overflow, you would do it differently for signed and for unsigned numbers.

Solution 3

He only asked about signed and unsigned. Don't know why people are adding extra stuff in this. Let me tell you the answer.

  1. Unsigned: It consists of only non-negative values i.e 0 to 255.

  2. Signed: It consist of both negative and positive values but in different formats like

    • 0 to +127
    • -1 to -128

And this explanation is about the 8-bit number system.

Solution 4

According to what we learned in class, signed integers can represent both positive and negative numbers, while unsigned integers are only non-negative.

For example, looking at an 8-bit number:

unsigned values 0 to 255

signed values range from -128 to 127

Solution 5

Just a few points for completeness:

  • this answer is discussing only integer representations. There may be other answers for floating point;

  • the representation of a negative number can vary. The most common (by far - it's nearly universal today) in use today is two's complement. Other representations include one's complement (quite rare) and signed magnitude (vanishingly rare - probably only used on museum pieces) which is simply using the high bit as a sign indicator with the remain bits representing the absolute value of the number.

  • When using two's complement, the variable can represent a larger range (by one) of negative numbers than positive numbers. This is because zero is included in the 'positive' numbers (since the sign bit is not set for zero), but not the negative numbers. This means that the absolute value of the smallest negative number cannot be represented.

  • when using one's complement or signed magnitude you can have zero represented as either a positive or negative number (which is one of a couple of reasons these representations aren't typically used).

Share:
30
james0
Author by

james0

Updated on July 08, 2022

Comments

  • james0
    james0 almost 2 years

    I am having some trouble with javascript event handling. In my application I have an event which makes external xml requests and gives a responce to my event listener. This is allowed to happen many times to the same event listener. My event listener is repeating functions for old copies of my event and repeating all of my functions on each of them. Here is my code:

        document.addEventListener("data", getRemoteDataEvent, false);
    
        function getRemoteDataEvent(event){
        console.log(event);
        if(event.success===false){
            console.log(event);
            alert("error obtaining remote data");
        } else if(event.response != "<query_result></query_result>"){
            var xml = $.parseXML(event.response);
            parseThis(xml);
        }  else if(event.response == "<query_result></query_result>"){
            console.log(event.response);
            alert("Sorry, we have not yet come to your area");
        }
    }
    

    has anyone else run into this issue before?

    edit: to show the remaining bits of my function. noting too important here, however do you see me missing a step in handling this?

    • Etai
      Etai almost 10 years
      I assume the function isn't console.log, so perhaps you can provide the real function and adding of the listener so we can see whats really happening
    • james0
      james0 almost 10 years
      done, thanks is there anything else? this function really doesn't do much on it's own.
    • Etai
      Etai almost 10 years
      Its not the parsethis which is happening again, is it?
    • Etai
      Etai almost 10 years
      And you only add this listener once? Not each time you send the request?
    • james0
      james0 almost 10 years
      that was the problem. if you want credit for answering just submit it as an answer.
    • Daniel
      Daniel almost 7 years
      Because 0 is neither positive nor negative, it is more appropriate to use the term non-negative value instead of positive value for unsigned integers.
  • vIceBerg
    vIceBerg over 15 years
    Is that the little-endian and big-endian thing?
  • Jasper Bekkers
    Jasper Bekkers over 15 years
    little vs. big endian has to do with the order of the bytes on the platform. Little endian might do 0xFF 0xFE 0x7F while big endian will do 0x7F 0xFE 0xFF.
  • Admin
    Admin about 11 years
    Just to add to this answer, basically it means that 10 == 00 where both those numbers are base 2.
  • Jonathan Leffler
    Jonathan Leffler over 8 years
    Note that signed integer overflow does trigger undefined behaviour, and modern compilers are ultra-aggressive about spotting this and exploiting it to modify your program in unexpected but technically legitimate ways because they're allowed to assume undefined behaviour won't occur — roughly speaking. This is much more of a problem now than it was 7 years ago.
  • Suraj Jain
    Suraj Jain over 7 years
    If i write unsigned int a = -2 , and signed int b = -2 , would the underlying representation same , i know it is not good to have unsigned number given a negative value , but still if i give it , what will be the underlying representation ?
  • al45tair
    al45tair about 7 years
    Minor niggle: sign and magnitude is used in IEEE floating point, so it's actually quite common. :-)
  • chaotic3quilibrium
    chaotic3quilibrium over 2 years
    Nice. Simple. Concise. Excellent job.