1

I'm studying about the NP class and one of the slides mentions:

It seems that verifying that something is not present is more difficult than verifying that it is present.
       ______                  _________
Hence, CLIQUE (complement) and SubsetSUM (complement) are not obviously members of NP.

Was it ever proved, whether the complement of CLIQUE is an element of NP?

Also, do you have the proof?

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
Kevin Van Ryckegem
  • 1,915
  • 3
  • 28
  • 55

2 Answers2

2

This is an open problem, actually! The complexity class co-NP consists of the complements of all problems in NP. It's unknown whether NP = co-NP right now, and many people suspect the answer is no.

Just as CLIQUE is NP-complete, the complement of CLIQUE is co-NP-complete. (More generally, the complement of any NP-complete problem is co-NP-complete). There's a theorem that if any co-NP-complete problem is in NP, then co-NP = NP,which would be a huge theoretical breakthrough.

If you're interested in learning more about this, check out the Wikipedia article on co-NP and look around online for more resources.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
  • Oh and just wondering, for the complement of CLIQUE, can't you just make a verifier for it using the verifier of CLIQUE? If the verifier of CLIQUE rejects, then the verifier of the complement of CLIQUE accepts => complement of CLIQUE has a verifier and so it is in the class of NP, so co-NP = NP. (I guess this is wrong?) – Kevin Van Ryckegem Jan 16 '16 at 00:55
  • 1
    It's a reasonable guess, but you're right, it doesn't work. :-) Suppose that your verifier accepts as its certificate a set of nodes that allegedly form the clique. Now, suppose you give the verifier the wrong set of nodes in a graph that does indeed contain a large clique. The verifier will say "no," meaning "that certificate doesn't work." But then the "complement" verifier you constructed would say "yes" even though a large clique exists. – templatetypedef Jan 16 '16 at 00:58
  • I'm not completely following: why will the verifier of CLIQUE say no if the set of nodes is a clique? – Kevin Van Ryckegem Jan 16 '16 at 01:04
  • 1
    @KevinVanRyckegem Imagine that you give the verifier a set of nodes that isn't a clique even though the graph does contain a set of nodes that do form a clique. – templatetypedef Jan 16 '16 at 01:05
  • Hmm, but the verifier would verify whether the certificate contains a set of nodes that form a clique in the given graph (that's how I see it). In case you want to verify whether a graph contains a clique, then I believe you need to use the alternative(which I saw in the slides): an NTM in order to find all possible sets of nodes and try them all as certificate. Given that the certificate is what we want to test and the graph is of correct syntax, I don't see where this verifier of the complement of clique would fail. Thanks for answering! :) – Kevin Van Ryckegem Jan 16 '16 at 01:10
  • 1
    You're confusing two different definitions of NP. You can define NP in terms of NTMs, or you can define it in terms of languages where elements in the language have certificates checkable in polynomial time. In the latter case the verifier isn't an NTM, it's a plain old TM. – Captain Segfault Jan 16 '16 at 01:45
1

The general intuition here: it's easy to prove a graph contains an N-clique: just show me the clique. It's hard to prove a graph that doesn't have an N-clique in fact doesn't have an N-clique. What property of the graph are you going to exploit to do that?

Sure, for some families of graphs you can -- for example, graphs with sufficiently few edges can't possibly have such a clique. It's entirely possible that all graphs can have similar proofs built around them, although it'd be surprising -- almost as surprising as P=NP.

This is why the complement of languages in NP are not, in general, obviously in NP -- in fact, we have the term "co-NP" (as in "the complement is in NP") to refer to languages like !CLIQUE.

One common approach to make progress in complexity theory, where we haven't made progress against the hard questions, is to show that some specific hard-to-prove result would imply something surprising. Showing that NP=co-NP is a common target of these proofs -- for example, any hard problem in both NP and co-NP probably isn't complete for either, because if it were it is complete for both and thus both are equal, so somehow you have those crazy general graph proofs.

This even generalizes -- you can start talking about what happens if your NTMs (or certificate checkers) have an oracle for an NP complete language like CLIQUE. Obviously both CLIQUE and !CLIQUE is in P^CLIQUE, but now there are (probably) new languages in NP^CLIQUE and co-NP^CLIQUE, and you can keep going further until you have an entire hierarchy of complexity classes -- the "polynomial hierarchy". This hierarchy intuitively goes on forever, but may well collapse at some point or even not exist at all (if P=NP).

The polynomial hierarchy makes this general argument technique more powerful -- showing that some result would make the polynomial hierarchy collapse to the 2nd or 3rd level would make that result pretty surprising. Even showing it collapses at all would be somewhat surprising.

Captain Segfault
  • 1,686
  • 8
  • 11