range of an int
in [Learn C or C++]
|
From: conrad on 12 Jan 2008 13:03 What is the purpose behind having ranges for various signed integer types as -2^n and (2^n) - 1? I don't follow why the postive end subtracts 1 from the 2^n value to establish the upper limit. Can someone explain the reasoning behind this? -- conrad
From: Andrew Koenig on 12 Jan 2008 13:18 "conrad" <conrad(a)lawyer.com> wrote in message news:1f2c2da7-e21b-4273-b154-77b4df2549db(a)m34g2000hsf.googlegroups.com... > What is the purpose behind having ranges > for various signed integer types as > -2^n and (2^n) - 1? I don't follow > why the postive end subtracts 1 > from the 2^n value to establish > the upper limit. Can someone > explain the reasoning behind this? Let's look at n=4 as an example. There are 2^n possible distinct values that an n-bit quantity can have. If one of those values is zero, and distinct bit patterns yield distinct values, then the number of positive values plus the number of negative values must be equal to (2^n)-1, which is an odd number if n is any positive integer. In other words, the following statements cannot all be true at once: 1) Every bit pattern represents a different value. 2) There is a bit pattern that represents zero. 3) The number of distinct positive values is equal to the number of distinct negative values.
From: Richard Heathfield on 12 Jan 2008 13:59 conrad said: > What is the purpose behind having ranges > for various signed integer types as > -2^n and (2^n) - 1? This isn't actually guaranteed. The range guarantee you get from C (and, I believe, C++) for an integer type with n value bits and a sign bit is -((2^n)-1) to +((2^n)-1). You *might* get the range you specify, though. > I don't follow > why the postive end subtracts 1 > from the 2^n value to establish > the upper limit. Can someone > explain the reasoning behind this? Let's start off by using a simple sign-and-magnitude system, using a really tiny int with a sign bit (where a set bit means "negative") and just three value bits. Let's look at the possible values: sign value bit bits value -------------------- 1 111 -7 1 110 -6 1 101 -5 1 100 -4 1 011 -3 1 010 -2 1 001 -1 1 000 -0 0 000 +0 0 001 +1 0 010 +2 0 011 +3 0 100 +4 0 101 +5 0 110 +6 0 111 +7 Get the idea? With a sign-and-magnitude system, there are two 0-values, one ostensibly positive and the other ostensibly negative. But the system you're describing is slightly different. It's called "two's complement", and it's simple enough - negative N is represented by flipping all the bits of N and adding 1: sign value bit bits value -------------------- 1 000 -8 1 001 -7 1 010 -6 1 011 -5 1 100 -4 1 101 -3 1 110 -2 1 111 -1 0 000 +0 0 001 +1 0 010 +2 0 011 +3 0 100 +4 0 101 +5 0 110 +6 0 111 +7 The advantage of this scheme is that you can use it to do subtraction really neatly. If you want to subtract 4 from 6, i.e. do 6-4, all you have to do is take the two's complement of 4 and ADD it to 6. 6: 0110 -4: 1100 -------- 0010 Hey, presto: 2. I trust that, as you have read through these examples of the representations of integers, you have discovered in passing why the range limits are as they are. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ Google users: <http://www.cpax.org.uk/prg/writings/googly.php> "Usenet is a strange place" - dmr 29 July 1999
From: conrad on 12 Jan 2008 17:31 On Jan 12, 12:18 pm, "Andrew Koenig" <a...(a)acm.org> wrote: > "conrad" <con...(a)lawyer.com> wrote in message > > news:1f2c2da7-e21b-4273-b154-77b4df2549db(a)m34g2000hsf.googlegroups.com... > > > What is the purpose behind having ranges > > for various signed integer types as > > -2^n and (2^n) - 1? I don't follow > > why the postive end subtracts 1 > > from the 2^n value to establish > > the upper limit. Can someone > > explain the reasoning behind this? > > Let's look at n=4 as an example. > > There are 2^n possible distinct values that an n-bit quantity can have. If > one of those values is zero, and distinct bit patterns yield distinct > values, then the number of positive values plus the number of negative > values must be equal to (2^n)-1, which is an odd number if n is any positive > integer. In other words, the following statements cannot all be true at > once: > > 1) Every bit pattern represents a different value. > 2) There is a bit pattern that represents zero. > 3) The number of distinct positive values is equal to the number of > distinct negative values. I was more concerned about why there is an unevenness across the interval. You have more negative values than positive values. So if we consider n = 3 and twos complement, then: 101 = -3 110 = -2 111 = -1 000 = 0 001 = 1 010 = 2 011 = 3 And then we elect to have 4, 100, be represented by our remaining bit pattern and to interpret it as a negative four. It seems like it could have been just as well to choose to interpret that bit pattern as a positive four. Therefore, the unevenness of this interval seems to be an arbitrary choice. So instead of having our interval defined as follows: [-(2^(n - 1)-1), (2^(n - 1)] We arbitrarily choose to have it defined as follows: [-(2^(n - 1)), 2^(n-1)-1] In the case of n = 3 Instead of [-3, 4] We get: [-4, 3] Am I off base or is this seemingly arbitrary choice the reasoning behind this unnevenness? -- conrad
From: Richard Heathfield on 12 Jan 2008 18:10
conrad said: <snip> > 011 = 3 > > And then we elect to have > 4, 100, be represented by > our remaining bit pattern > and to interpret it as a > negative four. It seems like > it could have been just as well > to choose to interpret that > bit pattern as a positive four. > Therefore, the unevenness of this > interval seems to be an arbitrary > choice. No, in implementations where you get the unevenness (instead of two 0s or, perhaps, a trap representation), it's done to make two's complement work properly and easily. See my other reply in this thread, which - I hope! - makes it clear. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ Google users: <http://www.cpax.org.uk/prg/writings/googly.php> "Usenet is a strange place" - dmr 29 July 1999 |