I am trying to use Horner's rule to convert words to integers. I understand how it works and how if the word is long, it may cause an overflow. My ultimate goal is to use the converted integer in a hash function h(x)=x mod tableSize. My book suggests, because of the overflow, you could "apply the mod operator after computing each parenthesized expression in Horner's rule." I don't exactly understand what they mean by this. Say the expression looks like this:
((14*32+15)*32+20)*32+5
Do I take the mod tableSize after each parenthesized expression and add them together? What would it look like with this hash function and this example of Horner's rule?
The book is saying that you should take advantage of these mathematical equivalences:
(a * b) mod m = ((a mod m) * (b mod m)) mod m
(a + b) mod m = ((a mod m) + (b mod m)) mod m
Thus,
h = (((x*c) + y)*c + z) mod m
Is equivalent to
_ _ _ _
h = (((x*c) + y)*c + z)
Where
_
a * b = ((a mod m) * (b mod m)) mod m
_
a + b = ((a mod m) + (b mod m)) mod m
Essentially, for each basic addition and basic subtraction, you replace it with an "advanced" version that mod the operands, and mod the results. Since operands to the basic multiplication are now in the range of 0..m-1, the biggest number you'll get is (m-1)^2, which can alleviate overflow if m is small enough.
See also
Wikipedia:modular exponentiation
Wikipedia:modulo operation
-1 mod 2 = 1 mathematically, but -1 % 2 in Java is -1.
By the way, it should be pointed out that 32 is a terrible choice of multiplier for hash functions of this class (since it's not a prime), especially for computing (since it's a power of 2). Much better is 31, because:
It's prime (mathematically important!)
It's one less than a power of two, so it can be optimized to a cheaper shift and subtract
31 * i == (i << 5) - i
They mean replace the result of a parenthesized expression with that result mod tableSize:
((((14*32+15)%tableSize)*32+20)%tableSize)*32+5
It's easier to understand this using the Java code. We should apply the modulo operator at each step in the calculation inside the loop:
public static int hashCode(String key) {
int hashVal = 0;
for (int j = 0; j < key.length(); j++) {
// For small letters.
int letter = key.charAt(j) - 96;
hashVal = (hashVal * 32 + letter) % arraySize; // mod
}
return hashVal;
}
Related
this is so far all i have done
i am trying to optimize the code for less time.but it is not working.
for _ in range(int(input())):
n, m = map(int, input().split())
count = 0
for i in range(1, n+1):
for j in range(1, n+1):
if i < j <= n and ((m%i)%j) == ((m%j)%i):
count += 1
print(count)
another approach I tried:
if i < j <= n and (m-(m%j))%i == 0:
both condition give correct result.but show time limit exceed
what should i do.thanks
Since a < b, we infer that (M mod a) mod b = M mod a, so the condition is equivalent to M mod a = (M mod b) mod a, i.e., M − (M mod b) is a multiple of a. We can iterate over all b and count factors of M − (M mod b) using a sieve, resulting in a Θ(N + M log N)-time algorithm.
N = 2304
M = 23498
def fast():
npairs = 0
nfactors = [1] * (M + 1)
for b in range(2, N + 1):
npairs += nfactors[M - M % b]
for i in range(0, M + 1, b):
nfactors[i] += 1
return npairs
def naive():
return sum((M % a) % b == (M % b) % a for b in range(2, N + 1) for a in range(1, b))
print(fast(), naive())
Think of it like x%mod(a) is same as x%mod(b) only condition a<b and if mod(b) is calculated, don't need to calculate mod(a) again if its already stored .
(n-1) is for all the pairs of 1's
for _ in range(int(input())):
n,m=map(int,input().split())
count=0
dictitems=defaultdict(int)
for i in range(2,n+1):
rem=m%i
count+=dictitems[rem]
for j in range(rem,n+1,i):
dictitems[j]+=1
print(count+(n-1))
Your approach is a good start but takes exactly N * N iterations.
You can start with following improvements.
sort the data
Using 2 pointer approach with optimised search range for second pointer
for i in range(1, n+1):
for j in range(i+1, n+1): # note j start at `i+1`
I have created a method that allows me to find the GCF/GCD of two numbers, and although I have a working code, I don't know how or why it works. I understand Euclid's algorithm, but am not sure how the following snippet uses it.
private int gcd(int a, int b)
{
if (b == 0)
return a;
else if(a ==0)
return b;
else
return gcd(b, a % b);
}
I am especially confused on what it is returning, because why are were returning two values? And what does the a % b do? How does this use Euclid's algorithm?
"the greatest common divisor of two numbers does not change if the
larger number is replaced by its difference with the smaller number."
(wikipedia - Euclidean algorithm)
So, modulo:
Modulo returns the remainder of the integer divison between two integers. Integer division is divison without fractions or floating points. Let's denote integer division as m /\ n.
m /\ n = o;
m % n = p;
o * n + p = m;
As an example,
29 /\ 3 = 9; (3 goes - whole - into 29 9 times)
29 % 3 = 2; (the integer division of 29 into 3 has a remainder of 2)
9 * 3 + 2 = 29; (9 goes into 29 3 times (and 3 goes into 29 9 times), with a remainder of 2)
Note that if m is smaller than n (i.e. m < n), then n goes into m 0 times (m /\ n = 0), so the remainder of the integer division will be m (m % n = m, because o * n + p = m and so (0*n) + p = 0 + p = p = m);
So, how does the function work? let's try using it.
1 - gcd(m, n), m < n
So, if we start out gcd(m, n) with an m that is smaller than n, the only thing that happens on the next nested call to gcd is that the order of the arguments changes: gcd(n, m % n) = gcd(n, m);
2 - gcd(n, m), m < n
Okay, so now the first argument larger than the second.
According to euclid's algorithm, we want to do something to the larger of the two numbers. We want to replace it with the difference between it and the smaller number. We could do m - n a bunch of times. But what m % n does is the exact same as subtracting n from m as many times as possible before doing so would result in a negative number. Doing a subtraction would look like (((m - n) - n) - n) - n) and so on. But if we expand that out, we get:
m - (n * o). Because o * n + p = m, we can see that m - (n * o) = p and p = m % n. So, repeatedly subtracting the smaller from the larger is the same as doing modulo of the larger with the smaller.
In the next step, the second argument may be 0 (if n was a divisor of m). In this case, the function returns n. this is correct because n is a divisor of itself and also, as we've seen, a divisor of m.
Or, the second argument may be smaller than n. That is because the remainder of the integer divison of m into n must be smaller than n - this is because, if the remainder of the division were larger than n, then n could have fit into m one more time, which it didn't; this is an absurd result. Assuming that n is not 0, then the second argument (let's call it p) is smaller than n.
So, we are now calling gcd(n, p), where p < n.
3 - gcd(n, p), p < n
What happens now? well, we are exactly in the same place as we were in the previous paragraph. Now we just repeat that step, i.e. we will continue to call gcd(a, b), until the smaller of the two numbers that are passed into gcd(a ,b) is a divisor of the larger of the two numbers, (meaning that a % b = 0) in which case you simply return the smaller of the two numbers.
1) What does the a % b do?
% is the modulus or remainder operator in Java. The % operator returns the remainder of two numbers. For example 8 % 3 is 2 because 8 divided by 3 leaves a remainder of 2.
2) The Euclidean algorithm is based on the principle that the greatest common divisor of two numbers does not change if the larger number is replaced by its difference with the smaller number. Actually, your gcd function is used a more efficient version of the Euclidean algorithm. This version instead replacing the larger of the two numbers by its remainder when divided by the smaller of the two (with this version, the algorithm stops when reaching a zero remainder). This was proven by Gabriel Lamé in 1844 (https://en.wikipedia.org/wiki/Euclidean_algorithm)
3) Your gcd function's not returning two values, it's a recursive function. The recursive function is a function which either calls itself or is in a potential cycle of function calls. In case of your gcd function, it will be repeat until one of two parameters become zero and the gcd value is the remain parameter.
You could learn more about recursive function at this link.
http://pages.cs.wisc.edu/~calvin/cs110/RECURSION.html
Given that your question has a few components, I’ll discuss the evolution of Euclid’s classical algorithm into the recursive method you presented. Please note that the methods presented here assume that a >= b
The method below most likely implements the algorithm that you are familiar with, which repeatedly subtracts b (the smaller number) from a (the larger number), until it is no longer larger or equal to b. If a == 0, there is no remainder, giving b as the GCD. Otherwise, the values of a and b are swapped and repeated subtraction continues.
public int classic_gcd(int a, int b) {
while (true) {
while (a >= b)
a = a - b;
if (a == 0)
return b;
int c = b;
b = a;
a = c;
}
}
Since the inner while loop, essentially calculates the reminder of a divided by b, it can be replaced with the modulus operator. This greatly improves the convergence rate of the algorithm, replacing a potentially large number of subtractions with a single modulus operation. Consider finding the GCD of 12,288 and 6, which would result in over 2,000 subtraction. This improvement is shown in the modified method below.
public int mod_gcd(int a, int b) {
while (true) {
int c = a % b;
if (c == 0)
return b;
a = b;
b = c;
}
}
Lastly, the modified algorithm can be expressed as a recursive algorithm, that is, it calls upon itself, as follows:
public int recurse_gcd(int a, int b) {
if (b == 0)
return a;
else
return recurse_gcd(b, a % b);
}
This method accomplishes the same as before. However, rather than looping, the method calls itself (which if not checked is an endless loop too). The swapping of values is accomplishing by changing the order of the arguments passed to the method.
Mind you, the methods above are purely for demonstration and should not be used in production code.
for(int i = 1; i <= 5; i++) {
for(int j = 1; j <= i; j++) {
int a = i + j*2;
System.out.print(a);
}
}
when run the above code I am getting output as
3
46
579
681012
79111315
I am not able to understand why it is printing first row as 3, i+j*2 =4 as per the logic.
I am not able to understand why it is printing first row as 3, i+j*2 =4 as per the logic.
Precedence. Multiplication takes precedence over addition, so on the first call, i+j*2 is 1+1*2 which is 1+(1*2) which is 1+2 which is 3.
The precedence of basic operations can be remembered with PEMDAS or BODMAS (the "MD" and "AS" have the same precedence, so I've shown them on a single line here):
P Parentheses / Brackets B
E Exponenentiation / Orders1 O
MD Multiplication & Division DM
AS Addition and Subtraction AS
1 Powers (2^5), square roots, etc.
The Java site has a page on operator precedence, which has this table:
postfix expr++ expr--
unary ++expr --expr +expr -expr ~ !
multiplicative * / %
additive + -
shift << >> >>>
relational < > <= >= instanceof
equality == !=
bitwise AND &
bitwise exclusive OR ^
bitwise inclusive OR |
logical AND &&
logical OR ||
ternary1 ? :
assignment = += -= *= /= %= &= ^= |= <<= >>= >>>=
1 They mean the conditional operator, which is a ternary operator (an operator accepting three operands) and as it happens, the only one Java has.
Multiplication (*) has arithmetic precedence over addition (+). In the first iteration, i and j are both 1. The first thing to be calculated is j*2, i.e., 1*2=2. Then we add i and the previously calculated product and get 1+2=3.
How do I compute F(n)%mod where mod is a prime number.
and F(n)=n!/(q!^r)%mod....(x^r stands for pow(x,r)).
I'm trying it with fermat's little theorem for computing the inverse modulo but the problem I'm facing is that fermat is applicable only if gcd(denominator,mod)=1.
So is there any other way to solve this.
If the modulus is prime, you can compute the inverse using the extended Euclidean algorithm:
function inverse(x, m)
a, b, u = 0, m, 1
while x > 0
q = b // x # integer division
x, a, b, u = b % x, u, x, a - q * u
if b == 1 return a % m
error "must be coprime"
If the modulus is composite, this algorithm will still work as long as x and m are coprime. If they share a factor, then the inverse does not exist.
There is no modular inverse if the gcd is not 1. Right at the top of the Wikipedia page:
The multiplicative inverse of a modulo m exists if and only if a and m are coprime (i.e., if gcd(a, m) = 1).
As you are trying to compute this quotient modulo p (for a certain prime), let me assume that you know the result is an integer.
As people have mentioned, if q >= p, then you cannot compute the inverse of the denominator, as q! is not coprime with the modulo, so this number is not invertible. But that does not mean that you cannot compute the whole quotient modulo p.
Let a, b be the number of p factors in the numerator and the denominator, respectively. As the result is an integer, we have a >= b. If the inequality is strict, then the result is 0. Otherwise, if equality holds we can remove those factors from numerator and denominator and proceed, as now the denominator is coprime with p.
So let me start with the method for computing those a, b numbers efficiently. The key is known as De Polignac's formula, and it says that for a given k, the number of p factors in k! can be calculated like this:
int polignac(int k, int p) {
int res = 0, power = p;
while (k >= power) {
res += k/power;
power *= p;
}
return res;
}
So with this we obtain the p factors for both n! and q!, so it is trivial to obtain the p factors of q!^r (just multiply by r).
In the strict inequality case, we are done. If not, we have to compute the modulo of both numerator and denominator "dropping" all the p factors. This can also be efficiently solved. We can write k! like this:
k! = 1 x 2 x 3 x ... x p x (p + 1) x (p + 2) ... x (p^2) x ...
If we remove the p factors and apply modulo, we have the following:
k! = 1 x 2 x 3 x ... x (nothing here, just a 1) x 1 x 2 ... x (another 1) x ...
Therefore, the same product keeps repeating until the end. So calculate 1 x 2 x ... x (p - 1) modulo p, raise it to the proper power modulo p (using fast exponentiation) and just multiply it be the "reamaining" terms, as in general k is not divisible by p.
I want to calculate nCr modulo 142857. Following is my code in Java:
private static int nCr2(int n, int r) {
if (n == r || r == 0) {
return 1;
}
double l = 1;
if (n - r < r) {
r = n - r;
}
for (int i = 0; i < r; i++) {
l *= (n - i);
l /= (i + 1);
}
return (int) (l % 142857);
}
This gives nCr in O(r) time. I want an algorithm to get the result in less time than this. Is there such an algorithm?
You can precompute results for given n and r pairs and hard-code them in the table int t[][].
Later, during run-time, when you need nCr(n, r), you just make a look-up to this table: t[n][r].
This is O(1) during run-time.
As your number is no prime, this answer doesn't apply. But you could easily decompose 142857 into primes, compute the corresponding moduli, and use the Chinese Remainder Theorem to get your result. This may or may not make sense for numbers you're working with.
In any case you must avoid double, unless you can be sure that all your intermediate results can be represented exactly with only 53 bits (otherwise you lose precision and get a non-sense out).
You already have most of the answer in the function that you mention. If n is fixed and r is variable, you can use nCr = nC(r-1) * (n - r + 1) / r. So you can use a table for nCr and build it incrementally (unlike what the other answer mentions where precomputation is not incremental).
So your new function can be made recursive with a table being passed.