Three-bit majority decision tree

ID: three-bit-majority-decision-tree

Three votes give a small but revealing majority function:
Our decision tree queries , then . If these bits agree, return their common value: two equal votes already force the majority function. If they disagree, query and return its value. The first two queries have a fixed order, but whether a third query occurs is adaptive.
Figure 1.
An exact three-bit majority decision tree: equal first answers stop after two queries
. Details.
Each internal label in the diagram names the next bit to inspect. Each leaf lists its output, decision-tree query cost , and compatible inputs; an asterisk denotes an unread bit. The two shallow leaves each cover two inputs, while each deeper leaf covers one. Reading every bit would also compute the majority function, but would miss these exact shortcuts.
All eight inputs give the following exhaustive check. The parity column is the parity of , computed by exclusive or; its decision-tree query cost is justified under parity lower bound for Boolean queries.
Majority function outputQueried coordinates for the majority functionMajority function query countParity outputParity query count00002030010213010031301113031000313101130311012031111213
The worst inputs for this decision tree are , exactly those with . Its actual depth is three. Every exact decision tree for this majority function has depth at least three: after the first query, an adversary can answer the second distinct query with the opposite bit, leaving the last bit decisive. Consequently its optimal decision-tree depth is , even though some inputs finish sooner. Every input has a two-bit query certificate, namely two agreeing votes; locating those votes can require a third query. This separates having a short query certificate from finding one.

New to topics? Read the docs here!