When adding binary numbers, how do you just ignore the overflow?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite
1












So lets say I used 2's complement to put -17 in binary and then I added it to +27, e.g.:



 +27 0001 1011b
+ -17 1110 1111b
-------------------
+10 0000 1010b


This calculation here should have an overflow of 1. Where did this overflow of 1 go? How can you possibly just disregard it when it would completely change the whole calculation?



When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?



Also, does 2's complement have -0 value and a +0 or only one 0 value?










share|improve this question























  • Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits.
    – Hearth
    Nov 22 at 22:48






  • 1




    Adding two 2’s complement numbers with different signs can never cause an overflow.
    – Spehro Pefhany
    Nov 23 at 2:06














up vote
1
down vote

favorite
1












So lets say I used 2's complement to put -17 in binary and then I added it to +27, e.g.:



 +27 0001 1011b
+ -17 1110 1111b
-------------------
+10 0000 1010b


This calculation here should have an overflow of 1. Where did this overflow of 1 go? How can you possibly just disregard it when it would completely change the whole calculation?



When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?



Also, does 2's complement have -0 value and a +0 or only one 0 value?










share|improve this question























  • Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits.
    – Hearth
    Nov 22 at 22:48






  • 1




    Adding two 2’s complement numbers with different signs can never cause an overflow.
    – Spehro Pefhany
    Nov 23 at 2:06












up vote
1
down vote

favorite
1









up vote
1
down vote

favorite
1






1





So lets say I used 2's complement to put -17 in binary and then I added it to +27, e.g.:



 +27 0001 1011b
+ -17 1110 1111b
-------------------
+10 0000 1010b


This calculation here should have an overflow of 1. Where did this overflow of 1 go? How can you possibly just disregard it when it would completely change the whole calculation?



When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?



Also, does 2's complement have -0 value and a +0 or only one 0 value?










share|improve this question















So lets say I used 2's complement to put -17 in binary and then I added it to +27, e.g.:



 +27 0001 1011b
+ -17 1110 1111b
-------------------
+10 0000 1010b


This calculation here should have an overflow of 1. Where did this overflow of 1 go? How can you possibly just disregard it when it would completely change the whole calculation?



When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?



Also, does 2's complement have -0 value and a +0 or only one 0 value?







digital-logic binary






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 23 at 8:11









manassehkatz

22916




22916










asked Nov 22 at 22:42









fred

8317




8317











  • Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits.
    – Hearth
    Nov 22 at 22:48






  • 1




    Adding two 2’s complement numbers with different signs can never cause an overflow.
    – Spehro Pefhany
    Nov 23 at 2:06
















  • Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits.
    – Hearth
    Nov 22 at 22:48






  • 1




    Adding two 2’s complement numbers with different signs can never cause an overflow.
    – Spehro Pefhany
    Nov 23 at 2:06















Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits.
– Hearth
Nov 22 at 22:48




Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits.
– Hearth
Nov 22 at 22:48




1




1




Adding two 2’s complement numbers with different signs can never cause an overflow.
– Spehro Pefhany
Nov 23 at 2:06




Adding two 2’s complement numbers with different signs can never cause an overflow.
– Spehro Pefhany
Nov 23 at 2:06










3 Answers
3






active

oldest

votes

















up vote
4
down vote













Carry and overflow are not the same thing.



The MSB of a 2's-complement number is the sign bit. The bit you're talking about is the carry-out from the addition of the MSBs. There is an "overflow" only if the signs of the operands are identical AND the sign bit of the result and that carry-out are not identical. If the signs of the operands are different, then there cannot be an overflow, regardless of the state of the carry-out



Try a few examples for yourself to see how it works.






share|improve this answer






















  • I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
    – fred
    Nov 22 at 23:03






  • 1




    Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
    – Dave Tweed
    Nov 22 at 23:07






  • 2




    -0 only exists in one's complement or floating point systems.
    – pjc50
    Nov 22 at 23:08










  • Thanks fellas..
    – fred
    Nov 22 at 23:17

















up vote
2
down vote













There are many ways to explain it. Here is one.



Eight-bit signed binary can represent integers as low as -128DECIMAL and as high as +127DECIMAL. So, why can it not represent the next greater integer, +128DECIMAL?



Answer: it could represent +128DECIMAL. The trouble is, the representation would be the same as that of -128DECIMAL. See:



