I need help in determining if my logic here is right or wrong.
Example Question
"Assuming I have an 8-bit signed decimal value of 200 in two's compliment form..."
My Thought Process
Now because it is 8-bits and is signed, the most significant bit must be reserved for the sign.
Thus, the maximum positive value it can have is:
2^(8-1) - 1 = 127
At first I was confused because I thought, why is the question stating that 200 is able to be 8-bits and signed? Then I thought, that's where the two's compliment statement comes into question.
Because it is two's compliment in reality, this is the case:
8-bit Signed, 2's Compliment, Decimal = 200
Convert to Binary --> 1100 1000
Because it is signed, the actual two's compliment number is ACTUALLY -56 (I would use negating methods to invert the 1's and 0's then + 1, but for the interest of time, I just found a converter online).
So my conclusion is:
8-bit Signed, 2's Compliment, Decimal value of 200 is actually -56.
Ultimate Question
Is my thought process correct with this? If so, I think the most confusing part about this is telling my brain that one number is equal to a completely different number.
Yes, I think your analysis is correct.
To expand a bit more, I think the wording of the question is awkward and would have been better stated as "What is the value of 1100 1000 in base 10, where the number is a two's complemented number?"
The trick here is to think not that 200 == -56, but that the single point of truth is the bits 11001000. These bits of numbers have no meaning by themselves. We have the computer interpret them differently based on the program. So two's complement (with 8 bit numbers) treats that as -56, an unsigned interpretation would treat that as 200, and in ASCII this would be some special character depending on the encoding.
Related
For example, we're given the number -1.5(10).
Converting it to signed binary we get 11.1000(2).
Its two's complement is 00.1000(2), which is 0.5(10) when converted to decimal.
Which is self-explanatory, because it's a different binary number.
What else is there to explain?
You are mixing apples (signed-binary) and oranges (two's complement).
You took a negative value in one representation (signed-binary), negated it using the technique for a different representation (2's complement), and (unsurprisingly) ended up with trash as a result.
If you had negated 11.1000(2) as appropriate for signed-binary, you'd end up with 01.1000(2) -- the correct answer.
If you had started with the 2's complement representation of -1.5, 10.1000(2), and took the 2's complement of that, you'd end up with 01.1000(2) -- also correct.
Note that none of this involves converting anything to decimal.
I’m doing computer science A-level course in a high school and currently working on two’s complement arithmetic. For some reason I don’t quite get it. I know how to convert a signed integer into its two’s complement equivalent, but here’re my confusions:
I’ve done some research and people say the op-code which is the carry-bit tells the CPU if a 2’s complement code represents a positive integer or a negative, but sometimes the carry-bit is ignored according to some people; for instance, adding 1111 (-1) to 1000 (-8) you get 10111 (-9), but if it’s a 4-bit computer, the most significant bit which is the 5th bit cannot be stored, so how does the computer deal with that ?
A somewhat trivial question is if it’s given that 00110011 represent a signed integer in two’s complement form, how do I know if the actual code is 0110011, which is a positive number (in 2’s complement form), or 110011, which is a negative number (in 2’s complement form) ?
Thanks!
Typically, what doesn't fit is lost. So, 11112 + 10002 = 01112. However, some CPUs have special flags which get set to 0 or 1 depending on whether or not there's unsigned overflow (the carry flag) and signed overflow (the overflow flag). Some CPUs may be able to automatically raise an overflow exception when an arithmetic instruction can't produce result without overflow.
Typically, the CPU does not care if 11112 is -110 or 1510. Binary addition and subtraction of two N-bit integers gives you the same N-bit sum or difference irrespective of whether you're operating on unsigned integers or 2's complement signed integers. The same is true when multiplying two N-bit signed 2's complement or unsigned integers: the N least significant bits of the product is the same in both cases.
IOW, it's your job to keep track of what types you're manipulating, to take care of overflows (if they're possible) and to select proper instructions for those types (e.g. you typically have signed and unsigned division, signed and unsigned comparison, etc).
I'm reading this article about exponent bias in floating point numbers and it says the following:
n IEEE 754 floating point numbers, the exponent is biased in the
engineering sense of the word – the value stored is offset from the
actual value by the exponent bias. Biasing is done because exponents
have to be signed values in order to be able to represent both tiny
and huge values, but two's complement, the usual representation for
signed values, would make comparison harder. To solve this problem the
exponent is biased before being stored, by adjusting its value to put
it within an unsigned range suitable for comparison. By arranging the
fields so that the sign bit is in the most significant bit position,
the biased exponent in the middle, then the mantissa in the least
significant bits, the resulting value will be ordered properly,
whether it's interpreted as a floating point or integer value. This
allows high speed comparisons of floating point numbers using fixed
point hardware.
I've also found this explanation from wikipedia's article about offset binary:
This has the consequence that the "zero" value is represented by a 1
in the most significant bit and zero in all other bits, and in general
the effect is conveniently the same as using two's complement except
that the most significant bit is inverted. It also has the consequence
that in a logical comparison operation, one gets the same result as
with a two's complement numerical comparison operation, whereas, in
two's complement notation a logical comparison will agree with two's
complement numerical comparison operation if and only if the numbers
being compared have the same sign. Otherwise the sense of the
comparison will be inverted, with all negative values being taken as
being larger than all positive values.
I don't really understand what kind of comparison they are talking about here. Can someone please explain using a simple example?
'Comparison' here refers to the usual comparison of numbers by size: 5 > 4, etc. Suppose floating-point numbers were stored with as
[sign bit] [unbiased exponent] [mantissa]
For example, if the exponent is a 2's complement 3-bit binary number and the mantissa is a 4-bit unsigned binary number, you'd have
1 010 1001 = 4.5
1 110 0111 = 0.21875
You can see that the first is bigger than the second, but to figure this out, the computer would have to calculate 1.001 x 2^2 and 0.111 x 2^(-2) and then compare the resulting floating-point numbers. This is already complex with floating-point hardware, and if there is no such hardware for this computer, then...
So the number is stored as
[sign bit] [biased exponent] [mantissa]
Using the same 3-bit binary number for the exponent (this time biased; see a related question) and unsigned 4-bit mantissa, we have
1 101 1001 = 4.5
1 001 0111 = 0.21875
But now comparison is very easy! You can treat the two numbers as integers 11011001 and 10010111 and see that the first is obviously bigger: obvious even to a computer, as integer comparisons are easy. This is why biased exponents are used.
I was learning binary numbers and 2's complement.
Lets say I have the binary number 1111. This is 15, but is also -1 (got from 2's complement method).
Can you explain how do i tell if it is 15 or -1?
Depends on the data type you use. Most programming languages offer signed and unsigned types.
A series of bits means nothing without a data type. E.g. an unsigned Int16 would contain only positive numbers up to 16 bits, while a signed Int16 would also contain negative numbers (but of course, less positive ones).
It's a matter of definition. If I write 10, you could read ten (decimal) or two (binary) or a whole bunch of other numbers, depending on the number system. If you don't know which system I use, there's no way you can tell what I mean. In your case, 15 is an answer in a unsigned binary system, -1 is an answer in a 2's compliment binary system.
If the register is 4-bit 2's complement, then the maximum range of values possible to be achieved is -8 to 7, so 15 is out of the question. For 15 to be represented, an unsigned register has to be used.
(Not sure if I am allow to ask a question like this but will delete if asked)
Convert -25 into binary representation using 8 bits and 2's complement format to represent a negative number. So far I got 11001.
I tried to google methods but I am not sure how to do it using the 8 bits way.
This question is not using code, just conversions but from what I did was
convert it to binary which was 11001 then I added 3 zero's to make it 8bits (assuming that is correct) 00011001 then I did 1's complement 11100110 and 2's complement by adding 1 which equals 11100111.
I am not sure if that is correct.
Two's complement is probably one of the more straightforward operations on binary numbers. In short, you'll want to take the following actions to convert a decimal number into two's complement form:
Write down the binary representation of the positive version of your number. In this case, 25 should be represented as: 00011001
Next, flip all the digits: 11100110
Add one: 11100111
Sit back, grab a drink, and bask in the glory of the newly-created two's complement representation of a decimal number.
Source
1.assume the negative sign and get the binary of the positive integer.adopt 8bit notation
25--00011001
2.get the two's complement.
11100111
+ 1
=11111000
3.relax and enjoy the two's complement