integer types

[Mark R Rivet]

can someone tell me why on a signed int the range is -32768 to +32768.
why do we get one more in the negative. I understand it takes two
bytes of memory.

 

[JKop]

Mark R Rivet posted:

can someone tell me why on a signed int the range is -32768 to +32768.
why do we get one more in the negative. I understand it takes two
bytes of memory.

int is different sizes on different platforms.


Let's say it's 32-Bit. Here's what it looks like in memory:


0000 0000 0000 0000 0000 0000 0000 0000 0000



With an unsigned int , you can use all 32-Bits, that leaves you with:

2 ^ 32

possible combinations. If you include the number, 0, then that gives you a
range of:

0 -> (2 ^ 32) - 1

0 -> (4,294,967,296) -1

0 -> 4,294,967,295



If you have a signed int , then one of the bits is used to indicate the
sign. That leaves you with 31 Bits to express the value.

With those 31-Bits, there's:

2 ^ 31

possible combinations.

Include the number, 0, and that leaves you with:

(2 ^ 31) - 1 possible combinations, including 0.

(2 ^ 31) - 1 = 2,147,483,647


Now, to find out the range, just divide that by 2.

You get: 1,073,741,823.5


There's your problem, it's not an integer! The extra 1 is given to the
positive side.

--

I'll elaborate further, here's an 8-Bit Signed Integer:

0000 0000

The value of that is equal to 0.

Now let's make the negative:

1000 0000

0 = -0
Here, we have two values for 0, that's a waste! Therefore:

1000 0000

is equal to -1!

And concordantly:

1000 0001

is equal to -2!!



Hope that helps.


-JKop

 

[Tim Love]

can someone tell me why on a signed int the range is -32768 to +32768.

You mean -32768 to 32767 inclusive, I think.

why do we get one more in the negative.

Don't forgot 0.

I understand it takes two bytes of memory.

Yes. Google for "two's complement" or look at
http://www2.eng.cam.ac.uk/~tpl/E6/binary.html

 

[JKop]

JKop posted:

Let's say it's 32-Bit. Here's what it looks like in memory:


0000 0000 0000 0000 0000 0000 0000 0000 0000

TYPO TYPO TYPO



0000 0000 0000 0000 0000 0000 0000 0000



-JKop

 

[Karl Heinz Buchegger]

can someone tell me why on a signed int the range is -32768 to +32768.
why do we get one more in the negative. I understand it takes two
bytes of memory.

The simple answer is: because there is also 0.
If 16 bits can represent 65656 different combinations, and
32768 are used for negative numbers and one state is subtracted
for representing 0, how many states are left for the positive numbers?

A possible long answer is:
Use google to find a tutorial on "two's complement arithmetic".
Note: C++ doesn't have to use two's complement arithmetic. There are
other schemas available for representing negative numbers. But since
two's complement is easy and simple to implement it is used a lot.

 

[osmium]

can someone tell me why on a signed int the range is -32768 to +32768.
why do we get one more in the negative. I understand it takes two
bytes of memory.

The most common form of representation of binary integers is called "two's
complement" This takes the number zero from the allotment for negative
numbers, thus the imbalance. Note that two bytes is not universal, nor is
two's complement.

 

[Victor Bazarov]

can someone tell me why on a signed int the range is -32768 to +32768.

Actually, you made a mistake -- it's -32768 to +32767 (the last digit is
'seven', not 'eight') -- but I bet it was just a typo. And that range
only exists on machines with a particular representation of numbers in
the hardware, so called "two's complement".

why do we get one more in the negative. I understand it takes two
bytes of memory.

You get "one more in the negative" because the hardware can represent it.
The language does not actually guarantee that you can get that "one more"
on all possible platforms. It requires, though, that you can get -32767
to +32767, which is the subset of numbers that all hardware systems
currently in use can represent in 16 bits.

There are three main systems of representing binary integral numbers in
computer hardware: two's complement, one's complement, signed magnitude.
On a PC you most likely have the former. The latter two are more or less
infrequent as far as modern computers go.

Please search the web or your local library for explanation on binary
representations of numbers in computer hardware.

BTW, a byte is not necessarily 8 bits, although it is possible that you
will never encounter a system where it's not so.

V

 

[Mark R Rivet]

Oh, thanks. I was thinking that the next bit, or bit 33 would be used
as the sign bit. thanks for clearing that up for me.

 

[Mark R Rivet]

Thanks, that's a great reference

You mean -32768 to 32767 inclusive, I think.

Don't forgot 0.

Yes. Google for "two's complement" or look at
http://www2.eng.cam.ac.uk/~tpl/E6/binary.html

 

[Mark R Rivet]

Yes, I've looked at google and found a great article that was
suggested in an earlier reply, thanks.

 

[Mark R Rivet]

The most common form of representation of binary integers is called "two's
complement" This takes the number zero from the allotment for negative
numbers, thus the imbalance. Note that two bytes is not universal, nor is
two's complement.

