Property testing

Template:Short description Property testing is a field of theoretical computer science, concerned with the design of super-fast algorithms for approximate decision making, where the decision refers to properties or parameters of huge objects.Template:R

A property testing algorithm for a decision problem is an algorithm whose query complexity (the number of queries made to its input) is much smaller than the instance size of the problem. Typically, property testing algorithms are used to determine whether some combinatorial structure Template:Mvar (such as a graph or a boolean function) satisfies some property Template:Mvar, or is "far" from having this property (meaning that an Template:Mvar-fraction of the representation of Template:Mvar must be modified to make Template:Mvar satisfy Template:Mvar), using only a small number of "local" queries to the object. Template:RTemplate:R

For example, the following promise problem admits an algorithm whose query complexity is independent of the instance size (for an arbitrary constant ε > 0):

"Given a graph on Template:Mvar vertices, decide whether it is bipartite, or cannot be made bipartite even after removing an arbitrary subset of at most εn² edges."

Property testing algorithms are central to the definition of probabilistically checkable proofs, as a probabilistically checkable proof is essentially a proof that can be verified by a property testing algorithm.

Definition and variants

Formally, a property testing algorithm with query complexity q(n) and proximity parameter Template:Mvar for a decision problem Template:Mvar is a randomized algorithm that, on input Template:Mvar (an instance of Template:Mvar) makes at most q(Template:Abs) queries to Template:Mvar and behaves as follows:

• If Template:Mvar is in Template:Mvar, then the algorithm accepts Template:Mvar with probability at least 2/3.
• If Template:Mvar is Template:Mvar-far from Template:Mvar, then the algorithm rejects Template:Mvar with probability at least 2/3.

Here, "Template:Mvar is ε-far from Template:Mvar" means that the Hamming distance between Template:Mvar and any string in Template:Mvar is at least ε Template:Abs.

A property testing algorithm is said to have one-sided error if it satisfies the stronger condition that the accepting probability for instances x ∈ L is 1 instead of 2/3.

A property testing algorithm is said be non-adaptive if it performs all its queries before it "observes" any answers to previous queries. Such an algorithm can be viewed as operating in the following manner. First the algorithm receives its input. Before looking at the input, using its internal randomness, the algorithm decides which symbols of the input are to be queried. Next, the algorithm observes these symbols. Finally, without making any additional queries (but possibly using its randomness), the algorithm decides whether to accept or reject the input. Template:R

Features and limitations

The main efficiency parameter of a property testing algorithm is its query complexity, which is the maximum number of input symbols inspected over all inputs of a given length (and all random choices made by the algorithm). Computer scientists are interested in designing algorithms whose query complexity is as small as possible. In many cases, the running time of property testing algorithms is sublinear in the instance length. Typically, the goal is first to make the query complexity as small as possible as a function of the instance size Template:Mvar, and then study the dependency on the proximity parameter Template:Mvar.

Unlike other complexity-theoretic settings, the asymptotic query complexity of property testing algorithms is affected dramatically by the representation of instances. For example, when ε = 0.01, the problem of testing bipartiteness of dense graphs (which are represented by their adjacency matrix) admits an algorithm of constant query complexity. In contrast, sparse graphs on Template:Mvar vertices (which are represented by their adjacency list) require property testing algorithms of query complexity Ω(n^1/2).

The query complexity of property testing algorithms grows as the proximity parameter Template:Mvar becomes smaller for all non-trivial properties. This dependence on Template:Mvar is necessary, as a change of fewer than Template:Mvar symbols in the input cannot be detected with constant probability using fewer than O(1/ε) queries. Many interesting properties of dense graphs can be tested using query complexity that depends only on Template:Mvar and not on the graph size Template:Mvar. However, the query complexity can grow enormously fast as a function of Template:Mvar. For example, for a long time, the best known algorithm for testing whether a graph does not contain any triangle had a query complexity which is a tower function of poly(1/ε), and only in 2010 was this improved to a tower function of log(1/ε). One of the reasons for this enormous growth in bounds is that many of the positive results for property testing of graphs are established using the Szemerédi regularity lemma, which also has tower-type bounds in its conclusions. The connection of property testing to the Szemerédi regularity lemma and related graph removal lemmas is elaborated on below.

Testing graph properties

