numbering systems

Can somone please tell me what 128 is in binary.

if -128 = 10000000
and we apply (-n = ~n + 1)
we get 01111111 which is 127 + 1 = 128

but what is 128 in binary? If 127 = 01111111 then
adding one 11111111 gives us 255 not 128.

As much as i love my calculator i cant seem to rely on it
for numbering conversions. for 128 it gives me 10000000
and for -128 it gives me 1110000000. I dont know
why it seems to add stuff. :(

also i have a book which says that -128 in Hex is
0x80 but as far as i can see that's 128 not -128

8*16^1 = 128
0*16^0 = 0 :confused:

Quote:

---

but what is 128 in binary? If 127 = 01111111 then adding one 11111111 gives us 255 not 128.

---

ummmmm.....wouldn't adding 1 to 01111111 give you 10000000?

Besides, if you have negative numbers you are using two's complement arithmetic. 11111111 = -1.

Or am I missing something. Probably am.

Um... I think the problem is the fact that you're using only 8 bits and expecting to make it have more than 2^8 possible values.

1,2,3,..,127 = count of 127
-1,-2,-3, ... , -127, -128 = count of 128
don't forget 0 = count of 1

So, 1+127+128 = 256 = 2^8.

Unless I'm totally out of it today, but I doubt that. :P

Recap: You can't have +128 with an 8-bit, signed integer.

Destined

Destined is correct.

right 1*2^7 = -128 = 10000000
since the high order bit is singed we ge a negitive decmial
value.

but if we invert the bits we end up with
01111111 = 127 + 1 = 128

but what is 128 in binary? I know that 128 cannot
be represented using 8 bits since a signed byte
ranges from -128 to 127 if you add a 1 to the end of
01111111 you end up with 11111111 which is 255 not
what we want.

Quote:

---

1*2^7 = -128 = 10000000

---

2^7=128

Quote:

---

but if we invert the bits we end up with
01111111 = 127 + 1 = 128

---

1111111 binary = 127 decimal

Quote:

---

but what is 128 in binary? I know that 128 cannot
be represented using 8 bits since a signed byte
ranges from -128 to 127 if you add a 1 to the end of
01111111 you end up with 11111111 which is 255 not
what we want.

---

1111111+1 binary = 10000000 binary = 128 decimal

Comparing a signed byte with an unsigned, 128 for signed is the first negative value (-128) and 255 the last negative value (-1), so signed byte cannot express values above 127. Use a unsigned byte or bigger integer.
Here's something to visualize the behavour of the datatypes as the increment:

Code:

---

unsigned byte: 0,1,2...127, 128, 129...254,255,  0
signed byte:  0,1,2...127,-128,-127... -2, -1,  0
signed word:  0,1,2...127, 128, 129...254,255,256

---

128 in binary?

128 = 1000 0000

That's the answer. I think that you're confusing the binary value for 128 versus the byte storage of 128.

I haven't really bothered to learn the details of how numbers are stored (such as a single) in byte format, but I do know that negative numbers have a sign-bit. It seems that you're assuming that the highest-bit value is the sign bit.

Hence your version of 1111 1111 = -128, whereas the binary version of 1111 1111 = 255.

I hope this helps clarify a little bit. :D

Destined

It just weird to me.

If 127 in bin is 01111111
and we invert we come up with 1000000
which is -128
128 (10000001) + 1 = -127(10000001)

ok i understand that but why is
41 which is 00101001 in bin

invert 11010110 = 214?
and then if you add 1 (11010111) you come up with
215 not -41.

This is the way a book i am reading is showing it:


Given a value: 00101001 = 41
Form 1's complement 11010110
add 1: 00000001
Result is 2's complement 11010111 = -41

Kedaman's got it, too. :)

Basically, define your sign bit, (say the 9th bit instead of the 8th bit), then this should all work.

Destined

No, the cpu wouldn't like it. You use signed or unsigned integers that are either 8, 16 or 32 bit long, otherways the processor will get confused.

If you are confused, think of the signed bit as valued -128 instead of 128, so that when you calculate the value of say
1100 0000
you have
1*(-128) + 1*64 + 0*32..

or if you aren't talking about computers, forget about the sign bit and use - prefix instead, like in real math :)

-1 000 000 bin = -128 dec
1 000 000 bin = 128 dec

Thanks guys for replying. :) But i still dont understand
why these two formulas seem to work sometimes
and not others.

Neg to pos: (-n == ~n + 1)
-127 = 100000001
invert 011111110 = 126 + 1 = 127

Pos to neg: (n == ~n + 1)
127 = 01111111
invert 10000000 = -128 + 1 = -127