DECIMAL BINARY
-128 1000 0000
-127 1000 0001
-126 1000 0010
...
+126 0111 1110
+127 0111 1111
+128 1000 0000
+129 1000 0001
+130 1000 0010
...


Observe:



  • +128DECIMAL is indistinguishable from -128DECIMAL;

  • +129DECIMAL is indistinguishable from -127DECIMAL;

  • +130DECIMAL is indistinguishable from -126DECIMAL;

  • and so on.

By keeping the carry bit (it's actually not an overflow bit; overflow is something else), you would be affirming the false representation, wouldn't you? Try it. You'll see.



You don't want that carry bit.



NOTES ON OVERFLOW



If you wish to know what overflow is, it's what happens when you try (for example) to add 96DECIMAL + 64DECIMAL. The result comes out as -32DECIMAL, which is wrong because the addition register has overflowed.



Note that the example, incidentally, has no carry.






share|improve this answer





























    up vote
    0
    down vote













    Picking up this specific bit:




    When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?




    Yes, you need to know the number of bits you are going to be working with, because that determines what the two's-complement representation of your negative number will look like.



    So, in your example, you have:



     +27 0001 1011b
    + -17 1110 1111b
    -------------------
    +10 0000 1010b


    where there would be a "carry" out of the 8th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8th-bit carry, we would get the wrong answer:



     +27 0000 0001 1011b
    + -17 0000 1110 1111b << WRONG representation of "-17" in 12 bits.
    ------------------------
    +266 0001 0000 1010b << WRONG answer in 12 bits.


    However, if we do this again, but using the correct 12-bit representation of -17, then we again get the correct result, although here we are "ignoring" the carry out of the 12th bit:



     +27 0000 0001 1011b
    + -17 1111 1110 1111b << Correct representation of "-17" in 12 bits.
    ------------------------
    + 10 0000 0000 1010b << Correct answer in 12 bits.


    Conceptually, you can think of the "true" two's-complement representation of -17 as being an infinite string of 1s, ending in ...10 1111. When doing calculations with a finite number of bits, you take just enough of those 1s to fill your register and discard any "carry" that would go outside that size.






    share|improve this answer




















      Your Answer





      StackExchange.ifUsing("editor", function ()
      return StackExchange.using("mathjaxEditing", function ()
      StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
      StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
      );
      );
      , "mathjax-editing");

      StackExchange.ifUsing("editor", function ()
      return StackExchange.using("schematics", function ()
      StackExchange.schematics.init();
      );
      , "cicuitlab");

      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "135"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f408332%2fwhen-adding-binary-numbers-how-do-you-just-ignore-the-overflow%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      4
      down vote













      Carry and overflow are not the same thing.



      The MSB of a 2's-complement number is the sign bit. The bit you're talking about is the carry-out from the addition of the MSBs. There is an "overflow" only if the signs of the operands are identical AND the sign bit of the result and that carry-out are not identical. If the signs of the operands are different, then there cannot be an overflow, regardless of the state of the carry-out



      Try a few examples for yourself to see how it works.






      share|improve this answer






















      • I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
        – fred
        Nov 22 at 23:03






      • 1




        Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
        – Dave Tweed
        Nov 22 at 23:07






      • 2




        -0 only exists in one's complement or floating point systems.
        – pjc50
        Nov 22 at 23:08










      • Thanks fellas..
        – fred
        Nov 22 at 23:17














      up vote
      4
      down vote













      Carry and overflow are not the same thing.



      The MSB of a 2's-complement number is the sign bit. The bit you're talking about is the carry-out from the addition of the MSBs. There is an "overflow" only if the signs of the operands are identical AND the sign bit of the result and that carry-out are not identical. If the signs of the operands are different, then there cannot be an overflow, regardless of the state of the carry-out



      Try a few examples for yourself to see how it works.






      share|improve this answer






















      • I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
        – fred
        Nov 22 at 23:03






      • 1




        Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
        – Dave Tweed
        Nov 22 at 23:07






      • 2




        -0 only exists in one's complement or floating point systems.
        – pjc50
        Nov 22 at 23:08










      • Thanks fellas..
        – fred
        Nov 22 at 23:17












      up vote
      4
      down vote










      up vote
      4
      down vote









      Carry and overflow are not the same thing.



      The MSB of a 2's-complement number is the sign bit. The bit you're talking about is the carry-out from the addition of the MSBs. There is an "overflow" only if the signs of the operands are identical AND the sign bit of the result and that carry-out are not identical. If the signs of the operands are different, then there cannot be an overflow, regardless of the state of the carry-out



      Try a few examples for yourself to see how it works.






      share|improve this answer














      Carry and overflow are not the same thing.



      The MSB of a 2's-complement number is the sign bit. The bit you're talking about is the carry-out from the addition of the MSBs. There is an "overflow" only if the signs of the operands are identical AND the sign bit of the result and that carry-out are not identical. If the signs of the operands are different, then there cannot be an overflow, regardless of the state of the carry-out



      Try a few examples for yourself to see how it works.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Nov 23 at 12:36

























      answered Nov 22 at 23:01









      Dave Tweed

      116k9143255




      116k9143255











      • I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
        – fred
        Nov 22 at 23:03






      • 1




        Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
        – Dave Tweed
        Nov 22 at 23:07






      • 2




        -0 only exists in one's complement or floating point systems.
        – pjc50
        Nov 22 at 23:08










      • Thanks fellas..
        – fred
        Nov 22 at 23:17
















      • I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
        – fred
        Nov 22 at 23:03






      • 1




        Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
        – Dave Tweed
        Nov 22 at 23:07






      • 2




        -0 only exists in one's complement or floating point systems.
        – pjc50
        Nov 22 at 23:08










      • Thanks fellas..
        – fred
        Nov 22 at 23:17















      I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
      – fred
      Nov 22 at 23:03




      I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen?
      – fred
      Nov 22 at 23:03




      1




      1




      Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
      – Dave Tweed
      Nov 22 at 23:07




      Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0.
      – Dave Tweed
      Nov 22 at 23:07




      2




      2




      -0 only exists in one's complement or floating point systems.
      – pjc50
      Nov 22 at 23:08




      -0 only exists in one's complement or floating point systems.
      – pjc50
      Nov 22 at 23:08












      Thanks fellas..
      – fred
      Nov 22 at 23:17




      Thanks fellas..
      – fred
      Nov 22 at 23:17












      up vote
      2
      down vote













      There are many ways to explain it. Here is one.



      Eight-bit signed binary can represent integers as low as -128DECIMAL and as high as +127DECIMAL. So, why can it not represent the next greater integer, +128DECIMAL?



      Answer: it could represent +128DECIMAL. The trouble is, the representation would be the same as that of -128DECIMAL. See:



      DECIMAL BINARY
      -128 1000 0000
      -127 1000 0001
      -126 1000 0010
      ...
      +126 0111 1110
      +127 0111 1111
      +128 1000 0000
      +129 1000 0001
      +130 1000 0010
      ...


      Observe:



      • +128DECIMAL is indistinguishable from -128DECIMAL;

      • +129DECIMAL is indistinguishable from -127DECIMAL;

      • +130DECIMAL is indistinguishable from -126DECIMAL;

      • and so on.

      By keeping the carry bit (it's actually not an overflow bit; overflow is something else), you would be affirming the false representation, wouldn't you? Try it. You'll see.



      You don't want that carry bit.



      NOTES ON OVERFLOW



      If you wish to know what overflow is, it's what happens when you try (for example) to add 96DECIMAL + 64DECIMAL. The result comes out as -32DECIMAL, which is wrong because the addition register has overflowed.



      Note that the example, incidentally, has no carry.






      share|improve this answer


























        up vote
        2
        down vote













        There are many ways to explain it. Here is one.



        Eight-bit signed binary can represent integers as low as -128DECIMAL and as high as +127DECIMAL. So, why can it not represent the next greater integer, +128DECIMAL?



        Answer: it could represent +128DECIMAL. The trouble is, the representation would be the same as that of -128DECIMAL. See:



        DECIMAL BINARY
        -128 1000 0000
        -127 1000 0001
        -126 1000 0010
        ...
        +126 0111 1110
        +127 0111 1111
        +128 1000 0000
        +129 1000 0001
        +130 1000 0010
        ...


        Observe:



        • +128DECIMAL is indistinguishable from -128DECIMAL;

        • +129DECIMAL is indistinguishable from -127DECIMAL;

        • +130DECIMAL is indistinguishable from -126DECIMAL;

        • and so on.

        By keeping the carry bit (it's actually not an overflow bit; overflow is something else), you would be affirming the false representation, wouldn't you? Try it. You'll see.



        You don't want that carry bit.



        NOTES ON OVERFLOW



        If you wish to know what overflow is, it's what happens when you try (for example) to add 96DECIMAL + 64DECIMAL. The result comes out as -32DECIMAL, which is wrong because the addition register has overflowed.



        Note that the example, incidentally, has no carry.






        share|improve this answer
























          up vote
          2
          down vote










          up vote
          2
          down vote









          There are many ways to explain it. Here is one.



          Eight-bit signed binary can represent integers as low as -128DECIMAL and as high as +127DECIMAL. So, why can it not represent the next greater integer, +128DECIMAL?



          Answer: it could represent +128DECIMAL. The trouble is, the representation would be the same as that of -128DECIMAL. See:



          DECIMAL BINARY
          -128 1000 0000
          -127 1000 0001
          -126 1000 0010
          ...
          +126 0111 1110
          +127 0111 1111
          +128 1000 0000
          +129 1000 0001
          +130 1000 0010
          ...


          Observe:



          • +128DECIMAL is indistinguishable from -128DECIMAL;

          • +129DECIMAL is indistinguishable from -127DECIMAL;

          • +130DECIMAL is indistinguishable from -126DECIMAL;

          • and so on.

          By keeping the carry bit (it's actually not an overflow bit; overflow is something else), you would be affirming the false representation, wouldn't you? Try it. You'll see.



          You don't want that carry bit.



          NOTES ON OVERFLOW



          If you wish to know what overflow is, it's what happens when you try (for example) to add 96DECIMAL + 64DECIMAL. The result comes out as -32DECIMAL, which is wrong because the addition register has overflowed.



          Note that the example, incidentally, has no carry.






          share|improve this answer














          There are many ways to explain it. Here is one.



          Eight-bit signed binary can represent integers as low as -128DECIMAL and as high as +127DECIMAL. So, why can it not represent the next greater integer, +128DECIMAL?



          Answer: it could represent +128DECIMAL. The trouble is, the representation would be the same as that of -128DECIMAL. See:



          DECIMAL BINARY
          -128 1000 0000
          -127 1000 0001
          -126 1000 0010
          ...
          +126 0111 1110
          +127 0111 1111
          +128 1000 0000
          +129 1000 0001
          +130 1000 0010
          ...


          Observe:



          • +128DECIMAL is indistinguishable from -128DECIMAL;

          • +129DECIMAL is indistinguishable from -127DECIMAL;

          • +130DECIMAL is indistinguishable from -126DECIMAL;

          • and so on.

          By keeping the carry bit (it's actually not an overflow bit; overflow is something else), you would be affirming the false representation, wouldn't you? Try it. You'll see.



          You don't want that carry bit.



          NOTES ON OVERFLOW



          If you wish to know what overflow is, it's what happens when you try (for example) to add 96DECIMAL + 64DECIMAL. The result comes out as -32DECIMAL, which is wrong because the addition register has overflowed.



          Note that the example, incidentally, has no carry.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 22 at 23:12

























          answered Nov 22 at 23:07









          thb

          357313




          357313




















              up vote
              0
              down vote













              Picking up this specific bit:




              When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?




              Yes, you need to know the number of bits you are going to be working with, because that determines what the two's-complement representation of your negative number will look like.



              So, in your example, you have:



               +27 0001 1011b
              + -17 1110 1111b
              -------------------
              +10 0000 1010b


              where there would be a "carry" out of the 8th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8th-bit carry, we would get the wrong answer:



               +27 0000 0001 1011b
              + -17 0000 1110 1111b << WRONG representation of "-17" in 12 bits.
              ------------------------
              +266 0001 0000 1010b << WRONG answer in 12 bits.


              However, if we do this again, but using the correct 12-bit representation of -17, then we again get the correct result, although here we are "ignoring" the carry out of the 12th bit:



               +27 0000 0001 1011b
              + -17 1111 1110 1111b << Correct representation of "-17" in 12 bits.
              ------------------------
              + 10 0000 0000 1010b << Correct answer in 12 bits.


              Conceptually, you can think of the "true" two's-complement representation of -17 as being an infinite string of 1s, ending in ...10 1111. When doing calculations with a finite number of bits, you take just enough of those 1s to fill your register and discard any "carry" that would go outside that size.






              share|improve this answer
























                up vote
                0
                down vote













                Picking up this specific bit:




                When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?




                Yes, you need to know the number of bits you are going to be working with, because that determines what the two's-complement representation of your negative number will look like.



                So, in your example, you have:



                 +27 0001 1011b
                + -17 1110 1111b
                -------------------
                +10 0000 1010b


                where there would be a "carry" out of the 8th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8th-bit carry, we would get the wrong answer:



                 +27 0000 0001 1011b
                + -17 0000 1110 1111b << WRONG representation of "-17" in 12 bits.
                ------------------------
                +266 0001 0000 1010b << WRONG answer in 12 bits.


                However, if we do this again, but using the correct 12-bit representation of -17, then we again get the correct result, although here we are "ignoring" the carry out of the 12th bit:



                 +27 0000 0001 1011b
                + -17 1111 1110 1111b << Correct representation of "-17" in 12 bits.
                ------------------------
                + 10 0000 0000 1010b << Correct answer in 12 bits.


                Conceptually, you can think of the "true" two's-complement representation of -17 as being an infinite string of 1s, ending in ...10 1111. When doing calculations with a finite number of bits, you take just enough of those 1s to fill your register and discard any "carry" that would go outside that size.






                share|improve this answer






















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  Picking up this specific bit:




                  When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?




                  Yes, you need to know the number of bits you are going to be working with, because that determines what the two's-complement representation of your negative number will look like.



                  So, in your example, you have:



                   +27 0001 1011b
                  + -17 1110 1111b
                  -------------------
                  +10 0000 1010b


                  where there would be a "carry" out of the 8th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8th-bit carry, we would get the wrong answer:



                   +27 0000 0001 1011b
                  + -17 0000 1110 1111b << WRONG representation of "-17" in 12 bits.
                  ------------------------
                  +266 0001 0000 1010b << WRONG answer in 12 bits.


                  However, if we do this again, but using the correct 12-bit representation of -17, then we again get the correct result, although here we are "ignoring" the carry out of the 12th bit:



                   +27 0000 0001 1011b
                  + -17 1111 1110 1111b << Correct representation of "-17" in 12 bits.
                  ------------------------
                  + 10 0000 0000 1010b << Correct answer in 12 bits.


                  Conceptually, you can think of the "true" two's-complement representation of -17 as being an infinite string of 1s, ending in ...10 1111. When doing calculations with a finite number of bits, you take just enough of those 1s to fill your register and discard any "carry" that would go outside that size.






                  share|improve this answer












                  Picking up this specific bit:




                  When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?




                  Yes, you need to know the number of bits you are going to be working with, because that determines what the two's-complement representation of your negative number will look like.



                  So, in your example, you have:



                   +27 0001 1011b
                  + -17 1110 1111b
                  -------------------
                  +10 0000 1010b


                  where there would be a "carry" out of the 8th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8th-bit carry, we would get the wrong answer:



                   +27 0000 0001 1011b
                  + -17 0000 1110 1111b << WRONG representation of "-17" in 12 bits.
                  ------------------------
                  +266 0001 0000 1010b << WRONG answer in 12 bits.


                  However, if we do this again, but using the correct 12-bit representation of -17, then we again get the correct result, although here we are "ignoring" the carry out of the 12th bit:



                   +27 0000 0001 1011b
                  + -17 1111 1110 1111b << Correct representation of "-17" in 12 bits.
                  ------------------------
                  + 10 0000 0000 1010b << Correct answer in 12 bits.


                  Conceptually, you can think of the "true" two's-complement representation of -17 as being an infinite string of 1s, ending in ...10 1111. When doing calculations with a finite number of bits, you take just enough of those 1s to fill your register and discard any "carry" that would go outside that size.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 23 at 13:23









                  TripeHound

                  26616




                  26616



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Electrical Engineering Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      Use MathJax to format equations. MathJax reference.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f408332%2fwhen-adding-binary-numbers-how-do-you-just-ignore-the-overflow%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown






                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Displaying single band from multi-band raster using QGIS

                      How many registers does an x86_64 CPU actually have?