For a graph Template:Mvar with Template:Mvar vertices, the notion of distance we will use is the edit distance. That is, we say that the distance between two graphs is the smallest Template:Mvar such that one can add and/or delete εn² edges and get from the first graph to the second. Under a reasonable representation of graphs, this is equivalent to the earlier Hamming distance definition (up to possibly a change of constants).

To make precise the general notions of property testing in the context of graphs, we say a tester for graph property Template:Mvar should distinguish with at least two-thirds probability between the cases of Template:Mvar satisfying Template:Mvar and the cases where Template:Mvar is Template:Mvar-far in edit distance from satisfying Template:Mvar. The tester can access some oracle to query whether a pair of vertices has an edge between them in Template:Mvar or not. The query complexity is the number of such oracle queries. Say the tester has one-sided error if it has false positives and not false negatives, i.e. if Template:Mvar satisfies Template:Mvar, the tester always outputs the correct answer. Template:RTemplate:R

We can only differentiate between graphs that satisfy Template:Mvar versus those far from Template:Mvar, as opposed to satisfying versus not satisfying Template:Mvar. In the latter case, consider two graphs: Template:Mvar satisfying Template:Mvar and Template:Mvar not satisfying Template:Mvar by changing only a few edges. One example is testing triangle-freeness with Template:Mvar a graph with exactly one triangle and Template:Mvar having one of these edges removed. Then, the tester cannot tell them apart unless it queries every edge, which it cannot do.

Short history

The field of graph property testing was first introduced by Goldreich, Goldwasser, and Ron. In their seminal paper published in 1998, an abstract graph partition problem is analyzed and some testers provided. These include as special cases several important graph properties like bipartiteness, k-colorability, having a large clique, and having a large cut. Template:R In particular, the natural algorithms that sample a subgraph and check whether it satisfy the property are all correct, albeit with perhaps-suboptimal query complexities.

Since then, several related discoveries have been made

• In 1992, Alon, Duke, Lefmann, Rödl, and Yuster showed that for every graph Template:Mvar, the property of not containing Template:Mvar as a subgraph is testable. Template:R
• In 1999, Alon, Fischer, Krivelevich, and Szegedy showed that for every graph Template:Mvar, the property of not containing Template:Mvar as an induced subgraph subgraph is testable. Template:R
• In 2005, Alon and Shapira showed that any monotone graph property (one that is preserved under vertex and edge deletion) is testable with one-sided error. Template:R
• In 2008, Alon and Shapira exhibited testers with one-sided error for all hereditary graph properties. They also characterized properties that are easy to test. Namely, these natural properties are semi-hereditary. These statements will be clarified below. Template:R

Testing hereditary graph properties

A graph property is hereditary if it is preserved under deletion of vertices, or equivalently, if it is preserved under taking induced subgraphs. A few important hereditary properties are [[glossary of graph theory terms|Template:Mvar-freeness]] (for some graph Template:Mvar), [[graph coloring|Template:Mvar-colorability]], and planarity. All hereditary properties are testable.

Theorem (Alon & Shapira 2008). Every hereditary graph property is testable with one-sided error. Template:R

The proof relies on a version of the graph removal lemma for infinite families of induced subgraphs. The query complexity using this regularity approach is large due to the tower function bound in the Szemerédi regularity lemma.

Theorem (Infinite graph removal lemma). For each (possibly infinite) set of graphs Template:Mathcal and ε > 0, there exist h₀ and δ > 0 so that, if Template:Mvar is an Template:Mvar-vertex graph with fewer than δn^v(H) copies of Template:Mvar for every H ∈ Template:Mathcal with at most h₀ vertices, then Template:Mvar can be made induced Template:Mathcal-free by adding/removing fewer than εn² edges. Template:R

Oblivious testers

Informally, an oblivious tester is oblivious to the size of the input. For a graph property Template:Mvar, it is an algorithm that takes as input a parameter Template:Mvar and graph Template:Mvar, and then runs as a property testing algorithm on Template:Mvar for the property Template:Mvar with proximity parameter Template:Mvar that makes exactly q(ε) queries to Template:Mvar.

