A bit string is a string over the alphabet {0, 1}. A palindrome is a string whose reversal is
identical to the string. How many bit strings of length 15 are palindromes that don’t start with
111?
starts with 111 must ends with 111 so there're 9 bits left.
The center bit can be either 0 or 1. For each case, there are 4 bits to the left which can have 16 possible values, and the right 4 bits must match the left 4 bits.
So all together 2 * 16 = 32.
Well, sorry it should be "don't start with 111". Then it should be 32 * 7 = 224 possible values.
Related
I understand how binary works and I can calculate binary to decimal, but I'm lost around signed numbers.
I have found a calculator that does the conversion. But I'm not sure how to find the maximum and the minumum number or convert if a binary number is not given, and question in StackO seems to be about converting specific numbers or doesn't include signed numbers to a specific bit.
The specific question is:
We have only 5 bits for representing signed numbers in two's complement:
What is the highest signed integer?
Write its decimal value (including the sign only if negative).
What is the lowest signed integer?
Write its decimal value (including the sign only if negative).
Seems like I'll have to go heavier on binary concepts, I just have 2 months in programming and I thought i knew about binary conversion.
From a logical point of view:
Bounds in signed representation
You have 5 bits, so there are 32 different combinations. It means that you can make 32 different numbers with 5 bits. On unsigned integers, it makes sense to store integers from 0 to 31 (inclusive) on 5 bits.
However, this is about unsigned integers. Meaning: we have to find a way to represent negative numbers too. Meaning: we have to store the number's value, but also its sign (+ or -). The representation used is 2's complement, and it is the one that's learned everywhere (maybe other exist but I don't know them). In this representation, the sign is given by the first bit. That is, in 2's complement representation a positive number starts with a 0 and a negative number starts with an 1.
And here the problem rises: Is 0 a positive number or a negative number ? It can't be both, because it would mean that 0 can be represented in two manners for a given number a bits (for 5: 00000 and 10000), that is we lose the space to put one more number. I have no idea how they decided, but fact is 0 is a positive number. For any number of bits, signed or unsigned, a 0 is represented with only 0.
Great. This gives us the answer to the first question: what is the upper bound for a decimal number represented in 2's complement ? We know that the first bit is for the sign, so all of the numbers we can represent must be composed of 4 bits. We can have 16 different values of 4-bits strings, and 0 is one of them, so the upper bound is 15.
Now, for the negative numbers, this becomes easy. We have already filled 16 values out of the 32 we can make on 5 bits. 16 left. We also know that 0 has already been represented, so we don't need to include it. Then we start at the number right before 0: -1. As we have 16 numbers to represent, starting from -1, the lowest signed integer we can represent on 5 bits is -16.
More generally, with n bits we can represent 2^n numbers. With signed integers, half of them are positive, and half of them are negative. That is, we have 2^(n-1) positive numbers and 2^(n-1) negative numbers. As we know 0 is considered as positive, the greatest signed integer we can represent on n bits is 2^(n-1) - 1 and the lowest is -2^(n-1)
2's complement representation
Now that we know which numbers can be represented on 5 bits, the question is to know how we represent them.
We already saw the sign is represented on the first bit, and that 0 is considered as positive. For positive numbers, it works the same way as it does for unsigned integers: 00000 is 0, 00001 is 1, 00010 is 2, etc until 01111 which is 15. This is where we stop for positive signed integers because we have occupied all the 16 values we had.
For negative signed integers, this is different. If we keep the same representation (10001 is -1, 10010 is -2, ...) then we end up with 11111 being -15 and 10000 not being attributed. We could decide to say it's -16 but we would have to check for this particular case each time we work with negative integers. Plus, this messes up all of the binary operations. We could also decide that 10000 is -1, 10001 is -2, 10010 is -3 etc. But it also messes up all of the binary operations.
2's complement works the following way. Let's say you have the signed integer 10011, you want to know what decimal is is.
Flip all the bits: 10011 --> 01100
Add 1: 01100 --> 01101
Read it as an unsigned integer: 01101 = 0*2^4 + 1*2^3 + 1*2^2 + 0*2^1 + 1*2^0 = 13.
10011 represents -13. This representation is very handy because it works both ways. How to represent -7 as a binary signed integer ? Start with the binary representation of 7 which is 00111.
Flip all the bits: 00111 --> 11000
Add 1: 11000 --> 11001
And that's it ! On 5 bits, -7 is represented by 11001.
I won't cover it, but another great advantage with 2's complement is that the addition works the same way. That is, When adding two binary numbers you do not have to care if they are signed or unsigned, this is the same algorithm behind.
With this, you should be able to answer the questions, but more importantly to understand the answers.
This topic is great for understanding 2's complement: Why is two's complement used to represent negative numbers?
I've got a question to which I need someone to help me verify to see if my answer is correct or not.
Showing all steps involved, convert the unsigned decimal number 28.2 to:
Hexadecimal, using 1 digit for the integer part and 2 for the fractional part.
I come up with the answer C1.33, but since I am only allowed 1 digit for the integer part I would assume I would remove the 1?
Hex, or hexadecimal, is a number system of base 16.hex digits are
0,1,2,3,4,5,6,7,8 and 9 A, B, C, D, E, F
decimal hex
C1 28
C 12
1 1
For 28 is C1 in hex, you cannot represent it with either c or 1
Please refer: link
My computer uses ASCII, American Standard Code for Information Exchange.
It is my understanding that this uses a 7 bit code to represent all the letters, symbols, and numbers needed for the english language.
It is my understanding that these 7 bits can be represented with hexadecimal codes.
I thought that hexadecimal needed 8 bits. 4 bits per number.
Can some one explain to me how the hexadecimal system can be used to represent the codes in the 7 bit ASCII system.
Thanks in advance.
Hexadecimal numbers don't need eight bits, each hex digit can represent four bits but there's no upper limit, since you can just use more digits:
0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffff...
For representing seven-bit values, you can just use the lower half of the eight-bit hex numbers, 0x00 through 0x7f.
That gives you the binary numbers 0000000 through 1111111.
With 7 bits you can represent every number from 0 to 2^7 = 127 (decimal) = 7f (hexadecimal).
Hexadecimal doesn't need 7 bits, it is just another way to write numbers.
You can combine any combination of up to 4 bits into one hexadecimal character.
1 bit: 0 to 1
2 bits: 0 to 3
3 bits: 0 to 7
4 bits: 0 to F
For 7 bits you need 2 hex digit, one coding 3 bits and the other 4 bits so you get a code of 00 to 7F.
Or you use 8 bits, but the most significant bit is always 0.
i've been asked to work on the following question with the following specification/ rules...
Numbers are held in 16 bits split from left to right as follows:
1 bit sign flag that should be set for negative numbers and otherwise clear.
7 bit exponent held in Excess 63
8 bit significand, normalised to 1.x with only the fractional part stored – as in IEEE 754
Giving your answers in hexadecimal, how would the number -18 be represented in this system?
the answer is got is: 11000011 00100000 (or C320 in hexadecimal)
using the following method:
-18 decimal is a negative number so we have the sign bit set to 1.
18 in binary would be 0010010. This we could note down as 10010. We know work on what’s on the right side of the decimal point but in this case we don’t have any decimal point or fractions so we note down 0000 0000 since there are no fractions. We now write down the binary of 18 and the remainder zeroes (which are not necessarily required) and separate them with a decimal point as shown below:
10010.00000000
We now normalise this into the form 1.x by moving the decimal point and placing it between the first and second number (counting the amount of times we move the decimal point until it reaches that area). The result now is 1.001000000000 x 2^4 and we also know that the decimal point has been moved 4 times which for now we will consider to be our exponent value. The floating point system we are using has 7 bit exponent and uses excess 63. The exponent is 4 in excess 63 which would equal to 63 + 4 = 67 and this in 7 bit binary is shown as 1000011.
The sign bit is: 1 (-ve)
Exponent is: 1000011
Significand is 00100…
The binary representation is: 11000011 00100000 (or C320 in hexadecimal)
please let me know if it's correct or if i've done it wrong and what changes could be applied. thank you guy :)
Since you seem to have been assigned a lot of questions of this type, it may be useful to write an automated answer checker to validate your work. I've put together a quick converter in Python:
def convert_from_system(x):
#retrieve the first eight bits, and add a ninth bit to the left. This bit is the 1 in "1.x".
significand = (x & 0b11111111) | 0b100000000
#retrieve the next seven bits
exponent = (x >> 8) & 0b1111111
#retrieve the final bit, and determine the sign
sign = -1 if x >> 15 else 1
#add the excess exponent
exponent = exponent - 63
#multiply the significand by 2^8 to turn it from 1.xxxxxxxx into 1xxxxxxxx, then divide by 2^exponent to get back the decimal value.
result = sign * (significand / float(2**(8-exponent)))
return result
for value in [0x4268, 0xC320]:
print "The decimal value of {} is {}".format(hex(value), convert_from_system(value))
Result:
The decimal value of 0x4268 is 11.25
The decimal value of 0xc320 is -18.0
This confirms that -18 does convert into 0xC320.
Since I knew how to manually convert hexadecimal to decimal using this method.
Read from right to left, the last digit multiplied by the constant value 16 and plus the first digit.
For example:
12h = 2 + (1 * 16) = 18
99h = 9 + (9 * 16) = 153
How do I convert back into hex from decimal?
As you can see in the picture above. You need to draw a table in your brain
Lets take 456 as example.
If we divide 456 by 16 . Remainder = 8 & Quotient = 28
We further divide 28 by 16 and get remainder = 12 & quotient = 1
Now further dividing 1 by 16 results in remainder = 1 and quotient = 0
So we stop.
Now we take the remainders, bottom up.
1 , 12 , 8
Converting 12 in hex notation gives C.
So the answer is 1C8
To convert from decimal to hex you must know the powers of 16. 16^1 is obviously 16; 16^2 is 256; 16^3 is 4096; 16^4 is 65536; etc.
For each power of 16, divide the number by that power to get one hex digit. Then take the remainder and divide by the next lower power of 16.
This is enough of a hassle that it's easiest to let a calculator do it, or use a scripting language such as Python.