Or, what is the range of numbers that can be represented on a 4-bit machine using 2s-complement?
That would be -8 to +7
The range is -8 to 7, or 1000 to 0111. You can see the full range here.
4 bits (using 2's complement) will give you a range from -8 to 7.
This should be straightforward to work out yourself.
Range in twos complement will be:
-1 * 2 ^ (bits - 1)
to
2 ^ (bits - 1) - 1
So for 4 bits:
-1 * 2 ^ (4 - 1) = -1 * 2 ^ 3 = -8
to
2 ^ (4 - 1) - 1 = 2 ^ 3 - 1 = 7
Also, if you are interested and for others maybe browsing this question -
twos complement is used for easy binary arithmetic:
to add - you just add the two numbers without conversion and disregard the overflow:
-6 + 7 = 1
is
1010 = -6
0111 = 7
------
(1)0001 = 1 (ignoring the overflow)
...and more yet - to convert a negative binary number to its opposite positive number:
if the sign bit (highest order bit) is 1, indicating negative... reading from least significant to most significant bit (right to left), preserve every bit up through the first "1", then invert every bit after that.
So, with 8 bit
10011000 .. becomes
01101000 (* -1) = 104 * -1 = -104
and that is why 10000000 is your lowest negative number (or in X bit 1000.all zeroes..000), it translates to unsigned 10000000 * -1 = -128
Maybe a long winded answer but to those without the 1s and 0s background I figure it is useful
Well let's dissect this question.
Firstly, the question should be framed as - "The least*(because it is negative, so biggest is not the right usage)* possible negative number to be stored in 4-bit would be?"
Numbers are of two types -
Signed (holds both + and - numbers )
Unsigned (holds only + numbers)
We will be using binary representation to understand this.
For Unsigned -
4-bit minimum number = 0000 (0)
4-bit maximum number = 1111 (255)
So range would be Range : 0-15
For Signed 4-bits, first bit represent sign(+/-) and rest 3-bits represent number.
4-bit minimum will be a negative number.
So replace the first bit(MSB) with 1 in 0000(least unsigned number), making it 1000.
Calculate decimal equivalent of 1000 = 1*2^3 = 8
So, number would be -8 (- as we have 1 as the first bit in 1000)
4-bit maximum will be a positive number.
So replace the first bit(MSB) with 0 in 1111(largest unsigned number), making it 0111.
Calculate decimal equivalent of 0111 = 1*2^2 + 1*2^1 + 1*2^0 = 7
So, number would be +7 (+ as we have 0 as the first bit in 0111)
Range would be -8 to +7.
Related
I have n = 7. How many different values can be represented using 7 digits in In Hexadecimal Systems?
I approached it this way:
I set each bit of the 7 to be equal to 1. Therefore the highest number I get is 111 1111 = 16^0 + 16^1 + 16^2 + 16^3 + 16^4 + 16^5 + 16^6 which is equal to 17895697. I also consider zero being part of the answer, so my range is 0 to 17895697 and therefore, I get 17895698 different values. however, I know that in binary you would do 2^7 = 128. does it apply to hexadecimals as well? If I do it this way I get 16^7 = 268435456 which does not equal to what I got before.
Is any of my answers correct? if not, could someone please explain what it the right way to do this question?
It may be more simple explanation that you would expect, but it does not mean it would not work.
One hexadecimal digit can represent one of 16 values (0x0 to 0xF, or 0 to 15 if you prefer), so 16^7 = 268,435,456 and that's how many different values you can achieve if you use all the bits.
0000 0000 0000 0000 0000 0000 0000 to 1111 1111 1111 1111 1111 1111 1111.
The general formula is the sum of digit * base^place
Consider decimal numbers. What's the largest number you can represent with 3 decimal digits? The largest possible digit is 9. Therefore the max number is:
9*10^2 + 9*10^1 + 9*10^0 = 9*100 + 9*10 + 9*1 = 999
The next largest number would with be 1*10^3 = 1000
Another way to calculate the max of decimal three digits, is to get the smallest number with 4 digits and subtract 1.
The smallest decimal with 4 digits is 1000 or
1*10^3 + 0*10^2 + 0*10^1 + 0*10^0 = 1000
Now subtract 1
1000 - 1 = 999
The possible digits for a hex num are 0..F (values 0..15)
For a 7 digits the places range from 6 down to 0.
The largest possible number is therefore:
15*16^6 + 15*16^5 .... 15*16^0
Or the smallest number in hex with 8 digits is #10000000
1*16^7 + 0*16^6 ... + 0*16^0 = 1*16^7
So the largest possible number with in hex with 7 digits is
1*16^7 -1
16^7 is the correct answer. Why? Because for every character you add there are 16 times the previous possibilities. So for 7 characters it's 16^7.
Consider binary - 2^1, you get 0 and 1, 2 possible values. 2^2, you get 0 through 3 (00,01,10,11), 4 possible values.
Using hex, it's 16^7 possible values, which is 268,435,456 possible values.
How do you represent (decimal) integer 50 in binary?
How many bits must be "flipped" in order to capitalize a lowercase 'a' that is represented in ASC11?
How do you represent the (decimal) integer 50 in, oh, "hexadecimal," otherwise known as base-16? Recall that decimal is simply base-10, and binary is simply base-2. Infer from those base systems how to represent this one?
Please answer these questions for me.HELP.
To help you some:
Binary is only made up of 1's and 0's.This may help you understand binary conversion
Decimal is 0-9
Hexadecimal is 0-9, then A-F (so A would represent 10, B would be 11, etc up to F which is 15)
Converting from decimal to another base
Here some tips for you regarding conversion to binary:
What is 50 mod 2? What about 25 mod 2 and then 12 mod 2? What are your results if you continue this?
What does any number mod 2 (always) return as result? - 1 or 0
Do you realise any patterns? - You get the reversed binary number as result
Test case 50:
50 mod 2 = 0 - 6th digit
25 mod 2 = 1 - 5th digit
12 mod 2 = 0 - 4th digit
6 mod 2 = 0 - 3rd digit
3 mod 2 = 1 - 2nd digit
1 mod 2 = 1 - 1st digit
The remainders of the divisions concatenated and reverses are: 110010, which is 50 in binary.
Can this be also transformed to further bases? - Yes, as we see with trying to convert 50 to hexadecimal:
50 mod 16 = 2 - 2nd digit
3 mod 16 = 3 - 1st digit
The remainders again concatenated and reversed are 32, which conveniently is 50 in hexadecimal.
In general we can say to convert a number to an arbitrary base you must take the remainder of the number and the base and then divide the number by the base and do the same thing again. In a program this would look something like:
while the number is greater 0 do:
result = (number mod base) + result;
number = number div base;
Converting from any base to decimal
How do you convert a number from an arbitrary base into base 10? First let us do a test case with binary. Lets take the 50 from the previous example: 110010
The method to convert from binary is multiplying every digit with the base to the power of the position of it in the number and adding up the result. The enumeration of the positions begins with 0 at the least significant digit. Our previous number would then look something like this:
1 *2^5 + 1 *2^4 + 0 *2^3 + 0 *2^2 + 1 *2^1 + 0 *2^0
What simplifies to:
32 + 16 + 2 = 50
It also works with any other base, like our 32 from the previous example:
3 *16^1 + 2*16^0 = 48 + 2 = 50
In program this would look something like this:
from end of number to beginning do:
result = result + digit * (base ^ position)
If I have got 1101 0010 0010 0010 on a 16bit system and want to convert it to decimal the result is -11,742 (teacher told me)
But if I enter the binary number into my calculator I get 53794.
Why is this the case? How does the system (8bit, 16bit, 32bit, 64bit) affect this?
I tried to convert the binary number with hand (2+32+512+4096+16384+32768 = 53794) but only to confirm my calculator....
It's because computer arhitmetic is based on two's complement
You shoud read about method of colpement
For example in complement decimal number natural subtraction looks like that (using 4 digits):
0000
0001 -
9999 =
It's obviously -1 because in complemental system first digit (in big endian of course, you shoud be familiar with endianness) defines sign. For example in decimal complement 4 is 4, 4 is 4, 3 is 3, 2 is 2, 1 is 1, 0 is 0, 9 is -1, 8 is -2, 7 is -3, 6 is -4 and 5 is -5.
It's because in complement number system you always operate on same number of digits but you are adding and substracting as always except ignoring overflowing result. For example with two decimal digits:
04
05 -
...9999 =
As I told result are only two digits (we added two digits) so the result is 99. As I also mentioned before first number is interpreted as -1 (not 9). Because it is positional number system we can easy convert this result to our normal decimal system just summing digits multypling by correct power's of ten:
10^1 * 9 + 10^0 * 9
//as I told - first nine is -1 so:
10^1 * -1 + 10^0*9 = -10 + 9 = -1
Now try with first result:
9999 = 9 * 10^3 + 10^2 * 9 + 10^1 * 9 + 10^0 * 9
//first nine is -1 so:
-1 * 10^3 + 999 = -1000 + 999 = -1
Now in binary it is much simpler because first number just tells as what sign is. Try with 8 bit number:
1111 1111
It's obviously -1 because if we add 1 the result will be 0. You may say I'm laying becaus you can simply make following addition:
1111 1111
0000 0001 +
1 0000 0000 =
But it's not correct in complement system. It's because in complement system first digit not only describe sign of number but also all number can be infinitly expanded by that digit! It's why id complement decimal 99 = 9999 ! It also means that we can easy expand 8 bytes number to for example 32 bytes!
For example try with numbers 17 and -1. You are now familiar with -1. In 8 bytes two's complemex -1 is:
1111 1111
Expanded to 32 bytes it gives us:
1111 1111 1111 1111 1111 1111 1111 1111
To convert it to normal decimal system we need to do 2^31 + 2^30 + ... + 2^0 but (as I mentioned) first 1 is -1 so it's exactly -1 * 2^31 + 2^30 + .. + 2^0 if you compute this it's exactly -2147483648 + 2147483647 = -1 !
0001 0001 (decimal 17)
Expanded to 32 bites gives:
0000 0000 0000 0000 0000 0000 0001 0001
And we can agree it's still 17 :)
To provide I'm not some crazy, just IT student I'm going to present C++ code that does exactly that stuff:
#include <iostream>
using namespace std;
int main(void)
{
char eightBits = 255; //eightBits := 0x11111111
int eightBytes = eightBits; //eightBytes becaming 255, right?
cout <<eightBytes <<endl; // MAGIC !
return 0;
}
Basically, it depends on how much space there is. The most significant bit is used to determine whether or not the number is negative.
In a 32-bit system, the two following numbers are equivalent:
1101 0010 0010 0010
0000 0000 0000 0000 1101 0010 0010 0010
As a signed 16-bit value, the 1 at the beginning denotes that it's a negative number. To get its value, flip each bit, then add one.
1101 0010 0010 0010
0010 1101 1101 1101
0010 1101 1101 1110
= 11742
As an unsigned 16-bit value, all sixteen bits are used to determine the magnitude. This would result in 53794.
Reference
The unpoken bit here is about the sign. It is stored on the front end and denotes the sign.
http://www.binaryconvert.com/result_signed_short.html?decimal=045049049055052050
More succinctly, a 16bit 'word' or integer is usually called a 'short' on most systems and represents signed number between −32,768 and +32,767. This is the 'binary' number to which your teacher is referring, which is not stored directly as a binary number, but in binary format. There are actually only 15 spots to store the value and one that must be reserved for the sign. Otherwise, an unsigned value can use all 16 spots for numbers and thus can go to from 0 to +65,535.
There are different ways to represent binary numbers:
Unsigned (what you are doing)
Signed
1's complement
2's complement (what you are supposed to do according to your teacher)
Digital systems generally use 2's complement representation.
To get decimal number for a binary number in 2's complement:
1. First bit is the sign bit. If the number starts with 0, it is positive, otherwise it is negative.
2. If the number is positive, its decimal value is unsigned value of the remaining bits other than the sign bit. If the number is negative, its absolute decimal value = (signed value of the complement of the remaining bits)+1.
In computers, it is common to represent "two's complement" signed numbers by assuming that the leftmost bit is duplicated an infinite number of times, so that the bit sequence (1101 0010 0010 0010) is regarded as (1111....1111 1101 0010 0010 0010). Although an infinite string of ones may seem like an infinitely large number, adding one to such a string will yield an infinite string of zeroes (i.e. 0). Thus, an infinite string of ones is the additive inverse of 1, and thus has an effective value of -1. An infinite string of ones followed by some number of zeroes, will be the additive inverse of a single 1 followed by that number of zeroes (so in your example, the leftmost "1" has an effective value of -32768 rather than +32768). While the fact that applying the power-series formula to 1+2+4+8+16+32+64... yields -1 is often regarded as an anomaly, it is consistent with the way that "two's complement" math works.
Note that while many descriptions of two's complement math simply describe the sign of the uppermost bit's "scaling factor" as being inverted (e.g. -32768 rather than +32768), thinking in terms of left-padding with copies of the leftmost bit makes it easier to understand why signed numbers behave as though the leftmost number is duplicated (e.g. converting a negative 16-bit integer to a 32-bit integer fills the leftmost 16 bits with ones).
I've built a four bit adder/subtractor utilizing 4, 1 bit full adders and the input and output are twos complement numbers.
If X=0111 and Y=1000 their sum is obviously 1111.
In decimal this is equivalent to 7 + 8 thus 15 which is what the sum results in.
I am confused however if this result needs to be translated back into "regular" binary by flipping the bits and adding one? So that the answer would be 0001 representing 1 in decimal instead. And that Y in decimal before translation was actually 0110 representing 6 thereby yielding the following in binary 7-6 = 1. If anyone could point me in the right direction I would appreciate it!
It appears you've got the conversion for Y wrong. Y = 10002 = -810.
To represent -6 you take 0110, flip the bits to get 1001 and add one, so Y = 1010. (And 0111 + 1010 = 0001 as you expect.)
To go back, flip the bits of 1010 = 0101 and add one giving 0110 = 6.
Edit to answer your follow-up question:
Let:
X = 0111
Y = 1100
X + Y = 0011 (ignoring overflow)
So whatever we're adding, it equals 3. We know that X = 7.
Y = 1100 => 0011 + 1 = (negative)0100 = -4
7 + (-4) = 3
No translation is necessary, just represent the positive and negative numbers correctly. I think your confusion is coming from the fact that we're "negating" the negative numbers to find the absolute value of that number and sticking a negative sign in front of it, as in the conversion of Y above. That's because negative numbers in 2's complement aren't as readable as positive numbers, but 0100 is still +4 and 1100 is still -4.
For example, if n=9, then how many different values can be represented in 9 binary digits (bits)?
My thinking is that if I set each of those 9 bits to 1, I will make the highest number possible that those 9 digits are able to represent. Therefore, the highest value is 1 1111 1111 which equals 511 in decimal. I conclude that, therefore, 9 digits of binary can represent 511 different values.
Is my thought process correct? If not, could someone kindly explain what I'm missing? How can I generalize it to n bits?
29 = 512 values, because that's how many combinations of zeroes and ones you can have.
What those values represent however will depend on the system you are using. If it's an unsigned integer, you will have:
000000000 = 0 (min)
000000001 = 1
...
111111110 = 510
111111111 = 511 (max)
In two's complement, which is commonly used to represent integers in binary, you'll have:
000000000 = 0
000000001 = 1
...
011111110 = 254
011111111 = 255 (max)
100000000 = -256 (min) <- yay integer overflow
100000001 = -255
...
111111110 = -2
111111111 = -1
In general, with k bits you can represent 2k values. Their range will depend on the system you are using:
Unsigned: 0 to 2k-1
Signed: -2k-1 to 2k-1-1
What you're missing: Zero is a value
A better way to solve it is to start small.
Let's start with 1 bit. Which can either be 1 or 0. That's 2 values, or 10 in binary.
Now 2 bits, which can either be 00, 01, 10 or 11 That's 4 values, or 100 in binary... See the pattern?
Okay, since it already "leaked": You're missing zero, so the correct answer is 512 (511 is the greatest one, but it's 0 to 511, not 1 to 511).
By the way, an good followup exercise would be to generalize this:
How many different values can be represented in n binary digits (bits)?
Without wanting to give you the answer here is the logic.
You have 2 possible values in each digit. you have 9 of them.
like in base 10 where you have 10 different values by digit say you have 2 of them (which makes from 0 to 99) : 0 to 99 makes 100 numbers. if you do the calcul you have an exponential function
base^numberOfDigits:
10^2 = 100 ;
2^9 = 512
There's an easier way to think about this. Start with 1 bit. This can obviously represent 2 values (0 or 1). What happens when we add a bit? We can now represent twice as many values: the values we could represent before with a 0 appended and the values we could represent before with a 1 appended.
So the the number of values we can represent with n bits is just 2^n (2 to the power n)
The thing you are missing is which encoding scheme is being used. There are different ways to encode binary numbers. Look into signed number representations. For 9 bits, the ranges and the amount of numbers that can be represented will differ depending on the system used.