Does anyone know the steps for dividing unsigned binary integers using non-restoring division?
It's hard to find any good sources online.
i.e if A = 101110 and B = 010111
how do we find A divided by B in non-restoring division? What do the registers look like in each step?
Thanks!
(My answer is a little late-reply. But I hope it will be useful for future visitors)
Algorithm for Non-restoring division is given in below image :
In this problem, Dividend (A) = 101110, ie 46, and Divisor (B) = 010111, ie 23.
Initialization :
Set Register A = Dividend = 000000
Set Register Q = Dividend = 101110
( So AQ = 000000 101110 , Q0 = LSB of Q = 0 )
Set M = Divisor = 010111, M' = 2's complement of M = 101001
Set Count = 6, since 6 digits operation is being done here.
After this we start the algorithm, which I have shown in a table below :
In table, SHL(AQ) denotes shift left AQ by one position leaving Q0 blank.
Similarly, a square symbol in Q0 position denote, it is to be calculated later
Hope all the steps are clear from the table !!!
1) Set the value of register A as 0 (N bits)
2) Set the value of register M as Divisor (N bits)
3) Set the value of register Q as Dividend (N bits)
4) Concatenate A with Q {A,Q}
5) Repeat the following “N” number of times (here N is no. of bits in divisor):
If the sign bit of A equals 0,
shift A and Q combined left by 1 bit and
subtract M from A,
else shift A and Q combined left by 1 bit and add M to A
Now if sign bit of A equals 0, then set Q[0] as 1, else set Q[0] as 0
6) Finally if the sign bit of A equals 1 then add M to A.
7) Assign A as remainder and Q as quotient.
Related
Given a finite random sequence of bits, how can the minimum number of bit toggles necessary to result in a sorted sequence (i.e. any and all 0's are before any and all 1's) be determined?
Note, homogeneous sequences (e.g. 0000000 and 1111111) are considered sorted by this definition.
Also, this is not technically "sorting" the sequence because elements are toggled in-place, not restricted to swapping with other elements, is there better word to describe this activity than "sorting"?
Let Z(n) be the cost of setting the first n bits all 0.
Let X(n) be the cost of minimum cost of "sorting" the first n bits.
We have:
Z(0) = 0, X(0) = 0
if the ith bit is 0: Z(i) = Z(i-1), X(i) = min( Z(i-1), X(i-1)+1 )
if the ith bit is 1: Z(i) = Z(i-1)+1, X(i) = X(i-1)
The answer is X(n).
It's even easier in code:
z=0
x=0
for bit in sequence:
if bit == 0:
x = min(z,x+1)
else:
z = z+1
return x
One canonical dynamic program would be to evaluate in O(1) time and space two states for each bit: the cost of keeping the bit the same or toggling it, while assigning it as rightmost of the relevant section (also incurring the relevant cost for the implied toggles due to the assignment).
Sorry, the above applies to the general problem - where "sorted" could be in either direction. (To choose a direction, pick the relevant one from the best variable assignments below.)
Python code:
def f(bits):
set_bits = sum(bits)
left_ones = 0
best = len(bits)
for i, bit in enumerate(bits):
right_ones = set_bits - left_ones - bit
left_zeros = i - left_ones
right_zeros = len(bits) - i - 1 - right_ones
# As rightmost 0
best = min(best, bit + left_ones + right_zeros)
# As rightmost 1
best = min(best, (bit ^ 1) + left_zeros + right_ones)
left_ones += bit
return best
Output:
bit_sets = [
[1,0,0,1,1], # 1
[1,0,0,1,0,1], # 2
[0,1,1,0,1,0], # 2
[1,1,1,1], # 0
[0,0,1,1], # 0
[0,1,0,0,0], # 1
[1,0,1,1,1] # 1
]
for bits in bit_sets:
print(f(bits), bits)
I encountered a problem recently I have a hard time finding the answer.
This is the question:
Consider a set of numbers.There are tree kinds of input:
1 x
2 x
3
The first command adds integer x to the set.
The second one means for every element y in list, put:
y = y xor x
and The last command prints the biggest number in the set. for instance:
10
3
1 7
3
2 4
2 8
2 3
1 10
1 3
3
2 1
results:
0
7
15
if n is the number of commands in input:
and:
also there is a 1 second execution time limit!
My solution so far:
lets call the set S and have an integer m which initially is 0.as you know:
number = number xor x xor x
meaning that if we apply xor twice on something then the its effect is reversed and the original number doesn't change. That being said if we every time we insert a number(command 1) we do the following:
y = y xor m
add y to S
and every time we want to get a number from the set:
find y
y = y xor m
return y
and if command two comes to the following:
m = m xor x
then the problem is almost solved, since initially save the XORed version of the numbers and when needed we do the revers!
But the problem here is to find the largest number in the set( pay attention that the numbers in the set are different from original numbers) so command 3 works right. I don't know how to do this in an efficient time.but I have an idea here:
if we save the binary representation of the numbers in the set in a trie data structure at first the maybe we can quickly find the biggest number. I don't really know how but this idea occurred to me.
so to sum up these are my issues:
problem 1:
how to find the biggest number in the revised list
problem 2:
is this trie idea good?
problem 3:
how can I implement it in code(the language is not very important here) so that it works time find?
also what is the time complexity needed to solve this problem in the first place?
Thanks for reading my question.
Yes your idea is correct, it can be solved in O(N log 10^9) using binary trie data structure.
The idea is to store numbers in binary notation yet putting biggest bits first, so while traversing the trie we can choose a branch that leads to greatest answer.
For determining which branch to choose we can determine this bit by bit, if from some trie node we have 2 branches with values 0 and 1 we choose the one which gives better result after xoring with m
Sample code (C++):
#include <bits/stdc++.h>
using namespace std;
int Trie[4000005][2];
int nxt = 2;
void Add(int x)
{
bitset<32>b(x);
int c = 1;
for(int j=31; j>=0; j--)
if(Trie[c][b[j]])c=Trie[c][b[j]];
else c = Trie[c][b[j]] = nxt++;
}
int Get(int x)
{
bitset<32>b(x),res(0);
int c = 1;
for(int j=31; j>=0; j--)
if(Trie[c][!b[j]])c=Trie[c][!b[j]],res[j]=!b[j];
else c = Trie[c][b[j]], res[j]=b[j];
return res.to_ullong()^x;
}
int main()
{
ios::sync_with_stdio(0);cin.tie(0);cout.tie(0);
int q,m=0;
cin>>q;
Add(0);
while(q--)
{
int type;
cin>>type;
if(type==1)
{
int x;
cin>>x;
Add(x^m);
}
else if(type==2)
{
int x;
cin>>x;
m^=x;
}
else cout<<Get(m)<<"\n";
}
}
This is very similar to this problem and should be solvable in O(n), because the number of bits for x is constant (for 10^9 you will have to look at the 30 lowest bits).
At start m = 0, each time you encounter the 2nd command you do m ^= x (m = m xor x).
Use a binary tree. Unlike for the linked question the amount of numbers in a bucket doesn't matter, you just need to be able to tell if there is a number that has a certain bit which is one or zero. E.g. for 3-bit numbers 1, 4 and 5 the tree could look like this (left means bit is 0, right means bit is 1):
*
/ \
1 1 there are numbers with highest bit 0 and 1
/ /
1 1 of the numbers with 1st bit 0, there is a number with 2nd bit 0 and ...
\ / \
1 1 1 of the numbers with 1st and 2nd bit 0, there is a number with 3rd bit 1,...
1 4 5 (the numbers just to clarify)
So adding a number just means adding some edges and nodes.
To get the highest number in the set you go down the tree and through the bits of m and calculate the max x as follows:
Initialize node n as the root of the tree, i = 29 the bit of m we are looking at and the solution x = 0.
mi = (m & (1 << i)) >> i (1 if the bit in m is 1, 0 otherwise).
If we look at n and there is only an edge denoting a 0 or if mi == 1 and we have a 0-edge: n becomes the node connected by that edge, x = 2 * x + mi (or more fancy: x = (x << 1) | mi).
Otherwise n becomes the node connected by the 1-edge and x = 2 * x + 1 - mi
If i > 0: decrease i by 1 and continue with step 2.
An example for 3-bit numbers m = 6 (110) and the numbers 1 (001), 4 (100) and 5 (101) in the set, the answer should be 7 (111), i.e. 1 xor 6: First step we go left and x = 1, then we can only go left and x = 3, then we can only go right and x = 7.
I'm going through "Elements of Programming Interviews" and the very first question is about computing the parity of a number ( whether the number of 1's in the binary representation is even or odd). The final solution provided does this:
short Parity(unsigned long x) {
x ^= x >> 32;
x ^= x >> 16;
x ^= x >> 8;
x ^= x >> 4;
x &= 0xf;
...
I understand that with that final value of x you can lookup the answer in a lookup table = 0x6996. But my question is why does the above code work? I've worked a 16 bit example out by hand and it does give the correct parity, I just don't understand it conceptually.
The lookup table is confusing. Let's drop it and keep going:
...
x ^= x >> 2;
x ^= x >> 1;
p = x&1;
To figure it out, let's start with the 1-bit case. In the 1-bit case, p=x, so if x is 1 the parity is odd, and if x is 0 the parity is even. Trivial.
Now the two bit case. You look at b0^b1 (bit 0 XOR bit 1) and that's the parity. If they're equal, the parity is even, otherwise it's odd. Simple, too.
Now let's add more bits. In the four bit example - b3 b2 b1 b0, we calculate x ^ (x>>2), which gives us a two bit number: b3^b1 b2^b0 . These are actual two parities - one for the odd bits of the original number, and one for the even bits of the original number. XOR the two parities and we get the original parity.
And now this goes on and on for us many bits as you want.
It works because,
the parity of a single bit is itself (base case)
the parity of the concatenation of bitstrings x and y is the xor of the parity of x and the parity of y
That gives a recursive algorithm by splitting every string down the middle until it's a base case, which you can then group by layer and flip upside down to get the code shown in the question .. sort of, because it ends early and apparently does the last step by lookup.
For an n bit number x, the answer is always in the rightmost n/(2 to the power z) bits of x after z iterations.
Let's take an example where n=8 and x=10110001 (b7, b6, b5, b4, b3, b2, b1, b0).
It's actual/correct answer is even_parity.
After 1 iteration
10110001
00001011
___________
x = 10111010
Rightmost 8/(2 to the power 1) = 4 digits of x = 1010(even parity)
After 2 iterations
10111010
00101110
___________
x = 10010100
Rightmost 8/(2 to the power 2) = 2 digits of x = 00(even parity)
After 3 iterations
10010100
01001010
___________
x = 11011110
Rightmost 8/(2 to the power 3) = 1 digit of x = 0(even parity)
Now we can extract any dth digit of a number b by ANDING it with a
number q in which only the dth digit is 1(one) and all other digits are 0(zero).
Here we want to extract the (0th digit)/(rightmost digit) of final value of x.
So let's AND it(i.e, ( final_value_of_x
(i.e, 11011110)
)
after (
2 to the power(
log n to the base 2
)
) iterations
) with 00000001 to get the answer.
11011110
00000001
_________________
00000000
Here is the problem statement:
Given two integers: L and R,
find the maximal values of A xor B given, L ≤ A ≤ B ≤ R
Input Format:
The input contains two lines, L is present in the first line.
R in the second line.
Constraints :
1 ≤ L ≤ R ≤ 1000
Output Format
The maximal value as mentioned in the problem statement.
Source:
Maximising XOR
Here is one unique solution to the above:
def maxXOR(L,R):
P = L^R
ret = 1
while(P): # this one takes (m+1) = O(logR) steps
ret <<= 1
P >>= 1
return (ret - 1)
print(maxXOR(int(input()),int(input())))
Could you please explain the intuition behind this solution?
Thank you.
There is one simple way using which you can solve the problem in O(1).
Let's start:
Do the bit-wise XOR of L and R and store it in a variable say xored.
Then take the MSB in the xored which is set and make all the bits from that MSB -----> LSB as 1 and that is the answer.
Following example which will make things clear.
L = 10111 --> (23)
R = 11100 --> (28)
_X___ <-- that's most significant differing bit
01111 <-- here's our final answer i.e. (15).
To set all the bits from MSB to LSB, first calculate the 2^n - 1 where n = number of bits required to represent L^R and then do L^R | (2^(n) - 1).
Solution in Python:
import math
def main():
xored = int(input().strip()) ^ int(input().strip())
print("{}".format(xored | ((1 << (1 + int(math.log2(xored)))) - 1)))
if __name__ == "__main__":
main()
NOTE: You can refer to solution in C and C++ here!.
I've got another interesing programming/mathematical problem.
For a given natural number q from interval [2; 10000] find the number n
which is equal to sum of q-th powers of its digits modulo 2^64.
for example: for q=3, n=153; for q=5, n=4150.
I wasn't sure if this problem fits more to math.se or stackoverflow, but this was a programming task which my friend told me quite a long time ago. Now I remembered that and would like to know how such things can be done. How to approach this?
There are two key points,
the range of possible solutions is bounded,
any group of numbers whose digits are the same up to permutation con contain at most one solution.
Let us take a closer look at the case q = 2. If a d-digit number n is equal to the sum of the squares of its digits, then
n >= 10^(d-1) // because it's a d-digit number
n <= d*9^2 // because each digit is at most 9
and the condition 10^(d-1) <= d*81 is easily translated to d <= 3 or n < 1000. That's not many numbers to check, a brute-force for those is fast. For q = 3, the condition 10^(d-1) <= d*729 yields d <= 4, still not many numbers to check. We could find smaller bounds by analysing further, for q = 2, the sum of the squares of at most three digits is at most 243, so a solution must be less than 244. The maximal sum of squares of digits in that range is reached for 199: 1² + 9² + 9² = 163, continuing, one can easily find that a solution must be less than 100. (The only solution for q = 2 is 1.) For q = 3, the maximal sum of four cubes of digits is 4*729 = 2916, continuing, we can see that all solutions for q = 3 are less than 1000. But that sort of improvement of the bound is only useful for small exponents due to the modulus requirement. When the sum of the powers of the digits can exceed the modulus, it breaks down. Therefore I stop at finding the maximal possible number of digits.
Now, without the modulus, for the sum of the q-th powers of the digits, the bound would be approximately
q - (q/20) + 1
so for larger q, the range of possible solutions obtained from that is huge.
But two points come to the rescue here, first the modulus, which limits the solution space to 2 <= n < 2^64, at most 20 digits, and second, the permutation-invariance of the (modular) digital power sum.
The permutation invariance means that we only need to construct monotonous sequences of d digits, calculate the sum of the q-th powers and check whether the number thus obtained has the correct digits.
Since the number of monotonous d-digit sequences is comparably small, a brute-force using that becomes feasible. In particular if we ignore digits not contributing to the sum (0 for all exponents, 8 for q >= 22, also 4 for q >= 32, all even digits for q >= 64).
The number of monotonous sequences of length d using s symbols is
binom(s+d-1, d)
s is for us at most 9, d <= 20, summing from d = 1 to d = 20, there are at most 10015004 sequences to consider for each exponent. That's not too much.
Still, doing that for all q under consideration amounts to a long time, but if we take into account that for q >= 64, for all even digits x^q % 2^64 == 0, we need only consider sequences composed of odd digits, and the total number of monotonous sequences of length at most 20 using 5 symbols is binom(20+5,20) - 1 = 53129. Now, that looks good.
Summary
We consider a function f mapping digits to natural numbers and are looking for solutions of the equation
n == (sum [f(d) | d <- digits(n)] `mod` 2^64)
where digits maps n to the list of its digits.
From f, we build a function F from lists of digits to natural numbers,
F(list) = sum [f(d) | d <- list] `mod` 2^64
Then we are looking for fixed points of G = F ∘ digits. Now n is a fixed point of G if and only if digits(n) is a fixed point of H = digits ∘ F. Hence we may equivalently look for fixed points of H.
But F is permutation-invariant, so we can restrict ourselves to sorted lists and consider K = sort ∘ digits ∘ F.
Fixed points of H and of K are in one-to-one correspondence. If list is a fixed point of H, then sort(list) is a fixed point of K, and if sortedList is a fixed point of K, then H(sortedList) is a permutation of sortedList, hence H(H(sortedList)) = H(sortedList), in other words, H(sortedList) is a fixed point of K, and sort resp. H are bijections between the set of fixed points of H and K.
A further improvement is possible if some f(d) are 0 (modulo 264). Let compress be a function that removes digits with f(d) mod 2^64 == 0 from a list of digits and consider the function L = compress ∘ K.
Since F ∘ compress = F, if list is a fixed point of K, then compress(list) is a fixed point of L. Conversely, if clist is a fixed point of L, then K(clist) is a fixed point of K, and compress resp. K are bijections between the sets of fixed points of L resp. K. (And H(clist) is a fixed point of H, and compress ∘ sort resp. H are bijections between the sets of fixed points of L resp. H.)
The space of compressed sorted lists of at most d digits is small enough to brute-force for the functions f under consideration, namely power functions.
So the strategy is:
Find the maximal number d of digits to consider (bounded by 20 due to the modulus, smaller for small q).
Generate the compressed monotonic sequences of up to d digits.
Check whether the sequence is a fixed point of L, if it is, F(sequence) is a fixed point of G, i.e. a solution of the problem.
Code
Fortunately, you haven't specified a language, so I went for the option of simplest code, i.e. Haskell:
{-# LANGUAGE CPP #-}
module Main (main) where
import Data.List
import Data.Array.Unboxed
import Data.Word
import Text.Printf
#include "MachDeps.h"
#if WORD_SIZE_IN_BITS == 64
type UINT64 = Word
#else
type UINT64 = Word64
#endif
maxDigits :: UINT64 -> Int
maxDigits mx = min 20 $ go d0 (10^(d0-1)) start
where
d0 = floor (log (fromIntegral mx) / log 10) + 1
mxi :: Integer
mxi = fromIntegral mx
start = mxi * fromIntegral d0
go d p10 mmx
| p10 > mmx = d-1
| otherwise = go (d+1) (p10*10) (mmx+mxi)
sortedDigits :: UINT64 -> [UINT64]
sortedDigits = sort . digs
where
digs 0 = []
digs n = case n `quotRem` 10 of
(q,r) -> r : digs q
generateSequences :: Int -> [a] -> [[a]]
generateSequences 0 _
= [[]]
generateSequences d [x]
= [replicate d x]
generateSequences d (x:xs)
= [replicate k x ++ tl | k <- [d,d-1 .. 0], tl <- generateSequences (d-k) xs]
generateSequences _ _ = []
fixedPoints :: (UINT64 -> UINT64) -> [UINT64]
fixedPoints digFun = sort . map listNum . filter okSeq $
[ds | d <- [1 .. mxdigs], ds <- generateSequences d contDigs]
where
funArr :: UArray UINT64 UINT64
funArr = array (0,9) [(i,digFun i) | i <- [0 .. 9]]
mxval = maximum (elems funArr)
contDigs = filter ((/= 0) . (funArr !)) [0 .. 9]
mxdigs = maxDigits mxval
listNum = sum . map (funArr !)
numFun = listNum . sortedDigits
listFun = inter . sortedDigits . listNum
inter = go contDigs
where
go cds#(c:cs) dds#(d:ds)
| c < d = go cs dds
| c == d = c : go cds ds
| otherwise = go cds ds
go _ _ = []
okSeq ds = ds == listFun ds
solve :: Int -> IO ()
solve q = do
printf "%d:\n " q
print (fixedPoints (^q))
main :: IO ()
main = mapM_ solve [2 .. 10000]
It's not optimised, but as is, it finds all solutions for 2 <= q <= 10000 in a little below 50 minutes on my box, starting with
2:
[1]
3:
[1,153,370,371,407]
4:
[1,1634,8208,9474]
5:
[1,4150,4151,54748,92727,93084,194979]
6:
[1,548834]
7:
[1,1741725,4210818,9800817,9926315,14459929]
8:
[1,24678050,24678051,88593477]
9:
[1,146511208,472335975,534494836,912985153]
10:
[1,4679307774]
11:
[1,32164049650,32164049651,40028394225,42678290603,44708635679,49388550606,82693916578,94204591914]
And ending with
9990:
[1,12937422361297403387,15382453639294074274]
9991:
[1,16950879977792502812]
9992:
[1,2034101383512968938]
9993:
[1]
9994:
[1,9204092726570951194,10131851145684339988]
9995:
[1]
9996:
[1,10606560191089577674,17895866689572679819]
9997:
[1,8809232686506786849]
9998:
[1]
9999:
[1]
10000:
[1,11792005616768216715]
The exponents from about 10 to 63 take longest (individually, not cumulative), there's a remarkable speedup from exponent 64 on due to the reduced search space.
Here is a brute force solution that will solve for all such n, including 1 and any other n greater than the first within whatever range you choose (in this case I chose base^q as my range limit). You could modify to ignore the special case of 1 and also to return after the first result. It's in C#, but might look nicer in a language with a ** exponentiation operator. You could also pass in your q and base as parameters.
int q = 5;
int radix = 10;
for (int input = 1; input < (int)Math.Pow(radix, q); input++)
{
int sum = 0;
for (int i = 1; i < (int)Math.Pow(radix, q); i *= radix)
{
int x = input / i % radix; //get current digit
sum += (int)Math.Pow(x, q); //x**q;
}
if (sum == input)
{
Console.WriteLine("Hooray: {0}", input);
}
}
So, for q = 5 the results are:
Hooray: 1
Hooray: 4150
Hooray: 4151
Hooray: 54748
Hooray: 92727
Hooray: 93084