but if i try this on say 41
41 = 00101001
invert 11010110 = 214 ????? :confused:

11010110 signed byte = 1010110-10000000 bin= -42 dec

I guess the conclusion is that calculators represent
binary diffrent from computers.

pos to neg: ((n-1) ~n == (-n))

41 - 1 = 40
40 = 00101000
invert 11010111 = 215

Dilenger4: It doesn't seem to work? I think it does.

Might I ask how do you know (how do you calculate) how 1000 000 = -128?

You look at 11010110 and see 214. So do I. However, I look at 1000 0000 and see 128, not -128. You're just being a little inconsistent in how you a number, that's all.

Kedaman: When I referred to 9 bits instead of 8, I thought he might be doing this mathmatically. ;) But you're right in that if Dilenger4 wants to implement it, the number of bits should be in a power of 2.

Destined

Quote:

---

Might I ask how do you know (how do you calculate) how 1000 000 = -128?

---

For each 1 within the binary string add 1*2^n where
n is the zero based position within the binary string.

Quote:

---

You look at 11010110 and see 214. So do I. However, I look at 1000 0000 and see 128, not -128. You're just being a little inconsistent in how you a number, that's all.

---

thats why i am saying i guess calculators represent binary
diffrent from computers because my cal
defines 1000 0000 as 128 not -128.

Destined Soul
No, it's just because cpu's in general are just built that way, 8, 16 or 32, nothing more or less or between. If you do it mathematically forget about bytes and bits, because it's un-mathematical so to speak.

Dilenger4, if it confuses you so much, explicitely type what each expression are, ie:
unsigned byte
bin
dec
and if you haven't got it yet bin != unsigned byte.

Quote:

---

Originally posted by Dilenger4


thats why i am saying i guess calculators represent binary
diffrent from computers because my cal
defines 1000 0000 as 128 not -128.

---

note your computer won't represent you any binary values, if they do they will represent them binary, try the M$ calculator for instance. The way computer memory is stored is totally different issue.

Guv.... how did i know that you would reply ;)

This confusion was discussed in another thread. I read most, but not all of the posts to this thread. I am sorry if the following was discussed in one that I skipped.

The misunderstandings are due to not taking word length into account. In addition to the word length, you must also specify unsigned values, signed magnitude, or twos complement rules.

For 8-bit numbers, 0111 1111 is 127, no matter what the rules are.

For unsigned 8-bit numbers, 1000 0000 is 128, and 1111 1111 is 255. If leading zeros are supressed for longer numbers, these values are the same.

For 8-bit signed magnitude, 1000 0000 is minus zero, and 1111 1111 is minus 127.

For 8-bit twos complement, 1000 0000 is minus 128, and 1111 1111 is minus one.

Most hand calculators work with at least 12-bit binary and suppress leading zeros. For 12-bit twos complement, a calculator will show 128 as 1000 0000 and minus 128 as 1111 1000 0000.

The rules for signed magnitude are obvious. Reversing the first bit changes from positive ot negative or vice versa.

For twos complement, you change from positive to negative and vice versa by reversing every bit and adding one. Also, If the carry into the sign bit is different from the carry out, you have overflow.

For 8-bit twos complement, 1111 1111 + 0000 0001 (minus one + plus one), you get 0000 0000, which is zero (as expected). Note the carry into and out of the sign bit.

For 8-bit twos complement, 1000 0000 + 1111 1111 (-128 + -1), you get 0111 1111 (+127), which is an error due to overflow. Note carry into and out of the sign bit are different.

Similarly 0111 1111 + 0000 0001 (127 + 1), you get 1000 0000 (-128), which is an error due to overflow. Once again, carry into and out of the sign bit are different.

Forgot to mention the following.

It was asked how 1000 0000 is minus 128 in 8-bit twos complement.

Twos complement is best understood by realizing that the sign bit has a negative weight whose absolute value is twice the weight of the next bit to the right.

Bit weights for 8-bit binary are (from right to left): 1, 2, 4, 8, 16, 32, 64, -128.

The above makes it obvious that 1000 0000 is -128, and that 1111 1111 is minus one (-128 + 127).

The confusion was partly due to my assumption that
calculators recognize and take into account the high order
bit which ive come to find out that they do not.

pos to neg: ((n-1) ~n == (-n))

41 - 1 = 40
40 = 00101000
invert 11010111
11010111 equals 215 by what my cal was is saying
when 11010111 is really -41

That's no standard you should rely on either, signed integers are only used as a data storage format for computers, not anywhere in represented math where (-) can be represented.

Exactaly. I was unaware that numbering systems were used
for things other than data storage in computers. I foolishly assumed that my cal would produce sined integers. Thanks guys for your help. :D