Definition. An oblivious tester is an algorithm that takes as input a parameter Template:Mvar. It computes an integer q(ε) and then asks an oracle for an induced subgraph Template:Mvar on exactly q(ε) vertices from Template:Mvar chosen uniformly at random. It then accepts or rejects (possibly randomly) according to Template:Mvar and Template:Mvar. We say it tests for the property Template:Mvar if it accepts with probability at least 2/3 for Template:Mvar that has property Template:Mvar, and rejects with probability at least 2/3 or Template:Mvar that is Template:Mvar-far from having property Template:Mvar. Template:RTemplate:RTemplate:R

Crucially, the number of queries an oblivious tester makes is a constant dependent only on Template:Mvar and not the size of the input graph Template:Mvar. In complete analogy with property testing algorithms, we can talk about oblivious testers with one-sided error.

Testing semi-hereditary graph properties

We can contrive some graph properties for which a tester must access the number of vertices.

Example. A graph Template:Mvar satisfies property Template:Mvar if it is bipartite with an even number of vertices or perfect with an odd number of vertices.Template:R

In this case, the tester cannot even differentiate which property (bipartiteness or perfectness) to test unless it knows the number of vertices. There are many examples of such unnatural properties. In fact, the characterization of graph properties testable by an oblivious tester with one-sided error leads to a class of natural properties.

Definition. A graph property Template:Mvar is semi-hereditary if there exists a hereditary graph property Template:Mvar such that any graph satisfying Template:Mvar satisfies Template:Mvar, and for every ε > 0, there is an M(ε) such that every graph of size at least M(ε) that is Template:Mvar-far from satisfying Template:Mvar contains an induced subgraph that does not satisfy Template:Mvar. Template:R

Trivially, hereditary properties are also semi-hereditary. This characterization partially answers the converse to the other Alon & Shapira theorem above: the properties that are easy to test properties (having oblivious testers with one-sided error) are almost hereditary. In the same paper, they showed that

Theorem (Alon & Shapira 2008). A graph property Template:Mvar has an oblivious one-sided error tester if and only if Template:Mvar is semi-hereditary. Template:R

Examples: testing some graph properties

In this section, we will give some natural oblivious testing algorithms with one-sided error for triangle-freeness, bipartiteness, and [[Graph coloring|Template:Mvar-colorability]]. They are natural in the sense that we follow the natural idea of randomly sampling some subset Template:Mvar of vertices of Template:Mvar and checking whether the graph property holds on the subgraph spanned by Template:Mvar by brute-force search. We have one-sided error since these properties are actually hereditary: if Template:Mvar satisfy the property, so must the induced subgraph spanned by Template:Mvar, so our tester always accepts.

For triangle-freeness, the tester is an application of the triangle removal lemma. In particular, it tells us that if graph Template:Mvar is Template:Mvar-far from being triangle-free, then there is a (computable) constant δ = δ(ε) so that Template:Mvar has at least δn³ triangles.

Example (Triangle-freeness Testing Algorithm).

1. Given graph Template:Mvar, choose a random set Template:Mvar of q(ε) = 1/δ triples of vertices independently at random, where Template:Mvar is as above.
2. For every triple of vertices in Template:Mvar, query whether all three pairs of vertices are adjacent in Template:Mvar.
3. The algorithm accepts if no triple of vertices induces a triangle, and rejects otherwise. Template:R

For bipartiteness and [[Graph coloring|Template:Mvar-colorability]], let Template:Mvar be the desired upper bound on error probability for the following testers. Note that query complexity should not be confused with running time. The latter is often exponential (as is the case of both) due to a lack of polynomial time decision algorithm to test the property on the induced subgraph. We instead check by brute-force search. Template:R

Example (Bipartite Testing Algorithm).

1. Given graph Template:Mvar, choose a random set Template:Mvar of q(ε) = O(log(1/(εδ))/ε²) vertices.
2. For every pair of vertices in Template:Mvar, query whether they are adjacent in Template:Mvar.
3. It accepts if the induced subgraph of Template:Mvar on Template:Mvar is bipartite and rejects otherwise. Template:R

Example (k-colorability Testing Algorithm).

1. Given graph Template:Mvar, choose a random set Template:Mvar of q(ε) = O(k⁴ log²(k/δ)/ε³) vertices.
2. For every pair of vertices in Template:Mvar, query if they are adjacent in Template:Mvar.
3. It accepts if the induced subgraph of Template:Mvar on Template:Mvar is k-colorable and rejects otherwise. Template:R