12.7. Reduction Between Problems

To get into this discussion, let us talk about the problem between, the difference between generating a solution and checking a solution. So, supposing a school Math’s teacher assigns the following homework, take a large number which is known to be the product of two prime numbers and find these two prime numbers. From the student point of view obviously, the problems is to generate the solution. So, given the large number N, the student is expected to find two prime numbers p and q, such that p times q is equal to N. Now, the student submits or the students submit their solutions to teacher for evaluation. So, the teacher is in much better respective, the teacher does not have to keep generating p and q, the teacher has does not even need to know the answer. The teacher can just take the answer given by the student, multiply p times q and determine whether p times q is equal to N or not. Even without knowing the answer or even if the answer is wrong, the teacher may not know the right answer, the teacher can decide whether or not the student as given the correct answer.

In this section, we discuss the distinction between generating solutions and checking solutions. Generating a solution involves figuring out an answer to a problem, like a student finding two prime numbers that multiply to a given number. In contrast, checking a solution is validating whether a proposed solution is correct. For example, teachers don't need to know the prime numbers themselves; they just need to verify if the student's answer is correct by multiplying the proposed numbers and checking if they equal the given large number.

Think of a chef baking a cake. The chef must create the recipe (generate the solution), but a judge at a cooking competition just needs to taste the cake and give feedback (check the solution) without knowing the exact recipe.

So, this gives us some notion of a checking algorithm. So, if you have a problem, I can say that I have a checking algorithm, if for every instance I can take a solution to that instance and quickly verify whether or not that solution is actually a valid one. So, checking algorithm takes an input for the problem, a solution which is maybe not just the solution, but solution plus some extra information, and then it determine whether or not, this is a valid solution.

A checking algorithm is defined as a method that can quickly verify if a proposed solution to a problem is valid. It takes both the problem instance and the solution candidate as inputs and checks if the solution corresponds correctly to the problem requirements. This means that even if one doesn't have the complete answer, the validity of a proposed answer can be confirmed without difficulty.

Imagine a bank teller who verifies checks. The teller doesn't need to know who the check's author is or the account details; they only need to confirm if the check is valid based on the information present. This mirrors how checking algorithms work—they verify without needing to generate the solution themselves.

So, in this context, let us look at a very canonical problem which has a checking algorithm called Boolean satisfiability. So, we have some Boolean variables x, y and z. So, Boolean variables can take values, true or false and we have a standard operations on Boolean variables, negation takes a value of true and transit false and vise verses. So, we write that with this exclamation mark using some programming language terminologies, so not x it is used an exclamation mark x.

The Boolean satisfiability problem is a classic example of a problem with a checking algorithm. It involves several Boolean variables that can either be true or false, along with standard logical operations such as negation, conjunction, and disjunction. The essence of this problem lies in determining whether a particular Boolean formula can be satisfied by assigning true or false values to the variables. The checking algorithm can quickly verify if a given assignment of truth values satisfies the formula without generating all possible combinations.

Consider a light switch in a room with various other switches controlling different lights. You don't need to go through each combination of switches each time; instead, you can check whether the current arrangement successfully lights up the room, similar to how checking algorithms validate Boolean expressions.

So, when we introduce reducibility in the contest of linear programming and network floors we said that one aim is to transfer efficient solution from B to A. So, when I reduce A to B, if B is an efficient, then A is efficient. But in this contest, what we are trying to say is that this is not known to be an efficient, then this also is not known to be efficient.

In computational theory, reduction is the process of transforming one problem into another. By reducing problem A to problem B, if B can be solved efficiently, then A can also be solved efficiently. However, if B is not known to be efficiently solvable, this casts doubt on the efficiency of A as well. This concept helps classify problems in terms of their computational difficulty and relates various problem classes to one another.

Think of this like a branch of a library. If the branch is well-organized, you can find books efficiently. However, if you had to send books to another branch that is messy, you may not find books quickly there either. Similarly, the efficiency of solving problem A depends on how efficiently problem B can be solved.

--