Minimum Number of Bits Required for Two's Complement Form - c++

On my midterm, there was a question stating:
Given the decimal values, what is the minimum number of bits required to represent each number in Two's Complement form?
The values were: -26, -1, 10, -15, -4.
I did not get this question right whatsoever, and the solutions are quite baffling.
The only part I really understand is finding the range in which the value is located. For example, -15 would be within the range of [-2^5, 2^5), and -4 would be in the range from [-2^2, 2^2). What steps are needed from here in order to find how many bits were necessary?
I tried finding some pattern to solve it, but it only worked for the first two cases. Here's my attempt:
First I found the range. -2^6 < -26 < 2^6
Then I found the value for 2^6 = 32.
Then I found the difference between the "closest" bound, and the value.
-26 - (-32) = 6
Again, this worked for the first two values by chance, and now I'm stumped as to find the actual relation between the number of bits required for an integer to be represented in Two's complement form, and the actual integer.
Thanks in advance!

First off, you're off on your powers of 2. 32 = 25.
Anyway, I followed you through the first two steps. Your last step doesn't make sense.
Find the power-of-two range that brackets the number. You want a power-of-two range of the form [-2N, 2N - 1]. So, for -26, that would be -25 &leq; -26 &leq; 25 - 1. That corresponds to -32 &leq; -26 &leq; 31.
Number of bits for the 2s complement representation will then simply be N plus 1. The "plus 1" accounts for the sign bit. For -26, that's 5 + 1 = 6.
So, for each of the numbers you gave: -26, -1, 10, -15, -4.
-25 &leq; -26 &leq; 25 - 1 becomes -32 &leq; -26 &leq; 31, which gives 5 + 1 = 6.
-20 &leq; -1 &leq; 20 - 1 becomes -1 &leq; -1 &leq; 0, which gives 0 + 1 = 1.
-24 &leq; 10 &leq; 24 - 1 becomes -16 &leq; 10 &leq; 15, which gives 4 + 1 = 5.
-24 &leq; -15 &leq; 24 - 1 becomes -16 &leq; -15 &leq; 15, which gives 4 + 1 = 5.
-22 &leq; -4 &leq; 22 - 1 becomes -4 &leq; -4 &leq; 3, which gives 2 + 1 = 3.
Got it?
The -1 one is tricky...

Related

C++ how would you find a number with the most similar bits in N integers?

For example say I have 3 integers 18 9 21
those 3 integers in binary : 10010, 10001, 10101
and say there's a number x I want that number to basically be the most similar bits for example the first digit of each number is 1 so x will start off as "1.....". The second digit of all three numbers is zero, so it will be "10...". The third digit is a mix: We have a 0,0 and a 1. but we have more zeros than 1's so x will be "100.." etc.
Is there any way to do this? I've been looking at bitwise operators and I'm just not sure how to do this? Because bitwise and doesn't really work on three numbers like this because if it sees even just one zero it will just return 0
I would simply add the bits if I were you: imagine the numbers: 17, 9 and 21, and let's write them in binary:
17 : 10001
9 : 01001
21 : 10101
Put this in a "table" and sum your binary digits:
1 0 0 0 1
0 1 0 0 1
1 0 1 0 1
2 1 1 0 3
... and then you say "When I have 0 or 1, I put '0', when 2 or 3, I put '1'", then you get:
1 0 0 0 1
=> your answer becomes "10001" which equals 17.

Understanding two's complement

I don't understand why an n-bit 2C system number can be extended to an (n+1)-bit 2C system number by making bit bn = bn−1, that is, extending to (n+1) bits by replicating the sign bit.
This works because of the way we calculate the value of a binary integer.
Working right to left, the sum of each bit_i * 2 ^ i,
where
i is the range 0 to n
n is the number of bits
Because each subsequent 0 bit will not increase the magnitude of the sum, it is the appropriate value to pad a smaller value into a wider bit field.
For example, using the number 5:
4 bit: 0101
5 bit: 00101
6 bit: 000101
7 bit 0000101
8 bit: 00000101
The opposite is true for negative numbers in a two's compliment system.
Remember you calculate two's compliment by first calculating the one's compliment and then adding 1.
Invert the value from the previous example to get -5:
4 bit: 0101 (invert)-> 1010 + 1 -> 1011
5 bit: 00101 (invert)-> 11010 + 1 -> 11011
6 bit: 000101 (invert)-> 111010 + 1 -> 111011
7 bit: 0000101 (invert)-> 1111010 + 1 -> 1111011
8 bit: 00000101 (invert)-> 11111010 + 1 -> 11111011

Ternary Numbers, regex