thanks for the reply. I've recieved many replies and thank everyone.
If it weren't for these speedy reply's and this news group, I wonder
where I would get the answer. Even though I have posted what Im sure
is a trivial question for most people, the understanding of this
concept, Im sure, is very important. So thank you very much.

 

[Mark R Rivet]

Actually, you made a mistake -- it's -32768 to +32767 (the last digit is
'seven', not 'eight') -- but I bet it was just a typo. And that range
only exists on machines with a particular representation of numbers in
the hardware, so called "two's complement".


You get "one more in the negative" because the hardware can represent it.
The language does not actually guarantee that you can get that "one more"
on all possible platforms. It requires, though, that you can get -32767
to +32767, which is the subset of numbers that all hardware systems
currently in use can represent in 16 bits.

There are three main systems of representing binary integral numbers in
computer hardware: two's complement, one's complement, signed magnitude.
On a PC you most likely have the former. The latter two are more or less
infrequent as far as modern computers go.

Please search the web or your local library for explanation on binary
representations of numbers in computer hardware.

BTW, a byte is not necessarily 8 bits, although it is possible that you
will never encounter a system where it's not so.

V

Thanks Victor, that agree's with what other people are saying, and
wow, the reponse time was great. I hope I can count on that because Im
only in my first year studying C++. Some of the concepts that I should
have understood in the first semester have been overlooked by the
instructor. I'm not sure the teacher even has a good understanding of
C++ which might sound strange. But when ever I have him help me debug
my programs, it seems like he doesn't know the syntax of C++. I wonder
sometimes how he got the job. Many students have complained to him
about his methods and he just gets defensive about the whole.
Unfortunately, we are stuck with him because he is the only one. Oh
well, judging by the posts in this group, I think I will be fine.
Thanks again, Mark.

 

[David Harmon]

On Fri, 28 May 2004 13:00:12 GMT in comp.lang.c++, Mark R Rivet

can someone tell me why on a signed int the range is -32768 to +32768.
why do we get one more in the negative. I understand it takes two
bytes of memory.

Because the positive numbers start with 0, and the negatives with -1.

 

[Karl Heinz Buchegger]

(2 ^ 31) - 1 possible combinations, including 0.

(2 ^ 31) - 1 = 2,147,483,647

Now, to find out the range, just divide that by 2.

You get: 1,073,741,823.5

There's your problem, it's not an integer! The extra 1 is given to the
positive side.

Obviously the negative side.

--

I'll elaborate further, here's an 8-Bit Signed Integer:

0000 0000

The value of that is equal to 0.

Now let's make the negative:

1000 0000

0 = -0
Here, we have two values for 0, that's a waste! Therefore:

1000 0000

is equal to -1!

And concordantly:

1000 0001

is equal to -2!!

Could be.
In the most used system today (two's complement) it is not.

------------

take 0 0000 0000 = 0
negate that by
reversing all bits 1111 1111
and adding 1 0000 0000 = 0

Thus +0 == -0 == 0 with bit pattern 0000 0000

------------

take 1 0000 0001 = 1
negate that by
reversing all bits 1111 1110
and adding 1 1111 1111 = -1

thus the bit pattern for -1 equals 1111 1111

------------

take 2 0000 0010 = 2
negate that by
reversing all bits 1111 1101
and adding 1 1111 1110

thus the bit pattern for -2 equals 1111 1110

------------

given the bit pattern 1011 0011
which number does it represent?

Since the left most bit equals 1, this is a negativ number.
To figure out which one, lets first make it positive.

1011 0011
negate that by
reversing all bits 0100 1100
and add 1 0100 1101

converting this bit pattern to decimal shows that
it represents the number 77. Thus 1011 0011 is the
bit pattern for -77

--------------

given the bit pattern 1000 0001
which number does it represent?

Again, the leftmost bit equals 1, thus it is a negative number


1000 0001
reverse 0111 1110
add 1 0111 1111

converting to decimal -> 127

thus 1000 0001 is the bit pattern for -127

 

[Karl Heinz Buchegger]

[snip]
Thanks Victor, that agree's with what other people are saying, and
wow, the reponse time was great. I hope I can count on that because Im
only in my first year studying C++. Some of the concepts that I should
have understood in the first semester have been overlooked by the
instructor. I'm not sure the teacher even has a good understanding of
C++ which might sound strange.

Would you believe me when I say: Not at all

This group and alt.comp.lang.learn.c-c++ is full of posts from
students with incompetent teachers.

 

[Julie]

On Fri, 28 May 2004 13:00:12 GMT in comp.lang.c++, Mark R Rivet


Because the positive numbers start with 0, and the negatives with -1.

0 is not a positive (or negative) number.

 

[Victor Bazarov]

0 is not a positive (or negative) number.

At least it's "non-negative".

 

[Jeff Schwab]

Mark R Rivet writes:




The most common form of representation of binary integers is called "two's
complement" This takes the number zero from the allotment for negative
positive?

numbers, thus the imbalance. Note that two bytes is not universal, nor is
two's complement.

 

[Mabden]

can someone tell me why on a signed int the range is -32768 to +32768.
why do we get one more in the negative. I understand it takes two
bytes of memory.

Zero is on the "positive" side.