I'm wondering about the NP-completeness of a variation of the Subset-sub problem:
Subset-sum problem:
Given a set of integers and an integer s, does any non-empty subset sum to s?
This problem is known to be in NP and be NP-complete. Now consider the variation:
Subset-sum problem (congruence variation):
Given two integers s and m and a set of integers modulo m, does any non-empty subset sum to s mod m?
(i.e., all the numbers in the set are modulo m and the expected sum s is also in mod m).
I'm wondering if this problem has been studied before? (Would like to know if it is NP-complete or not). Does anyone know if there is any paper or similar variation of the Subset-sum problem? Thank you!
Yes, this problem is also NP-complete. Since normal subset sum is NP complete, there is a reduction of some other NP-complete problem to subset sum.
The same reduction will also work to prove that modular subset sum is NP complete, if you can additionally generate a sufficiently large modulus with a size that is polynomial in the input size. The modulus just has to be bigger than the largest number used in the subset sum solution, and then the difference between subset sum and modular subset sum is irrelevant.
For any reduction I can think of, it is easy to generate such a modulus. Remember that it is only the size of the modulus that has to be polynomial in the input size, so, say 100^(N^2) works fine -- it's only 2*(N^2) digits long.
Related
I have learned that the Partition problem is included in the NP-Hard problem. I have done some searching about this Problem and seem to not find the reason why is for a certain problem it cannot be concluded that P = NP for a certain algorithm.
If Partition problem can be solved in time 𝑂 (𝑛𝑀) where 𝑛 is the number of elements in the set, and 𝑀 is the sum of the absolute values of the elements in the set. Why based on these, it cannot be concluded that P = NP?
The definition of P and NP states that an algorithm (non-deterministic in case of NP) exists that runs in a polynomial time. The trick is that the argument of the polynomial is the size of the problem, which is defined as the number of bits that encode the problem instance.
The trick with the Partition problem is that numbers are exponential in terms of bits encoding them, so 𝑂(𝑛𝑀) is actually exponential in terms of the size of the encoding.
The class of NP-complete problems where a deterministic polynomial time algorithm exists where the argument of the polynomial is the sum of numbers that define the problem is called weakly NP-complete. Partition, backpack and similar are in this class.
Related Wikipedia entry: https://en.wikipedia.org/wiki/Weak_NP-completeness
Because M is the sum of the absolute values of the elements. It's not polynomial to n, and thus it is not a polynomial time algorithm. Same idea with the dynamic programming solution for the knapsack problem.
I have to find the maximum number which is less than or equal to SQUARE_ROOT(N) and divides N.
Most direct solution is of O(SQUARE_ROOT(N)) , is there any O(logN) solution since number can be vary large in the range of 10^18.
If N equals to p*q, where p and q are prime numbers, you should find this primes first to answer your question. So this problem in general is not easier than Integer factorization. And there is no known algorithm with O(logN) complexity.
No algorithm has been published that can factor all integers in polynomial time, i.e., that can factor b-bit numbers in time O(b^k) for some constant k. Neither the existence nor non-existence of such algorithms has been proved, but it is generally suspected that they do not exist and hence that the problem is not in class P. The problem is clearly in class NP but has not been proved to be or not be NP-complete. It is generally suspected not to be NP-complete.
May be you could find something useful among different factorization algorithms.
If N is composite, then
N = MaximumDivisor(N) * MinimumDivisor(N).
I'm learning dynamic programming and I've been having a great deal of trouble understanding more complex problems. When given a problem, I've been taught to find a recursive algorithm, memoize the recursive algorithm and then create an iterative, bottom-up version. At almost every step I have an issue. In terms of the recursive algorithm, I write different different ways to do recursive algorithms, but only one is often optimal for use in dynamic programming and I can't distinguish what aspects of a recursive algorithm make memoization easier. In terms of memoization, I don't understand which values to use for indices. For conversion to a bottom-up version, I can't figure out which order to fill the array/double array.
This is what I understand:
- it should be possible to split the main problem to subproblems
In terms of the problem mentioned, I've come up with a recursive algorithm that has these important lines of code:
int optionOne = values[i] + find(values, i+1, limit - values[i]);
int optionTwo = find(values, i+1, limit);
If I'm unclear or this is not the correct qa site, let me know.
Edit:
Example: Given array x: [4,5,6,9,11] and max value m: 20
Maximum subsequence in x under or equal to m would be [4,5,11] as 4+5+11 = 20
I think this problem is NP-hard, meaning that unless P = NP there isn't a polynomial-time algorithm for solving the problem.
There's a simple reduction from the subset-sum problem to this problem. In subset-sum, you're given a set of n numbers and a target number k and want to determine whether there's a subset of those numbers that adds up to exactly k. You can solve subset-sum with a solver for your problem as follows: create an array of the numbers in the set and find the largest subsequence whose sum is less than or equal to k. If that adds up to exactly k, the set has a subset that adds up to k. Otherwise, it does not.
This reduction takes polynomial time, so because subset-sum is NP-hard, your problem is NP-hard as well. Therefore, I doubt there's a polynomial-time algorithm.
That said - there is a pseudopolynomial-time algorithm for subset-sum, which is described on Wikipedia. This algorithm uses DP in two variables and isn't strictly polynomial time, but it will probably work in your case.
Hope this helps!
Suppose I have a finite set of numeric values of size n.
Question: Is there an efficient algorithm for enumerating the k-combinations of that set so that combination I precedes combination J iff the sum of the elements in I is less than or equal to the sum of the elements in J?
Clearly it's possible to simply enumerate the combinations and sort them according to their sums. If the set is large, however, brute enumeration of all combinations, let alone sorting, will be infeasible. If I'm only interested in obtaining the first m << choose(n,k) combinations ranked by sum, is it possible to obtain them before the heat death of the universe?
There is no polynomial algorithm for enumerating the set this way (unless P=NP).
If there was such an algorithm (let it be A), then we could solve the subset sum problem polynomially:
run A
Do a binary search to find the subset that sums closest to the desired number.
Note that step 1 runs polynomially (assumption) and step 2 runs in O(log(2^n)) = O(n).
Conclusion: Since the Subset Sum problem is NP-Complete, solving this problem efficiently will prove P=NP - thus there is no known polynomial solution to the problem.
Edit: Even though the problem is NP-Hard, getting the "smallest" m subsets can be done on O(n+2^m) by selecting the smallest m elements, generating all the subsets from these m elements - and choosing the minimal m of those. So for fairly small values of m - it might be feasible to calculate it.
Quoted from wikipedia, the P vs NP problem, regarding the time complexity of algorithms "... asks whether every problem whose solution can be quickly verified by a computer can also be quickly solved by a computer."
I am hoping that somebody can clarify what the difference between "verifying the problem" and "solving the problem" is here.
I am hoping that somebody can clarify what the difference between "verifying the problem" and "solving the problem" is here.
It's not "verifying the problem", but "verifying the solution". For example you can check in polynomial time whether a given set is valid for SAT. The actual generation of such set is NP hard. The section Verifier-based definition in the Wikipedia article NP (complexity) could help you a little bit:
Verifier-based definition
In order to explain the verifier-based definition of NP, let us consider the subset sum problem: Assume that we are given some integers, such as {−7, −3, −2, 5, 8}, and we wish to know whether some of these integers sum up to zero. In this example, the answer is "yes", since the subset of integers {−3, −2, 5} corresponds to the sum (−3) + (−2) + 5 = 0. The task of deciding whether such a subset with sum zero exists is called the subset sum problem.
As the number of integers that we feed into the algorithm becomes larger, the number of subsets grows exponentially, and in fact the subset sum problem is NP-complete. However, notice that, if we are given a particular subset (often called a certificate), we can easily check or verify whether the subset sum is zero, by just summing up the integers of the subset. So if the sum is indeed zero, that particular subset is the proof or witness for the fact that the answer is "yes". An algorithm that verifies whether a given subset has sum zero is called verifier. A problem is said to be in NP if and only if there exists a verifier for the problem that executes in polynomial time. In case of the subset sum problem, the verifier needs only polynomial time, for which reason the subset sum problem is in NP.
If you're more into graph theory the Hamilton cycle is a NP-complete problem. It's trivial to check whether a given solution is a Hamilton cycle (linear complexity, traverse the solution path), but if P != NP than there exists no algorithm with polynomial runtime which solves the problem.
Maybe the term "quick" is misleading in this context. An algorithm is quick in this regard if and only if it's worst-case runtime is bounded by a polynomial function, such as O(n) or O(n log n). The creation of all permutations for a given range with the length n is not bounded, as you have n! different permutations. This means that the problem could be solved in n 100 log n, which will take a very long time, but this is still considered fast. On the other hand, one of the first algorithms for TSP was O(n!) and another one was O(n2 2n). And compared to polynomial functions these things grow really, really fast.
The RSA encryption uses prime numbers like following: two big prime numbers P and Q (200-400 digits each) are multiplied to form the public key N. N=P*Q
To break the encryption one needs to figure out P and Q given the N.
While finding P and Q is very difficult and can take years, verifing the solution is just about multiplying P by Q and comparing with N.
So solving the problem is very hard while it takes nothing to verifying the solution.
P.S. The example is only part of the RSA simplified for this question. The real RSA is much more complex.