I'm looking for some regex/automata help. I'm limited to + or the Kleene Star. Parsing through a string representing a ternary number (like binary, just 3), I need to be able to know if the result is 1-less than a multiple of 4.
So, for example 120 = 0*1+2*3+1*9 = 9+6 = 15 = 16-1 = 4(n)-1.
Even a pointer to the pattern would be really helpful!
You can generate a series of values to do some observation with bc in bash:
for n in {1..40}; do v=$((4*n-1)); echo -en $v"\t"; echo "ibase=10;obase=3;$v" | bc ; done
3 10
7 21
11 102
15 120
19 201
23 212
27 1000
31 1011
...
Notice that each digit's value (in decimal) is either 1 more or 1 less than something divisible by 4, alternately. So the 1 (lsb) digit is one more than 0, the 3 (2nd) digit is one less than 4, the 9 (3rd) digit is 1 more than 8, the 27 (4th) digit is one less than 28, etc.
If you sum up all the even-placed digits and all the odd-placed digits, then add 1 to the odd-placed ones (if counting from 1), you should get equality.
In your example: odd: (0+1)+1, even: (2). So they are equal, and so the number is of the form 4n-1.

represent negative number with 2' complement technique?

I am using 2' complement to represent a negative number in binary form
Case 1:number -5
According to the 2' complement technique:
Convert 5 to the binary form:
00000101, then flip the bits
11111010, then add 1
00000001
=> result: 11111011
To make sure this is correct, I re-calculate to decimal:
-128 + 64 + 32 + 16 + 8 + 2 + 1 = -5
Case 2: number -240
The same steps are taken:
11110000
00001111
00000001
00010000 => recalculate this I got 16, not -240
I am misunderstanding something?
The problem is that you are trying to represent 240 with only 8 bits. The range of an 8 bit signed number is -128 to 127.
If you instead represent it with 9 bits, you'll see you get the correct answer:
011110000 (240)
100001111 (flip the signs)
+
000000001 (1)
=
100010000
=
-256 + 16 = -240
Did you forget that -240 cannot be represented with 8 bits when it is signed ?
The lowest negative number you can express with 8 bits is -128, which is 10000000.
Using 2's complement:
128 = 10000000
(flip) = 01111111
(add 1) = 10000000
The lowest negative number you can express with N bits (with signed integers of course) is always - 2 ^ (N - 1).

Find rank of a number on basis of number of 1's

Let f(k) = y where k is the y-th number in the increasing sequence of non-negative integers with
the same number of ones in its binary representation as k, e.g. f(0) = 1, f(1) = 1, f(2) = 2, f(3) = 1, f(4)
= 3, f(5) = 2, f(6) = 3 and so on. Given k >= 0, compute f(k)
many of us have seen this question
1 solution to this problem to categorise numbers on basis of number of 1's and then find the rank.i did find some patterns going by this way but it would be a lengthy process. can anyone suggest me a better solution?
This is a counting problem. I think that if you approach it with this in mind, you can do much better than literally enumerating values and checking how many bits they have.
Consider the number 17. The binary representation is 10001. The number of 1s is 2. We can get smaller numbers with two 1s by (in this case) re-distributing the 1s to any of the four low-order bits. 4 choose 2 is 6, so 17 should be the 7th number with 2 ones in the binary representation. We can check this...
0 00000 -
1 00001 -
2 00010 -
3 00011 1
4 00100 -
5 00101 2
6 00110 3
7 00111 -
8 01000 -
9 01001 4
10 01010 5
11 01011 -
12 01100 6
13 01101 -
14 01110 -
15 01111 -
16 10000 -
17 10001 7
And we were right. Generalize that idea and you should get an efficient function for which you simply compute the rank of k.
EDIT: Hint for generalization
17 is special in that if you don't consider the high-order bit, the number has rank 1; that is, f(z) = 1 where z is everything except the higher order bit. For numbers where this is not the case, how can you account for the fact that you can get smaller numbers without moving the high-order bit?
f(k) are integers less than or equal to k that have the same number of ones in their binary representation as k.
For example, k needs m bits, that is k = 2^(m-1) + a, where a < 2^(m-1). The number of integers less than 2^(m-1) that have the same number of bits as k is choose(m-1, bitcount(k)), since you can freely redistribute the ones among the m-1 least significant bits.
Integers that are greater than or equal to 2^(m-1) have the same most significant bit as k (which is 1), so there are f(k - 2^(m-1)) of them. This implies f(k) = choose(m-1, bitcount(k)) + f(k-2^(m-1)).
See "Efficiently Enumerating the Subsets of a Set". Look at Table 3, the "Bankers sequence". This is a method to generate exactly the sequence you need (if you reverse the bit order). Just run K iterations for the word with K bits. There is code to generate it included in the paper.